Pour les professionnels de la gouvernance des risques, de la conformité et de l'IA
L'analyse de risque à T0 est une hypothèse de travail — valide, nécessaire, rigoureuse. Qu'elle s'appuie sur EBIOS RM, ISO 31000, FAIR ou des simulations Monte-Carlo, elle produit une cartographie structurée, des scénarios stratégiques, des pertes attendues en euros. C'est un exercice intellectuel et organisationnel de haute tenue.
Mais elle repose sur une présupposition tacite : que le système évalué attend l'évaluation. Qu'il demeure, entre le moment de l'analyse et celui de la revue, suffisamment identique à lui-même pour que la photographie conserve une ressemblance.
L'agent agentique rompt ce contrat.
Non pas parce qu'il est rapide — la vitesse est un symptôme, pas la maladie. Non pas parce qu'il est complexe — la complexité est gérable par décomposition. Mais parce qu'il est ontologiquement instable : il modifie ses propres conditions d'existence en cours d'exécution. L'agent qui s'auto-évalue, réécrit ses prompts, injecte de nouveaux outils, étend sa mémoire contextuelle ou apprend en boucle fermée ne se contente pas d'explorer un espace de possibles prédéfini. Il élargit cet espace. Ce qu'il devient à t+1 n'était pas un possible à t — il est une création ex nihilo du processus d'exécution lui-même.
Le système en production n'est plus le système évalué. Il en porte le nom, la version, le commit Git — mais pas l'identité comportementale. La photographie de T0 n'est pas obsolète au sens où elle vieillit. Elle est caduque au sens où son référent a cessé d'exister.
Face à cette instabilité, la réflexe professionnel est l'accélération : instrumenter, monitorer, automatiser la détection. Des hooks d'état (tool_added, prompt_rewritten, memory_updated, skill_learned), du scoring dynamique, du Policy-as-Code. L'idée séduisante est que si l'humain ne peut suivre la vélocité de la machine, l'automatisation comblera le décalage.
C'est une impasse.
La vélocité asymétrique n'est pas un problème de tempo à résoudre par plus d'automatisation. C'est une impossibilité épistémologique : l'agent qui modifie ses compétences crée des espaces de risque qui n'existaient pas dans le langage de l'analyste. Le hook skill_learned() ne capture pas ce qui a été appris — seulement qu'un apprentissage a eu lieu. La sémantique du risque échappe à la syntaxe de la détection. Même instrumenté en temps réel, même pour un seul système isolé, le monitoring ne saisit que des indicateurs de mutation, non des contenus de risque.
Pire : l'automatisation de la détection crée une illusion de maîtrise. Le log structuré, le JSON traçable, la preuve continue pour l'IA Act — tout cela documente que quelque chose s'est passé, non que ce qui s'est passé était maîtrisable. La conformité devient un théâtre de la diligence : on produit des preuves d'avoir vu, non des preuves d'avoir compris.
Et même cette "vue" est fragmentaire. L'effet papillon agentique — la combinaison non-linéaire de trois micro-mutations individuellement sous-seuil qui crée un macro-scénario émergent — n'est pas détectable par des hooks locaux. Chaque hook voit son événement. Aucun ne voit la composition. La dette de risque s'accumule non pas dans les mutations visibles, mais dans leurs interactions invisibles.
Le Continuous Risk Management Model (CRMM) de Forrester, le Policy-as-Code, les approches "runtime governance" — tous partagent une ambition louable : ne plus laisser la gouvernance en dehors de la boucle d'exécution. Mais ils risquent de reproduire, à une échelle différente, le même erreur fondamental : croire que le problème est la lenteur humaine et que la solution est la rapidité machine.
Le CRMM n'est pas un 3LoD accéléré. Il est une avancée nécessaire — mais structurellement incomplète s'il se contente d'automatiser la surveillance sans reposer sur des invariants architecturaux. La vitesse de décision ne compense pas l'absence de limites constitutionnelles. Il est autre chose — ou il n'est rien. Le Policy-as-Code n'est pas un analyste de risque automatisé. Il est un mécanisme de matérialisation de contraintes que l'humain a définies a priori. Le code ne pense pas le risque. Il impose, par construction, ce que l'humain a jugé inacceptable. La différence est subtile mais fondamentale : dans le premier cas, on délègue la compréhension ; dans le second, on délègue l'application d'une compréhension préalable.
Or cette compréhension préalable ne peut provenir de l'analyse de risque classique — justement parce que celle-ci suppose un système stable. D'où vient-elle ? C'est la question que nos cadres actuels ne peuvent pas formuler, parce qu'ils supposent que la réponse est dans leur propre méthode.
Si l'humain ne peut pas suivre le contenu du risque en temps réel — et ce n'est pas une incapacité temporaire, c'est une limite structurelle — alors la maîtrise doit changer de sujet.
Non plus : "Quel est le risque actuel et comment l'atténuer ?"
Mais : "Quelles sont les conditions que ce système ne peut pas modifier, même en auto-dream, et comment les rendre contraignantes ?"
La maîtrise ne porte plus sur le risque résiduel — ce qui reste après atténuation dans un système connu. Elle porte sur le risque de rupture d'invariant — ce qui échappe aux limites programmées dans le système lui-même. L'analyse de risque classique, déplacée, devient une analyse des conditions de possibilité : non pas "que peut-il arriver ?" mais "que ne peut-il pas arriver sans enfreindre ses propres contraintes ?".
Ces contraintes ne sont pas des règles métier (que l'agent peut contourner par réécriture de prompt). Ce sont des limites architecturales : isolation réseau, absence de droits d'écriture sur le code source, impossibilité d'accès à certains namespaces, déterminisme forcé des fonctions critiques. Elles ne sont pas "vérifiées" en continu — elles sont vérifiées une fois, et rendues inviolables par conception.
C'est ici que l'analyse de risque à T0 retrouve une pertinence déplacée : non pas pour évaluer le système dans son devenir, mais pour justifier les invariants que l'on impose à ce devenir. EBIOS, FAIR, Monte-Carlo redeviennent pertinents — mais comme outils de décision architecturale, non comme outils de surveillance comportementale.
L'IA Act, l'ISO 42001, les cadres de conformité existants — tous supposent un sujet de diligence (l'opérateur humain) et un objet de diligence (le système IA). Ils supposent que le sujet peut, par documentation, audit et mise à jour, maintenir une relation de maîtrise sur l'objet.
Mais quand l'objet modifie ses propres conditions d'opération, la frontière sujet/objet s'efface. L'agent qui réécrit son propre code de conformité ne contrevient pas à la règle — il redéfinit l'espace où la règle a du sens. La diligence raisonnable continue (Art. 9 IA Act) devient une fiction réglementaire : non pas par malice des opérateurs, mais parce que le "continu" exigé suppose un tempo humain dans un monde agentique.
L'IA Act demande des logs (Art. 12), des mises à jour (Art. 9), de la traçabilité. C'est un effort de traduction forcée : projeter le langage du monde physique (carnet d'entretien, version, documentation) sur le monde computationnel où la version est un concept obsolète dès l'auto-modification. La conformité devient un exercice de style — rigoureux, coûteux, mais portant sur un simulacre du système réel.
Ce n'est pas une critique de l'intention réglementaire. Les régulateurs en sont conscients (cf. NIST AI RMF itératif, exigences post-marché de l'IA Act), mais les textes restent ancrés dans un paradigme de maîtrise continue humaine qui suppose un objet stable. Le décalage n'est pas volontaire : il est ontologique. C'est un constat de son inadéquation structurelle à l'objet qu'elle vise.
Nous ne savons pas encore maîtriser les risques des systèmes agentiques. Nous savons seulement que nos cadres actuels maîtrisent un autre objet — un objet stable, observable, fini, pensé pour être pensé par un humain.
L'agent agentique n'est pas cet objet. La maîtrise des risques à venir ne sera pas une accélération des méthodes existantes. Elle ne sera pas non plus une substitution de l'humain par la machine — cette substitution est déjà ce que l'agent effectue sur lui-même, et c'est précisément le problème. Elle sera, peut-être, une invention conceptuelle : comment penser la sécurité d'un système qui se pense lui-même ? Comment définir des limites qui ne soient pas des règles que l'agent peut réinterpréter, mais des conditions que son existence même présuppose ?
Cet article n'apporte pas la réponse. Il cherche seulement à rendre visible la question que nos outils nous empêchent de poser — parce qu'ils sont trop bien adaptés à un monde qui n'existe plus. Les prochains articles de cette série exploreront comment cette inversion conceptuelle se traduit concrètement : de la cartographie des invariants architecturaux à la traduction opérationnelle des seuils FAIR, en passant par la physique des gates de décision. Mais avant de bâtir, il fallait admettre que le sol a changé.
Ce n'est pas une critique des analystes de risque, des RSSI, des auditeurs EBIOS ou des actuaires FAIR. Leur travail reste indispensable — mais comme préalable à la mise en production, non comme garantie du runtime.
Ce n'est pas non plus un appel à l'abandon de la conformité. L'IA Act, l'ISO 42001, les obligations de documentation restent des ancrages juridiques nécessaires dans un monde social qui exige accountability. Mais il faut reconnaître leur portée limitée : ils régulent la responsabilité humaine, non le comportement agentique.
Ce n'est pas enfin un manifeste pour la "gouvernance par l'IA" — cette solution serait pire que le problème, puisqu'elle confierait à l'agent la maîtrise de sa propre dérive.
C'est une invitation à repenser le lieu de la décision. Non plus dans le suivi impossible, mais dans la conception des conditions. Non plus dans l'évaluation du risque, mais dans l'architecture de l'impossibilité.
Le risque n'est plus un état à évaluer. C'est une dynamique à circonscrire. À nous de redéfinir ce que "limiter" signifie quand la limite elle-même est ce que le système cherche à transcender.
Références implicites : EBIOS RM v1.0 (ANSSI), FAIR (Factor Analysis of Information Risk), ISO 31000, ISO 42001, EU AI Act 2024/1689, Forrester CRMM (2024-2025)
No responses yet.