Un contrat entre les mauvaises personnes
Le contrat avait été signé fin 2023 et, du point de vue du fournisseur principal, c’était un contrat propre, bien structuré, avec toutes les clauses de sauvegarde que le service juridique avait exigées au fil des années. Il spécifiait clairement l’objet de la fourniture, fixait les niveaux de service, prévoyait les pénalités en cas de manquement, définissait le périmètre de responsabilité du fournisseur avec des plafonds standard à la valeur annuelle du contrat, excluait les dommages indirects, encadrait la sous-traitance par une clause exigeant que le client approuve les principaux sous-traitants et plaçant sur le client la charge d’en vérifier l’adéquation. Il avait été négocié pendant quatre mois, était passé par trois cycles de revue juridique des deux côtés, avait été signé par des dirigeants munis des procurations nécessaires. Le fournisseur principal, une software house de cinquante personnes, le considérait comme un bon contrat. Le client, une société de services de santé privée comptant un million d’assurés, le considérait comme un contrat équilibré. Pendant deux ans la relation s’est bien passée.
Fin 2025, un assuré a subi un dommage du fait de ce que le système clinique aurait dû faire et n’a pas fait. La cause technique a été imputée à une bibliothèque d’évaluation du risque que le système utilisait pour classer les priorités d’intervention. La bibliothèque avait été fournie par un sous-traitant approuvé par le client quatre ans plus tôt, avait été silencieusement mise à jour par le sous-traitant lui-même quatre-vingts jours avant l’incident avec un changement d’algorithme que personne n’avait communiqué au fournisseur principal, et personne n’avait demandé une mise à jour de la documentation parce que le sous-traitant considérait sa mise à jour comme une maintenance ordinaire. Le sous-traitant avait son siège dans un pays tiers, n’avait pas de représentant légal dans l’Union, et dans les mois suivant l’action en justice s’est révélé pratiquement injoignable pour les notifications judiciaires.
Le fournisseur principal a réagi à la demande de dommages de l’avocat de l’assuré en montrant le contrat. Il a soutenu que le sous-traitant avait été approuvé par le client, que la modification avait été introduite unilatéralement par le sous-traitant sans aucune communication, que le contrat excluait les dommages indirects et plafonnait la responsabilité à la valeur annuelle, et qu’en tout état de cause la responsabilité matérielle pesait sur le client en tant qu’entité gérant directement la relation avec l’assuré. L’avocat de l’assuré n’a contesté aucun de ces points contractuels. Il a simplement noté que le contrat entre fournisseur et client ne le concernait pas, parce qu’il ne l’avait pas signé, et que son action s’appuyait sur le nouveau régime européen de responsabilité du produit, sous lequel le fournisseur principal était qualifiable de producteur du produit défectueux et répondait à titre objectif envers le lésé final, indépendamment des clauses contractuelles convenues avec son client. Ces clauses, a-t-il ajouté, régissaient le recours entre les parties signataires, pas l’exposition envers les tiers. Le contrat, autrement dit, était un bon contrat entre les mauvaises personnes.
L’objection traditionnelle
L’objection que je voudrais affronter tout de suite, parce qu’elle est la plus enracinée et la plus sincère, c’est celle qui vient des juristes traditionnels avec qui j’ai travaillé ces dernières années. Elle dit ceci : tout cela est un problème de rédaction du contrat. Si les clauses sont bien écrites, si les manleves sont complètes, si les procédures de sous-traitance sont rigoureuses, le fournisseur principal est protégé. C’est une objection formellement cohérente avec la manière dont le droit des contrats a fonctionné pendant quarante ans dans le logiciel. Jusqu’à il y a quelques années, c’était aussi substantiellement vrai, parce que le régime de responsabilité du producteur de logiciel était faible, les actions des tiers lésés passaient presque toujours par le client direct, et le fournisseur principal pouvait raisonnablement attendre que son exposition s’épuise dans les limites contractuelles convenues.
Cette époque est terminée. Le régime juridique qui se consolide en Europe entre 2024 et 2027, et dont j’ai déjà écrit dans cette série à propos du logiciel évalué comme promesse écrite et de la spécification comme actif juridiquement pertinent, introduit un niveau de responsabilité qui opère hors du contrat et que le contrat ne peut que partiellement encadrer. La révision de la Product Liability Directive, applicable à partir du 9 décembre 2026, qualifie explicitement le logiciel de produit et applique au producteur de logiciel un régime de responsabilité objective envers les lésés finaux. Le Cyber Resilience Act, pleinement applicable à partir du 11 décembre 2027, introduit des obligations de sécurité du produit numérique qui pèsent sur le producteur tout au long du cycle de vie et s’étendent aux composants intégrés. L’AI Act répartit les obligations le long de la chaîne des fournisseurs de systèmes d’IA, de sorte que le fournisseur du système final doit garantir que les composants qu’il intègre sont conformes. Le Digital Operational Resilience Act, applicable à partir du 17 janvier 2025, impose aux entités financières et à leurs fournisseurs critiques d’ICT des obligations de gestion du risque de la chaîne d’approvisionnement qui traversent les frontières contractuelles. NIS2, applicable à partir du 18 octobre 2024, fait le même mouvement pour les secteurs critiques élargis. Pris individuellement, chacun de ces actes serait gérable avec quelques ajustements contractuels. Pris ensemble, et dans leurs intersections, ils définissent une structure de responsabilité que le contrat de fourniture n’est plus capable de contenir.
Les quatre présupposés tombés
Le modèle contractuel traditionnel du logiciel a grandi dans une époque où certains présupposés implicites tenaient, et il est devenu inadéquat parce que tous ces présupposés sont tombés dans la même décennie. Il y avait d’abord l’idée que la responsabilité du fournisseur envers le client épuisait l’exposition du fournisseur, parce que le client intermédiaire absorbait et gérait toute responsabilité envers les tiers lésés. Il y avait ensuite la conviction que le logiciel était un objet délimité au moment de la livraison, évaluable sur la base d’un cahier des charges statique au moment du release. On tenait pour acquis, en troisième lieu, que la chaîne d’approvisionnement était essentiellement bilatérale du point de vue juridique, c’est-à-dire que chaque maillon pouvait être encadré par un contrat entre deux parties sans avoir à se soucier des dynamiques globales de la chaîne. Et l’on présupposait enfin que le régime de responsabilité resterait stable dans le temps, suffisamment pour rendre raisonnable la signature de contrats pluriannuels sur la base du cadre juridique en vigueur au moment de la signature. C’étaient des présupposés qui ressemblaient à des lois de la nature de la contractualisation logicielle jusqu’aux environs de 2020, et qui, rétrospectivement, se révèlent n’être que les caractéristiques d’une époque juridique spécifique.
Le premier présupposé a été érodé par l’élargissement de la légitimité active des tiers lésés dans la nouvelle PLD. Sous l’ancien régime de responsabilité du produit, le lésé final pouvait agir contre le producteur, mais en pratique les actions passaient surtout par le revendeur ou l’intégrateur commercial, et le producteur de logiciel jouissait jusqu’en 2024 d’une incertitude interprétative sur le fait même de rentrer dans la définition de producteur. La nouvelle Directive, en incluant explicitement le logiciel dans la définition de produit et en introduisant des présomptions de défectuosité qui allègent la charge de la preuve du lésé, rend la position du producteur de logiciel beaucoup plus exposée. Elle ajoute en outre un mécanisme de disclosure documentaire permettant au juge d’ordonner au fournisseur d’exhiber la documentation technique du produit, et de présumer le défaut en cas de non-exhibition. À partir de ce moment, l’avocat du lésé n’a plus besoin de passer par le client intermédiaire et peut agir directement contre le fournisseur principal du logiciel qui a causé le dommage, ignorant entièrement les clauses contractuelles entre fournisseur et client, parce que ces clauses régissent une relation à laquelle le lésé est tiers. La chose est écrite explicitement à l’Article 15 de la Directive, intitulé « Exclusion ou limitation de la responsabilité », qui impose aux États membres de garantir que la responsabilité de l’opérateur économique envers le lésé ne puisse être limitée ni exclue par des clauses contractuelles ou par des dispositions de droit national. C’est un article court et technique, mais c’est la clé de voûte de tout l’édifice, parce qu’il transforme ce qui ressemblait à une marge de manœuvre contractuelle en zone d’indisponibilité juridique.
Le deuxième présupposé a été érodé par le Cyber Resilience Act et par l’AI Act, qui tous deux introduisent des obligations de sécurité et de gestion du risque pesant sur le producteur tout au long du cycle de vie du produit, et non plus seulement au moment de la livraison. Le logiciel a cessé d’être un objet délimité dans le temps de la livraison et se présente comme un objet continuellement exposé au régime réglementaire ; chaque mise à jour, chaque modification, chaque intégration de nouveaux composants peut être requalifiée comme modification substantielle qui fait rentrer le produit dans le régime applicable, même si le produit avait été mis sur le marché à une époque antérieure. Le fournisseur principal qui a livré le système en 2023 ne s’est pas déchargé de la responsabilité en 2026 quand une bibliothèque tierce intégrée à ce système a cessé d’être maintenue et a développé des vulnérabilités de sécurité. La responsabilité s’est simplement déplacée sur le plan de la maintenance, et le fournisseur qui n’a pas mis à jour est un fournisseur qui a manqué à une obligation continue, pas à une obligation limitée au moment de la livraison originelle.
Le troisième présupposé, celui de la bilatéralité de la chaîne d’approvisionnement, a lui aussi été érodé par l’introduction de chaînes de responsabilité qui traversent la contractualisation bilatérale. Sous le régime DORA, l’entité financière doit cartographier et gérer ses ICT third-party risk tout au long de la chaîne, et quand un fournisseur est qualifié de critique, les obligations s’étendent de sorte que les clauses contractuelles entre l’entité financière et le fournisseur critique doivent contenir des éléments spécifiques imposés par le Règlement, indépendamment de la volonté des parties. Le CRA, pour sa part, impose au producteur d’un produit numérique de garantir la sécurité du produit intégré, et cette garantie ne s’épuise pas dans les rapports contractuels avec ses sous-traitants, parce que le régulateur évalue le produit comme un tout unitaire indépendamment de la composition interne de la chaîne. La PLD révisée ajoute une complication supplémentaire en prévoyant que le modificateur substantiel d’un produit peut devenir lui-même responsable comme producteur, et cela ouvre une dynamique de responsabilité circulaire dans laquelle le fournisseur principal, l’intégrateur intermédiaire, le sous-traitant et l’utilisateur final peuvent être appelés en cause à des titres différents pour le même dommage. NIS2 et l’AI Act complètent le tableau en étendant des obligations analogues respectivement aux secteurs critiques élargis et aux systèmes d’intelligence artificielle à haut risque, avec pour résultat que chaque segment de la chaîne est aujourd’hui traversé par au moins deux ou trois régimes superposés que les clauses contractuelles bilatérales ne parviennent pas à composer.
Le quatrième présupposé, celui de la stabilité du régime juridique dans le temps, est celui dont l’érosion produit les effets les plus subtils, parce que les contrats pluriannuels signés aujourd’hui sous le cadre en vigueur seront appliqués demain sous un cadre qui aura évolué. Le fournisseur qui signe un contrat de six ou sept ans en 2026 se trouvera à l’exécuter en 2032 ou 2033 sous des régimes qui pourraient avoir alors changé de manière significative, parce que la PLD prévoit une clause de révision, parce que le CRA fera l’objet de lignes directrices qui modifieront l’interprétation de sections entières, parce que l’AI Act a déjà été défini comme un chantier ouvert par la Commission elle-même. Le contrat pluriannuel sous le modèle traditionnel présupposait une inertie réglementaire qui n’existe plus.
Quatre phénomènes que le contrat n’adresse pas
Chacun de ces quatre phénomènes a des conséquences pratiques que le contrat traditionnel ne sait pas adresser. La responsabilité solidaire des fournisseurs de composants critiques, introduite de manières différentes par la PLD et par le CRA, fait que le fournisseur principal répond des défauts des composants intégrés même quand les sous-traitants sont inexécutants ou injoignables. Les clauses contractuelles qui régissent le recours contre les sous-traitants restent valables entre les parties signataires, mais ne déplacent pas la responsabilité envers le lésé final, qui peut toujours agir contre le fournisseur principal comme maillon accessible et patrimonialement le plus solide de la chaîne. Le fournisseur principal qui voulait transférer le risque sur le sous-traitant par des clauses contractuelles se retrouve donc à devoir l’absorber et à pouvoir seulement essayer ensuite de récupérer par la voie du recours, à supposer que le sous-traitant soit encore existant, solvable et joignable.
Les obligations de disclosure documentaire introduites par la nouvelle PLD sont le deuxième phénomène, et elles sont particulièrement insidieuses parce qu’elles transforment le fournisseur en un sujet qui doit exhiber au juge sa propre documentation technique, même quand cette documentation inclut des choix de conception, des configurations de sécurité, des datasets d’entraînement, des décisions architecturales que l’entreprise considérerait comme secret industriel. Le juge doit équilibrer le droit à la disclosure avec la protection des secrets d’affaires, mais en pratique le fournisseur se trouve exposé à des demandes documentaires que le contrat avec le client ne peut limiter, parce que le contrat ne lie ni le juge ni le lésé. Le fournisseur peut avoir convenu avec le client de l’inaccessibilité de la documentation, mais si le lésé demande l’exhibition, le fournisseur doit produire, et le refus éventuel d’exhiber génère une présomption de défectuosité au sens de l’Article 10 de la Directive.
Les présomptions de défectuosité que le fournisseur seul ne peut renverser sont le troisième phénomène, et le plus subtil des quatre. La nouvelle PLD prévoit que le juge puisse présumer la défectuosité du produit quand le produit est techniquement ou scientifiquement complexe et que la preuve du défaut serait excessivement difficile pour le lésé. Pour les systèmes logiciels complexes, et en particulier pour ceux qui intègrent des composants IA, cette présomption s’active presque automatiquement, et la charge de la renverser pèse sur le fournisseur. Renverser la présomption exige de démontrer que le produit ne présentait pas le défaut au moment de la livraison, ou que le défaut a été introduit ultérieurement par des modifications hors du contrôle du fournisseur. Les deux démonstrations exigent une documentation historique détaillée du système, et le fournisseur qui n’a pas maintenu cette documentation se trouve dans l’incapacité de prouver quoi que ce soit, et donc à succomber à la présomption.
L’accountability du modificateur substantiel est le quatrième phénomène, et c’est celui qui rompt le plus radicalement la structure du contrat bilatéral. Quand un client ou un intégrateur intermédiaire modifie substantiellement un produit logiciel fourni par un tiers, il peut devenir lui-même responsable comme producteur du produit modifié, et cela ouvre une dynamique dans laquelle le fournisseur d’origine pourrait ne plus être responsable du produit tel que modifié, mais le modificateur pourrait ne pas avoir les compétences, la documentation et la structure pour assumer la responsabilité qu’il a matériellement assumée. Le résultat est une zone grise de responsabilité dans laquelle le lésé choisit qui assigner sur la base de critères d’accessibilité patrimoniale et procédurale, et dans laquelle les parties impliquées se renvoient la responsabilité avec des résultats souvent paradoxaux.
Le tassement qui n’arrive pas tout de suite
On pourrait objecter, et quelqu’un le fera, que tout cela est exagéré et que la pratique judiciaire trouvera un moyen de remettre de l’ordre dans le système. C’est une objection qui mérite respect, parce que la pratique judiciaire a toujours cette fonction de tassement, et parce que les règlements européens, une fois traduits en jurisprudence nationale, perdent souvent la rigidité qu’ils ont sur le papier. La réponse que je me sens de donner, après avoir observé comment la pratique évolue dans les juridictions européennes où les premiers cas émergent, c’est que le tassement viendra, mais qu’il viendra dans cinq ou sept ans, et qu’entre-temps la fenêtre d’exposition pour les fournisseurs qui opèrent sous des contrats traditionnels est très large. Les premières décisions importantes en matière de responsabilité du producteur de logiciel sous la nouvelle PLD n’arriveront pas avant 2028, parce que le régime s’applique aux produits mis sur le marché après le 9 décembre 2026 et que les actions en justice ont des délais minimaux d’un an et demi. À partir de là, il faudra encore trois ou quatre ans pour qu’une jurisprudence consolidée se forme. Pendant ce temps, chaque fournisseur opérant avec des contrats du vieux modèle accumule une exposition rétroactive, parce que beaucoup des systèmes qu’il livre aujourd’hui seront encore en production quand la jurisprudence se sera tassée, et seront évalués selon les critères qui se seront consolidés à ce moment-là.
Les secteurs qui nous précèdent
Il serait malhonnête de ne pas reconnaître qu’il existe des secteurs où ces dynamiques existent depuis des décennies, et où les contrats de fourniture ont une structure qui reconnaît l’inadéquation du modèle bilatéral traditionnel. Ce sont des secteurs qui vivent sous des régimes serrés de responsabilité du produit bien avant le logiciel généraliste, et qui ont développé des pratiques contractuelles qui méritent d’être étudiées. L’aviation civile en est un, et les contrats de fourniture de composants aéronautiques incorporent depuis toujours des obligations de traçabilité documentaire, de certification de tiers, de gestion coordonnée des non-conformités, de responsabilité solidaire envers les autorités réglementaires. Le dispositif médical en est un autre, et les contrats de fourniture de composants pour dispositifs médicaux prévoient des accords-cadres de qualité qui vont au-delà du simple contrat commercial, et qui régissent la relation entre les parties comme une relation réglementaire en plus que commerciale. L’automobile est le troisième, surtout après l’introduction des normes ISO 26262 sur la sécurité fonctionnelle des systèmes électroniques des véhicules, et les contrats de fourniture de logiciel pour l’automobile incorporent depuis une dizaine d’années des clauses de responsabilité le long de la chaîne qui reconnaissent l’impossibilité de confiner l’exposition dans des rapports bilatéraux.
Ce qui se passe dans le logiciel généraliste, c’est la convergence — accélérée par le paquet réglementaire européen — vers le modèle que ces secteurs pratiquent déjà. La différence est que aviation, dispositifs médicaux et automobile ont eu trente ans pour bâtir les pratiques contractuelles, les compétences internes, les standards de secteur et les relations de fourniture structurées. Le logiciel généraliste a cinq ou sept ans pour faire la même chose, et il doit le faire alors qu’il continue d’opérer sur des marchés où la majorité des concurrents raisonne encore avec le vieux modèle. C’est une transition asymétrique, dans laquelle qui bouge en premier paie un coût de positionnement que qui bouge ensuite ne paie pas, mais qui bouge en premier construit aussi des capacités d’absorber les évolutions réglementaires successives que qui bouge ensuite devra acheter à marché consolidé.
Cinq dimensions opérationnelles
Sur un plan opérationnel, la transformation du contrat de fourniture de logiciel a cinq dimensions à gérer simultanément. La première est le passage du contrat-document aux documents contractuels comme écosystème. Un contrat de fourniture de logiciel sous le nouveau régime ne s’épuise pas dans un document unique valable jusqu’au renouvellement, mais constitue un système de documents corrélés qui comprend le contrat principal, les annexes de niveaux de service, les annexes de sécurité, les accords qualité similaires à ceux du dispositif médical, les accords de traitement des données personnelles au sens de l’Article 28 RGPD, les accords de gestion coordonnée des vulnérabilités, les accords de disclosure réciproque de la chaîne d’approvisionnement. Chacun de ces documents vit avec son propre cycle de mise à jour, et le contrat principal devient le cadre qui les tient ensemble, pas le contenant de toutes les clauses.
La deuxième dimension est la transformation de la clause de limitation de responsabilité. Les clauses traditionnelles qui plafonnent la responsabilité du fournisseur à la valeur annuelle du contrat, ou qui excluent les dommages indirects, restent valables entre les parties signataires mais ne produisent pas d’effets envers les tiers lésés. Pour le fournisseur, cela signifie que l’exposition effective est celle envers le lésé final, pas celle convenue avec le client, et que les polices d’assurance doivent être dimensionnées sur cette exposition effective, pas sur les plafonds contractuels. La pratique assurantielle du secteur est en ce moment confuse, parce que les compagnies redéfinissent les produits pour la responsabilité civile des producteurs de logiciel en fonction du nouveau régime, et les primes augmentent de manière non linéaire. Pour les software houses italiennes de taille moyenne, le coût assurantiel de la responsabilité de produit devient un poste de bilan significatif, là où il y a quelques années il était négligeable.
La troisième dimension est la réécriture des clauses sur la sous-traitance, qui doivent passer d’un modèle dans lequel le client approuve les principaux sous-traitants au moment de la signature à un modèle dans lequel il existe une procédure continue d’évaluation, de monitoring et de disclosure des sous-traitants tout au long de la durée du contrat. Le fournisseur principal doit pouvoir démontrer à tout moment la composition de sa chaîne d’approvisionnement, doit pouvoir produire la SBOM au sens du CRA, doit pouvoir répondre à des demandes d’audit du client ou du régulateur, doit gérer les situations dans lesquelles un sous-traitant sort du marché ou cesse la maintenance d’un composant. Tout cela exige des outils de gestion de la chaîne d’approvisionnement que le modèle contractuel traditionnel tenait pour acquis et qui aujourd’hui deviennent objet d’activité opérationnelle continue.
La quatrième dimension est l’introduction de clauses de gestion coordonnée des vulnérabilités et des incidents de sécurité. Sous le CRA, sous NIS2 et sous DORA pour le financier, le fournisseur et le client ont tous deux des obligations de reporting dans des fenêtres temporelles serrées, et le respect de ces fenêtres exige une coordination que le contrat doit régir de manière opérationnelle, pas seulement formelle. Une clause qui dit « les parties collaborent dans la gestion des incidents » est inutile si elle ne précise pas qui notifie, dans quel délai, par quels canaux, avec quels seuils de gravité. La clause doit être presque un mini-runbook contractuel, et sa qualité se mesure dans la capacité de fonctionner au moment où un incident réel est en cours, pas dans son élégance juridique.
La cinquième dimension est la plus subtile, et concerne la gestion du cycle de vie du produit. Sous le CRA, le producteur doit déclarer la période de support du produit et la maintenir pendant cette période, et doit gérer la sortie du produit du marché de sorte que les utilisateurs soient informés et aient des chemins de transition. Le contrat de fourniture de logiciel doit régir cet aspect, parce que le fournisseur principal est exposé envers le lésé final même après la fin de la relation contractuelle avec le client, et parce que la gestion de l’end of support devient un moment critique où des responsabilités résiduelles peuvent se matérialiser. Les clauses traditionnelles de perpetual licence ou de no warranty after termination ne produisent pas d’effets envers les tiers lésés, ce qui signifie que le fournisseur doit gérer le cycle de vie du produit comme une fonction qui excède la durée du contrat.
Disclosure : dix-huit mois de réécriture
Je dois être transparent sur un point, parce que sur ce sujet je décris des transformations que je vis en première personne. La révision de nos contrats de fourniture, dans l’entreprise où je travaille, est une activité en cours depuis dix-huit mois et n’est pas encore arrivée à une forme stable. Nous travaillons avec notre cabinet d’avocats de référence pour réécrire le contrat de base de fourniture de services logiciels, et ce qui en sort est très loin du contrat propre et élégant que nous espérions produire, et a la forme d’un système de documents plus articulé que le précédent, avec des annexes qui existent pour des raisons différentes et qui ne se réduisent pas à un seul template. Certains clients acceptent la nouvelle structure, d’autres la trouvent inutilement complexe et demandent à revenir au vieux modèle. La pression du marché vers la simplicité contractuelle est encore forte, et dans certains cas nous-mêmes acceptons de signer des contrats du vieux modèle quand le client l’impose, sachant que nous accumulons une exposition rétroactive. C’est un choix que nous faisons pour des raisons commerciales immédiates, et que j’ai appelé exposition composée dans nos conversations internes, parce qu’elle s’accumule de manière non linéaire à mesure que le portefeuille clients grandit.
Une opportunité, pas seulement un fardeau
Je veux aussi dire, parce que sinon le texte ressemblerait à une prévision pessimiste sur l’industrie italienne du logiciel, que la transformation que je décris est une opportunité avant d’être un fardeau. Les software houses italiennes de taille moyenne qui décideront de bâtir des compétences contractuelles cohérentes avec le nouveau régime, d’accompagner le travail de delivery d’un travail continu de maintenance documentaire et de gestion de la chaîne d’approvisionnement, de former à l’interne les figures hybrides que j’ai décrites dans le texte précédent de cette série, auront dans cinq ans une position concurrentielle difficile à éroder. Les software houses qui continueront à signer des contrats traditionnels en espérant que le cadre réglementaire ne s’applique pas vraiment, ou que la jurisprudence nationale l’adoucira, se trouveront exposées et devront combler le retard à des coûts bien supérieurs à ceux soutenables aujourd’hui. C’est une de ces situations où la décision de ne pas décider est la plus coûteuse de toutes, parce que le temps travaille contre qui ne bouge pas, et parce que chaque contrat signé aujourd’hui sous le vieux modèle est un passif qui se révélera dans quelques années, quand les cas que la PLD a dessinés comme scénario standard commenceront à apparaître dans les rubriques des journaux spécialisés.
La centralité qui meurt
En mettant ensemble les quatre textes de cette série, l’argument général que je cherche à construire est le suivant. Le logiciel, comme objet industriel et comme objet juridique, change de nature sous nos yeux, et la culture d’ingénierie et commerciale du secteur ne s’adapte pas à la vitesse que le moment exige. Le premier texte, Cruft, pas patine, soutenait que le logiciel ne sait pas vieillir comme les objets matériels. Le suivant, La dette de spécification, déplaçait l’attention sur le fait que la spécification écrite est devenue l’actif juridiquement pertinent du produit et que notre industrie n’a pas les outils pour la maintenir en vie. Puis est arrivé L’ascension du compliance engineer, consacré à la figure professionnelle hybride qui émerge pour superviser le vide entre l’ingénierie et la régulation. Dans ce quatrième texte, l’argument se déplace du plan du produit et du travail au plan de la relation entre organisations, et la thèse est que le contrat de fourniture, l’instrument juridique classique de cette relation, est en train de devenir un instrument parmi d’autres d’une relation plus large et plus structurée que le droit contractuel traditionnel ne peut que partiellement encadrer.
Le contrat de fourniture de logiciel n’est pas mort, et rien de ce que j’ai écrit ne doit être lu comme une prévision de sa disparition. Ce qui est mort, c’est sa centralité, l’idée que la relation entre fournisseur et client puisse être décrite exhaustivement par un document bilatéral négocié au début du rapport et mis à jour aux renouvellements. La relation contemporaine est une relation multilatérale, chargée réglementairement, dynamiquement exposée à des sujets tiers que le contrat ne lie pas, et traversée par des obligations documentaires continues que le contrat ne peut que résumer. Penser qu’il suffirait d’écrire mieux les clauses est une nostalgie compréhensible et humaine, et c’est aussi le moyen le plus rapide d’accumuler de l’exposition en se croyant protégé. Les clauses servent encore, et même plus qu’avant, mais elles servent comme éléments d’un dispositif plus large qui les contient et les dépasse.
Le contrat, tel que nous l’avons connu, est devenu l’illusion gentille qui permet aux fournisseurs de logiciel de croire qu’ils savent à quoi ils s’exposent. Les contrats traditionnels continueront d’être signés pendant quelques années encore, parce que le marché bouge plus lentement que le droit, et parce que le vieux modèle est familier et que les nouveaux modèles sont encore en formation. Mais qui continue à signer des contrats traditionnels dans les cinq prochaines années signe, en plus du contrat, un pari silencieux sur le fait que les choses ne changeront pas vraiment. C’est un pari que ma génération de ceux qui font du logiciel en Europe perdra probablement, parce que les choses sont déjà en train de changer, et que ce qui aujourd’hui ressemble à un excès de prudence des quelques-uns qui bougent se révélera dans quelques années être le minimum prudentiel qui était requis dès le départ.
Ce qu'il faut retenir
L’Article 15 de la PLD révisée est la clé de voûte du nouveau régime : la responsabilité envers le lésé ne peut être limitée ni exclue par des clauses contractuelles ou par des dispositions de droit national. Ce qui ressemblait à une marge de manœuvre contractuelle devient une zone d’indisponibilité juridique.
Quatre présupposés implicites du modèle contractuel traditionnel sont tombés dans la même décennie : l’exposition du fournisseur épuisée dans la relation client, le logiciel comme objet délimité à la livraison, la chaîne d’approvisionnement comme somme de relations bilatérales, la stabilité réglementaire qui rendait raisonnables les contrats pluriannuels sous un cadre fixe.
Quatre phénomènes que le contrat traditionnel ne sait pas adresser : responsabilité solidaire pour les composants critiques, disclosure documentaire au juge (avec présomption de défaut en cas de non-exhibition), présomptions de défectuosité pour les systèmes techniquement complexes, accountability du modificateur substantiel — qui rompt le plus radicalement la structure bilatérale.
Les secteurs qui vivent ce régime depuis des décennies — aviation civile, dispositifs médicaux, automobile — ont eu trente ans pour bâtir les pratiques. Le logiciel généraliste a cinq à sept ans pour faire la même chose, alors que la plupart des concurrents raisonnent encore avec le vieux modèle.
Le contrat n’est pas mort : c’est sa centralité qui l’est. La relation contemporaine est multilatérale, chargée réglementairement, dynamiquement exposée à des tiers que le contrat ne lie pas, traversée par des obligations documentaires continues que le contrat ne peut que résumer. Les clauses servent encore — plus qu’avant — mais comme éléments d’un dispositif plus large qui les contient et les dépasse.
Questions & réponses
Pourquoi le contrat de fourniture de logiciel a-t-il « cessé d'être central » ?
Parce que le régime juridique qui se consolide en Europe entre 2024 et 2027 introduit un niveau de responsabilité qui opère hors du contrat et que le contrat ne peut que partiellement encadrer. La PLD révisée, le CRA, l’AI Act, NIS2 et DORA convergent pour rendre le fournisseur responsable envers le tiers lésé indépendamment des clauses convenues avec le client intermédiaire, et pour imposer des obligations documentaires, de sécurité et de gestion de la chaîne qui traversent la contractualisation bilatérale. Les clauses régissent toujours le recours entre signataires, mais elles ne déplacent pas la responsabilité envers les tiers. Le contrat n’est pas mort : c’est sa centralité qui l’est.
Que change l'Article 15 de la PLD révisée ?
L’Article 15, intitulé « Exclusion ou limitation de la responsabilité », impose aux États membres de garantir que la responsabilité de l’opérateur économique envers le lésé ne puisse être limitée ni exclue par des clauses contractuelles ou par des dispositions de droit national. C’est un article court et technique, mais c’est la clé de voûte de l’ensemble : il transforme ce qui ressemblait à une marge contractuelle en zone d’indisponibilité juridique. Le fournisseur qui se protège par des clauses de plafonnement ou d’exclusion des dommages indirects découvre que ces clauses régissent le recours avec le client signataire, pas l’exposition envers le tiers lésé.
Quels sont les quatre phénomènes opérationnels que le contrat traditionnel ne sait pas adresser ?
Premièrement, la responsabilité solidaire des fournisseurs de composants critiques : le fournisseur principal répond des défauts des sous-traitants même quand ces derniers sont inexécutants ou inatteignables. Deuxièmement, les obligations de disclosure documentaire au juge, avec présomption de défaut en cas de non-exhibition (Article 10 PLD). Troisièmement, les présomptions de défectuosité pour les systèmes techniquement complexes, qui s’activent presque automatiquement pour les logiciels intégrant des composants IA. Quatrièmement, l’accountability du modificateur substantiel : le client ou l’intégrateur intermédiaire qui modifie un produit peut devenir lui-même producteur responsable, brisant la structure bilatérale du contrat.
Quels secteurs opèrent déjà sous un régime similaire, et que pouvons-nous apprendre ?
Aviation civile, dispositifs médicaux et automobile vivent sous des régimes stricts de responsabilité du produit depuis des décennies et ont développé des pratiques contractuelles utiles. Les contrats aéronautiques incorporent des obligations de traçabilité documentaire et de certification de tiers. Le dispositif médical prévoit des accords-cadres qualité qui vont au-delà du simple contrat commercial. L’automobile, surtout après ISO 26262, intègre des clauses de responsabilité le long de la chaîne. La différence, c’est que ces secteurs ont eu trente ans pour bâtir les pratiques ; le logiciel généraliste a cinq à sept ans pour faire la même chose.
Quelles sont les cinq dimensions opérationnelles de la transformation contractuelle ?
Première : passer du contrat-document aux documents contractuels comme écosystème (contrat-cadre, SLA, annexes de sécurité, accords qualité, accords de traitement des données ex Article 28 RGPD, gestion coordonnée des vulnérabilités, disclosure de la chaîne). Deuxième : la clause de limitation de responsabilité, qui reste valable entre parties mais ne produit pas d’effets envers les tiers (et impose une réévaluation des polices d’assurance). Troisième : la réécriture de la sous-traitance, d’une approbation initiale à une procédure continue d’évaluation et de disclosure. Quatrième : des clauses opérationnelles de gestion des vulnérabilités et incidents, presque comme des mini-runbooks contractuels. Cinquième : la gestion du cycle de vie du produit et de l’end of support, qui dépassent la durée de la relation contractuelle.
Y a-t-il un lien entre ce texte et les trois essais précédents de la série ?
Oui, et c’est le quatrième et dernier de la série. Cruft, pas patine soutenait que le logiciel ne sait pas vieillir. La dette de spécification déplaçait l’attention sur le fait que la spécification écrite est devenue l’actif juridiquement pertinent du produit et qu’il manque les outils pour la maintenir en vie. L’ascension du compliance engineer décrivait la figure hybride qui émerge pour superviser le vide entre l’ingénierie et la régulation. Ce texte déplace l’argument au plan de la relation entre organisations : le contrat — instrument juridique classique de cette relation — devient un instrument parmi d’autres d’un dispositif plus large. La thèse unifiante est que le logiciel, comme objet industriel et comme objet juridique, change de nature sous nos yeux, et que la culture d’ingénierie et commerciale du secteur ne s’adapte pas à la vitesse que le moment exige.
L'auteur
