Qui est responsable d'une faille dans un code généré par IA ?

Introduction

La question de la responsabilité en cas de faille est celle qui préoccupe le plus les entreprises adoptant ces outils. Sa réponse est plus simple qu’attendu et moins favorable qu’espéré.

Le principe : la responsabilité de celui qui déploie

L’entreprise qui exploite un logiciel répond de son fonctionnement envers ses clients et envers les tiers.

Cette responsabilité ne dépend pas de la méthode de développement.

Un code écrit à la main, généré, ou repris d’un composant tiers engage de la même manière celui qui le met en production.

L’usage d’un outil n’est ni une circonstance atténuante ni un fait exonératoire.

La position de l’éditeur de l’outil

Ses conditions excluent généralement toute garantie sur les productions.

Elles précisent fréquemment que les productions peuvent être inexactes, incomplètes ou inadaptées, et qu’il appartient à l’utilisateur de les vérifier.

Elles limitent fortement sa responsabilité, souvent à un montant correspondant aux sommes versées sur une période courte.

Une action contre l’éditeur au titre d’une faille est donc, en l’état des conditions usuelles, largement dépourvue de perspective.

L’obligation de sécurité

Elle a plusieurs sources.

L’obligation contractuelle envers les clients, souvent explicitée dans les engagements de sécurité.

L’obligation de sécurité des traitements de données personnelles, qui impose des mesures appropriées au regard du risque et de l’état des connaissances.

Les obligations sectorielles, selon l’activité.

Pour les produits comportant des éléments numériques, les obligations issues du règlement européen sur la cyberrésilience, dont les obligations de signalement sont applicables depuis le 11 septembre 2026.

Aucune de ces obligations n’admet d’exception tenant à la méthode de développement.

L’appréciation de la faute

En cas d’incident, l’analyse porte sur les mesures mises en œuvre.

Une faille résultant d’une vulnérabilité connue, non détectée faute de tests, caractérise un manquement.

Une faille résultant d’un défaut subtil, non détectable par les moyens usuels, s’apprécie différemment.

Le recours à un outil génératif, sans revue humaine ni tests de sécurité, aggrave l’appréciation : il caractérise une absence de diligence, non une circonstance atténuante.

À l’inverse, une chaîne de vérification documentée, avec analyse statique, tests de sécurité et revue humaine, démontre la diligence attendue.

Les vulnérabilités caractéristiques

Les analyses disponibles montrent que le code généré présente une proportion non négligeable de vulnérabilités, comparable à celle du code humain mais avec des profils particuliers.

Les défauts les plus fréquemment relevés portent sur la validation des entrées, la gestion des secrets, les configurations par défaut trop permissives, l’usage de bibliothèques obsolètes et les mécanismes d’authentification simplifiés.

Ces catégories doivent orienter les contrôles automatisés.

La chaîne de vérification attendue

L’analyse statique du code, intégrée à la chaîne de construction.

L’analyse des dépendances et de leurs vulnérabilités connues.

Les tests de sécurité applicatifs.

La revue humaine du code produit, en particulier des portions touchant à l’authentification, aux autorisations, au traitement des entrées et à la gestion des secrets.

Une politique de correction des vulnérabilités, avec des délais différenciés par gravité.

Cette chaîne relève de l’ingénierie, mais sa documentation constitue la démonstration juridique.

La répartition avec les prestataires

Lorsque le développement est confié à un tiers, le contrat doit répartir les obligations.

Une obligation de revue humaine du code produit, expressément stipulée.

Une obligation d’exécuter les contrôles de sécurité et d’en communiquer les résultats.

Une garantie contre les vulnérabilités résultant d’un manquement à ces obligations.

Une obligation d’assurance de responsabilité civile professionnelle.

Cette répartition organise le recours ; elle ne modifie pas la responsabilité envers les clients et les tiers.

Les obligations de signalement

Depuis le 11 septembre 2026, le règlement européen sur la cyberrésilience impose, pour les produits comportant des éléments numériques, le signalement des vulnérabilités activement exploitées et des incidents graves.

Le calendrier est exigeant : alerte précoce dans les vingt-quatre heures, notification complète dans les soixante-douze heures, rapport final au plus tard quatorze jours après la mise à disposition d’une mesure corrective.

Le champ du règlement vise les produits comportant des éléments numériques mis sur le marché : un service en ligne pur n’y est en principe pas soumis, mais une solution de traitement de données à distance indispensable au fonctionnement d’un produit y entre.

Cette qualification doit être examinée.

Documenter la vérification, pas la méthode

Ce qui est examiné après un incident est la diligence, non l’outil employé. Notre expertise en droit du numérique accompagne ces dispositifs.

En résumé

• Celui qui déploie le code en répond, quelle que soit la méthode de développement.
• Les conditions des outils excluent toute garantie sur les productions.
• L’usage sans revue ni tests aggrave l’appréciation de la faute.
• Analyse statique, analyse des dépendances, tests de sécurité et revue humaine constituent la chaîne attendue.
• Les obligations de signalement du règlement sur la cyberrésilience s’appliquent depuis le 11 septembre 2026.