Le Pentagone impose 3 contrôles pour chaque fragment de code généré par l’IA

Un agent d’IA a mis à jour une bibliothèque, corrigé le build et ouvert une demande de fusion en une minute. Le correctif paraît propre et, à première vue, les tests sont au vert. Mais qui est responsable si l’agent a discrètement affaibli un contrôle des droits d’accès ? Et sera-t-il possible, six mois plus tard, d’établir quel modèle a introduit la modification et qui a autorisé sa mise en production ?

La nouvelle instruction 8430.01 du département de la Guerre des États-Unis apporte une réponse stricte : tout code créé ou modifié par une IA est considéré comme non vérifié tant que l’équipe n’en a pas confirmé la qualité. Les développeurs restent responsables de la sécurité, du bon fonctionnement et de l’intégrité du résultat. Une approbation humaine est exigée pour les fonctions critiques.

Cette règle s’applique aux organismes du département et aux programmes d’acquisition comprenant des logiciels. Mais l’approche est utile à toute entreprise qui autorise déjà des agents dans ses dépôts : la vitesse de génération du code ne prouve pas qu’une modification est sûre.

Ce qu’il faut précisément démontrer

L’instruction ramène l’utilisation de l’IA à trois exigences pratiques.

La première est la traçabilité. L’équipe doit savoir où l’IA est intervenue, quels modèle et version ont été utilisés, et quelles actions l’agent a exécutées. Une simple mention « réalisé avec l’IA » ne suffit pas. L’historique doit relier la modification à un processus précis et à la personne qui l’a lancé.

La deuxième est la vérification. Le code de l’agent doit subir les mêmes tests, analyses de dépendances, recherches de vulnérabilités et règles d’approbation que le code écrit par un humain. Pour les fonctions dont dépendent la sécurité du système ou la vie humaine, la décision finale revient à un spécialiste désigné.

La troisième concerne les frontières des données. Les requêtes, le code source et les informations non publiques ne doivent pas être envoyés sans discernement à un modèle externe. L’organisation doit définir à l’avance les modèles autorisés, les environnements dans lesquels ils s’exécutent et les règles de conservation des données.

À quoi cela ressemble sur un correctif ordinaire

Supposons qu’un agent propose de mettre à jour une bibliothèque d’autorisation. Un processus normal se présente ainsi : l’agent crée une branche séparée et une demande de fusion ; le journal enregistre son compte de service ainsi que le développeur qui lui a confié la tâche ; le pipeline lance les tests, l’analyse des dépendances et l’analyse de sécurité. Comme la modification touche une zone protégée, le système exige l’approbation de l’ingénieur responsable. L’agent peut corriger une erreur détectée, mais il ne peut pas lui-même lever le blocage et envoyer le code dans la branche principale.

Cette procédure n’interdit pas l’autonomie. Elle en fixe les limites. On peut confier à l’agent la recherche de mises à jour, la préparation d’un correctif et la nouvelle exécution des contrôles. Le droit de fusionner ou de publier dépend du risque : une correction de documentation peut passer automatiquement, tandis qu’une modification de l’autorisation doit obligatoirement être validée par un humain.

GitLab cite sa propre plateforme comme moyen de mettre en œuvre ces exigences : journaux d’audit, branches protégées, règles d’approbation, analyse des dépendances et passerelle auto-hébergée vers les modèles. C’est un exemple utile, mais la source reste un contenu commercial. L’instruction décrit des exigences et n’impose pas GitLab ; les mêmes principes peuvent être appliqués dans GitHub, Azure DevOps ou un système interne.

Ce qu’il faut modifier dans le processus de développement

Ne commencez pas par choisir un nouvel outil d’IA, mais par cartographier les autorisations. Consignez les dépôts et les données accessibles à l’agent, les actions qu’il peut exécuter seul et les étapes auxquelles il doit s’arrêter. Identifiez les branches protégées, les fichiers critiques et les opérations de publication. Désignez pour chacun des responsables et des contrôles obligatoires.

Ajoutez ensuite la provenance des modifications au journal d’audit : le modèle, sa version, le compte de service de l’agent et l’initiateur humain. Ne vous fiez pas uniquement à un commentaire dans la demande de fusion : il se perd facilement et se prête mal aux enquêtes.

La principale conclusion est simple : l’IA accélère l’écriture d’un correctif, mais ne transfère pas la responsabilité de l’équipe vers le modèle. Si une entreprise ne peut pas montrer qui a lancé l’agent, ce qui a précisément été vérifié et qui a autorisé la publication, elle ne dispose pas encore d’un développement assisté par l’IA maîtrisé, mais seulement d’un générateur rapide de dette technique.