Nous parlons beaucoup d’architecture, de cloud, de cybersécurité, de dette technique, d’agilité et, désormais, d’intelligence artificielle.
Nous parlons beaucoup moins d’un autre observatoire de l’informatique : la jurisprudence.
Pourtant, les juridictions françaises voient depuis plusieurs décennies arriver des logiciels qui ne répondent pas aux besoins, des projets d’intégration qui dérapent, des ERP qui ne sont jamais livrés comme prévu, des relations client-prestataire qui se détériorent, des données difficiles à récupérer ou encore des systèmes dont les limites n’ont pas été suffisamment expliquées.
Ces décisions racontent une partie de l’histoire de l’IT.
Et elles révèlent quelque chose de particulièrement intéressant pour les professionnels des systèmes d’information : lorsqu’un projet informatique échoue, la question n’est généralement plus seulement de savoir si « le logiciel fonctionne ».
Il faut reconstruire le projet.
Qui devait comprendre le besoin ? Qui détenait l’expertise ? Qui devait alerter ? Qui devait fournir l’information ? Qu’avait réellement promis le fournisseur ? Qu’avait accepté le client ? Quels risques avaient été identifiés ?
Autrement dit : qui savait quoi, qui devait faire quoi et peut-on encore le démontrer ?
C’est précisément pour cette raison que la jurisprudence informatique mérite d’être lue non seulement par les juristes, mais également par les consultants, architectes, chefs de projet et responsables IT.
L’informatique est aussi une affaire d’asymétrie de compétence
L’une des notions les plus intéressantes rencontrées dans la jurisprudence informatique française est celle du devoir de conseil du professionnel.
L’idée est relativement intuitive.
Lorsque deux entreprises contractent autour d’une technologie complexe, elles ne possèdent pas nécessairement le même niveau de connaissance sur cette technologie.
Le professionnel informatique dispose précisément d’une expertise pour laquelle son client vient le chercher.
Cette asymétrie n’est pas neutre.
Elle peut produire des obligations.
On en trouve une illustration ancienne dans un arrêt de la chambre commerciale de la Cour de cassation du 3 décembre 1985, n° 84-14.463.
L'affaire concernait un système informatique de gestion et les difficultés rencontrées lors de son utilisation. La décision relève notamment que le professionnel devait étudier les besoins de son client et apprécier la formation nécessaire des utilisateurs au regard des possibilités du système.
Ce qui est remarquable est la date : 1985.
Bien avant le cloud, les ERP modernes, le SaaS et l’IA générative, la question de l’adéquation entre technologie, besoin et capacité des utilisateurs était déjà devant les tribunaux.
Source officielle :
Cour de cassation, chambre commerciale, 3 décembre 1985, n° 84-14.463 — Légifrance
« Le client ne nous l’avait pas demandé » n’est pas toujours une réponse suffisante
Plus de trente ans plus tard, la Cour de cassation formule très explicitement cette logique.
Dans un arrêt du 20 juin 2018, n° 17-14.742, une société avait acquis un logiciel et invoquait ensuite des dysfonctionnements.
La cour d’appel avait notamment considéré que certaines spécificités voulues par le client n’avaient pas été portées suffisamment tôt à la connaissance du prestataire.
La Cour de cassation casse partiellement la décision.
Elle rappelle que l’obligation de conseil inhérente au contrat de fourniture informatique impose au vendeur de se renseigner sur les besoins de l’acheteur et de l’informer de l’aptitude du produit proposé à l’utilisation envisagée.
Source officielle :
Cour de cassation, chambre commerciale, 20 juin 2018, n° 17-14.742 — Légifrance
Pour quelqu’un travaillant dans l’IT, cette décision est particulièrement intéressante.
Elle vient heurter une défense que nous connaissons tous dans les projets :
« Ce n’était pas écrit dans le besoin. »
Évidemment, cela ne signifie pas qu’un fournisseur doit deviner toutes les attentes imaginables de son client.
La portée exacte d’une obligation dépend du contrat et des circonstances.
Mais la logique retenue ici est importante : le professionnel ne peut pas nécessairement rester passif face à un besoin insuffisamment exploré.
Son expertise lui impose aussi de poser des questions.
Et c’est là que le sujet devient beaucoup plus intéressant qu’une simple affaire juridique.
Le cahier des charges n’est peut-être pas le bouclier que l’on imagine
Dans les organisations IT, nous avons tendance à matérialiser la responsabilité par des documents :
le cahier des charges, les spécifications fonctionnelles, les user stories, les critères d’acceptation, les contrats d’interface.
Cette documentation est indispensable.
Mais elle peut donner naissance à une illusion :
si quelque chose n’est pas écrit, personne n’en est responsable.
La jurisprudence sur le devoir de conseil invite à être beaucoup plus prudent.
Pour un professionnel, identifier qu’un besoin est insuffisamment défini peut faire partie du travail.
Traduit dans le langage d’un projet IT, cela signifie qu’une phase de cadrage n’est pas simplement une formalité commerciale.
Elle sert à déterminer si la solution envisagée correspond réellement au problème.
C’est précisément ce que font — lorsqu’ils sont correctement utilisés — les ateliers de cadrage, études de faisabilité, prototypes, POC, audits d’architecture et phases de discovery.
Vu sous cet angle, le cadrage devient aussi une forme de gestion du risque contractuel.
Mais le client n’est pas un spectateur du projet
Il serait néanmoins excessif d’en déduire que tout échec informatique devient automatiquement la responsabilité du fournisseur.
Un système d’information est généralement construit à partir de deux expertises différentes.
Le fournisseur connaît la technologie.
Le client connaît son métier.
Le prestataire peut comprendre Kubernetes, Oracle, SAP, Snowflake, Salesforce ou une architecture événementielle.
Mais il ne connaît pas spontanément toutes les subtilités d’un processus de souscription en assurance, d’une chaîne logistique industrielle ou d’un mécanisme comptable propre à son client.
Il existe donc une interdépendance fondamentale.
La réussite du projet suppose une circulation correcte de l’information entre expertise métier et expertise technologique.
C’est probablement l’un des enseignements les plus utiles de la lecture des contentieux IT : le projet informatique n’est pas seulement une prestation.
C’est une organisation temporaire de connaissances distribuées.
MAIF contre IBM : anatomie d’un grand projet informatique en difficulté
L’affaire opposant la MAIF à IBM constitue à cet égard un cas d’étude fascinant.
Le 14 décembre 2004, la MAIF conclut avec IBM France un contrat d’intégration « clé en main ».
IBM doit assurer la maîtrise d’œuvre globale d’un projet d’installation d’un progiciel, moyennant un prix forfaitaire.
Puis arrivent les difficultés techniques.
Le projet prend du retard.
En 2005, deux protocoles viennent réviser le projet initial : le calendrier est allongé et le montant du forfait augmente.
Le projet finit par être arrêté.
Un expert judiciaire intervient ensuite sur les causes de sa non-réalisation.
Le contentieux arrivera jusqu’à la Cour de cassation.
Source officielle :
Cour de cassation, chambre commerciale, 4 juin 2013, n° 12-13.002 — Cour de cassation
Pour un professionnel de l’IT, cette affaire mérite d’être lue presque comme un retour d’expérience de programme informatique.
On y retrouve un scénario extrêmement contemporain :
un périmètre ambitieux,
un engagement initial,
des difficultés techniques,
des retards,
une renégociation,
une augmentation du budget,
puis la rupture de confiance.
C’est presque l’archétype du grand projet informatique en difficulté.
Le contrat devient une architecture de responsabilités
Un grand système informatique est rarement construit par une seule entité.
Prenons un projet contemporain.
Nous pouvons avoir :
- un client ;
- une DSI ;
- plusieurs directions métier ;
- un éditeur ;
- un intégrateur ;
- un cabinet de conseil ;
- un fournisseur cloud ;
- un hébergeur ;
- plusieurs sous-traitants ;
- éventuellement une AMOA.
Lorsque le projet fonctionne, cette organisation paraît normale.
Lorsque le projet échoue, elle devient une question fondamentale :
qui avait la responsabilité du résultat qui n’a pas été atteint ?
C’est ici que le contrat informatique peut être regardé comme une véritable architecture de responsabilités.
Qui fournit les données ?
Qui garantit leur qualité ?
Qui réalise les tests ?
Qui valide la recette ?
Qui assure la performance ?
Qui dimensionne l’infrastructure ?
Qui décide qu’un risque est acceptable ?
Qui assure la reprise des données ?
Qui autorise le passage en production ?
Pour un architecte IT, cette liste ressemble étrangement à une matrice RACI.
Pour un juriste, elle contribue aussi à déterminer les obligations des parties.
Les deux disciplines parlent parfois de la même chose avec un vocabulaire différent.
La documentation technique devient une mémoire du projet
Cela conduit à une deuxième réflexion.
Nous produisons énormément de documentation dans les projets informatiques :
comptes rendus,
tickets,
procès-verbaux de recette,
emails,
spécifications,
Architecture Decision Records,
registres de risques,
rapports de tests,
réserves,
demandes de changement.
Ces documents sont souvent considérés comme de la bureaucratie.
Pourtant, lorsqu’un projet commence à dériver, leur fonction change complètement.
Ils deviennent la mémoire du système.
Imaginons qu’un architecte identifie un risque important de performance.
Il l’explique oralement pendant un comité.
Le client décide néanmoins de poursuivre.
Dix-huit mois plus tard, la plateforme rencontre précisément le problème anticipé.
Que reste-t-il de cette alerte ?
Un souvenir ?
Ou une décision documentée ?
C’est là qu’apparaît une règle de gouvernance extrêmement simple :
une décision importante devrait laisser une trace proportionnée à son importance.
Pas pour organiser une culture permanente de la défiance.
Mais parce qu’un système complexe nécessite une mémoire.
Le devoir de conseil traduit en langage d’ingénieur
La notion juridique de « devoir de conseil » peut sembler abstraite à un ingénieur.
Essayons donc de la traduire en langage IT.
Dans un projet bien gouverné, un professionnel devrait idéalement pouvoir démontrer quelque chose comme :
J’ai cherché à comprendre votre besoin.
J’ai vérifié l’adéquation de la solution proposée avec ce besoin.
J’ai identifié les principales hypothèses.
J’ai signalé les limites importantes dont j’avais connaissance.
J’ai explicité les prérequis nécessaires.
J’ai documenté les risques majeurs.
Cette traduction est évidemment une grille de lecture personnelle et non une définition juridique du devoir de conseil.
Mais elle montre quelque chose d’intéressant :
les bonnes pratiques d’ingénierie et les mécanismes de maîtrise du risque juridique peuvent parfois converger.
Un Architecture Decision Record bien tenu n’est donc pas uniquement utile aux développeurs qui reprendront le système trois ans plus tard.
Il raconte pourquoi une décision a été prise.
Faurecia contre Oracle : peut-on contractuellement plafonner les conséquences d’un échec ?
Une autre affaire incontournable de la jurisprudence informatique française oppose Faurecia à Oracle.
Faurecia souhaitait déployer un logiciel intégré couvrant notamment la gestion de production et la gestion commerciale.
Plusieurs contrats sont conclus avec Oracle.
Des difficultés apparaissent, notamment autour d’une solution provisoire et de la livraison d’une nouvelle version.
Le contentieux conduit notamment les juridictions à examiner une clause limitative de réparation.
Dans son arrêt du 29 juin 2010, n° 09-11.841, la Cour de cassation valide dans cette affaire l’application de la clause, en relevant notamment que le plafond d’indemnisation retenu n’était pas dérisoire et ne vidait pas l’obligation essentielle de sa substance.
Source officielle :
Cour de cassation, chambre commerciale, 29 juin 2010, n° 09-11.841 — Légifrance
Cette jurisprudence est particulièrement intéressante pour comprendre la logique économique des contrats informatiques.
Un fournisseur peut accepter un projet à 500 000 euros.
Mais peut-il raisonnablement accepter une exposition potentielle de 50 millions d’euros si le système tombe en panne ?
C’est notamment pour maîtriser ce risque que les contrats comportent des mécanismes de plafonnement de responsabilité.
Mais le droit français pose également une limite.
L’article 1170 du Code civil dispose aujourd’hui :
« Toute clause qui prive de sa substance l'obligation essentielle du débiteur est réputée non écrite. »
Source officielle :
Article 1170 du Code civil — Légifrance
Autrement dit, la gestion contractuelle du risque existe, mais elle ne peut pas nécessairement aboutir à vider l’engagement principal de sa substance.
Avant même la signature, l’information compte
Le sujet devient encore plus intéressant lorsqu’on remonte avant le démarrage du projet.
L’article 1112-1 du Code civil prévoit notamment que la partie qui connaît une information déterminante pour le consentement de l’autre doit l’en informer lorsque cette dernière l’ignore légitimement ou fait confiance à son cocontractant.
Le texte précise également que les parties ne peuvent ni limiter ni exclure ce devoir.
Source officielle :
Article 1112-1 du Code civil — Légifrance
Pour l’industrie informatique, les questions deviennent immédiatement intéressantes.
Que se passe-t-il lorsqu’avant la signature un fournisseur sait qu’une migration sera particulièrement complexe ?
Qu’une fonctionnalité déterminante nécessitera probablement du spécifique ?
Qu’une architecture comporte une limitation importante ?
Qu’une intégration annoncée comme simple présente en réalité une incertitude majeure ?
Il faut évidemment analyser chaque situation concrètement avant d’en tirer une conséquence juridique.
Mais une conclusion organisationnelle peut déjà être formulée :
la phase commerciale et la phase technique ne vivent pas dans deux univers indépendants.
Et cela pose une question que beaucoup d’entreprises technologiques connaissent parfaitement :
que se passe-t-il lorsque la promesse commerciale va plus loin que la certitude technique ?
Même le poste de travail raconte l’évolution du droit numérique
La jurisprudence informatique ne concerne pas uniquement les grands programmes de transformation.
Elle concerne aussi quelque chose d’aussi banal qu’un ordinateur professionnel.
Dans un arrêt du 10 mai 2012, n° 11-13.884, la chambre sociale de la Cour de cassation rappelle que les fichiers créés par un salarié à l’aide de l’outil informatique mis à sa disposition pour son travail sont présumés professionnels, sauf s’ils sont identifiés comme personnels.
Dans cette affaire, le fait que les fichiers se trouvent dans un dossier nommé « Mes documents » ne suffisait pas à renverser cette présomption.
Source officielle :
Cour de cassation, chambre sociale, 10 mai 2012, n° 11-13.884 — Légifrance
Là encore, une convention informatique apparemment anodine — le nom d’un dossier — rencontre le droit du travail, la vie privée et le droit de la preuve.
Le numérique crée constamment ce type de frontières.
Et maintenant, l’intelligence artificielle
C’est probablement ici que la jurisprudence IT des prochaines années deviendra particulièrement intéressante.
L’intelligence artificielle reprend une grande partie des problèmes historiques de l’informatique et leur ajoute de nouvelles incertitudes.
Imaginons un système d’IA déployé dans une entreprise et produisant une décision incorrecte.
Qui porte quelle responsabilité ?
L’éditeur du modèle ?
L’intégrateur ?
Le fournisseur de données ?
L’entreprise qui utilise le système ?
L’équipe ayant construit la couche RAG ?
L’utilisateur ?
La réponse dépendra évidemment du contexte, du régime juridique applicable, du contrat et du rôle exact de chaque acteur.
Mais les anciennes questions vont probablement revenir sous une nouvelle forme.
Qui connaissait les limites du système ?
Qui devait les expliquer ?
Les performances annoncées correspondaient-elles réellement au cas d’usage ?
Les risques d’erreur avaient-ils été correctement documentés ?
Le client disposait-il des informations nécessaires pour décider ?
Hallucinations, biais, qualité des données, dérive des modèles, confidentialité, explicabilité, dépendance à un fournisseur : beaucoup de problèmes présentés comme radicalement nouveaux pourraient finalement rencontrer des raisonnements juridiques beaucoup plus anciens.
Le devoir de conseil construit autour de l’informatique classique pourrait ainsi fournir une grille de lecture particulièrement intéressante pour observer les futurs contentieux liés à l’IA.
La jurisprudence IT est aussi une histoire de gouvernance
Lorsque l’on enlève le vocabulaire juridique, les affaires informatiques parlent souvent de problèmes que les professionnels connaissent parfaitement :
besoin insuffisamment défini,
responsabilités ambiguës,
architecture inadaptée,
promesse trop ambitieuse,
risque insuffisamment documenté,
tests incomplets,
retard,
dépassement budgétaire,
dégradation de la relation client-fournisseur.
Le tribunal intervient lorsque les mécanismes ordinaires de gouvernance n’ont pas permis de résoudre le conflit.
Et c’est précisément ce qui rend ces décisions intéressantes pour les professionnels de l’IT.
Elles permettent d’observer des projets numériques après leur accident.
Lire les décisions judiciaires comme des post-mortems IT
Les ingénieurs connaissent bien la culture du post-mortem.
Après un incident majeur, on essaie de reconstruire les événements :
Que s’est-il passé ?
Quelles hypothèses étaient incorrectes ?
Quels signaux ont été ignorés ?
Quelles barrières n’ont pas fonctionné ?
Quelle décision aurait pu éviter l’incident ?
Une décision judiciaire portant sur un projet informatique ressemble parfois étonnamment à cet exercice.
Avec une différence majeure.
Le post-mortem arrive plusieurs années plus tard.
Il contient des contrats, des expertises, des emails, des factures, des avenants, des témoignages et parfois des milliers de pages de pièces.
Mais la question centrale reste assez proche :
comment le projet a-t-il pu arriver là ?
C’est peut-être ainsi que nous, professionnels de l’IT, devrions davantage lire la jurisprudence.
Non pas pour nous transformer en juristes.
Mais parce que les décisions judiciaires constituent une gigantesque collection de post-mortems de projets numériques.
Et dans une industrie fascinée par la prochaine technologie, étudier méthodiquement les échecs du passé pourrait être l’une des meilleures manières de construire les systèmes de demain.
Sources principales
Cour de cassation, chambre commerciale, 3 décembre 1985, n° 84-14.463
Système informatique de gestion, besoins du client et obligations du professionnel.
Consulter la décision sur Légifrance
Cour de cassation, chambre commerciale, 29 juin 2010, n° 09-11.841 — Faurecia / Oracle
Obligation essentielle et clause limitative de réparation.
Consulter la décision sur Légifrance
Cour de cassation, chambre commerciale, 4 juin 2013, n° 12-13.002 — MAIF / IBM
Projet d’intégration informatique « clé en main », difficultés techniques, retards et révision du projet.
Consulter la décision sur le site de la Cour de cassation
Cour de cassation, chambre commerciale, 20 juin 2018, n° 17-14.742
Obligation du fournisseur informatique de se renseigner sur les besoins de l’acheteur et sur l’adéquation de la solution.
Consulter la décision sur Légifrance
Cour de cassation, chambre sociale, 10 mai 2012, n° 11-13.884
Présomption du caractère professionnel des fichiers présents sur l’outil informatique professionnel.
Consulter la décision sur Légifrance
Code civil, article 1112-1
Devoir précontractuel d’information.
Consulter l’article sur Légifrance
Code civil, article 1170
Clause privant de sa substance l’obligation essentielle du débiteur.
Consulter l’article sur Légifrance
À propos de cette publication
Cet article propose une lecture personnelle de décisions de justice et de textes juridiques sous l’angle des systèmes d’information, de la gouvernance IT et de la gestion des projets numériques.
Je ne suis pas avocat et cette publication n’a pas vocation à constituer un conseil ou une consultation juridique. Elle s’inscrit dans une démarche de veille, de réflexion et de vulgarisation autour des interactions entre droit et technologies.
Les décisions et textes cités sont accessibles publiquement et sont référencés afin de permettre au lecteur de consulter les sources originales. Pour toute situation juridique particulière, il convient de consulter un professionnel du droit.