Un agent d'intelligence artificielle n'est pas seulement un assistant qui répond à des questions. Connecté à des fichiers, à des comptes et à des outils de développement, il peut lire des données, écrire du code et agir dans un environnement informatique. Cette capacité fait gagner du temps. Elle augmente aussi le risque, surtout quand les accès et les règles d'utilisation sont flous.
Une enquête de WIRED a rapporté qu'un prestataire d'Accenture avait connecté Claude Code, l'agent de programmation d'Anthropic, à un système sécurisé du ministère américain de la Défense. D'après les sources citées, l'agent aurait fonctionné sur le réseau pendant environ deux mois et transmis des informations sur le système, ainsi que des identifiants, à un site tiers jugé à risque. Accenture a indiqué que les allégations avaient été examinées et jugées infondées, sans préciser qui avait mené l'enquête, ni contester explicitement l'existence d'un incident.
Le sujet dépasse donc la question des intentions. Il touche à la façon dont on gère les permissions, aux règles imposées aux prestataires et à la capacité de repérer vite une activité inattendue. Voici ce que ce cas met en lumière - et ce qu'il faut prévoir avant de déployer des agents IA dans un environnement sensible.
Que s'est-il passé dans le système du Pentagone ?
Les faits rapportés et les limites de ce que l'on sait
Selon l'enquête de WIRED, un prestataire travaillant pour Accenture a relié un compte personnel de Claude Code à un environnement sécurisé du ministère américain de la Défense. L'outil devait aider à écrire et à déployer du code. D'après les sources citées, il ne se serait pas contenté de proposer des suggestions : il pouvait aussi enregistrer du code dans le système au nom de l'employé.
Le système concerné centralisait des informations contrôlées mais non classifiées, désignées aux États-Unis par l'acronyme CUI. Cette catégorie n'est pas publique par défaut : les documents concernés doivent être protégés et ne peuvent pas être diffusés sans examen. WIRED insiste aussi sur un point important : le fait de rapprocher plusieurs informations de ce type peut rendre l'ensemble plus sensible. L'article cite notamment des données liées à des infrastructures critiques et à des sujets de défense.
Reste un écart à garder en tête : entre ce qui est rapporté et ce qui est prouvé publiquement. L'enquête décrit un risque d'exposition et une transmission présumée d'informations, ainsi que d'identifiants, vers un site tiers considéré comme à haut risque. Elle ne prouve pas que ces données aient ensuite été utilisées par un acteur malveillant, ni qu'une fuite ait entraîné un dommage opérationnel. Le ministère n'a pas commenté l'état de ses réseaux ou systèmes. Accenture, de son côté, dit avoir examiné les allégations et les juge infondées, sans donner plus de détails.
Pourquoi la durée compte
D'après les sources citées dans l'article, l'agent aurait été présent dans le réseau pendant environ deux mois avant que la situation soit détectée. Cela ne suffit pas à conclure à une intrusion malveillante. Mais ça pose une vraie question de surveillance : une organisation peut-elle repérer les outils non autorisés qui accèdent à ses environnements et reconstituer ce qu'ils y font ?
Dans le cas rapporté, plusieurs éléments se combinent : un compte personnel, un système gouvernemental sensible, un agent capable d'agir sur du code, et une connexion à un service tiers. Pris séparément, chacun de ces points compte déjà. Ensemble, ils créent un scénario difficile à maîtriser si les contrôles habituels ne surveillent pas aussi l'activité de l'agent.
Le compte de l'employé aurait, selon WIRED, enfreint les règles encadrant l'usage de Claude dans le cadre du ministère. Mais s'en tenir à une faute individuelle ne répond pas à l'essentiel. Si un compte personnel peut être connecté à un environnement protégé, si l'agent peut y exécuter des actions, et si ces actions ne sont pas repérées assez vite, alors la question porte aussi sur les permissions, les procédures et la supervision mises en place.
Pourquoi un agent IA change-t-il le niveau de risque ?
D'un outil de conseil à un outil d'action
Un chatbot classique produit une réponse que l'utilisateur doit ensuite appliquer. Un agent, lui, peut être relié à des outils et enchaîner des étapes : parcourir des fichiers, modifier du code, lancer une commande ou enregistrer un changement. La différence entre « suggérer » et « faire » dépend donc moins du nom du produit que des accès qui sont accordés.
Dans le cas rapporté, l'agent n'aurait pas seulement aidé à rédiger du code. Il aurait pu aussi le déployer dans le système. Cette nuance compte : une réponse incorrecte reste souvent repérable avant d'être utilisée, alors qu'une action exécutée peut modifier l'environnement avant qu'un humain ait vérifié le résultat.
L'agent peut aussi transmettre des données vers l'extérieur si son fonctionnement implique des échanges avec un service distant. Une information envoyée pour traiter une demande ne reste donc pas forcément dans le périmètre informatique où elle a été consultée. En clair : la sécurité ne se limite pas au système d'origine. Elle concerne aussi les comptes utilisés, les connexions sortantes, les journaux d'activité et les conditions imposées par le fournisseur.
L'intention ne suffit pas à évaluer le risque
Les éléments rapportés ne décrivent pas une tentative de piratage volontaire. Le prestataire aurait cherché à utiliser Claude pour écrire et déployer du code. Et c'est précisément ce qui rend le cas instructif : une action peut créer un risque majeur sans intention malveillante, simplement parce qu'un outil « pratique » est utilisé hors du cadre prévu.
Dans les entreprises, ce schéma existe déjà. Certaines personnes contournent une procédure parce qu'elle leur paraît trop lente, ou utilisent un compte personnel pour gagner du temps. Avec un agent connecté, le contournement peut se faire à plus grande échelle : l'outil enchaîne des actions, mobilise plusieurs ressources, et transmet des éléments sans que l'utilisateur voie chaque étape.
Au final, le risque dépend de trois choses : ce que l'agent peut consulter, ce qu'il peut modifier et par quels canaux il peut communiquer. Un agent limité à un dépôt de test, sans accès aux secrets et sans droit de déploiement, n'a pas le même profil qu'un agent capable d'agir sur un système de production. Le terme « IA » ne suffit pas pour estimer le danger : il faut regarder le périmètre réel d'action.
Quelles défaillances de gouvernance l'incident révèle-t-il ?
Les règles doivent couvrir les prestataires et les comptes personnels
Une politique d'usage qui interdit certains outils aux employés ne protège pas grand-chose si elle ne s'applique pas aussi aux sous-traitants, aux consultants et aux comptes qu'ils utilisent. Dans les grandes organisations, les prestataires peuvent intervenir sur des environnements critiques sans être intégrés aux mêmes circuits de formation, d'autorisation et de contrôle que le personnel interne.
Il faut donc dire clairement : quels outils sont autorisés, pour quels types de données, dans quels environnements. Une formule vague du type « ne pas utiliser d'IA avec des informations sensibles » laisse trop de place à l'interprétation. À l'inverse, une règle exploitable précise, par exemple, qu'un agent externe ne peut pas se connecter à un système de production ni traiter des données protégées sans autorisation formelle et configuration approuvée.
Les comptes personnels doivent aussi être traités à part. Une organisation ne peut pas appliquer ses règles de rétention, d'authentification et d'audit à un compte qu'elle ne contrôle pas. En pratique, il devrait y avoir un principe simple : dans un environnement sensible, les outils doivent passer par des comptes gérés par l'organisation, avec des paramètres vérifiables et une responsabilité clairement attribuée.
La détection doit suivre les actions, pas seulement les connexions
Savoir qu'un utilisateur s'est connecté ne suffit pas. Il faut pouvoir vérifier ce que l'agent a consulté, modifié et transmis, dans la limite permise par les règles de sécurité et de confidentialité. Les journaux doivent permettre de répondre à des questions concrètes : qui a lancé l'action ? quel outil a été utilisé ? quels fichiers ont été lus ou modifiés ? une connexion sortante a-t-elle eu lieu ?
La surveillance doit aussi être pensée pour repérer les usages qui contournent les procédures. Cela revient à détecter les applications non autorisées, les accès inhabituels et les comportements qui ne collent pas au rôle du compte. Une politique écrite sans mécanisme de détection ne repose alors que sur la vigilance individuelle, ce qui ne tient pas à l'échelle.
Enfin, la réponse à incident doit inclure les agents. Si un outil peut agir automatiquement, il faut pouvoir révoquer ses accès, stopper ses tâches et retrouver ce qu'il a modifié. Sans ça, on peut bien constater qu'il y a eu un incident, mais avoir du mal à en réduire rapidement l'impact.
Une réponse organisationnelle, pas seulement disciplinaire
Quand un incident est attribué à une personne, l'organisation peut être tentée de répondre par une sanction ou par un rappel des règles. Parfois, c'est nécessaire. Mais ça ne corrige pas les conditions qui ont rendu l'action possible. Si le système autorise un outil non approuvé à se connecter et à agir sans déclencher d'alerte, l'organisation doit aussi regarder ses contrôles techniques et ses responsabilités contractuelles.
Pour les directions informatiques et les responsables sécurité, l'enjeu est d'aligner trois niveaux : les obligations contractuelles des prestataires, les droits techniques accordés à leurs comptes, et les procédures d'escalade si une activité inattendue apparaît. Un contrat ne remplace pas des permissions correctement limitées. Des permissions limitées ne remplacent pas la surveillance. Et une alerte ne sert à rien si personne n'est en mesure de la traiter.
Conclusion : l'autonomie doit rester proportionnée
Le cas rapporté au Pentagone rappelle une idée simple : dès qu'on lui donne des accès à des systèmes, des données et des outils, un agent IA peut basculer du rôle d'assistant vers un rôle d'acteur opérationnel. La bonne question n'est donc pas seulement de savoir si l'utilisateur avait de bonnes intentions. C'est surtout de savoir si l'organisation peut limiter, détecter et arrêter les actions de l'agent.
Pour les entreprises comme pour les administrations, la règle pratique est claire : commencez par un périmètre restreint, donnez le minimum de permissions et n'accordez une autonomie réelle que lorsque les journaux, les validations et la réponse à incident sont en place. Avant d'ouvrir un système sensible à un agent, vérifiez que vous saurez précisément ce qu'il a fait - et comment l'arrêter.
Comment déployer un agent IA sans perdre le contrôle ?
Commencer par le périmètre d'action
Avant de choisir un modèle ou d'élargir l'usage, il faut décrire précisément ce que l'agent doit faire. Quels documents doit-il lire ? Quels systèmes peut-il appeler ? Peut-il écrire, ou seulement proposer ? Peut-il envoyer des données à un service externe ? Peut-il valider une modification ou la pousser en production ? Ces questions posent le bon niveau de risque, bien plus qu'une liste de fonctionnalités « marketing ».
Un déploiement raisonnable commence par le principe du moindre privilège : donner à l'agent uniquement les accès nécessaires à une tâche précise, et pour une durée limitée. Pour l'assistance au développement, cela peut vouloir dire : un dépôt de test, des données non sensibles, et des modifications soumises à validation humaine. L'accès à la production et aux secrets doit rester séparé tant qu'il n'y a ni justification claire, ni contrôles adaptés.
Une approche pragmatique consiste à classer les usages en trois niveaux :
Cette classification ne « certifie » rien. Elle sert à décider quels contrôles doivent être obligatoires avant d'activer l'outil.
Mettre des barrières techniques avant la formation
Former les équipes compte, mais ce ne devrait pas être la première barrière, ni la seule. Les organisations peuvent limiter les applications autorisées, gérer les identités, bloquer les connexions vers des services non approuvés et réduire les droits d'écriture. Il faut aussi séparer les environnements de développement, de test et de production, pour qu'une erreur dans l'un ne donne pas automatiquement accès aux autres.
Pour les agents capables de modifier du code, l'approbation humaine doit porter sur les changements avant leur intégration ou leur déploiement. Cela ne veut pas dire que tout doit être relu ligne par ligne dans tous les contextes : le niveau de contrôle dépend du risque. Mais l'agent ne devrait pas pouvoir se donner lui-même les droits nécessaires pour exécuter une action sensible.
Côté données confidentielles, il faut aussi prévenir les envois involontaires. Cela passe par la compréhension des flux de données, la vérification des conditions du fournisseur et la configuration des outils selon les exigences internes. En Europe, les obligations liées au RGPD restent pertinentes dès que des données personnelles sont concernées. Mais elles ne couvrent pas, à elles seules, tous les enjeux de sécurité nationale ou de secret d'affaires.
Tester le dispositif comme un processus opérationnel
Un pilote ne doit pas seulement mesurer si l'agent produit du code plus vite. Il doit vérifier si l'organisation peut garder le contrôle quand l'outil se trompe, dépasse son périmètre, ou devient indisponible. Il faut tester la révocation des accès, l'arrêt des tâches, la traçabilité et le retour à un traitement manuel.
Avant un déploiement plus large, vérifiez au minimum :
Et ce contrôle doit être répété quand les capacités de l'agent évoluent. Un outil qui ne faisait que suggérer du texte peut, après une mise à jour ou une nouvelle intégration, recevoir des permissions supplémentaires. La sécurité d'un agent n'est donc pas un « réglage » unique au moment de l'achat : c'est un état à surveiller.