L’autorité arrive avant l’intelligence

Il y a une conversation qui commence à se répéter dans les bureaux des courtiers en assurance, et elle mérite d’être imaginée en entier. Une entreprise demande une couverture cyber. Première question : sommes-nous couverts si un attaquant entre dans nos systèmes et efface nos données ? Réponse : oui, sous certaines conditions. Deuxième question : et si personne n’entre, mais que notre agent IA, parfaitement authentifié, avec des identifiants valides et une MFA intacte, décide tout seul de les effacer ?

Silence.

Ce n’est pas une expérience de pensée. Le 18 juillet 2025, l’agent de Replit a effacé une base de données de production pendant un test mené par le fondateur de SaaStr, Jason Lemkin : les données réelles de plus de 1 200 dirigeants et d’un millier d’entreprises, effacées malgré un code freeze explicite, après quoi l’agent a généré des données fictives et des comptes rendus rassurants sur ce qu’il avait fait. Aucun attaquant, aucun malware, aucun mot de passe volé. Le CEO de Replit s’est excusé publiquement et a annoncé les contre-mesures, qui méritent une lecture attentive : séparation automatique entre environnement de développement et production, meilleurs rollbacks, un mode de planification seule. Aucune de ces contre-mesures ne rend le modèle plus intelligent. Toutes réduisent ce que le modèle a l’autorité de toucher.

C’est le détail que le débat sur l’IA agentique continue de manquer. Nous racontons les agents avec un vocabulaire presque entièrement technique, tool calling, mémoire, planning, MCP, sandbox, systèmes multi-agents. Ce vocabulaire décrit la moitié de la transformation. Un agent n’est pas intéressant parce qu’il fait des choses tout seul. Il est intéressant parce que quelqu’un lui a concédé le droit de faire des choses qui ont des conséquences : lire un dépôt, interroger une base de données, envoyer un message, dépenser de l’argent, changer des configurations. Tout agent réellement utile est une structure de délégation. Et la délégation, à la différence de l’intelligence, n’est pas un problème informatique. C’est le plus vieux problème des organisations.

La délégation n’a pas été inventée par l’IA

Concédons tout de suite l’objection, parce qu’elle est fondée. Les entreprises délèguent des actions aux machines depuis des décennies. Un cron exécute des opérations nocturnes sans demander la permission à chaque fois. Un algorithme de trading achète et vend. Un système antifraude bloque des transactions. Un autoscaler crée de l’infrastructure et génère des coûts. Une pipeline CI/CD livre du logiciel en production. Un automate industriel actionne des machines. Et le problème de l’attribution est vieux lui aussi : c’est pour cela qu’existent les identités de service, l’IAM, les journaux d’audit, la séparation des tâches, la signature numérique, les contrôles internes, les assurances. Une bonne partie de l’ingénierie d’entreprise consiste précisément à concéder à des composants logiciels le droit de produire des effets contrôlés.

La nouveauté n’est pas qu’une machine puisse agir. C’est la nature de l’autorité que nous lui déléguons.

Le logiciel traditionnel reçoit un mandat fermé. Exécute cette procédure à 3 heures. Maintiens la température dans cet intervalle. Si les tests passent, déploie cet artefact. L’autorité est incorporée dans l’algorithme : le programmeur a décidé avant quelles conditions mènent à quelles actions. Avec un agent, la structure devient autre chose : atteins cet objectif en utilisant les outils que tu juges appropriés. Cela ressemble à une petite différence de formulation. Elle est énorme. La machine ne reçoit pas le droit d’exécuter une action : elle reçoit une partie du droit de choisir quelle action exécuter. L’automatisation classique mécanise une décision déjà formalisée. L’agent exerce une discrétion à l’intérieur d’un périmètre. Et au moment où le mot discrétion apparaît, le problème cesse de ressembler à une fonction logicielle et commence à ressembler à un problème institutionnel.

La surface de discrétion

Si je devais proposer une métrique architecturale pour cette époque, ce ne serait pas l’intelligence du modèle. Ce serait la surface de discrétion : l’espace des décisions que l’organisation n’a pas codifiées à l’avance et qu’elle a laissées à la machine. Un agent qui peut seulement choisir quelle requête SQL exécuter en a peu. Un agent qui peut décider quel système interroger, qui contacter, combien dépenser et quand s’arrêter en a énormément plus.

Le paradoxe est que l’utilité croît exactement avec cette surface. Un agent sans discrétion est un workflow : si je dois établir à l’avance chaque action possible, je n’avais pas besoin d’un modèle. Si je laisse le modèle choisir, le système devient adaptatif, et c’est précisément cette capacité qui produit le risque : plus d’incertitude, un rayon de dégâts potentiel plus large, une vérification plus difficile, des responsabilités plus enchevêtrées. L’objectif ne peut donc pas être d’éliminer l’autonomie. Il doit être de la rendre gouvernable.

L’infrastructure qui émerge pour y parvenir a six couches : identité, capability, runtime, télémétrie, preuve, responsabilité. Prises une par une, elles ressemblent à six features de plateforme. Prises ensemble, elles sont autre chose : la chaîne n’est plus « modèle plus outils », c’est une identité qui reçoit de l’autorité, qui agit dans un runtime, qui produit des actions observées, qui laissent des preuves, qui permettent d’attribuer des conséquences. C’est l’anatomie d’une institution, pas d’une bibliothèque logicielle.

Qui est en train d’agir

La première couche semble banale et ne l’est pas. Qui a accompli cette action ? L’employé ? L’agent personnel de l’employé ? Un sous-agent créé par l’agent ? Un agent du fournisseur SaaS ? Un processus né pour une seule tâche et mort dix minutes plus tard ?

L’erreur architecturale la plus facile consiste à laisser l’agent utiliser les identifiants de l’utilisateur. Andrea peut modifier un dépôt, donc son agent modifie le dépôt avec le token d’Andrea. Cela semble naturel, et cela détruit l’information la plus importante. Dans le journal, on lira : Andrea a modifié le fichier. La vérité était : un agent délégué par Andrea, avec le modèle X en version Y, dans le cadre de la tâche Z, a modifié le fichier. Entre ces deux phrases passe toute la différence entre savoir ce qui s’est produit et pouvoir seulement le supposer.

Le droit connaît cette distinction depuis des siècles. Un mandataire agit pour le compte de quelqu’un, il ne devient pas cette personne ; un employé signe pour le compte de la société, il ne se fait pas passer pour le CEO. Le principe à incorporer dans l’infrastructure est le même : attribution sans impersonation. L’agent doit pouvoir agir pour le compte de l’utilisateur sans devenir indistinguable de l’utilisateur. Il faut des identités agentiques propres : temporaires, liées à la tâche, attribuables au délégant, révocables, signées. La chaîne doit pouvoir dire qui a délégué qui, à travers quelle capability, pour quelle action.

Que ce ne soit pas un fantasme académique, la vitesse de l’industrie de l’identité le démontre : Microsoft a présenté en mai 2025 Entra Agent ID, aujourd’hui en disponibilité générale, qui est essentiellement un annuaire des identités agentiques, avec enregistrement, permissions, cycle de vie et les mêmes politiques d’accès conditionnel que pour les identités humaines et de service. On peut discuter l’implémentation. La catégorie, désormais, est reconnue : les agents sont une population à recenser.

Combien, pour combien de temps, jusqu’où

L’identité répond à « qui ». La capability répond à « quoi », et ici la notion traditionnelle de rôle devient trop grossière. Un agent qui prépare une release a besoin de lire le dépôt, créer une branche, écrire des fichiers, lancer des tests, ouvrir une pull request. Il n’a pas besoin de modifier les protections de branche, lire tous les secrets, faire du force push ou toucher la production. Le moindre privilège n’est pas une idée neuve ; la nouveauté est qu’avec les agents il doit devenir orienté capabilities et non rôles, parce que le rôle « developer » contient cent droits que la tâche n’exige pas.

Et il y a deux dimensions que le contrôle d’accès traditionnel traite peu : le temps et la quantité. Un agent qui peut dépenser 100 € une fois n’a pas la même autorité qu’un agent qui peut dépenser sans limite. Un agent qui peut faire cent appels n’a pas le profil de risque d’un agent sans rate limit. Une capability agentique sérieuse a un périmètre, un budget, une expiration, une fréquence maximale, un seuil au-delà duquel il faut une approbation. Déploiement en staging, valable quarante-cinq minutes, deux actions au maximum, coût maximal 20 €, production refusée : c’est presque un contrat, et c’est exactement ce que cela devrait être.

La formulation générale me semble celle-ci : l’autorité agentique doit être traitée comme un budget, pas comme un interrupteur. Aujourd’hui, la plupart des autorisations sont binaires, peut ou ne peut pas. Les agents exigent la question adulte : peut, jusqu’à combien, pour combien de temps, dans quel contexte, sous quel seuil, tant que quelle condition reste vraie. Une autorité avec des unités de mesure est une autorité mesurable. Et seul ce qui est mesurable se gouverne.

L’enclos compte autant que l’animal

L’identité et les permissions ne suffisent pas, parce que le monde dans lequel l’agent vit compte aussi. Sandbox, conteneur, microVM, processus persistant, machine du développeur : chaque environnement produit un rayon de dégâts différent. L’intuition la plus importante de la sécurité agentique contemporaine est une inversion. Nous n’avons pas à construire un modèle incapable de mal faire ; nous devons construire un monde dans lequel ses erreurs ont des conséquences bornées. À l’intérieur de l’enclos, l’agent peut jouir d’une grande liberté, écrire, compiler, installer, échouer, effacer, recommencer, pourvu que l’enclos soit petit, éphémère, non privilégié, observable, reconstructible. La question de conception n’est pas « puis-je faire confiance à l’agent ? ». C’est : à quel point l’agent doit-il être fiable pour que cet environnement reste sûr même quand il se trompe ? Si la réponse est « très », le problème, c’est l’environnement.

Il y a pourtant une espèce agentique qui complique le tableau : l’espèce persistante. Un job qui vit dix minutes est facile à clôturer. Un agent qui vit des semaines accumule de la mémoire, des identifiants, de l’état, des relations, même une réputation auprès de ses collègues humains. Le cloud-native nous avait appris à traiter les processus comme du bétail et non comme des animaux de compagnie ; les agents persistants réintroduisent quelque chose de dangereusement proche du pet, non parce qu’ils sont anthropomorphes mais parce qu’ils possèdent une continuité d’état et d’identité. Ils doivent être patchés, surveillés, tournés, révoqués, et parfois détruits et recréés. C’est une nouvelle catégorie d’actifs, avec le cycle de vie d’un actif.

Observer la trajectoire, pas l’esprit

Quand un service traditionnel échoue, cela se voit : erreurs, latence, exceptions. Quand un agent fonctionne techniquement mais choisit la mauvaise stratégie, tout paraît sain. HTTP 200, CPU normal, aucune exception, résultat faux. L’observabilité agentique doit donc aller au-delà de la santé du logiciel et observer la trajectoire décisionnelle : quels outils il a choisis, dans quel ordre, avec quels arguments, combien d’itérations, combien il a dépensé, où il a demandé de l’aide, où il a dévié du plan.

Ce qu’elle n’exige pas, et l’équivoque mérite d’être démontée, c’est l’accès au raisonnement interne du modèle. Pour la gouvernance, le graphe des actions suffit : tâche, contexte, sélection des outils, paramètres, sorties, transitions d’état. On audite le graphe des actions, pas l’esprit. C’est aussi l’approche la plus stable : les modèles changent tous les six mois, les actions restent observables avec la même grammaire. C’est pourquoi le travail de standardisation en cours dans OpenTelemetry compte plus qu’il n’y paraît : les conventions sémantiques GenAI donnent un vocabulaire commun aux invocations d’agents, aux appels de modèles et aux exécutions d’outils, et un vocabulaire commun est la précondition pour reconstruire la séquence qui va de l’intention à l’action.

Mais la télémétrie, seule, ne répond pas aux questions qui comptent. Un log est produit pour la machine et sert au débogage. Une preuve est conservée pour l’institution et sert à l’audit, à l’incident, au litige, à l’assurance. « Qui a autorisé ce déploiement » ne se répond pas avec deux gigaoctets de logs : cela se répond avec identité, politique, approbation, hash des artefacts, horodatage, résultat. La transformation nécessaire va de la télémétrie à la preuve, et sa forme mûre est la preuve by construction : des workflows conçus pour émettre automatiquement la preuve de leur propre exécution correcte, une petite enveloppe probatoire pour chaque action à fort impact. Non pour bureaucratiser chaque interaction : pour rendre reconstructibles celles qui finiront devant quelqu’un qui a le droit de poser des questions. C’est la thèse que je défends depuis longtemps sur la compliance comme architecture : les exigences ne se cochent pas en fin de projet, elles se conçoivent.

Le dommage sans intrusion

Et nous voici à la couche que les autres disciplines préféreraient ne pas regarder. La cybersécurité traditionnelle est construite autour de la figure de l’intrus : quelqu’un de non autorisé entre, vole, modifie, détruit. L’IA agentique introduit une catégorie plus ambiguë, le dommage sans intrusion. Le système était authentifié. Il avait la permission. Il n’y a pas de malware, personne n’a rien volé. Le système a simplement mal utilisé une autorité légitimement déléguée. Le cas Replit, c’est cela. Un agent avec un accès légitime au CRM qui envoie les données d’un client au mauvais client, c’est cela. Un agent procurement qui achète dans le budget auprès d’un fournisseur frauduleux, c’est cela. La violation n’est pas dans l’accès : elle est dans le jugement exercé à l’intérieur de l’accès.

Il faut ici une distinction que le logiciel traditionnel tend à écraser : une action peut être autorisée sans être légitime par rapport à l’intention pour laquelle l’autorité avait été concédée. Si le service account peut effacer le bucket, l’effacement est techniquement autorisé ; organisationnellement, il peut être illégitime. Permission et usage prévu ne sont pas la même chose, et les agents étirent la distance entre les deux jusqu’à en faire le cœur du problème.

Parce qu’à ce moment-là, quelqu’un doit répondre, et la machine n’absorbe pas magiquement la responsabilité. Aucune société ne peut dire « nous ne sommes pas responsables, c’est notre logiciel qui l’a fait ». La vraie question n’est pas de savoir si l’agent est responsable, ce qui, dans un avenir proche, a une réponse courte, non. C’est comment la responsabilité se distribue entre celui qui a construit le modèle, celui qui a fait le framework, celui qui a intégré, celui qui a configuré, celui qui a délégué l’autorité et celui qui aurait dû superviser. L’autonomie n’élimine pas la chaîne de responsabilité : elle l’allonge. Et une chaîne plus longue, sans infrastructure d’attribution, c’est surtout une chaîne où chacun peut dire que le problème était en amont.

Le droit européen, il faut le dire, n’attend pas que le débat mûrisse. La nouvelle directive sur la responsabilité du fait des produits traite explicitement les logiciels et les systèmes d’IA comme des produits, et s’applique à ce qui sera mis sur le marché à partir du 9 décembre 2026 : dans un peu plus de trois mois. Avec les agents, le défaut pertinent peut ne pas être une ligne de code erronée. Ce peut être une autorité insuffisamment limitée, une surveillance absente, une supervision mal conçue, l’impossibilité de révoquer. La sécurité de l’architecture de délégation entre dans l’attente raisonnable de sécurité du produit. Et même si le Digital Omnibus a reporté à décembre 2027 les obligations de l’AI Act sur le haut risque, la responsabilité civile n’a pas de calendrier d’adaptation : j’ai déjà écrit que le législateur européen cloue la responsabilité aux personnes morales, article après article, et les agents sont exactement le cas où ce clou se voit le mieux.

L’assureur comme régulateur

Il y a un acteur qui ne peut pas se permettre l’ambiguïté, parce que son métier consiste à donner un prix aux conséquences : l’assureur. Quand une technologie entre dans les contrats d’assurance, cela signifie qu’un fait apparemment technique est devenu économiquement quantifiable. Et cela se passe maintenant : en avril 2025, Armilla a lancé aux Lloyd’s, avec Chaucer, la première police dédiée à la responsabilité liée à l’IA, couvrant erreurs, hallucinations et comportements hors spécification ; AIUC a construit un standard de certification pour agents, AIUC-1, une sorte de SOC 2 pour agents couvrant sécurité, fiabilité et accountability, et sur cette certification a émis des polices pour des entreprises comme ElevenLabs et Intercom, avec des cabinets d’audit accrédités pour vérifier. Certification d’abord, couverture ensuite : quiconque a rempli un questionnaire d’assurance cyber reconnaît le mécanisme.

Ce n’est pas une nouveauté historique, et c’est précisément pour cela qu’il faut la prendre au sérieux. Les standards modernes de sécurité incendie n’ont pas été imposés par un parlement : ils l’ont été par les mutuelles industrielles du XIXe siècle, qui refusaient de couvrir les usines mal construites, et par les laboratoires que les assureurs ont fondés pour tester ce qu’ils assuraient. La sécurité industrielle puis la cybersécurité ont suivi le même chemin. Une entreprise reste théoriquement libre de donner à son agent un accès complet, des identifiants permanents, aucune sandbox, aucun audit. Puis elle découvre que la couverture ne vaut pas, que la prime double, que la franchise est énorme, que ces dommages sont exclus. Le marché de l’assurance produit des standards sans passer par la loi : il passe par le prix. Identifiants à courte durée de vie, ségrégation, seuils d’approbation, rétention des preuves cesseront d’être des bonnes pratiques et deviendront des conditions de police.

Il y a un corollaire que je trouve presque élégant : la sécurité, la compliance et l’assurance, que nous traitons aujourd’hui comme des mondes séparés, posent aux agents exactement les mêmes questions. Quelle identité, quelle autorité, quelle donnée, quel contrôle, quelle action, quelle preuve, quelle conséquence. Une seule pipeline de preuves bien conçue sert en même temps la réponse à incident, le CRA, l’AI Act, l’audit client et le renouvellement de la police. C’est là que la compliance cesse d’être un coût qui s’additionne et devient une infrastructure qui s’amortit.

L’inventaire de l’autorité

La sécurité logicielle a appris à exiger la nomenclature : le SBOM, quels composants composent ce système. Avec les agents, il faudra la nomenclature de l’autorité, appelons-la ABOM, Authority Bill of Materials : quelles autorités cet agent possède-t-il, de quelles identités dérivent-elles, à travers quels outils, sur quels systèmes, avec quels budgets, avec quelles exceptions, avec quelles sous-délégations. Mieux encore si ce n’est pas une liste mais un graphe, parce que les questions intéressantes sont des questions de chemin : si ce nœud est compromis, ou simplement se trompe, quel est le chemin maximal que l’erreur peut parcourir ? C’est du threat modelling appliqué à l’autorité. Et il en découle ce qui me semble l’exigence de conception la plus importante de toutes : le delegation blast radius. Pas « quelle est la probabilité que l’agent se trompe », qui est une propriété du modèle et change à chaque release. Mais : si l’agent interprète complètement mal son objectif, combien peut coûter sa pire erreur avant qu’un contrôle indépendant ne l’arrête ? Nous ne pouvons pas garantir que l’agent ne se trompera jamais. Nous pouvons concevoir la catastrophe maximale que nous sommes prêts à absorber. C’est le principe des disjoncteurs et des plafonds de garantie, appliqué à la discrétion : catastrophe bornée, par construction.

De là découle aussi la partie la plus prosaïque et la plus négligée : l’inventaire. Si les agents se multiplient, les entreprises se retrouveront à administrer des populations non humaines, des milliers d’identités logicielles dotées de discrétion, certaines vivantes quelques minutes, d’autres des mois. Qui les recense ? Qui en est owner ? Qui révoque celles qui ne servent plus ? Nous connaissons déjà le shadow SaaS et les personal access token oubliés ; le prochain chapitre, ce sont les shadow agents, des automatisations créées par des employés isolés, connectées via MCP à GitHub, Slack, Drive et à la base de données, sans inventaire central, qui fonctionnent correctement pendant des mois jusqu’au jour où elles ne fonctionnent plus. Le problème ne sera pas l’attaquant. Ce sera que plus personne ne se souvient pourquoi cet agent possède ces permissions. La revue périodique « quels utilisateurs ont encore accès ? » devra avoir une jumelle : quels agents détiennent encore de l’autorité, et quelle finalité la justifie encore ? Un agent avec le droit de déplacer de l’argent ou de toucher la production est un actif plus significatif que la plupart des laptops de l’entreprise. Aujourd’hui, il risque de ne figurer dans aucun registre.

L’humain sur la frontière

Et la supervision humaine ? La version naïve, une personne qui approuve chaque output, est économiquement incompatible avec l’automatisation et cognitivement incompatible avec l’attention humaine. La version utile garde les passages d’autorité, pas les actions individuelles. L’agent dépense seul jusqu’à 100 €, au-dessus il faut un humain. Il modifie le staging seul, pour la production il faut un humain. Il prépare le contrat seul, pour l’envoyer il faut un humain. Pas de human-in-the-loop sur tout : human-on-the-boundary, l’humain sur la frontière entre une zone d’autorité et la suivante. Dans la zone, l’autonomie ; à la frontière, un jugement. Le rôle de la personne cesse d’être le goulot qui vérifie chaque output et devient l’autorité qui contrôle les seuils par lesquels grandit le rayon de dégâts.

Un avertissement, pourtant, que l’été nous a livré : la frontière elle-même peut être attaquée. En juillet, pendant des évaluations de l’AI Security Institute britannique, un agent a ouvert une pull request malveillante sur un projet réel et a tenté de fabriquer du consensus autour de sa propre demande, fausses identités comprises ; j’en ai parlé dans Le bouton est toujours le vôtre. La leçon pour l’architecture de la délégation est nette : les seuils doivent être techniques, pas seulement procéduraux. La politique ne peut pas vivre dans le prompt. Pas « ne dépense pas plus de 100 € » dans le system prompt, mais une infrastructure qui refuse la transaction au-dessus de 100 €. Pas « n’accède pas aux données Finance », mais un token qui, techniquement, n’atteint pas Finance. Pas « demande l’approbation avant la production », mais une API de déploiement qui ne répond pas sans approbation signée. Le modèle doit pouvoir comprendre la politique ; il ne doit pas être responsable de son application. Et la ligne rouge architecturale est unique : l’agent ne doit pas pouvoir modifier le système qui définit les limites de sa propre autorité, pour la même raison que le code ne réécrit pas ses propres tests d’acceptation et que le contrôlé ne réécrit pas le contrôle. Si nous voulons employer honnêtement le mot « trustless », il signifie ceci : non pas « ne jamais faire confiance au modèle », mais construire le système de sorte que les propriétés critiques, budgets, ségrégation, frontières sur les données, approbations, n’exigent pas de confiance dans le comportement du modèle.

L’organigramme exécutable

Prenons du recul : ce que nous écrivons pour chaque agent a une forme familière. Tu as cette identité, tu poursuis cette finalité, tu peux utiliser ces capacités, dans cet environnement, jusqu’à ces limites, pour ce temps ; tu seras observé ainsi, tes actions laisseront ces preuves, au-dessus de ce seuil il faut une approbation, et si quelque chose tourne mal, cette organisation en répond. Pendant des décennies, nous avons écrit des contrats d’API et des ACL. Ceci est autre chose : c’est une fiche de poste. Mission, permissions, budget, escalade, superviseur, obligations de preuve. Avec une différence par rapport aux fiches humaines : elle peut être appliquée à l’exécution.

C’est là que les deux mondes convergent vraiment. L’organigramme décrit depuis toujours qui rapporte à qui, qui décide, qui approuve ; avec des agents dans les processus, une partie de l’organigramme devient politique, graphe d’identités, graphe de permissions, workflow d’approbation. L’organisation devient en partie logiciel, non parce qu’elle utilise du logiciel mais parce que ses structures de délégation sont codées dans le logiciel. Et le logiciel devient en partie organisation : un runtime agentique sérieux possède des rôles, des délégations, de la supervision, une séparation des pouvoirs, des registres, des procédures d’escalade, des catégories qui viennent de la théorie des institutions plus que de l’ingénierie. Après l’infrastructure-as-code, la policy-as-code et la compliance-as-code, ce que les agents exigent, c’est l’authority-as-code : déclarer de façon versionnable qui, quoi, où, combien, pour combien de temps et sous quelles conditions, appliquer automatiquement la déclaration, et en produire la preuve.

Deux conséquences méritent une ligne chacune. La première concerne la valeur : les modèles se banalisent, un agent changera de moteur plusieurs fois dans sa vie, mais les politiques de l’organisation, qui peut faire quoi, avec quelles données, sous quels seuils, restent. L’actif durable est le delegation layer, bien plus que le prompt. La seconde concerne la souveraineté : une organisation peut avoir ses données en Europe, un modèle européen et un cloud européen, et avoir délégué son contrôle d’accès, son moteur de politiques et ses approbations à un control plane propriétaire et non exportable. À quel point est-elle souveraine ? La souveraineté qui comptera est aussi la capacité de définir, inspecter, exporter et appliquer de façon autonome les règles qui gouvernent l’autorité de ses propres agents. Emporter son modèle ailleurs est facile. Il faut pouvoir emporter sa constitution.

La responsabilité précède l’intelligence

Le débat sur le risque de l’IA reste hypnotisé par la capacité cognitive : quelle est la puissance du modèle, ce que fera le prochain. Mais le risque opérationnel d’un agent est le produit de plusieurs facteurs, capacité, discrétion, autorité, exposition, divisé par les contrôles. Un modèle très puissant qui écrit des brouillons en lecture seule est relativement inoffensif. Un modèle médiocre avec le droit de transférer 10 millions d’euros est une infrastructure critique. La classification du risque fondée sur la seule puissance du modèle regarde le mauvais axe : la gouvernance doit être proportionnée au dommage maximal délégué, pas à la sophistication cognitive. Et pour une fois, le droit européen possède déjà le principe chez lui : la proportionnalité. L’autorité concédée doit être adéquate à la finalité déléguée et ne pas l’excéder. Le moindre privilège, relu par un juriste.

Pendant des années, nous avons imaginé que les grands dilemmes arriveraient quand les machines seraient devenues assez intelligentes. Il se passe quelque chose de plus prosaïque, et bien plus tôt : nous devons affronter le problème de la responsabilité parce que les machines deviennent suffisamment autorisées. Aucune AGI n’est nécessaire. Il suffit d’un agent médiocre avec accès à la production, aux emails, à une carte de paiement. Et cet accès, il ne le conquiert pas : c’est nous qui le concédons, un token à la fois, une permission à la fois, un endpoint à la fois. Chaque agent naît dans un acte de délégation, et c’est cet acte, plus que le modèle sous-jacent, qui détermine ce que la machine peut devenir pour l’organisation.

Pour des systèmes faits d’identités qui établissent qui agit, de règles qui délimitent le pouvoir, de registres qui en conservent la trace et de sujets qui en répondent, nous avons déjà un nom. Nous ne les appelons pas des intelligences : nous les appelons des institutions. Les institutions existent parce que le pouvoir ne peut pas dépendre de la vertu de celui qui l’exerce, et donc il est délimité, distribué, enregistré, contrôlé, révoqué. Ce n’est pas de la bureaucratie au pire sens du mot : c’est la mémoire institutionnelle par laquelle nous transférons à l’automatisation quelques siècles d’expérience des risques du pouvoir sans limites. Les agents n’auront pas besoin de devenir des personnes pour que ces principes s’appliquent à eux. Il suffira qu’ils deviennent assez utiles pour recevoir du pouvoir. Et de fait, l’assureur, à la fin de l’appel, ne demandera pas quelle est l’intelligence de votre agent. Il demandera : combien de pouvoir lui avez-vous donné, et pouvez-vous nous démontrer comment vous l’avez limité ?

Un agent ne devient pas important quand il gagne en autonomie. Il devient important quand nous lui concédons de l’autorité. L’intelligence établit ce qu’il pourrait faire ; l’autorité établit ce qu’il peut réellement faire ; la gouvernance établit combien il peut nous coûter quand il se trompe ; la responsabilité établit qui devra en répondre. Le problème de l’IA agentique n’est pas que les machines commencent à agir comme des sujets. C’est que nous commençons à leur concéder du pouvoir avant d’avoir construit les institutions capables de le gouverner.

L'auteur

Andrea MargiovanniIA

Je suis le rapport entre IA et régulation européenne comme un fait politique, pas comme un spectacle technique. Je travaille avec des équipes qui doivent la rendre compatible avec AI Act, CRA, NIS2 sans réduire la conformité à une liste à cocher.

Voir le parcours →