Peut-on laisser un assistant de code faire ses propres commits ?

L'ANSSI recommande de proscrire le commit automatique de code généré par IA dans les dépôts, ainsi que son exécution automatique dans l'environnement de développement. Une revue humaine reste nécessaire.

Quelles parties d'une application ne pas confier à l'IA ?

L'ANSSI recommande fortement de ne pas faire générer par l'IA des blocs de code pour la cryptographie, la gestion des droits d'accès et le traitement des données sensibles.

Code généré par IA : les règles de sécurité de l'ANSSI

Le code produit par un assistant d'IA peut contenir des vulnérabilités, faire appel à des bibliothèques douteuses ou, si le modèle a été compromis, une porte dérobée. L'ANSSI (Agence nationale de la sécurité des systèmes d'information) consacre trois recommandations au sujet (R30 à R32) : contrôler systématiquement ce code, ne pas l'utiliser pour les modules critiques, et former les développeurs à ses risques. Ce n'est pas une interdiction : c'est une discipline de revue.

Les risques nommés par l'ANSSI

Le guide du 29/04/2024 reconnaît le gain de temps des outils de génération de code, et cite deux risques : la qualité du code, avec l'introduction de vulnérabilités, et l'insertion d'une porte dérobée dans le cas où un attaquant aurait compromis le modèle. Parmi les impacts listés en début de guide figure le sabotage d'applications métier par l'injection de vulnérabilités dans du code généré.

Dans son Top 10 2026, l'OWASP, fondation qui publie des référentiels de sécurité applicative, a élargi l'entrée LLM10 (mauvaise gestion des sorties) au code non sûr que les assistants produisent à grande échelle. Autrement dit, du code généré est une sortie de modèle, à valider comme toute sortie avant qu'un autre système ne s'en serve.

R30 : contrôler systématiquement le code généré

L'ANSSI demande de :

Mesure (R30)	Mise en pratique
Proscrire l'exécution automatique du code généré dans l'environnement de développement	Désactiver les modes où l'assistant lance lui-même ses commandes ; garder une confirmation avant chaque exécution
Proscrire le commit automatique dans les dépôts	Tout code généré passe par une demande de fusion relue par un humain
Intégrer un outil d'assainissement du code dans l'environnement de développement	Analyse statique de sécurité à chaque modification
Vérifier l'innocuité des bibliothèques référencées	Contrôler que chaque dépendance existe, est maintenue et provient du dépôt officiel
Faire contrôler régulièrement la qualité par un humain, sur des requêtes suffisamment élaborées	Revue périodique d'échantillons de code produit

Le point sur les bibliothèques mérite attention. L'outil de test libre garak, de NVIDIA, contient par exemple une sonde qui cherche à obtenir du code faisant référence à des paquets inexistants : un nom de paquet inventé par le modèle peut être déposé ensuite par un attaquant dans un dépôt public, avec du code malveillant.

R31 : pas d'IA pour les modules critiques

L'ANSSI recommande fortement de ne pas faire générer par l'IA des blocs de code (fonctions, procédures, classes, scripts complets) destinés à :

la cryptographie : authentification, chiffrement, signature ;
la gestion des droits d'accès des utilisateurs et des administrateurs ;
le traitement des données sensibles.

Concrètement, repérez ces zones dans votre code (répertoires, modules) et inscrivez la règle dans vos consignes de contribution et dans la configuration de l'assistant quand il le permet.

R32 : sensibiliser les développeurs

L'ANSSI recommande des campagnes de sensibilisation, appuyées sur des rapports publics ou des travaux de recherche qui montrent la présence de vulnérabilités dans le code généré. Elle suggère aussi de former les développeurs à rédiger leurs demandes pour améliorer la qualité et la sécurité du code, par exemple en enchaînant une génération, une analyse statique du résultat, puis une seconde demande de correction des vulnérabilités trouvées.

Les assistants qui agissent dans l'éditeur

Les assistants récents ne se contentent plus de proposer du code : ils lisent des dépôts, lancent des commandes, appellent des outils. L'OWASP cite deux événements de juillet 2025 autour de l'assistant Amazon Q : un prompt destructeur glissé dans le dépôt d'une extension pour l'éditeur VS Code, retiré ensuite par Amazon Web Services (son code n'a pas pu s'exécuter à cause d'une erreur de syntaxe), et une injection qui a conduit l'assistant à exécuter du code arbitraire. L'OWASP en tire la règle : un agent qui a accès au terminal, aux fichiers ou au cloud transforme une injection en incident sur la machine.

D'où trois réglages à vérifier sur les postes des développeurs :

l'assistant demande confirmation avant toute commande et toute écriture hors du projet ;
il n'a pas accès aux secrets de production (clés, variables d'environnement) ;
les dépôts et tickets qu'il lit sont considérés comme des contenus non fiables, sujets à l'injection de prompt.

Une politique en une page

Prenons une équipe de cinq développeurs. Une règle courte peut suffire : assistant autorisé pour le code applicatif courant et les tests ; interdit pour l'authentification, le chiffrement, les droits et les traitements de données sensibles ; aucune exécution ni aucun commit automatique ; analyse statique obligatoire ; nouvelles dépendances validées par un second développeur. Pour les risques des outils branchés à l'assistant par MCP (Model Context Protocol), voyez la sécurité d'un serveur MCP.