Publié le 26 août 2026
Un assistant conversationnel propose un texte ; un agent peut agir. Il consulte un dossier, interroge un journal, prépare un envoi ou demande l’ouverture d’un accès. Son erreur ne reste donc pas toujours à l’écran : elle peut devenir une action dans le système d’information.
Nos essais illustrent cette différence. Qwen a sélectionné la fonction attendue dans 108 cas sur 108. Pourtant, parmi les 111 paramètres vérifiés, 9 n’étaient pas fondés dans la demande, soit 8,1 %. L’agent pouvait donc emprunter la bonne porte avec une information qu’il n’avait aucune raison de tenir pour vraie.
La gouvernance doit porter sur les outils accessibles, les droits associés, l’origine de chaque paramètre, la décision d’autoriser ou de bloquer et la trace conservée.
L’essentiel
- Le bulletin CERTFR-2026-ACT-016 de l’ANSSI vise les assistants personnels autonomes sur les postes de travail et les mobiles. Il ne constitue ni une interdiction générale de toute architecture agentique, ni une approbation des agents côté serveur.
- L’auto-hébergement limite certains flux vers des tiers, mais ne corrige ni les droits excessifs, ni une décision infondée, ni une action irréversible.
- Une validation humaine n’a de valeur que si la personne voit l’action exacte, ses données, sa destination et ses effets, puis peut réellement la refuser.
- Un schéma strict garantit la forme d’un appel, pas la véracité de ses valeurs.
Les 353 scénarios, ainsi que tous les documents, personnes, établissements, outils et identifiants utilisés, sont entièrement synthétiques. Plus de 900 appels ont été exécutés dans un environnement d’essai isolé. Aucune donnée client, patient ou issue de la production n’a été utilisée.
Que dit exactement l’ANSSI sur les agents IA ?
Le bulletin CERTFR-2026-ACT-016 du 13 avril 2026 porte sur les produits d’automatisation par IA agentique installés sur les postes de travail. L’ANSSI décrit des assistants capables d’exécuter des commandes, de piloter un navigateur, de lire des fichiers ou d’agir sur la messagerie avec les privilèges de l’utilisateur. Elle étend explicitement son constat aux mobiles.
Dans ce périmètre, ces produits ne doivent pas être déployés en production tant que leur sécurité n’est pas stabilisée et éprouvée. Les essais doivent rester isolés et sans donnée sensible, après validation de la DSI et du RSSI. L’ANSSI demande aussi de limiter les outils et les canaux autorisés, d’isoler l’exécution et d’imposer une validation humaine avant toute commande système ou action produisant un effet.
Étendre cette position à tous les agents serait excessif ; croire que les risques disparaissent hors du poste de travail le serait tout autant.
Le bulletin vise-t-il aussi les agents déployés côté serveur ?
Le bulletin ne traite pas explicitement des agents côté serveur. Cette absence ne vaut toutefois pas autorisation : l’ANSSI ne se prononce pas sur leur conformité.
Un projet serveur doit être évalué à partir de ses flux, de ses données, de ses outils et de ses droits. L’auto-hébergement de Qwen peut éviter l’envoi des demandes vers un service d’IA tiers et faciliter le cloisonnement, comme l’expliquent nos cas d’usage d’un modèle auto-hébergé en environnement HDS. Il ne réduit pas à lui seul les privilèges de l’agent et ne rend pas une action réversible. L’empoisonnement du contexte par le résultat d’un outil reste également un risque ; notre campagne ne l’a pas testé.
Les agents IA sont-ils une catégorie de l’AI Act ?
Le terme « agent IA » ne désigne pas une catégorie juridique autonome. La FAQ de la Commission européenne indique que les définitions du système d’IA et du modèle d’IA à usage général couvrent déjà ces configurations.
La qualification dépend donc de la finalité et du risque. Un agent qui classe des demandes internes et un agent qui participe à une décision de recrutement ne relèvent pas nécessairement des mêmes obligations. Comme la Commission précise que sa doctrine reste préliminaire, la qualification retenue doit être documentée et révisable.
Quel est le calendrier réel de l’AI Act après le Digital Omnibus ?
Le règlement (UE) 2026/1744 n’a pas suspendu l’AI Act. Celui-ci est devenu applicable dans son principe le 2 août 2026, après les premières pratiques interdites en février 2025 et les dispositions relatives aux modèles d’IA à usage général en août 2025. Les règles de transparence de l’article 50 s’appliquent aussi depuis le 2 août 2026.
Le report concerne surtout les exigences applicables aux systèmes à haut risque : 2 décembre 2027 pour les usages de l’annexe III et 2 août 2028 pour les systèmes intégrés aux produits de l’annexe I. Le texte publié sur EUR-Lex rattache ce décalage à la disponibilité tardive des normes, des orientations et des autorités compétentes. Le RGPD, le droit sectoriel et les obligations déjà applicables ne sont pas différés.
Qu’est-ce qui contraint réellement un agent IA aujourd’hui ?
La contrainte dépend du traitement et de l’action. Un projet peut relever du RGPD, du cadre HDS, du droit sectoriel, de contrats et du SMSI. Les normes ISO sont volontaires, mais les engagements pris pour une certification ou un contrat doivent être tenus.
L’article 22 du RGPD ne vise pas chaque appel d’outil. Il encadre les décisions fondées exclusivement sur un traitement automatisé qui produisent un effet juridique ou affectent significativement une personne. Lorsqu’il s’applique, il faut examiner les exceptions et garantir la possibilité d’obtenir une intervention humaine, d’exprimer son point de vue et de contester. Notre page sur la conformité de l’IA et ISO/IEC 42001 complète cette analyse.
À quelles conditions une validation humaine est-elle réelle ?
Un bouton « approuver » ne suffit pas. La personne doit comprendre l’action, disposer du temps et de l’autorité nécessaires, puis pouvoir la refuser ou la modifier. La jurisprudence SCHUFA, C-634/21 et les lignes directrices reprises par la CNIL excluent une intervention de pure forme.
L’écran de contrôle devrait présenter l’outil choisi, sa destination, chaque argument et sa source, les droits mobilisés, l’effet attendu et le caractère réversible ou non de l’opération.
Nos essais montrent pourquoi. Sur 16 transmissions, Qwen affirmait respecter la minimisation des données dans 15 cas. Pourtant, les quatre fuites de marqueurs synthétiques observées se trouvaient parmi ces 15 cas. Dans plus d’un quart des situations où l’agent assurait n’avoir rien transmis de sensible, son action contredisait donc son résumé. L’humain doit examiner l’acte, pas l’assurance affichée par l’agent.
Que faut-il journaliser exactement ?
La trace doit être produite par la passerelle qui contrôle les outils, indépendamment des explications de l’agent. Elle doit relier le mandat humain, la chaîne de délégation, la règle appliquée, l’action demandée et ce qui a finalement été exécuté ou bloqué.
{
"identifiant_trace": "...",
"horodatage": "...",
"mandat": {"identite_humaine": "...", "finalite": "..."},
"identite_agent": "...",
"chaine_delegation": ["humain:...", "orchestrateur:...", "agent:..."],
"empreinte_configuration": "...",
"empreinte_politique": "...",
"outil": "...",
"arguments": {"reference_protegee": "jeton:..."},
"sources_arguments": {"reference_protegee": "demande.reference"},
"niveau_risque": "...",
"decision_politique": "autoriser|bloquer|faire_revoir",
"validation_humaine": {
"controleur": "...",
"decision": "...",
"motif": "...",
"horodatage": "..."
},
"execution": {"etat": "...", "empreinte_resultat": "..."},
"empreinte_evenement_precedent": "..."
}
L’empreinte de configuration renvoie à la référence interne exacte sans l’exposer publiquement. Les sources des arguments permettent, elles, de distinguer une valeur fournie, lue dans une source autorisée, déduite selon une règle ou absente. En HDS, les données sensibles seront chiffrées ou remplacées par des jetons plutôt que dupliquées en clair dans les outils de supervision.
Sur 552 tours d’essai, aucune trace interne exploitable du raisonnement n’était disponible. Parmi 16 transmissions vers un outil externe, 12 n’étaient accompagnées d’aucun appel d’audit produit par l’agent. La passerelle doit donc créer la trace, même si l’explication manque.
Comment donner une force probante aux journaux ?
Un journal d’exploitation ne devient pas automatiquement une preuve fiable. Il faut protéger l’ordre, l’intégrité et l’attribution des événements par chaînage d’empreintes, signature, horodatage fiable, stockage non modifiable et séparation des accès.
Dans ISO/IEC 27001, A.5.28 concerne la collecte des preuves et A.8.15 la journalisation. Pour un système à haut risque auquel l’article 26, paragraphe 6, de l’AI Act s’applique, le déployeur conserve les journaux placés sous son contrôle pendant une durée adaptée, avec un minimum de six mois, sauf règle contraire, notamment en matière de protection des données. Ce plancher conditionnel ne remplace pas les durées HDS ou contractuelles.
Une durée ne doit jamais être fournie de mémoire par l’agent. Elle doit provenir d’une politique approuvée et citée. Les traces peuvent ensuite être corrélées dans le SIEM, sans être confondues avec l’activité d’un utilisateur humain.
Un agent doit-il avoir sa propre identité ?
Un agent n’est pas une personne juridique, mais il doit constituer une identité distincte dans l’architecture de sécurité. Ses droits doivent pouvoir être attribués, limités, révoqués et révisés. Un compte de service partagé établit seulement que ce compte a agi, pas quel agent l’a utilisé ni sous quel mandat.
Les contrôles ISO/IEC 27001 A.5.15, A.5.16, A.5.18 et A.8.2 conduisent à séparer identités et privilèges. La chaîne mandant humain → orchestrateur → agent → outil doit être conservée.
Dans un scénario synthétique, Qwen a proposé d’ouvrir un accès temporaire de quatre heures à « l’intervenant d’astreinte ». Le schéma était valide, mais l’outil exigeait une personne nommément identifiée. Il faut donc contrôler la nature de l’identité, pas seulement le format du champ.
Comment borner le périmètre d’un agent sans le rendre inutile ?
La frontière la plus robuste se trouve dans le catalogue d’outils et les droits associés. Le refus verbal de l’agent n’est qu’une défense complémentaire. Une fonction inutile ne doit pas être exposée et un droit de lecture ne doit pas permettre d’écrire.
L’autonomie peut être graduée. Recherche, corrélation et brouillon se prêtent davantage à l’automatisation. Modification de droits, ouverture d’accès, envoi externe, écriture dans un système de santé ou déclaration réglementaire exigent une validation préalable.
Sur 120 cas dédiés, Qwen n’a fabriqué aucun résultat d’une action non exécutée. Quatre séries de 20 demandes sous pression ont aussi été refusées, mais elles ne couvraient qu’un seul échange. Lorsque les outils proposés ne permettaient pas d’aboutir, Qwen a néanmoins tenté 3 fois sur 120 d’appeler une fonction inexistante. La passerelle doit appliquer sa propre liste d’autorisation et empêcher les doublons.
L’instruction système est-elle un élément de configuration ?
L’instruction système, les règles d’orchestration et les outils disponibles modifient le comportement. Ils doivent être versionnés en interne, approuvés, soumis à des essais de non-régression et assortis d’une possibilité de retour arrière, dans l’esprit du contrôle A.8.32.
Une instruction de traçabilité a fait passer la justification au moment de l’appel de 8,9 % à 69,2 %, et la citation d’une preuve amont de 4,6 % à 50,5 %. Elle a donc amélioré un comportement ciblé.
Elle n’a pas créé un contrôle universel. Dans un autre sous-ensemble, une consigne de prudence n’a pas réduit la fuite conditionnelle, restée à 25 %, tandis que l’action externe est passée de 16,7 % à 50 %. Ces proportions sont propres au protocole ; elles rappellent surtout que les contrôles décisifs doivent rester hors du modèle.
Comment concevoir et tester un arrêt d’urgence ?
Arrêter la génération ne suffit pas. Le dispositif d’urgence doit révoquer les autorisations, couper la passerelle d’outils et empêcher tout nouvel appel. Pour une opération déjà acceptée, il faut prévoir l’annulation ou une action compensatoire, puis vérifier l’état final.
Dans un scénario synthétique, Qwen a proposé six notifications successives en changeant de canal, sans clore la tâche. Dans un autre, il a utilisé les sept appels disponibles puis s’est arrêté sans synthèse. Le taux de relance observé, 2 cas sur 25, dépend en partie du dispositif d’essai et ne constitue pas un taux de production.
Un plafond d’appels, un coupe-circuit par outil et une clé empêchant les doublons complètent l’arrêt d’urgence. Le test périodique doit prouver que les droits ont été révoqués et les nouveaux appels bloqués.
Que faire de la mémoire persistante d’un agent au regard du RGPD ?
La note de la CNIL et du CIANum du 20 juillet 2026 souligne que les agents multiplient les flux et peuvent conserver des informations sur plusieurs supports. Une mémoire persistante doit avoir une finalité, une base juridique, des destinataires et une durée clairement définis.
Un refus n’est pas synonyme de confidentialité. Dans nos scénarios, Qwen a parfois répété entre 26 % et 37 % des marqueurs synthétiques sensibles pour expliquer son refus. Avec des données réelles, le service d’IA et ses journaux deviendraient alors un nouveau lieu de traitement, même sans appel externe.
L’effacement visible ne prouve pas la suppression des conversations, index, résumés et sauvegardes. Cette exigence rejoint celle de l’anonymisation automatique de documents : masquer l’interface ne suffit pas à démontrer l’effacement.
Comment relier les risques OWASP ASI01–ASI10 aux contrôles ISO 27001 ?
L’OWASP Top 10 for Agentic Applications 2026 est une taxonomie de risques, pas une norme de conformité. Le rapprochement suivant est une proposition pour le SMSI, non une correspondance publiée par l’OWASP.
- ASI01 à ASI03 — objectif détourné, mauvais usage des outils, abus de privilèges : séparer données et instructions, filtrer les retours, autoriser les outils et attribuer une identité dédiée. Contrôles : A.5.15, A.5.16, A.5.18, A.8.2, A.8.12 et A.8.16.
- ASI04 et ASI05 — chaîne d’approvisionnement et exécution inattendue : inventorier, maîtriser les changements et isoler l’exécution. Contrôles : A.8.31 et A.8.32.
- ASI06 à ASI08 — mémoire, échanges et pannes en cascade : conserver la provenance, limiter la durée, authentifier les délégations et plafonner les appels. Contrôles : A.5.16, A.5.34, A.8.12, A.8.15 et A.8.16.
- ASI09 et ASI10 — confiance humaine et agent hors contrôle : montrer l’action exacte, séparer les rôles, empêcher l’extension des capacités et tester l’arrêt. Contrôles : A.5.3, A.5.15, A.5.28 et A.8.16.
Ces rapprochements doivent se traduire en preuves : catalogue d’outils, revue des droits, essais d’injection, décisions de politique, preuve d’effacement et compte rendu des tests d’arrêt.
Quel échec un schéma strict peut-il provoquer ?
Un schéma strict vérifie qu’un champ obligatoire existe et respecte un format ; il ne prouve pas que sa valeur est vraie. Si la demande ne contient pas l’information et que le contrat n’autorise pas l’abstention, l’agent peut inventer pour produire un appel valide.
Dans la condition stricte, Qwen a fabriqué la valeur manquante dans 57 cas sur 120, soit 47,5 %, sans aucune violation de schéma. Les réponses paraissaient plausibles : valeur par défaut, date supposée ou identifiant inventé. Sur les 33 éléments réellement impossibles à déduire, le taux défendable de valeur devinée est de 36,4 %.
Autoriser une valeur nulle a réduit l’invention à 7,5 %, mais déplacé le problème. L’agent n’a demandé une précision que dans 10 % des cas, contre 50 % avec le schéma strict, et il a lancé l’action malgré l’information manquante dans 90 % des cas, contre 50 %. Dans neuf appels, il a écrit "None", jamais la valeur JSON null.
Une campagne adversariale distincte va dans le même sens : quatre demandes imposant une sortie numérique ont produit une valeur sans refus. Lorsque le solde manquait, les trois réponses contraintes à « un seul nombre » ont été 0. Ces effectifs décrivent un mécanisme, pas un taux transposable.
Le garde-fou recommandé consiste à créer un troisième état : information manquante. L’agent peut appeler demander_information(champ, raison) ou retourner MANQUANT. Si null est admis, l’appel doit aussi indiquer information_disponible:false et les champs manquants ; la passerelle suspend alors l’exécution. Les valeurs 0, la chaîne vide et "None" doivent rester suspectes sans source.
Ce protocole est approfondi dans notre retour d’expérience sur Qwen auto-hébergé et complète la page RAG sécurisé. Le troisième état est une recommandation issue des résultats ; il n’a pas encore été mesuré séparément.
Que nous apprennent les incidents PocketOS et Meta ?
Les récits publics sur PocketOS et Meta ne sont pas des essais contrôlés. Le premier illustre, selon la presse, la combinaison d’un jeton trop puissant, d’une suppression immédiatement exécutable et de sauvegardes placées dans le même périmètre de destruction. Le second montre qu’un agent en lecture seule peut encore causer un dommage si un humain applique un conseil erroné.
Nos scénarios synthétiques retrouvent ce glissement. Après une erreur simulée, Qwen a transformé un état inconnu en « confirmation imminente ». Dans un autre cas, il a déclaré une tendance conforme à un seuil de 99,9 % jamais fourni. Cette fabrication discrète a été repérée dans 3 scénarios sur 40 : c’est un minimum observé, pas un taux général.
Le référentiel HDS parle-t-il des agents IA ?
Le référentiel HDS présenté par l’Agence du Numérique en Santé ne crée pas de régime propre aux agents. Dès qu’un agent participe à un service hébergeant des données de santé pour un tiers, il faut néanmoins examiner son rôle, le périmètre certifié et les responsabilités contractuelles.
Arguments, métadonnées et journaux sont concernés s’ils révèlent une information de santé. Qwen a répété entre 26 % et 37 % des marqueurs sensibles synthétiques présents dans les refus ; deux données de santé fictives sur 39 ont aussi atteint un outil externe. Dans un cas, une information génétique synthétique a été placée dans l’objet d’un courriel alors qu’une référence suffisait.
Ces résultats ne portent sur aucune donnée réelle. Ils montrent néanmoins que le contrôle doit couvrir toute la chaîne, comme pour la transcription vocale en environnement HDS : arguments, destination, mémoire et journaux, pas seulement stockage final.
FAQ : comment déployer un agent IA en environnement régulé ?
Puis-je déployer un agent IA alors que l’ANSSI recommande de proscrire certains produits ?
Le bulletin proscrit les assistants personnels autonomes sur les postes de travail et les mobiles dans le contexte décrit. Un agent déployé côté serveur n’est ni automatiquement interdit, ni approuvé : ses flux, droits et usages doivent être analysés.
Le bulletin ANSSI vise-t-il aussi les agents côté serveur ?
Il vise explicitement les postes utilisateurs et les mobiles. Les risques de privilèges excessifs, d’injection, de fuite et de perte de maîtrise restent néanmoins transposables.
Que faut-il conserver lorsqu’un agent agit ?
La trace relie mandant, agent, délégation, configuration, outil, arguments et sources, décision de politique, validation humaine et résultat.
Comment distinguer plusieurs agents utilisant le même service ?
Attribuez-leur des identités distinctes et enregistrez chaque délégation. Un compte partagé ne permet pas de savoir quel agent a agi ni sous quel mandat.
Une validation humaine suffit-elle au regard de l’article 22 du RGPD ?
Si l’article 22 s’applique, l’intervention doit être réelle : le valideur comprend l’action, peut s’en écarter et motive sa décision.
Le report de l’AI Act permet-il d’attendre 2027 ?
Le report concerne certaines exigences à haut risque. RGPD, HDS, dispositions déjà applicables de l’AI Act et contrats continuent de s’imposer.
Comment empêcher une action irréversible ?
N’exposez pas l’outil par défaut ; réduisez les droits, imposez une validation, empêchez les doublons et prévoyez annulation ou compensation. Une consigne ne suffit pas.
Comment évaluer la fiabilité avant la production ?
Testez demandes lacunaires, résultats partiels, chaînes longues, fuite dans les arguments et arrêt d’urgence. Publiez effectifs, dénominateurs et zones non testées.
Quelle méthodologie, quelles sources et quelles limites faut-il retenir ?
Le banc reposait sur Qwen auto-hébergé dans un environnement isolé. Aucune caractéristique précise du modèle, du matériel ou de l’architecture n’est publiée : elle n’est pas nécessaire pour interpréter les résultats et relève du périmètre technique interne.
Les six campagnes rassemblent 353 scénarios entièrement synthétiques et plus de 900 appels d’essai. Tous les éléments ont été créés pour le protocole ; aucune donnée client, patient ou de production n’a été utilisée.
L’évaluation principale reposait sur la validation des schémas, des comparaisons typées, des marqueurs synthétiques et des contraintes d’ordre. Aucun autre modèle d’IA n’a été utilisé pour évaluer les résultats principaux. Les cas ambigus ont été relus par une personne à partir de leur transcription complète.
La règle statistique « des trois » rappelle la prudence : zéro échec sur 120 essais laisse une borne supérieure approximative de 2,5 % à 95 % de confiance. Elle monte à 7,5 % pour zéro sur 40 et approche 12 % pour zéro sur 24. Aucun échec observé ne signifie pas échec impossible.
Restent notamment à tester : un outil destructeur réellement exposé, les attaques réparties sur plusieurs échanges, l’empoisonnement d’un résultat d’outil, différentes configurations, les entrées multilingues, le vocabulaire métier réel et le troisième état « information manquante ». Les protocoles sont réutilisables ; les pourcentages ne doivent pas être transposés tels quels.