Code généré par IA : sécuriser la chaîne de développement quand une partie du code n’est plus écrite par des humains

Une part du code n’a plus d’auteur humain

Les assistants de programmation fondés sur des grands modèles de langage se sont installés dans les directions informatiques, y compris dans la banque et l’assurance. L’ANSSI et son homologue allemand, le BSI, le constataient dès octobre 2024 : ces outils sont déjà largement utilisés dans de nombreuses organisations publiques et privées. Ils complètent des fonctions, suggèrent des bibliothèques, rédigent des tests et peuvent, par des extensions, agir pour le compte du développeur.

Le risque applicatif n’en est pas bouleversé, mais son échelle change. Le volume de code augmente alors que la capacité de relecture reste celle des équipes. Le code proposé est fluide et bien présenté, ce qui pousse à l’accepter sans l’examiner : c’est le biais d’automatisation décrit par l’ANSSI et le BSI. Et des choix qui engageaient un développeur, comme celui d’une dépendance, reviennent désormais à un modèle statistique.

Cet article examine quatre risques propres au code généré (dépendances inventées, vulnérabilités reproduites, secrets exposés, origine du code perdue), les référentiels et les textes applicables à la finance, puis les contrôles à placer dans la chaîne de développement. Il complète les articles consacrés aux attaques de supply chain logicielle et aux agents IA autonomes.

Des dépendances inventées, puis enregistrées par l’attaquant

Un assistant de code propose aussi les bibliothèques à importer, et il lui arrive d’en citer qui n’existent pas. Ce phénomène, appelé hallucination de paquets, a été mesuré par une équipe de l’université du Texas à San Antonio, de l’université de l’Oklahoma et de Virginia Tech, dans une étude présentée au USENIX Security Symposium en août 2025. Sur 576 000 échantillons de code Python et JavaScript produits par 16 modèles, 19,7 % des 2,23 millions de références à des paquets renvoyaient à des paquets inexistants : au moins 5,2 % en moyenne pour les modèles commerciaux, 21,7 % pour les modèles en source ouverte. L’étude recense 205 474 noms inventés distincts.

Ce qui rend le phénomène exploitable, c’est sa répétabilité. En soumettant dix fois 500 requêtes ayant produit des hallucinations, les auteurs ont constaté que 43 % des paquets inventés réapparaissaient à chaque itération. Un attaquant peut donc repérer les noms inventés récurrents et publier sous ces noms des paquets malveillants sur les registres publics. Le développeur qui installe la dépendance suggérée exécute alors son code. L’OWASP comme l’ENISA désignent désormais cette attaque, cousine du typosquattage, sous le nom de « slopsquatting ».

Autre résultat : la plupart des noms inventés ne sont pas des fautes de frappe. Seuls 13,4 % de ceux analysés différaient d’un ou deux caractères du paquet existant le plus proche, ce qui limite l’utilité des outils qui repèrent les imitations de noms connus. L’attaque ne requiert d’ailleurs ni vulnérabilité inconnue ni intrusion : il suffit de publier un paquet et d’attendre.

Des vulnérabilités reproduites à l’échelle

Deuxième risque : un assistant reproduit des schémas appris sur de grands volumes de code public, y compris des pratiques dépassées. Une équipe de l’université de New York a fait compléter 89 scénarios par un assistant de code, dans une étude présentée en 2022 au symposium de l’IEEE sur la sécurité et la vie privée : environ 40 % des 1 689 programmes obtenus étaient vulnérables. Une étude de l’université Stanford, présentée à la conférence ACM CCS en 2023, a montré que les participants aidés d’un assistant écrivaient un code significativement moins sûr, tout en étant plus enclins à le croire sûr.

L’ANSSI et le BSI en concluent que les assistants actuels ne peuvent pas garantir un code de qualité, et que des failles légères comme graves sont couramment présentes dans les extraits proposés. Ils citent le stockage des mots de passe, pour lequel MD5 ou une seule itération de SHA-256 sont encore souvent employés.

Ce qui change, c’est la propagation. Un motif vulnérable, comme une requête SQL construite par concaténation, peut être suggéré à des centaines de développeurs. La faille devient une famille de failles : un argument pour une gestion des vulnérabilités qui raisonne par motif de code, et pas seulement par composant.

Secrets exposés, origine perdue

Le troisième risque concerne les secrets, dans les deux sens. Vers le fournisseur d’abord : l’assistant hébergé reçoit le contexte de l’environnement de développement. L’ANSSI et le BSI soulignent que des informations sensibles, comme des clés d’API ou des descriptions d’infrastructure sous forme de code, peuvent fuir par les requêtes selon les conditions contractuelles du fournisseur, notamment en matière de réutilisation pour l’entraînement. Ils décrivent aussi des injections de requête indirectes : des instructions cachées dans la documentation d’un paquet peuvent amener l’assistant à proposer du code malveillant ou à exfiltrer des informations.

Vers le dépôt ensuite : un code accepté sans relecture peut embarquer un identifiant en dur, repris du contexte ou donné en exemple. L’ANSSI demande, dans ses essentiels DevSecOps, de s’assurer de l’absence de secrets en dur dans le code, les journaux des tâches et les dépôts. Le sujet rejoint celui des identités machine et des secrets : un secret passé par un assistant ou par un dépôt doit être traité comme exposé.

Le quatrième risque est la perte de traçabilité. Une modification porte le nom de la personne qui l’a validée, pas celui de l’outil qui l’a rédigée, ni la raison du choix d’une dépendance. L’ENISA relève que déléguer ces choix à un modèle réduit la visibilité sur leurs motifs. L’ANSSI et le BSI suggèrent de signaler les blocs de code générés, de documenter les outils employés et de tenir l’inventaire des assistants utilisés : si l’un d’eux s’avère empoisonné, cet inventaire aidera à savoir si l’établissement est concerné.

Des référentiels qui ont pris acte du sujet

Le GenAI Security Project de l’OWASP a publié en août 2026 l’édition 2026 de son Top 10 pour les applications LLM. L’édition 2025 traitait déjà la génération de code non sûr sous l’angle de la désinformation ; la nouvelle répartit le sujet sur trois entrées. LLM04:2026, sur la chaîne d’approvisionnement, décrit le « slopsquatting » et demande de vérifier qu’une dépendance suggérée par l’IA existe et correspond au paquet voulu. LLM07:2026 (désinformation) cite le code et les dépendances fabriqués. LLM10:2026 (traitement inapproprié des sorties) couvre désormais le code non sûr généré à grande échelle, avec un scénario explicite : du code généré compilé et déployé sans revue humaine ni test de sécurité.

Côté français, le guide de l’ANSSI sur la sécurité des systèmes d’IA générative (ANSSI-PA-102, avril 2024) consacre trois recommandations au code généré : le contrôler systématiquement (R30), limiter la génération pour les modules critiques (R31), sensibiliser les développeurs (R32). La publication conjointe de l’ANSSI et du BSI, « AI Coding Assistants » (octobre 2024), rappelle que ces outils ne remplacent pas des développeurs expérimentés, demande une analyse de risque avant leur introduction et une vérification du code généré par les développeurs. L’avis technique de l’ENISA sur l’usage sécurisé des gestionnaires de paquets (version 1.1, mars 2026) traite enfin du « vibe coding », lorsque la plus grande partie du code est déléguée à l’IA avec peu ou pas de revue humaine.

Dans la finance, un sujet de risque TIC avant d’être un sujet d’IA

Pour une banque ou un assureur, le code généré par IA n’appelle pas de régime propre : il entre dans des obligations existantes, qu’il rend plus difficiles à tenir.

DORA impose une gestion des changements garantissant que tous les changements apportés aux systèmes de TIC sont consignés, testés, évalués, approuvés, mis en œuvre et vérifiés de manière contrôlée (article 9, paragraphe 4, point e)). Pour les entités soumises au cadre général de gestion du risque TIC, le règlement délégué (UE) 2024/1774 précise à son article 16 que la procédure de développement comprend des examens du code source avec tests statiques et dynamiques, des contrôles protégeant l’intégrité du code source et, dans la mesure du possible, l’analyse avant mise en production du code issu de prestataires ou de projets en source ouverte. Son article 17 exige l’indépendance entre les fonctions qui approuvent les changements et celles qui les demandent et les mettent en œuvre. L’article 16 vise aussi, selon une approche fondée sur les risques, les systèmes développés hors de la fonction TIC, comme les outils que des équipes métiers produisent avec un assistant. L’assistant lui-même, fourni sous forme de service, relève, comme tout service TIC fourni par un tiers, du registre d’informations DORA prévu à l’article 28, paragraphe 3.

Le Cyber Resilience Act ne concerne l’établissement que s’il est fabricant d’un produit comportant des éléments numériques. Il exige alors, à partir du 11 décembre 2027, un produit conçu et développé de manière à garantir un niveau de cybersécurité approprié aux risques (annexe I, partie I) et une diligence raisonnable sur les composants tiers intégrés (article 13, paragraphe 5), dont font partie les dépendances suggérées par un assistant. Quant à l’AI Act, ses cas d’usage à haut risque visent, pour la finance, l’évaluation de la solvabilité et la tarification en assurance vie et maladie (annexe III, point 5) : un assistant de code n’en fait pas partie.

Des portes de sécurité dans la chaîne d’intégration

Les contrôles doivent être automatisés et placés là où tout le code passe : la chaîne d’intégration et de déploiement continus. Une porte de sécurité (« security gate ») y bloque une modification tant que des critères définis ne sont pas remplis. L’ANSSI recommande d’y prévoir des tests de sécurité automatisés, dont des analyses statique et dynamique.

Analyser le code avant la fusion. L’analyse statique (SAST) recherche dans le code modifié les motifs vulnérables, comme les injections ou la cryptographie faible. Exécutée à chaque demande de fusion, elle rattrape une partie des motifs que les assistants répètent.

Analyser ce que le code importe. L’analyse de composition logicielle (SCA) inventorie les dépendances directes et transitives, les confronte aux vulnérabilités connues et alimente la nomenclature logicielle (SBOM). Face au « slopsquatting », elle doit aussi signaler les paquets absents du registre interne ou trop récents.

Chercher les secrets à chaque étape. Sur le poste avant la validation, dans la chaîne d’intégration et dans l’historique des dépôts.

Bloquer, et pas seulement signaler. Une porte qui n’arrête jamais une fusion n’en est pas une. Les critères sont explicites (aucune vulnérabilité critique introduite, aucune dépendance non approuvée, aucun secret), et les exceptions motivées et limitées dans le temps.

Ces outils ont des limites : des faux positifs qui usent la confiance des équipes et une faible capacité à repérer les erreurs de logique métier, comme un contrôle d’autorisation mal placé. Les tests d’intrusion restent nécessaires, et le règlement délégué prévoit des tests de sécurité pour les systèmes exposés à l’internet.

Filtrer les dépendances avant qu’elles n’entrent

Contre les dépendances inventées, le contrôle le plus efficace se place en amont : empêcher l’installation d’un paquet inconnu.

Un registre interne comme source unique. Postes de développement et chaîne d’intégration ne récupèrent les paquets que par un dépôt d’artefacts interne, seul intermédiaire avec les registres publics, où filtrer, journaliser et bloquer.

Une liste d’autorisation. L’ANSSI et le BSI évoquent une liste blanche des paquets autorisés, et l’ENISA une liste interne de paquets ou de mainteneurs approuvés. Ajouter une dépendance devient une décision tracée, et non l’effet d’une suggestion acceptée.

Vérifier l’existence ne suffit pas. L’attaquant a pu enregistrer le nom inventé : l’existence d’un paquet ne prouve pas sa légitimité. L’ANSSI et le BSI recommandent d’en examiner la plausibilité (date de création, niveau d’usage, activité du dépôt source), et l’ENISA invite à se méfier des paquets détenus par des comptes récemment créés, sans autre contributeur.

Figer et contenir. Les fichiers de verrouillage avec empreintes d’intégrité, la désactivation des scripts d’installation dans la chaîne d’intégration et le confinement de l’environnement de développement limitent l’impact d’un paquet malveillant qui aurait passé les filtres.

Protéger les dépôts et attester l’origine des artefacts

Le dépôt est l’actif central de la chaîne : mal protégé, il rend contournables les contrôles placés en aval.

Contrôler qui peut écrire. DORA demande de limiter l’accès logique aux actifs de TIC à ce qui est nécessaire aux fonctions légitimes (article 9, paragraphe 4, point c)). Pour les dépôts, cela signifie moindre privilège, authentification multifacteur pour l’accès et pour la signature des commits, comme le recommande l’ANSSI, protection des branches principales et revue obligatoire par une autre personne que l’auteur. Les extensions et agents qui agissent pour les développeurs reçoivent des droits limités : l’ANSSI recommande de proscrire le commit automatique de code généré par IA, et l’ANSSI et le BSI conseillent d’auditer les interactions de ces extensions avec la CI/CD.

Traiter la CI/CD de production comme de l’administration. L’ANSSI le recommande : poste dédié, moindre privilège, jetons générés à la demande, journalisation et supervision.

Signer et attester. L’ANSSI recommande de maintenir l’intégrité du code source de bout en bout, en signant et en vérifiant les signatures des tags de version des artefacts. Le cadre SLSA, projet de l’OpenSSF, structure cette démarche. Sa version 1.2 (novembre 2025) comporte une piste « Build » graduée de L0 à L3, le niveau L2 exigeant une provenance signée produite par une plateforme de construction hébergée. Sa piste « Source » exige au niveau 2 un historique immuable et des attestations de provenance pour chaque révision, et au niveau 4 une revue par deux personnes de confiance pour toute modification des branches protégées.

L’attestation ne dit pas qui a conçu le code. Elle prouve qu’un artefact déployé provient d’une révision connue, construite et revue selon les contrôles prévus.

Une revue humaine ciblée et une politique d’usage explicite

Concentrer la revue humaine. Relire chaque ligne générée avec la même attention n’est pas tenable. L’ANSSI recommande fortement de ne pas faire générer par l’IA des blocs de code destinés aux modules critiques : cryptographie, gestion des droits d’accès, traitement de données sensibles. Dans la finance, la même logique s’étend aux flux de paiement, aux règles antifraude et aux interfaces exposées aux clients. Ces zones sont identifiées dans les dépôts et confiées à des relecteurs désignés, quelle que soit l’origine du code.

Dimensionner la sécurité applicative. Pour l’ANSSI et le BSI, les gains de productivité des développeurs doivent être compensés par un renforcement des équipes d’assurance qualité et de sécurité applicative. Ils proposent une phase d’évaluation suivie d’indicateurs, comme le volume de code nouveau et la charge des équipes de sécurité.

Écrire une politique d’usage. Elle fixe les assistants, les comptes et les données autorisés. L’ANSSI et le BSI recommandent d’interdire l’accès non maîtrisé, par exemple par des comptes personnels, de privilégier des comptes d’entreprise configurés de façon sûre, d’examiner les clauses sur la réutilisation des données et de limiter les extensions. La politique interdit la saisie de secrets, exclut les répertoires sensibles du contexte transmis, proscrit l’exécution et le commit automatiques et demande de signaler le code généré. Elle prolonge la démarche contre le « shadow AI » décrite pour les assistants IA internes.

Former, sans s’y reposer. La sensibilisation des développeurs est la recommandation R32 de l’ANSSI. Mais l’étude de Stanford le montre : l’excès de confiance fait partie du problème, et les contrôles automatiques doivent fonctionner quand le doute fait défaut.

Perspective Forum des Compétences

Le code généré par IA ne remplace pas les questions classiques de la sécurité applicative ; il les rend plus pressantes. Le volume augmente, la relecture ne suit pas, et des choix techniques se font sans que personne les ait vraiment décidés. Les référentiels en ont pris acte : l’ANSSI dès 2024, l’ENISA en mars 2026, l’OWASP dans son édition 2026.

Pour les banques et les assurances, trois actions se dégagent. D’abord, traiter le code généré comme une contribution externe non fiable : portes de sécurité bloquantes, registre interne et liste d’autorisation pour les dépendances, détection de secrets. Ensuite, protéger les dépôts et prouver l’origine de ce qui est déployé, ce que DORA et son règlement délégué demandent déjà : intégrité du code source, changements approuvés par une fonction indépendante, tests statiques et dynamiques. Enfin, concentrer l’attention humaine sur les zones critiques et dimensionner la sécurité applicative au rythme de la production de code.

Aucun de ces contrôles n’est propre à l’IA. Ce qui change, c’est qu’ils ne peuvent plus rester facultatifs, ni contournables par une suggestion acceptée en un clic.

La question à poser aux équipes est donc concrète : si un assistant proposait demain une dépendance qui n’existait pas la veille, à quelle étape de la chaîne quelqu’un, ou quelque chose, l’arrêterait-il ?

Sources publiques utilisées

Cet article s’appuie sur des travaux académiques, des publications d’agences de cybersécurité, des référentiels et des textes européens :

• J. Spracklen et al. (université du Texas à San Antonio, université de l’Oklahoma, Virginia Tech), « We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs », 34e USENIX Security Symposium, août 2025.
• H. Pearce et al. (université de New York), « Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions », IEEE Symposium on Security and Privacy, 2022 ; N. Perry et al. (université Stanford), « Do Users Write More Insecure Code with AI Assistants? », ACM CCS, 2023.
• ANSSI et BSI, « AI Coding Assistants », recommandations conjointes publiées le 4 octobre 2024.
• ANSSI, Recommandations de sécurité pour un système d’IA générative (ANSSI-PA-102, 29 avril 2024), recommandations R30 à R32 ; ANSSI, Les essentiels DevSecOps (version 1.0, février 2024).
• OWASP GenAI Security Project, Top 10 for LLM Applications, éditions 2026 (août 2026 ; LLM04, LLM07, LLM10) et 2025 (LLM09).
• ENISA, Technical Advisory for Secure Use of Package Managers, version 1.1 (mars 2026).
• SLSA (OpenSSF), spécification version 1.2, novembre 2025.
• Règlement (UE) 2022/2554 (DORA), article 9, paragraphe 4, points c) et e), et article 28, paragraphe 3 ; règlement délégué (UE) 2024/1774 de la Commission du 13 mars 2024, articles 16 et 17.
• Règlement (UE) 2024/2847 (Cyber Resilience Act), article 13, article 71 et annexe I ; règlement (UE) 2024/1689 (AI Act), annexe III, point 5.