Imaginez un stagiaire brillant, très rapide, qui ne dort jamais et rédige en quelques secondes des centaines de lignes de code. Il est souvent juste, mais il se trompe parfois avec un aplomb total. C’est, en simplifiant, ce que sont devenus les assistants de code et les agents d’IA dans les équipes de développement. Ils ne se contentent plus de suggérer une ligne, ils ouvrent des pull requests, modifient plusieurs fichiers et proposent des correctifs complets.

La question qui remonte à la DSI est simple : quand ce code provoque un incident, une faille ou un litige de propriété intellectuelle, qui en est le responsable ?

Ligne de code via IA l’usage est devenu la norme

Selon l’enquête Stack Overflow 2025, 84 % des répondants utilisent ou prévoient d’utiliser des outils d’IA dans leur développement, contre 76 % l’année précédente, et 51 % des développeurs professionnels s’en servent chaque jour. Dans les organisations qui les ont adoptés, Veracode estime que l’IA rédige désormais environ la moitié du code qui est ensuite validé. Ce dernier chiffre vient d’un éditeur de sécurité et reste à prendre comme un ordre de grandeur, pas comme une statistique universelle

Le cadre réglementaire se resserre

Deux textes européens comptent particulièrement :

• Le Cyber Resilience Act (CRA) impose, depuis le 11 septembre 2026, de notifier les vulnérabilités activement exploitées dans les produits comportant des éléments numériques.
• La directive 2024/2853 sur la responsabilité du fait des produits défectueux inclut explicitement le logiciel. Les États membres doivent la transposer avant le 9 décembre 2026.

le fait qu’une IA ait écrit le code n’est pas une défense. C’ est celui qui met le produit sur le marché qui en reste le responsable.

Encadrer l’usage plutôt que l’interdire

Interdire les assistants de code est irréaliste, les développeurs les utilisent déjà, avec ou sans autorisation. Mieux vaut donc poser un cadre autour de quatre questions.

• Quels outils, à quelles conditions contractuelles ? Il faut savoir si le code envoyé sert à entraîner le modèle, où il est traité et quelles garanties de confidentialité s’appliquent. C’est le même raisonnement que pour n’importe quel sous-traitant.
• Que devient la propriété intellectuelle ? Un modèle peut reproduire des motifs issus de code sous licence copyleft (des licences qui imposent de rouvrir le code qui les réutilise). Il faut donc des outils de détection de similarité et des clauses claires avec les prestataires.
• Comment garder la trace ? Étiqueter les commits ou les pull requests contenant du code assisté (un simple label suffit) permet de retrouver rapidement l’origine d’un problème.
• Qui est responsable ? Celui qui approuve la revue de code engage sa responsabilité, comme pour du code écrit à la main. Ce principe doit être écrit noir sur blanc dans la politique de développement.

La dette technique invisible

Le code généré est propre, lisible et généralement fonctionnel, donc difficile à critiquer. Or fonctionner et en être sûr sont deux choses différentes. Deux risques qui méritent une explication.

Des failles reproduites à grande échelle. Veracode a testé plus de 100 modèles sur des tâches de programmation courantes. Dans son rapport 2025, 45 % des échantillons de code ont échoué aux tests de sécurité et introduit des vulnérabilités du Top 10 OWASP, et Java affichait le pire résultat, avec 72 % d’échecs. La mise à jour 2026 est peu encourageante : le taux de réussite moyen aux tests de sécurité est de 56 %, presque inchangé par rapport aux 55 % du premier rapport. Les modèles progressent sur la syntaxe, beaucoup moins sur la sécurité, et le volume de code concerné augmente. Comme il s’agit d’une étude d’éditeur, elle sert de repère plutôt que de vérité absolue.

Des dépendances inventées. Ce risque porte un nom : le slopsquatting. Un modèle recommande parfois une bibliothèque qui n’existe pas. Un attaquant peut alors créer un paquet malveillant portant exactement ce nom, et le prochain développeur, ou le prochain agent autonome, qui lance l’installation télécharge le code piégé. Ce n’est pas un scénario théorique. Une étude présentée à USENIX Security 2025 a analysé 576 000 échantillons de code générés par 16 modèles. Résultat : 19,7 % de ces échantillons contenaient au moins un nom de paquet halluciné, soit 205 474 noms fictifs distincts. Les modèles commerciaux se trompent moins que les modèles ouverts (5,2 % contre 21,7 % en moyenne), mais aucun n’est immunisé. Les erreurs sont aussi prévisibles : 43 % des noms inventés reviennent à chaque nouvelle exécution, ce qui permet à un attaquant de les repérer et de les enregistrer à l’avance

Ce qu’il faut en retenir :

• Concentrer la revue humaine sur les zones sensibles : authentification, données personnelles, paiement.
• Tenir à jour une SBOM (Software Bill of Materials), c’est-à-dire l’inventaire des composants de chaque logiciel, à la manière d’une liste d’ingrédients. Elle est indispensable pour répondre aux exigences du CRA.
• Ne jamais laisser l’équipe qui génère le code être la seule à le tester.

Automatiser les garde-fous dans la chaîne CI/CD

Quand la production de code s’accélère, le contrôle doit suivre la même cadence. La chaîne CI/CD ( (CI=Intégration Continue et CD=Déploiement Continu ) est l’ensemble des étapes automatisées qui transforment du code en application déployée. C’est le bon endroit pour installer des contrôles qui ne dépendent pas de la vigilance de chacun.

• SAST (analyse statique) : un outil lit le code à la recherche de motifs dangereux, comme un correcteur orthographique de la sécurité.
• SCA (analyse de composition) : elle vérifie que les bibliothèques utilisées existent, sont saines et à jour. Elle répond directement au risque de slopsquatting.
• Détection de secrets : elle bloque les mots de passe et clés d’accès avant qu’ils ne soient enregistrés dans le code.
• Politique de dépendances : une liste de registres autorisés et l’épinglage des versions (lockfiles), pour qu’aucune installation ne se fasse au hasard.
• Signature des artefacts et provenance de build (type SLSA) : elles permettent de prouver ce qui a été déployé, par qui et comment.
• Environnements isolés pour les agents : un agent autonome ne doit jamais avoir d’accès direct à la production, et ses droits doivent rester minimaux.

Du codeur au contrôleur

L’IA ne supprime pas la responsabilité, elle la déplace, le développeur abandonne son rôle de rédacteur pour devenir relecteur. Dès lors, une question s’impose aux organisations : donnent-elles réellement à leurs équipes le temps, les compétences et les outils nécessaires pour exercer ce contrôle critique ? 

Le nœud du problème ne réside pas dans la performance intrinsèque des modèles, qui progresse à pas de géant, mais dans le décalage flagrant entre la vitesse de production du code et notre capacité humaine à le vérifier. Les données de Veracode l’illustrent parfaitement, alors que les volumes de code explosent, le taux de réussite aux tests de sécurité reste désespérément stable. 

Vers une gouvernance contractuelle du code tiers

Pour anticiper ce bouleversement, les DSI visionnaires refusent de voir l’IA comme un gain de productivité elles choisissent de traiter le code généré comme du code tiers, comme une ressource externe à inspecter, tracer et tester rigoureusement. 

L’ultime frontière de cette transition reste juridique. Demain, lorsque des agents autonomes prendront seuls des décisions d’architecture et de conception, la chaîne de responsabilité entre l’éditeur de l’outil, l’intégrateur et l’utilisateur final devra être totalement clarifiée d’abord à travers des clauses contractuelles sur mesure, puis par la force de la jurisprudence.