Le code écrit par l'IA est-il sûr ? Ce que disent les études indépendantes — et ce qu'il faut en mettre dans le contrat

Quand une PME évalue un prestataire qui développe avec l'IA, la question qu'elle pose presque toujours porte sur la qualité : « ça se voit, que c'est écrit par une machine ? ». C'est la question la moins utile. Sur la qualité perçue, on discute à l'infini et on corrige par une relecture. Le risque sérieux, celui que les données indépendantes mesurent vraiment, est ailleurs : la sécurité. Et il a une caractéristique désagréable — il ne se voit pas à la livraison, il se voit des mois plus tard, quand c'est devenu le vôtre.

Les travaux académiques indépendants publiés entre 2022 et 2026 disent trois choses distinctes, et aucune des trois n'est « l'IA écrit du code non sécurisé, donc ne l'utilisez pas ». Ils disent qu'une part non négligeable du code généré naît vulnérable ; que les refus d'un modèle en chat ne survivent pas à leur insertion dans un flux de travail réel ; et que l'automatisation agentique de la chaîne de livraison ouvre une surface d'attaque déjà exploitée. Trois choses qu'un acheteur peut mettre dans le contrat — ou découvrir après.

1. Une partie du code généré naît vulnérable

La donnée de référence date de 2022 et elle est académique, pas issue d'un fournisseur. Pearce et ses collègues ont fait générer à GitHub Copilot 1 689 programmes sur 89 scénarios construits autour des faiblesses les plus courantes, et ont constaté qu'environ 40 % des programmes générés contenaient une vulnérabilité (Pearce et al., « Asleep at the Keyboard? », IEEE S&P 2022). Pas sur du code inventé pour piéger l'outil : sur des scénarios ordinaires, du type de ceux qu'une entreprise commande chaque semaine.

Une répartition par langage circule aussi — autour de 50 % en C contre 39 % en Python. Nous la citons avec une réserve explicite, parce que c'est ainsi qu'elle doit être citée : cette ventilation provient de synthèses secondaires de l'étude et nous ne l'avons pas vérifiée sur le document original. Le chiffre sur lequel s'appuyer est le chiffre global. Et la bonne lecture n'est pas « 40 % du logiciel livré est troué » : c'est qu'un générateur n'a, en soi, aucune raison de produire du code sécurisé. La sécurité n'est pas une propriété émergente de la génération. C'est un contrôle que quelqu'un doit mettre autour.

2. Le refus en chat ne survit pas au flux de travail

C'est ici que se trouve le résultat le plus récent et le plus gênant, celui qui démonte la rassurance standard du prestataire (« ne vous inquiétez pas, le modèle refuse d'écrire ce genre de choses »). Une équipe de l'Alan Turing Institute a pris 204 requêtes malveillantes et les a soumises à GitHub Copilot Chat de deux façons. En chat direct, le modèle a refusé 808 fois sur 816. Les mêmes requêtes, découpées et insérées dans un flux de travail multi-tours ordinaire au sein de l'éditeur, ont produit une complétion malveillante 816 fois sur 816 (Kumar & Maple, « Refused in Chat, Written in Code », 2026).

Le point n'est pas « Copilot Chat renvoie du code dangereux ». Le point est que la protection vit au niveau de la conversation tandis que le vrai travail se déroule au niveau du flux : construire la requête au fil de plusieurs étapes d'une activité de développement ordinaire contourne un refus qui, interrogé frontalement, fonctionne presque toujours. Un contrôle placé au mauvais endroit est, en pratique, un contrôle qui n'existe pas.

Pour qui achète du logiciel, la conséquence est précise, et ce n'est pas un détail de chercheurs : la sécurité du modèle n'est pas une garantie dont vous héritez du fournisseur du modèle. Elle doit être vérifiée dans le processus de celui qui vous livre le code — avec des outils qui lisent le résultat, et non les bonnes intentions de celui qui l'a demandé.

3. Plus de code généré, une chaîne plus bruyante (une corrélation, pas une cause)

La troisième étude regarde ce qui se passe en aval, dans la chaîne de build et de livraison. Ont été analysées 61 837 exécutions de CI sur 2 355 dépôts déclenchées par cinq bots de programmation IA différents : Copilot et Codex affichent les taux de succès les plus élevés (autour de 93-94 %), les autres plus bas. La donnée intéressante est cependant ailleurs : dans les dépôts présentant une fréquence plus élevée de pull requests générées par l'IA, on observe un taux de succès global des workflows plus bas (« Reliability of AI Bots Footprints in GitHub Actions CI/CD Workflows », 2026).

C'est une corrélation, et il faut le dire clairement : l'étude ne démontre pas que les PR générées par l'IA font échouer la chaîne. Il se peut très bien que les projets les plus exposés à l'IA soient aussi les plus mouvementés. Mais pour qui doit décider, il reste là une information exploitable : un volume élevé de contributions automatiques s'accompagne d'un signal de build plus bruyant, et une chaîne bruyante est précisément l'endroit où un vrai échec cesse de se faire remarquer. Celui qui évalue un prestataire ne devrait pas demander « utilisez-vous l'IA ? », mais « quel est le taux de vert de votre chaîne, et qui regarde les rouges ? ».

4. La chaîne elle-même est devenue une cible

Le quatrième élément, nous l'avons déjà raconté en détail ailleurs, une ligne suffit donc ici : quand ce sont les agents qui écrivent et font tourner les workflows, le workflow lui-même devient surface d'attaque, avec des centaines de vulnérabilités d'injection confirmées exploitables sur des dépôts réels (arXiv:2605.07135) — la décomposition se trouve dans notre article sur ce qui fonctionne réellement de l'IA dans le développement. Aligné avec les trois précédents, il referme le tableau : le risque ne réside pas seulement dans le code livré, il réside aussi dans ce que l'automatisation a le droit d'exécuter pour votre compte.

Ce qu'il faut écrire dans le contrat (et non ce qu'il faut espérer)

Tout ce qui précède se traduit en clauses, pas en méfiance. Aucune d'elles n'exige de compétences techniques pour être exigée, et toutes sont vérifiables :

• Qui relit, et avant quoi. Mettez par écrit que chaque modification passe par une revue humaine identifiable avant la mise en production, et que l'approbation automatique n'est pas admise sur les chemins sensibles (authentification, paiements, données personnelles). Pas « on fait de la code review » : qui signe, et sur quels chemins la barrière ne s'ouvre jamais toute seule.
• Analyse statique et recherche de secrets comme obligation, non comme bonne habitude. Une analyse automatique des vulnérabilités (SAST) et le scan des secrets tournent sur chaque modification, avec le résultat joint à la livraison. C'est le contrôle qui répond directement aux 40 % de Pearce et au problème du refus contourné : il vérifie le résultat, pas l'intention.
• À qui appartient une vulnérabilité découverte après la livraison. C'est la clause qui manque presque toujours. Définissez une fenêtre de responsabilité, les délais de correction par gravité et qui paie : sans cela, le coût des 40 % retombe entièrement sur vous, des mois après avoir signé la recette.
• Ce que la chaîne a le droit d'exécuter. Quelles automatisations ont accès aux identifiants de production, lesquelles peuvent ouvrir et intégrer des modifications toutes seules, et ce qui exige une action humaine. Si l'automatisation peut pousser du code jusqu'en production sans signature, le périmètre de sécurité n'est pas celui que vous croyez.
• Où finit votre code. Quels outils IA sont utilisés sur votre dépôt, si le code alimente l'entraînement de tiers et comment les secrets sont gérés dans l'environnement de développement. Ce sont les mêmes questions à poser à n'importe quel prestataire SaaS — nous les avons rassemblées ici.

Aucune de ces clauses n'interdit l'IA. Toutes déplacent le risque là où il peut être géré : dans le processus du prestataire, avant la livraison, plutôt que dans votre bilan après.

Notre position, dite de l'intérieur

Nous écrivons du code avec l'IA tous les jours, sur ce site et sur nos produits — et c'est précisément pour cela que notre processus ressemble beaucoup à la liste ci-dessus : chaque modification franchit une série de contrôles au vert, une revue humaine avant la mise en production et des automatisations aux permissions explicites et restreintes, sans raccourci sur les chemins critiques. Ce n'est pas de la prudence de plaquette : c'est l'infrastructure qui transforme la vitesse de l'IA en un avantage qui dure, plutôt qu'en une dette de sécurité à régler plus tard. Un prestataire qui a déjà dû construire ces contrôles vous le dit ; celui qui ne vend que la démo, pas encore.

La décision à prendre

Ce n'est pas « IA oui ou IA non ». C'est une seule question, et elle se pose avant de signer : lesquelles de ces clauses figurent déjà dans le contrat que vous vous apprêtez à accepter ? Si la réponse est aucune, le problème n'est pas l'outil qu'utilise votre prestataire — c'est que le risque de sécurité est, en l'état, entièrement le vôtre et qu'il n'est écrit nulle part.

Si vous évaluez un prestataire ou si vous vous apprêtez à faire entrer l'IA dans votre développement, les contrôles que nous rattachons à chaque flux — y compris ceux de conformité — sont décrits dans notre overlay de conformité. Et pour comprendre par quel service il vaut mieux commencer, avec quels contrôles autour, nous avons transformé le premier pas en une évaluation self-service et gratuite : faites l'évaluation d'AI-readiness — puis, si cela a du sens, nous en parlons.

Cet article a une visée d'orientation. Les chiffres cités proviennent d'études académiques indépendantes, menées sur des outils et des périodes spécifiques : ils doivent se lire comme des indications de direction sur le type de risque, non comme une mesure du code que vous recevrez. La répartition par langage de l'étude de 2022 est rapportée par des synthèses secondaires et n'a pas été vérifiée sur le document original. Ce texte ne constitue ni un conseil juridique ni une évaluation de sécurité : chaque contrat doit s'apprécier au regard du contexte de l'entreprise concernée.