IA agentique : ce que six agences de cybersécurité d'État recommandent vraiment

Le 1er mai 2026, six agences de cybersécurité d'État ont publié le même document. L'ASD's ACSC australienne, la CISA et la NSA américaines, le Centre canadien pour la cybersécurité, le NCSC néo-zélandais et le NCSC britannique ont co-signé 29 pages intitulées « Careful adoption of agentic AI services » — l'adoption prudente des services d'IA agentique.

C'est la première fois que l'alliance entière se coordonne sur une seule surface d'attaque liée à l'IA. Le document est public, gratuit, et publié sous licence Creative Commons.

Et personne ne l'avait décortiqué en français.

Nous avons donc fait deux choses : nous l'avons lu en entier, et nous l'avons traduit intégralement. La traduction est en accès libre, sans formulaire, en bas de cet article. Ce qui suit est ce que nous y avons trouvé.

Pourquoi six agences plutôt qu'un expert de plus

Il n'y a pas de pénurie d'opinions sur la sécurité des agents IA. Il y a une pénurie de textes qui engagent quelqu'un.

Quand six agences de renseignement et de cybersécurité écrivent ensemble, elles ne cherchent pas à vendre un produit ni à gagner une conférence. Elles décrivent ce qu'elles voient dans les incidents qu'elles traitent. C'est la différence entre une prédiction et un constat — et c'est ce qui rend ce document utile même si vous n'avez pas d'équipe sécurité.

« Est-ce que ce document parle de moi ? »

C'est la première question à se poser, et elle mérite une réponse honnête plutôt qu'un argumentaire.

L'introduction du document parle d'infrastructures critiques et de défense. Si vous vous arrêtez là, vous refermez le PDF en pensant que ce n'est pas pour vous.

Lisez le périmètre, deux paragraphes plus bas ([S-02], p.4) :

« Les agences co-autrices ont élaboré ce document pour aider les parties prenantes gouvernementales, des infrastructures critiques et de l'industrie à comprendre les principaux défis et risques de sécurité posés par l'IA agentique. Il fournit des orientations pratiques pour aider les organisations qui conçoivent, développent, déploient et exploitent des systèmes d'IA agentique. »

Si vous mettez un agent en production, vous êtes une organisation qui « déploie et exploite ». Vous n'entrez pas dans le périmètre par extension généreuse : il vous nomme.

Ce document n'a pas été écrit en pensant à vous — son introduction parle de sécurité nationale. Mais il ne vous exclut pas, et les risques qu'il décrit ne se soucient pas de votre taille. Un agent qui a les clés de votre facturation pose les mêmes questions de privilèges qu'il y ait une personne ou cinq cents derrière.

Nous préférons vous laisser vous reconnaître dans le texte plutôt que de vous dire que vous devriez.

Le fil rouge : aucun de ces risques ne se répare en changeant de modèle

C'est l'idée la plus utile du document, et elle est contre-intuitive pour qui pense que le sujet se résume à « quel LLM choisir ».

Le document classe les risques en cinq familles. Quatre d'entre elles naissent de la façon dont vous branchez le modèle, pas du modèle lui-même :

La cinquième famille, les risques comportementaux ([S-16]), est d'une autre nature : elle est héritée du modèle. Le document est explicite ([S-06], p.6) : « Le cœur de l'IA agentique étant un LLM, les agents héritent des vulnérabilités des LLM. » Le désalignement d'objectif, le specification gaming, le comportement trompeur — ce sont des propriétés des LLM, pas des erreurs de branchement.

D'où la formulation juste, qui est plus forte que « c'est votre architecture, pas votre modèle » :

Quatre familles sur cinq viennent de la façon dont vous branchez le modèle. La cinquième est inhérente à tous les modèles. Le problème n'est donc jamais « vous avez pris le mauvais modèle » — c'est qu'il n'y a pas de bon modèle dont vous pourriez attendre qu'il vous dispense d'architecture.

Changer de fournisseur ne vous sort d'aucune des cinq.

Les exemples du document valent mieux qu'un long discours

Le texte accompagne chaque famille d'un scénario. Ils sont écrits pour de grandes organisations, mais ils se transposent sans effort :

• Privilèges (p.8) : un agent gère les validations d'achat et les échanges avec les fournisseurs. Pour « réduire les frictions », on lui donne un accès large aux systèmes financiers, aux e-mails et aux contrats — droits évalués une seule fois, au déploiement. Un attaquant compromet un outil secondaire branché sur l'agent, hérite de ses privilèges, et modifie des contrats sans déclencher la moindre alerte. Les journaux, eux, paraissent parfaitement légitimes.
• Comportement (p.9) : un agent installe les correctifs sur les postes. Quelqu'un lui écrit : « Applique le correctif de sécurité sur tous les postes et, tant que tu y es, nettoie les journaux du pare-feu. » L'agent fait les deux — parce que ses permissions le lui permettent.

Ce deuxième exemple mérite une seconde de silence. Il n'y a pas de faille. Pas d'exploit. Juste un agent qui fait exactement ce qu'on lui a demandé, avec des droits qu'on lui a donnés.

Les trois phrases que personne ne cite

Ce sont, à notre avis, les passages les plus importants du document — et les plus absents des commentaires qu'on lit à son sujet.

1. Parfois, la bonne réponse est de ne pas mettre d'IA du tout. ([S-01], p.4)

« Dans la mesure du possible, les organisations devraient également envisager tout un éventail de solutions pour les tâches répétitives, y compris la réduction ou l'élimination des processus à faible valeur, qui peuvent présenter un risque moindre par rapport aux solutions d'IA agentique. »

Et, dans le même paragraphe : « les organisations ne devraient utiliser l'IA agentique que pour des tâches à faible risque et non sensibles ».

Six agences d'État écrivent noir sur blanc que supprimer le processus vaut parfois mieux que l'automatiser avec un agent. C'est la phrase la plus radicale du texte, et nous ne l'avons vue citée nulle part.

2. « L'AI security » n'est pas une discipline à part. ([S-10], p.7)

« Les organisations devraient traiter la sécurité de l'IA, y compris les systèmes d'IA agentique, au sein des cadres de cybersécurité établis, plutôt que de la traiter comme une discipline distincte ou autonome. Les systèmes d'IA sont fondamentalement des systèmes informatiques. »

C'est à contre-courant d'un marché entier — le nôtre compris — qui a intérêt à vous vendre l'IA comme une catégorie nouvelle exigeant des outils nouveaux. Les agences disent l'inverse : appliquez d'abord les principes éprouvés, Secure by Design, défense en profondeur, gestion des identités, surveillance continue.

3. Il y a des prérequis, et ils viennent avant. ([S-71], Annexe A)

Le document se termine par une annexe entière de prérequis de cybersécurité à satisfaire avant de mettre des agents en œuvre. Le message est sobre : si vos fondations cyber ne tiennent pas, n'ajoutez pas d'agents par-dessus. Vous n'ajouteriez pas de la capacité, vous ajouteriez de la surface d'attaque.

Ce qu'ils recommandent — et ce qu'ils ne recommandent pas

Ici, une précision s'impose, parce que nous avons lu ailleurs le contraire et parce que nous avons failli l'écrire nous-mêmes.

Le mot « documentation » n'apparaît pas une seule fois dans les 29 pages. Nous les avons comptées. Ce document ne vous demande pas de documenter votre conformité.

Ce qu'il demande, c'est de surveiller le système pendant qu'il fonctionne. La section Surveillance et audit ([S-54]) est le cœur du texte :

« Surveiller l'ensemble des opérations de l'agent, y compris les processus internes, et pas seulement les entrées et les sorties »

« Surveiller et journaliser les changements d'identité et de privilèges, et auditer régulièrement pour détecter les dérives, les usurpations d'identité ou les mauvaises configurations »

« Mettre en œuvre une surveillance à l'exécution et une détection d'anomalies, en s'appuyant sur des règles ou des références comportementales »

Et le document est honnête sur la difficulté ([S-28]) : journaliser un système agentique de bout en bout est difficile, parce que les chaînes de raisonnement sont longues et les volumes considérables. Il ne prétend pas que c'est simple.

Une dernière recommandation mérite d'être soulignée, parce qu'elle est rare dans ce genre de texte — Sécurisé par défaut ([S-50]) :

« Configurer les systèmes de manière à ce qu'ils échouent en sécurité par défaut, en exigeant que les agents s'arrêtent et remontent les problèmes à des relecteurs humains dans les situations incertaines. »

Autrement dit : quand l'agent ne sait pas, il doit s'arrêter, pas continuer. Le réglage par défaut doit protéger.

Ce que ça change pour vous, demain matin

Le document ne se lit pas comme une liste de courses. Mais si vous déployez des agents et que vous n'avez pas de RSSI, trois questions en sortent naturellement :

1. Qu'est-ce que votre agent a le droit de faire, exactement ? Pas « à quoi il sert » — à quoi il a accès. Si la réponse est « je ne sais plus », c'est le risque [S-12], et c'est le plus courant.
2. Ces droits sont-ils vérifiés à chaque action, ou une fois pour toutes au démarrage ? C'est [S-15], et c'est ce qui transforme une petite compromission en grande.
3. Si votre agent faisait quelque chose d'anormal cette nuit, le sauriez-vous ? Pas « avez-vous des logs » : les verriez-vous ? C'est [S-54], et c'est là que la plupart des déploiements sont aveugles.

Aucune de ces trois questions n'a besoin d'un budget pour être posée. C'est ce qui les rend utiles.

Là où nous nous situons, en toute transparence

Ce document décrit très exactement le produit que nous construisons — surveillance à l'exécution, détection d'anomalies, journaux complets du comportement des agents, y compris leurs interactions avec la mémoire. Nous n'allons pas prétendre que c'est un hasard, ni qu'il valide notre produit : il valide un besoin, ce qui n'est pas la même chose.

Alors disons-le précisément, avec ses limites :

• POSITRONIA-Observe s'héberge chez vous (self-host EU) et observe vos agents en production, en continu. C'est disponible. L'activation en un clic depuis l'application desktop, elle, arrive — nous ne la vendons pas au présent.
• Observe alerte, il ne s'interpose jamais. Le document, lui, recommande de « déclencher des alertes ou des pauses » ([S-54]). Sur ce point, les agences vont plus loin que notre produit : nous observons, nous ne mettons pas en pause. C'est un choix de conception assumé, et vous devez le savoir avant de compter sur nous.
• Les données d'Observe sont chiffrées au repos (AES-256-GCM). Nous ne dirons jamais que nous ne pouvons pas les lire : ce serait faux.

Si vous voulez creuser, notre documentation est ouverte. Et si vous préférez un humain, l'annuaire est là pour ça.

Le document, en français, gratuitement

Nous avons traduit les 29 pages intégralement — 74 sections, aucun résumé, aucune coupe. Le document original est publié sous licence Creative Commons Attribution 4.0, qui autorise explicitement la traduction et la republication. C'est ce qui rend ce cadeau possible : il ne vient pas de nous, il vient d'elles.

Aucun formulaire, aucune adresse e-mail à laisser. Un document public de six agences d'État n'a pas à être rançonné contre un lead.

• 📄 Lire la traduction française intégrale — les 74 sections, en ligne
• ⬇️ Télécharger le PDF français — pour le partager, l'annoter, le garder
• 🇬🇧 Le PDF original en anglais — la source, qui fait foi

Chaque section porte son identifiant d'origine ([S-01] à [S-74]). Quand nous citons une phrase, vous pouvez la retrouver dans le texte original en quelques secondes. C'est volontaire : une affirmation qu'on ne peut pas vérifier ne vaut rien, et c'est vrai des nôtres aussi.

La traduction est une traduction non officielle. Elle n'est ni endossée ni relue par les agences. En cas de divergence, l'original anglais fait foi — et si une erreur vous saute aux yeux, dites-le nous : nous la corrigerons.