L’intelligence artificielle écrit le code. Qui en est responsable ?

L’intelligence artificielle rédigera en 2026 une part croissante du code des entreprises, les études sectorielles évoquant jusqu’à 40 %. Lorsque ce code plante en production ou ouvre une faille de sécurité, une question inconfortable s’impose au comité de direction : qui est responsable ? La réponse reste étonnamment souvent sans suite.

En lien :Quatre écueils : pourquoi les projets d’IA échouent en phase d’exploitation  /  Quand un modèle d’IA disparaît du jour au lendemain

Dans quelle mesure l’IA rédige-t-elle vraiment le code ?

Les chiffres varient selon les sources, mais la tendance est claire. Les études sectorielles estiment que la part de code générée par l’IA atteindra près de 40 % en 2026, avec une progression continue. Dans de nombreuses équipes de développement, l’assistant IA n’est plus une expérience, mais une composante du quotidien.

Qu’est-ce que le code généré par IA ? Il s’agit de code source produit par un assistant IA comme Copilot, Cursor ou un outil agentique, sur la base d’une instruction, et qu’un humain reprend, adapte ou intègre tel quel dans l’application. La responsabilité du résultat incombe formellement à l’entreprise, tandis que la paternité précise devient floue.

Avec cette part, un second chiffre augmente, moins souvent évoqué. Les études du secteur logiciel indiquent que le code généré par IA contient sensiblement plus de vulnérabilités et, sans contrôle rigoureux, accroît considérablement la dette technique. La vitesse génère du volume, et le volume sans vérification génère du risque.

Le vide juridique : quand personne n’est responsable

Le vrai danger ne réside pas dans le taux d’erreur, mais dans la responsabilité. Si l’on demande au sein des entreprises qui assume les dommages causés par un code généré par IA, les réponses se répartissent en trois camps. Les équipes de développement renvoient vers l’outil, la sécurité vers le développement, et les deux regardent du côté du fournisseur, dont le contrat limite généralement fortement la garantie.

Pour un membre de la direction, c’est un schéma connu sous un nouvel habillage. Une responsabilité partagée par tous finit par n’être assumée par personne. Tant qu’il reste flou qui valide un commit d’IA et en assume les conséquences, la chaîne de responsabilité fait défaut. Il subsiste un vide, et en cas de sinistre, c’est le comité de direction qui le comble, qu’il le veuille ou non.

S’ajoute à cela un problème pratique, que connaissent bien les responsables informatiques expérimentés issus de systèmes évolutifs. Le code généré par IA est souvent plus difficile à maintenir que du code écrit manuellement, car il manque la compréhension implicite qui naît de l’écriture personnelle. Lorsque le prompt initial est oublié et que le développeur est passé à autre chose, il reste un morceau de logiciel qui fonctionne… jusqu’à ce qu’il ne fonctionne plus.

Un scénario typique permet de mieux cerner la situation. Un assistant IA propose une fonction de bibliothèque, un développeur l’intègre sous la pression des délais, la revue de code l’approuve comme du code standard. Quelques semaines plus tard, cette même fonction ouvre une faille, car l’IA a suggéré une version obsolète et vulnérable. Lors du post-mortem, chacun renvoie la responsabilité à l’autre, et le DSI explique à son conseil de surveillance un incident que personne n’a consciemment provoqué. Ce schéma se répète tant que la validation n’a pas de visage.

Ce qui est en jeu sans gouvernance

En l’absence de règles de contrôle, trois risques s’additionnent, qui seraient maîtrisables individuellement mais deviennent coûteux ensemble. Un simple tableau comparatif montre où se situe la différence entre un code IA vérifié et un code non vérifié.

Le tableau semble simple, mais la différence ne l’est pas. Un contrôle exige une décision organisationnelle, pas un nouvel outil. C’est précisément sur ce point que de nombreux projets échouent, car ils délèguent le sujet au choix de l’outil, alors qu’il s’agit d’une décision managériale.

Les portes que doit désormais franchir un DSI

La sortie du vide passe par quelques règles strictes, ancrées dans le processus de développement. Quatre d’entre elles méritent une attention immédiate.

1. Obligation de révision pour le code IA. Chaque commit généré par IA subit la même révision humaine que le code écrit manuellement, assortie d’un scan de sécurité automatisé avant la fusion.
2. Un responsable par commit. Celui qui valide du code IA en assume la responsabilité. L’approbation porte un nom, pas le logo d’un outil.
3. Traçabilité de l’origine. Quelle partie provient de quel assistant, et avec quelle instruction ? Cette piste permet, en cas d’incident, de réduire la recherche d’erreurs de plusieurs semaines à quelques heures.
4. Clarifier la situation contractuelle avec le fournisseur. Avant un déploiement généralisé d’un outil, le service juridique vérifie les engagements du fournisseur. Ces garanties sont souvent limitées et doivent être examinées au cas par cas.

Aucun de ces quatre points ne nécessite de budget supplémentaire, mais tous exigent une décision. C’est précisément là que l’intention se distingue de la mise en œuvre. Une porte intégrée directement dans le pipeline de build est efficace. Une porte qui ne figure que dans une directive que personne ne lit ne coûte que le papier sur lequel elle est imprimée. Les responsables informatiques expérimentés ancrent donc cette obligation techniquement, pour qu’elle s’applique même à trois heures du matin, lorsque la pression des délais est maximale et la tentation de valider rapidement, la plus forte.

Qui porte la responsabilité dans l’entreprise

Des règles sans propriétaire s’évaporent. C’est pourquoi chaque décision de porte doit être associée à un rôle chargé de la faire respecter. En pratique, une répartition épurée a fait ses preuves : une personne responsable de l’IA au niveau de la direction, des propriétaires désignés par outil avec une responsabilité sur les résultats, un représentant de la sécurité pour l’évaluation des risques et des managers d’ingénierie pour le suivi quotidien.

L’essentiel est que ces rôles soient définis avant le prochain incident, et non après. Un comité de direction qui autorise l’utilisation de code IA sans répartir les responsabilités ne fait que reporter le problème au jour du premier incident sérieux. Les entreprises qui établissent dès maintenant une chaîne de responsabilité se dotent ainsi de la capacité à assumer l’usage de l’IA dans le code. Celles qui y renoncent ne font que reporter le problème au prochain incident.

Foire aux questions

Plus d’articles du réseau MBF Media

Source de l’image : générée par IA (juin 2026)