Contrat de prestation informatique en Tunisie : cadrer avant le litige

Qu'est ce qui doit figurer dans un contrat de prestation informatique ?

Le périmètre des livrables, le calendrier, les modalités de réception, le prix et son échelonnement, la titularité des droits, le sort des accès et des données, la maintenance et les conditions de fin de relation.

Un contrat informatique n'a pas besoin d'être long, il a besoin d'être précis sur peu de points. Nos équipes voient passer des documents de plusieurs pages entièrement consacrés à des généralités, qui ne disent rien du périmètre réel, ni de la manière dont la livraison sera validée. Ce sont pourtant ces deux questions qui alimentent la quasi totalité des litiges portés devant un juge.

La deuxième source de difficulté est la titularité. Un client qui a financé un développement suppose naturellement qu'il en dispose librement. Un prestataire qui a mobilisé des composants qu'il réutilise d'un projet à l'autre suppose l'inverse. Les deux positions se défendent, et seule une clause claire évite qu'elles ne se découvrent au moment de la séparation, lorsque le dialogue est déjà rompu.

La troisième concerne la sortie. Un contrat qui organise la fin de la relation, même dans une relation de confiance, protège les deux parties : remise des sources, transfert des accès, documentation minimale, restitution puis effacement des données. Ce volet coûte quelques lignes à la signature et représente souvent l'essentiel de la valeur du contrat lorsqu'un projet doit être repris par un autre intervenant.

Comment définir le périmètre pour éviter le litige sur les livrables ?

En décrivant les fonctions attendues avant de discuter le prix, et en énonçant aussi ce qui est exclu. Le périmètre s'écrit par le client, se relit par le prestataire, puis s'annexe au contrat signé.

Un devis rédigé sans document de besoin repose sur une compréhension implicite. Le prestataire chiffre ce qu'il a compris, le client lit ce qu'il espérait, et l'écart apparaît à la livraison. Écrire le besoin avant de demander un prix change entièrement la relation : les questions se posent au début, quand elles ne coûtent rien, plutôt qu'à la fin, quand chacun campe sur sa lecture.

L'exclusion est aussi utile que l'inclusion. Préciser que la rédaction des contenus, la reprise d'anciennes données, la traduction, le référencement ou la formation des utilisateurs ne font pas partie de la prestation évite des mois de discussion. Un contrat qui ne dit rien de ces postes conduit chaque partie à considérer, de bonne foi, qu'ils relèvent de l'autre.

Reste la question des évolutions, inévitables dans tout projet. Le contrat doit prévoir un mécanisme simple : toute demande nouvelle est formulée par écrit, chiffrée, puis acceptée avant d'être réalisée. Ce formalisme léger évite la situation la plus courante, celle d'un prestataire qui a accepté des demandes successives sans les facturer, puis réclame un complément qu'aucun écrit ne soutient.

À qui appartient le code, le contenu et le nom de domaine ?

Cela dépend de ce que le contrat prévoit. À défaut de clause claire, le client se retrouve fréquemment sans maîtrise du code produit, du nom de domaine ou des comptes d'hébergement ouverts par le prestataire.

Le nom de domaine est le point le plus fréquemment négligé et le plus lourd de conséquences. Enregistré par le prestataire à son propre nom, il devient un moyen de pression immédiat en cas de désaccord, puisqu'il conditionne l'existence même du service. Nos équipes recommandent invariablement que le domaine et l'hébergement soient ouverts au nom du client, celui ci confiant simplement la gestion technique au prestataire.

Le code produit soulève une question distincte. Une prestation peut être conçue comme la livraison d'un développement dont le client dispose librement, ou comme la mise à disposition d'un outil que le prestataire réutilise ailleurs. Les deux modèles sont légitimes et n'ont pas le même prix. Le litige naît lorsque le contrat n'a pas tranché et que chaque partie a payé, ou facturé, selon un modèle différent.

Les contenus fournis par le client demeurent les siens, mais leur restitution en fin de relation mérite d'être organisée : textes, photographies, fichiers sources, données saisies dans l'outil. La clause utile prévoit une remise dans un format exploitable, et non un simple accès temporaire à une interface. Sans cette précision, la reprise du projet suppose de tout reconstituer manuellement.

Comment organiser la recette et la réception des livrables ?

Par une procédure écrite qui désigne qui vérifie, sur quels critères, dans quel délai, et ce qui se passe en cas de réserves. La réception marque le point de départ des garanties et l'exigibilité du solde.

Sans procédure de réception, la fin du projet n'existe pas. Le prestataire estime avoir livré, le client continue de signaler des anomalies, le solde reste impayé et la relation s'épuise dans des échanges sans issue. Une clause de réception, même simple, met fin à cette indétermination : elle dit à quel moment la prestation est réputée conforme et à partir de quand une intervention devient une demande nouvelle.

Les critères doivent être vérifiables. Un livrable réputé conforme lorsqu'il fonctionne correctement ne dit rien d'utile. Une liste de fonctions à tester, chacune décrite dans le cahier des charges, permet en revanche de constater objectivement ce qui marche et ce qui manque. Cette liste se prépare au démarrage du projet, jamais à la livraison, où elle deviendrait un instrument de négociation.

Le mécanisme des réserves complète la procédure. Le client dispose d'un temps pour signaler par écrit les anomalies constatées, le prestataire d'un temps pour les corriger, et une seconde vérification intervient ensuite. Les réserves formulées se distinguent des demandes nouvelles, distinction que seul un périmètre écrit rend possible. Faute de quoi tout devient réserve pour le client et demande nouvelle pour le prestataire.

Le prestataire est il tenu à une obligation de résultat ?

Cela dépend de la nature de l'engagement souscrit et de ce que le contrat exprime. Un livrable défini avec précision se rapproche d'un engagement de résultat, une mission d'accompagnement suppose surtout des moyens et de la diligence.

La distinction n'est pas académique : elle détermine ce que le client doit démontrer. Lorsque l'engagement porte sur un livrable défini, il suffit d'établir que ce livrable n'a pas été remis ou qu'il ne correspond pas à la description. Lorsque l'engagement porte sur des moyens, il faut démontrer que le prestataire n'a pas fait preuve de la diligence attendue, ce qui est nettement plus délicat.

Le prestataire est par ailleurs tenu d'un devoir de conseil qui pèse d'autant plus qu'il est le professionnel de la matière. Il doit alerter le client lorsqu'une demande est techniquement inadaptée, lorsque le budget annoncé ne permet pas d'atteindre l'objectif exprimé, ou lorsqu'un choix crée une dépendance coûteuse. Le silence conservé sur ces points est régulièrement discuté dans les dossiers que nous traitons.

Le client, de son côté, n'est pas passif. Il doit fournir les contenus, les accès et les validations dans des délais raisonnables, et signaler les anomalies qu'il constate. Un projet immobilisé parce que le client n'a jamais transmis ses textes ne peut pas être reproché au prestataire, et la chronologie écrite des relances devient alors l'élément déterminant du débat.

Que prévoir lorsque le prestataire traite des données personnelles ?

Un encadrement écrit des usages autorisés, des mesures de sécurité, de l'interdiction de sous traitance non annoncée et du sort des données en fin de mission. Le client qui décide de la finalité reste responsable du traitement.

Dès que la prestation donne accès à un fichier clients, à des inscriptions, à des données de commande ou à des messages, la question dépasse le contrat technique. Le client, qui décide de la finalité et des moyens, demeure responsable du traitement, et l'externalisation ne transfère pas cette responsabilité. Une prestation confiée sans aucun écrit sur ce point laisse le client exposé pour des faits qu'il ne maîtrise pas.

Les points à couvrir sont peu nombreux mais précis. Ce que le prestataire peut faire des données et ce qu'il ne peut pas faire, notamment leur usage à des fins propres. Les mesures de sécurité attendues, accès nominatifs et traçabilité comprises. L'interdiction de recourir à un intervenant supplémentaire sans en informer le client. Enfin le sort des données au terme de la mission, restitution puis effacement documenté.

La fin de mission est le moment le plus risqué. Un prestataire évincé qui conserve une copie complète d'une base, un ancien intervenant dont l'accès administrateur n'a jamais été retiré, une sauvegarde restée sur un poste individuel : nos équipes rencontrent ces situations régulièrement. Une clause de restitution et d'effacement, accompagnée d'une confirmation écrite, réduit considérablement cette exposition.

Le projet est bloqué : comment sortir du litige ?

En reconstituant d'abord la chronologie écrite, puis en adressant une mise en demeure qui décrit précisément ce qui manque et fixe un terme. La rupture unilatérale sans cette étape fragilise celui qui la décide.

La première tâche est documentaire. Rassembler le contrat, le cahier des charges, les devis successifs, les validations, les demandes de modification, les factures, les paiements effectués et l'ensemble des échanges. Cette reconstitution révèle presque toujours que la difficulté n'est pas là où les parties la situaient : le litige apparent porte sur la qualité du livrable, le litige réel porte sur un périmètre jamais arrêté.

Vient ensuite la mise en demeure, qui doit être précise pour être utile. Elle rappelle ce qui avait été convenu, énumère ce qui manque fonction par fonction, demande l'exécution sous un terme et annonce la suite en cas d'inertie. Une mise en demeure générale, qui se contente de dénoncer un retard sans détailler les manquements, se heurte à une réponse tout aussi générale.

La rupture mérite d'être préparée plutôt que subie. Avant d'écarter le prestataire, il faut avoir récupéré ce qui est récupérable : accès, sources, sauvegardes, documentation, contenus. Un client qui rompt d'abord et réclame ensuite se retrouve fréquemment sans moyen de faire fonctionner ce qu'il a payé, ce qui affaiblit sa position au moment même où il pensait la renforcer.

Comment conserver la preuve des échanges d'un projet numérique ?

En exportant les messages avec leurs en têtes techniques, en capturant les fils de discussion avec leurs dates, et en confirmant par écrit toute décision prise oralement. Un projet piloté par conversations orales ne laisse aucune preuve.

La particularité des projets numériques est que tout s'y décide par messages courts, dans des fils de discussion que personne n'archive. Deux ans plus tard, l'historique a été purgé, le collaborateur qui échangeait a quitté l'entreprise et le compte de messagerie a été fermé. Il ne reste alors que deux récits contradictoires sur ce qui avait été promis et sur ce qui avait été accepté.

La discipline utile est simple. Les messages électroniques s'exportent dans leur format d'origine, avec leurs en têtes complets, et ne se transfèrent pas. Les fils de discussion se capturent périodiquement, avec les dates visibles et l'identité des participants. Chaque validation d'étape se confirme par un écrit court récapitulant ce qui a été validé, ce qui reste à faire et ce qui a été reporté.

Lorsque le litige est déjà ouvert, la constatation par un huissier notaire peut porter sur l'état d'un service en ligne : pages accessibles, fonctions manquantes, messages d'erreur, contenus présents ou absents. Ce procès verbal fixe l'état du livrable à une date certaine et prive l'adversaire de l'argument tenant à une capture réalisée par la partie qui l'invoque.

Cadrer un projet numérique avant qu'il ne devienne un litige

1. Écrire le besoin avant de demander un devis

   Un document, même bref, qui décrit les fonctions attendues, les pages ou écrans prévus, les utilisateurs concernés et ce qui est expressément exclu. Ce texte devient la référence commune et se joint au contrat. Sans lui, chaque partie projette sur le projet une attente différente.

   Cahier des charges annexé au contrat et signé par les deux parties

2. Vérifier l'identité et la capacité du prestataire

   Dénomination exacte, forme juridique, adresse, identifiant fiscal, personne habilitée à engager la structure. Un projet confié à une simple page commerciale sans entité identifiable rend toute action ultérieure difficile, quel que soit le soin apporté à la rédaction du contrat.

   Pièces d'identification de la structure conservées avec le contrat

3. Faire figurer périmètre, livrables et calendrier dans l'écrit

   Le contrat énumère ce qui est livré, sous quelle forme, à quelle échéance et selon quelles étapes. Il précise aussi ce qui sort du périmètre et le mécanisme applicable à toute demande nouvelle, afin que les évolutions ne se règlent pas au fil de conversations sans trace.

4. Régler les droits, les accès et les comptes dès la signature

   Titularité du code produit, licences des composants utilisés, sort des contenus fournis par le client, propriétaire du nom de domaine, comptes d'hébergement ouverts au nom de qui. Ces points paraissent secondaires au démarrage et deviennent centraux dès que la relation se dégrade.

   Liste écrite des comptes, accès et identifiants, tenue à jour

5. Échelonner le paiement sur des jalons vérifiables

   Chaque versement se rattache à une étape dont l'achèvement peut être constaté objectivement. Un paiement intégral à la commande expose le client, un paiement intégral à la fin expose le prestataire. L'échelonnement protège les deux parties et rend la discussion possible en cours de projet.

6. Documenter chaque validation et chaque demande nouvelle

   Toute validation d'étape, toute demande de modification et tout report se confirment par écrit, même brièvement. Une décision prise lors d'un appel et jamais confirmée disparaît du dossier. Ce réflexe, tenu pendant toute la durée du projet, épargne des mois de discussion ultérieure.

   Au fil du projet, sans attendre la fin Journal écrit des validations, demandes et reports

7. Mettre en demeure avant toute rupture en cas de blocage

   La mise en demeure rappelle ce qui avait été convenu, décrit précisément ce qui manque, demande l'exécution sous un terme et annonce la suite. Rompre sans cette étape expose la partie qui rompt à voir sa propre attitude discutée, quelle que soit la réalité du manquement subi.

   Dès que le retard ou le manquement est caractérisé Mise en demeure envoyée par une voie traçable

Les points dont l'absence produit le plus de litiges

Cas particuliers

Les erreurs qui coûtent cher

Questions fréquentes