Faille dans une dépendance open source : êtes-vous responsable du code que vous n'avez pas écrit ?
80 % du code livré aujourd'hui vient de dépendances tierces. Quand l'une d'elles est compromise, qui répond du sinistre ? Le point juridique pour les développeurs.
- Le droit ne distingue pas le code que vous avez écrit de celui que vous intégrez : vous répondez de l'ensemble du livrable.
- Les licences open source excluent quasi systématiquement toute garantie : vous ne pouvez pas vous retourner contre la communauté.
- Votre devoir de vigilance impose de surveiller les vulnérabilités connues (CVE) et de maintenir les dépendances à jour pendant la maintenance.
- RC Pro et garantie Cyber couvrent le préjudice et la gestion de crise quand une faille tierce est exploitée chez votre client.
La réalité technique : vous livrez surtout du code que vous n'avez pas écrit
Un projet logiciel moderne n'est plus un bloc artisanal. C'est un assemblage : un framework, des dizaines voire des centaines de librairies tierces, des paquets installés depuis des registres publics, eux-mêmes dépendant d'autres paquets. La part de code réellement tapée par le développeur dépasse rarement une fraction du livrable final.
Cette industrialisation a un revers : chaque dépendance importée est une surface d'attaque héritée. Une faille dans une librairie de désérialisation, un paquet compromis par injection malveillante dans la chaîne d'approvisionnement (attaque dite de supply chain), et c'est tout l'applicatif livré qui devient vulnérable, indépendamment de la qualité de votre propre code.
La question juridique devient alors brûlante : quand cette brèche est exploitée chez votre client, êtes-vous responsable d'un défaut que vous n'avez pas créé ?
Ce que dit le droit : le livrable est un tout indivisible
La réponse juridique est nette et peut surprendre : le droit ne distingue pas votre code de celui que vous intégrez. Vous livrez une solution fonctionnelle, et vous répondez de cette solution dans son ensemble. L'origine open source d'un composant défaillant ne vous exonère pas vis-à-vis de votre client, avec qui vous êtes seul lié contractuellement.
Autrement dit, choisir d'intégrer une dépendance est en soi un acte technique engageant votre responsabilité. Si vous retenez une librairie abandonnée, non maintenue ou réputée vulnérable, ce choix peut être qualifié de fautif au titre de votre devoir de conseil et de compétence.
Le client ne vous a pas payé pour assembler des briques au hasard. Il vous a payé pour votre expertise dans le choix et l'intégration de ces briques. C'est précisément cette expertise que le juge évalue en cas de litige.
L'impasse des licences open source : aucune garantie en amont
Le réflexe naturel serait de se retourner contre l'auteur de la librairie défaillante. C'est une impasse presque totale.
Les licences open source les plus répandues contiennent toutes une clause d'exclusion de garantie en lettres capitales : le logiciel est fourni « en l'état », sans aucune garantie de qualité, de sécurité ou d'adéquation à un usage. Les contributeurs déclinent expressément toute responsabilité. Vous ne pouvez donc pas reporter la charge sur la communauté qui a produit le composant.
Cette asymétrie est structurante : vous bénéficiez gratuitement d'un code, mais vous en assumez seul le risque dès lors que vous l'intégrez dans une prestation payante. Le maillon contractuel et financier de la chaîne, c'est vous.
- Le client se retourne contre vous, son cocontractant.
- Vous ne pouvez pas vous retourner contre l'éditeur open source.
- Le risque reste donc concentré sur le développeur intégrateur.
Le devoir de vigilance : une obligation qui dure après la livraison
Intégrer un composant sain à l'instant T ne suffit pas. Les vulnérabilités sont découvertes en continu et publiées sous forme de CVE (références publiques de failles). Une librairie réputée sûre aujourd'hui peut être déclarée critique demain.
Pendant la phase de maintenance, le développeur est tenu d'une obligation de veille raisonnable : suivre les alertes de sécurité, mettre à jour les dépendances vulnérables, et alerter le client lorsqu'une faille majeure affecte sa solution. Ignorer une CVE critique publiée depuis des mois, alors qu'un contrat de maintenance était en cours, expose à un reproche de négligence caractérisée.
Les bonnes pratiques attendues d'un professionnel diligent :
- Tenir un inventaire des dépendances (un SBOM, ou nomenclature logicielle) pour savoir ce qui compose réellement la solution.
- Automatiser l'analyse de vulnérabilités dans la chaîne d'intégration continue.
- Cadrer contractuellement la maintenance : préciser si la veille sécurité est incluse, et à quelle fréquence les mises à jour sont appliquées.
- Tracer les alertes transmises au client, surtout lorsqu'il refuse ou diffère une mise à jour critique.
Un environnement réglementaire qui durcit vos obligations
La responsabilité du développeur sur sa chaîne d'approvisionnement logicielle n'est plus seulement une affaire de jurisprudence contractuelle. Le cadre européen se structure pour responsabiliser les éditeurs et intégrateurs sur la sécurité des produits qu'ils mettent sur le marché.
Les nouveaux textes européens consacrés à la cybersécurité des produits numériques imposent progressivement des exigences de sécurité dès la conception (security by design), de gestion des vulnérabilités sur tout le cycle de vie, et de transparence sur les composants intégrés. La logique d'ensemble : celui qui met un produit logiciel sur le marché doit en garantir un niveau de sécurité minimal et corriger les failles découvertes.
Pour un prestataire de développement, cela renforce concrètement plusieurs attentes :
- Maintenir une nomenclature des composants à jour et documentée.
- Disposer d'un processus de traitement des vulnérabilités formalisé, pas improvisé.
- Informer le client et, dans certains cas, les autorités, en cas de faille activement exploitée.
Le sens de l'histoire est clair : ce qui relevait hier de la bonne pratique devient une obligation opposable. Ne pas l'anticiper, c'est cumuler le risque contractuel et le risque réglementaire.
Comment l'assurance répond à un risque que vous ne maîtrisez pas seul
Le paradoxe de la supply chain logicielle, c'est qu'elle fait peser sur vous un risque dont la source vous échappe en partie. C'est exactement le terrain où l'assurance prend tout son sens.
La RC Pro couvre le préjudice immatériel subi par votre client lorsqu'une faille de la solution livrée, y compris d'origine tierce, engage votre responsabilité : perte d'exploitation, frais de remédiation, défense face aux réclamations.
La garantie Cyber intervient sur le volet incident de sécurité proprement dit : gestion de crise, notification, expertise forensic, frais de restauration lorsque la vulnérabilité a été exploitée pour exfiltrer des données ou déployer un rançongiciel. Pour un développeur, c'est le complément quasi indispensable de la RC Pro.
Enfin, lorsque le parc machine et les outils de développement sont eux-mêmes une cible (poste compromis, serveur de build), l'assurance du matériel informatique protège l'outil de production. Pour bâtir une couverture cohérente avec votre activité, partez de la page dédiée au développement de logiciels.
Questions fréquentes
Vis-à-vis de votre client, oui, car vous lui livrez une solution dont vous répondez dans son ensemble. Le choix d'intégrer un composant engage votre expertise. Vous ne pouvez pas opposer à votre client l'origine open source d'un défaut, d'autant que les licences excluent toute garantie de l'auteur.
En pratique, presque jamais. Les licences open source courantes fournissent le logiciel « en l'état » et excluent expressément toute garantie et toute responsabilité des contributeurs. Le risque financier reste donc concentré sur vous, l'intégrateur, qui êtes le seul lié contractuellement au client.
Non, dès lors qu'un contrat de maintenance est en cours. Vous êtes alors tenu d'une veille raisonnable sur les vulnérabilités publiées et de mettre à jour les dépendances critiques, ou au minimum d'alerter le client. En l'absence de contrat de maintenance, précisez par écrit que cette veille n'est pas incluse.
En conservant les traces de votre vigilance : inventaire des dépendances, rapports d'analyse de vulnérabilités, e-mails d'alerte au client, journal des mises à jour appliquées. Ces écrits démontrent que vous avez agi en professionnel avisé, ce qui pèse lourd dans l'appréciation de votre responsabilité.
Très souvent oui. Quand une faille, même tierce, est exploitée chez votre client pour voler des données ou déployer un rançongiciel, la garantie Cyber finance la gestion de crise, l'expertise et la restauration. La RC Pro indemnise le préjudice, le Cyber prend en charge la réponse technique à l'incident : les deux se complètent.
Souscrivez votre assurance pro en 2 minutes
Toutes nos protections pour votre activité de Développement et programmation de logiciels — attestation immédiate, sans engagement.
* Tarifs indicatifs « à partir de », selon votre profil, votre activité et les garanties choisies. · Voir la fiche Développement et programmation de logiciels →
Article rédigé et vérifié par l'équipe Insurio — Tutassûr, courtier en assurance immatriculé à l'ORIAS sous le n° 22001730. Information à caractère général ne se substituant pas aux conditions de votre contrat.