Un projet informatique échoue rarement pour une seule raison. Besoin mal exprimé, recette bâclée, réversibilité oubliée : c'est le contrat qui détermine, le jour du litige, qui supporte le risque d'une solution qui ne fonctionne pas.
Exprimer le besoin : le document qui engagera les deux parties
L’essentiel d’un contentieux informatique se joue dans les documents rédigés avant la signature. Cahier des charges, expression des besoins, note de cadrage : ce sont eux qui, des années plus tard, permettront de dire si la solution livrée était ou non conforme.
Deux défauts reviennent constamment. Le premier est l’imprécision : des besoins formulés en termes fonctionnels vagues, sans indicateur mesurable, rendent la non-conformité presque impossible à démontrer. Le second est l’absence d’articulation contractuelle : le cahier des charges existe, mais le contrat ne lui donne aucune valeur, ou une valeur inférieure à celle de la proposition commerciale du prestataire, qui reprend un périmètre plus étroit.
Une clause d’ordre de priorité entre les documents, et l’annexion expresse de l’expression des besoins au contrat, règlent une large part de cette difficulté.
L’obligation de conseil du prestataire et le devoir de collaboration du client
Le professionnel de l’informatique n’exécute pas seulement une commande : il doit éclairer un client qui, par hypothèse, ne maîtrise pas la matière. Cela suppose de vérifier l’adéquation de la solution au besoin exprimé, d’alerter sur les insuffisances ou les contradictions du cahier des charges, de signaler les développements spécifiques que le projet rendra nécessaires et, dans les cas extrêmes, de refuser une commande vouée à l’échec.
Cette obligation de conseil est difficile à écarter par une clause contractuelle. Elle a toutefois une contrepartie : le client doit collaborer, désigner des interlocuteurs compétents et disponibles, fournir les données et les accès attendus, arbitrer dans les délais convenus. Dans la pratique des litiges, les responsabilités sont fréquemment partagées, et le partage dépend de ce que les comptes rendus de comité de pilotage permettent d’établir. Tenir ces comptes rendus, et les contester par écrit lorsqu’ils sont inexacts, relève de la gestion élémentaire du risque.
La recette : le moment où le risque bascule
La recette mérite d’être organisée par une clause détaillée : nature des tests, jeux d’essai, environnement de test, durée de la période de vérification, délai imparti au client pour formuler ses réserves, distinction entre anomalies bloquantes, majeures et mineures, conséquences de chaque catégorie.
Deux mécanismes appellent une attention particulière. La recette tacite, qui répute la solution acceptée à l’expiration d’un délai ou en cas de mise en production, produit des effets considérables : elle doit être acceptée en connaissance de cause. La recette par lots, ensuite, ne doit pas empêcher une vérification d’ensemble : des modules individuellement conformes peuvent former un système qui ne fonctionne pas.
Lorsque la recette échoue, il faut consigner les anomalies de manière circonstanciée et reproductible. Un procès-verbal de recette assorti de réserves précises vaut mieux qu’une acceptation suivie de contestations verbales.
Niveaux de service, disponibilité et pénalités
En mode SaaS, la qualité du service se mesure en exploitation, pas à la livraison. Le contrat de niveaux de service définit le taux de disponibilité, les plages de maintenance exclues du calcul, les délais de prise en compte et de rétablissement selon la gravité de l’incident, les modalités de mesure et l’outil qui fait foi.
Le point sensible est le sort des pénalités. Lorsqu’elles sont stipulées comme seule réparation du manquement, elles peuvent plafonner l’indemnisation à un montant sans rapport avec le préjudice subi. Il faut vérifier leur articulation avec la clause limitative de responsabilité, et réserver expressément les manquements graves ainsi que les hypothèses dans lesquelles la loi interdit toute limitation.
L’engagement sur la sécurité et la localisation des données doit figurer au même endroit, en cohérence avec le contrat de sous-traitance imposé par la réglementation sur les données personnelles, traité dans notre page RGPD et données personnelles.
Réversibilité et sortie du contrat
La réversibilité est la clause que l’on néglige à la signature et que l’on regrette à la rupture. Elle doit prévoir le format de restitution des données, exploitable sans l’outil du prestataire, le périmètre restitué, y compris les paramétrages et les données de journalisation utiles, le calendrier, la charge d’assistance incluse ou facturée, la durée pendant laquelle le prestataire conserve une copie et les modalités de suppression définitive.
Elle doit surtout être exigible même en cas de litige sur le paiement : une clause qui subordonne la restitution à l’apurement de toute facture contestée place le client dans une situation de dépendance difficilement soutenable.
L’échec du projet : résiliation et contentieux
Lorsque le projet dérape, l’erreur classique consiste à cesser les paiements et à attendre. Mieux vaut documenter les manquements, adresser une mise en demeure circonstanciée rappelant les engagements contractuels et fixant un délai, puis mettre en œuvre la clause résolutoire selon ses termes exacts.
Le choix du terrain n’est pas neutre : résolution pour inexécution, nullité pour manquement au devoir d’information, responsabilité contractuelle, chacun a ses conditions et ses effets propres sur la restitution des sommes versées. Lorsque la démonstration technique est centrale, une mesure d’instruction avant tout procès, permettant à un expert de constater l’état de la solution avant qu’elle ne soit modifiée ou désactivée, constitue souvent l’étape décisive.
Questions fréquentes
- Le prestataire peut-il se retrancher derrière un cahier des charges imprécis ?
- Difficilement. Le professionnel de l'informatique est tenu d'une obligation de conseil et de mise en garde qui lui impose d'éclairer son client sur l'adéquation de la solution à ses besoins, d'attirer son attention sur les insuffisances du cahier des charges et de refuser, le cas échéant, une commande inadaptée. Cette obligation se double toutefois d'un devoir de collaboration à la charge du client, qui doit exprimer son besoin et se rendre disponible pendant le projet.
- À quoi sert exactement la recette ?
- La recette est l'opération par laquelle le client vérifie que la solution livrée est conforme à ce qui était convenu, puis l'accepte. Son intérêt est probatoire autant que juridique : elle fixe le point de bascule du risque, déclenche souvent le paiement du solde et fait courir la garantie. Une recette prononcée sans réserve prive le client d'une partie de ses arguments sur les défauts apparents.
- Que devient ma base de données si je quitte mon prestataire SaaS ?
- Tout dépend de ce que prévoit le contrat. En mode SaaS, les données sont hébergées chez le prestataire, dans un format qui lui est propre. À défaut de clause de réversibilité précisant les formats de restitution, les délais, le coût et la durée de conservation après la fin du contrat, la sortie peut se révéler techniquement impraticable. La clause se négocie à la signature, jamais au moment de la rupture.
Exposer votre situation
Selon votre département, la demande est adressée à l’associé compétent. Le premier échange sert à vérifier l’absence de conflit d’intérêts et à vous indiquer la marche à suivre.