De la flotte d'agents à l'organisation agentique : définir qui fait quoi
Comment attribuer à chaque agent une mission, un périmètre, une autorité, un propriétaire et un cycle de vie avant le passage à l'échelle.
Les agents IA sont encore souvent conçus comme des fonctionnalités isolées. Un besoin est identifié, un modèle est connecté à des données et à quelques outils, puis l’agent est mis à disposition d’une équipe.
Cette approche fonctionne tant que les agents restent peu nombreux, faiblement autonomes et séparés les uns des autres. Elle atteint ses limites dès qu’ils peuvent lire des données sensibles, modifier un système métier, déclencher un workflow ou déléguer une tâche à un autre agent.
À ce stade, chaque agent devient un nouvel acteur opérationnel. Il possède une mission, des outils, des accès et un certain pouvoir d’action. Il introduit également des dépendances, des risques et une responsabilité qui doit rester attribuée à une personne ou à une équipe.
Le passage à l’échelle ne pose donc pas seulement un problème de modèles ou d’orchestration. Il pose un problème d’organisation.
Cet article ouvre une série consacrée à l’architecture organisationnelle des agents. Elle suivra quatre questions :
- Qui fait quoi ?
- Qui agit au nom de qui ?
- Qui peut parler à qui et transmettre quoi ?
- Qui contrôle, prouve et interrompt l’ensemble ?
La première question est la fondation des trois autres.
La situation actuelle : la création avance plus vite que l’organisation
Les briques nécessaires à la création d’agents progressent rapidement. Les plateformes savent connecter des modèles à des bases documentaires, à des API, à des outils et à des workflows. Les équipes métier peuvent expérimenter sans reconstruire toute une infrastructure.
Cette démocratisation apporte de la vitesse, mais elle encourage aussi une logique locale. Chaque équipe optimise son cas d’usage, choisit ses outils et définit ses propres règles. L’entreprise obtient progressivement plusieurs agents utiles, sans disposer pour autant d’une vision commune de leur place dans l’organisation.
Ce qui existe généralement :
- des catalogues de cas d’usage ;
- des assistants ou agents spécialisés ;
- des workflows d’orchestration ;
- des contrôles propres à chaque plateforme ;
- des journaux techniques séparés.
Ce qui manque souvent :
- une cartographie des agents et de leurs capacités ;
- un propriétaire clairement responsable de chaque agent ;
- une séparation explicite des missions ;
- des règles permettant d’éviter les doublons ;
- une définition commune de l’autorité et des limites ;
- un processus de suspension et de retrait.
Le NIST AI Risk Management Framework recommande déjà de maintenir un inventaire des systèmes d’IA, de clarifier les rôles et lignes de communication, puis de prévoir leur retrait en fin de cycle de vie. Avec des agents capables d’agir, ces exigences de gouvernance deviennent des propriétés d’architecture.
Un agent autonome reste un acteur logiciel opérationnel
Lorsqu’un agent intervient durablement dans un processus réel, il ne devient pas un membre du personnel. Il devient un agent opérationnel : un acteur logiciel auquel l’organisation attribue une mission, un périmètre, des outils, des accès et une autorité bornée.
Ce terme décrit une fonction dans le système d’information, pas un statut humain ou juridique. Un agent ne porte ni responsabilité juridique ni discernement humain général. Il ne répond pas lui-même des conséquences de ses décisions. La responsabilité reste attachée aux personnes et aux organisations qui l’ont conçu, autorisé, exploité et supervisé.
La bonne formulation est donc la suivante :
Un agent est un acteur opérationnel logiciel dont la mission et les pouvoirs doivent être explicitement attribués, limités et supervisés.
Cette définition distingue l’agent opérationnel d’une simple fonctionnalité conversationnelle. Plus il peut agir sur le système d’information, plus son cadre organisationnel doit être précis. Un agent n’est donc opérationnel que lorsque sa mission, ses pouvoirs, son propriétaire humain, ses contrôles et son cycle de vie sont explicitement définis.
Le risque d’Agent Sprawl
Lorsque les agents se multiplient sans modèle commun, l’organisation peut entrer dans une situation d’Agent Sprawl : une prolifération d’agents créés localement, avec des missions, des droits et des dépendances difficiles à cartographier.
Cinq symptômes permettent de la reconnaître.
1. Les responsabilités se chevauchent
Deux agents couvrent la même capacité avec des règles, des sources ou des réponses différentes. Un assistant interne et un agent RH peuvent, par exemple, répondre tous les deux aux questions sur les congés sans partager la même source de vérité.
Le doublon technique devient alors un conflit d’autorité : lequel fait référence ?
2. Les privilèges s’accumulent
Un agent reçoit un premier accès, puis de nouvelles permissions sont ajoutées au fil des demandes. Son mandat initial reste étroit, mais son identité technique devient progressivement capable d’intervenir sur un périmètre beaucoup plus large.
3. Les décisions peuvent se contredire
Deux agents agissent sur le même objet métier sans règle de priorité ou de verrouillage. L’un modifie une donnée pendant que l’autre travaille à partir d’une version antérieure. La connexion entre les agents n’élimine pas ce problème ; elle peut même l’accélérer.
4. La responsabilité devient introuvable
Lorsqu’une action incorrecte se produit, il faut pouvoir répondre à plusieurs questions : quel agent a agi, pour quelle mission, au nom de qui, avec quelle autorisation, selon quelle règle et sous la responsabilité de quelle équipe ?
Un journal technique indique qu’un appel API a eu lieu. Il ne suffit pas à établir la responsabilité organisationnelle.
5. La redondance devient structurelle
Plusieurs agents récupèrent les mêmes données, exécutent les mêmes contrôles ou appellent plusieurs fois les mêmes services. Les coûts et la latence augmentent, tandis que personne ne sait quel agent peut être retiré sans casser une dépendance invisible.
Ce que doit définir une architecture organisationnelle des agents
L’architecture organisationnelle des agents est le modèle qui attribue à chaque agent une place dans l’organisation et formalise ses relations avec les utilisateurs, les systèmes et les autres agents.
Elle répond à sept questions.
| Dimension | Question de conception |
|---|---|
| Position | À quel domaine, produit ou processus l’agent appartient-il ? |
| Mission | Quel résultat précis doit-il produire ? |
| Périmètre | Que peut-il traiter et que doit-il refuser ? |
| Autorité | Peut-il informer, proposer, exécuter, déléguer ou interrompre ? |
| Accès | Quelles données, quels outils et quels systèmes peut-il utiliser ? |
| Interfaces | Avec quels utilisateurs, agents et services peut-il échanger ? |
| Sensibilité | Quel niveau de validation, de trace et de supervision est nécessaire ? |
À ces dimensions s’ajoutent deux attributs indispensables : un propriétaire humain et un cycle de vie.
Le propriétaire répond de la mission, des résultats et des risques. Le cycle de vie prévoit la création, l’homologation, la modification, la suspension et le retrait.
La fiche de mission de l’agent
Chaque agent devrait être décrit par une fiche de mission commune aux équipes métier, architecture, sécurité et exploitation.
Cette fiche contient au minimum :
- son identité et sa version ;
- sa mission et son résultat attendu ;
- son propriétaire et son sponsor métier ;
- son périmètre positif ;
- son périmètre négatif ;
- ses outils et sources de connaissance ;
- ses niveaux d’autorité ;
- ses interfaces et partenaires ;
- ses conditions d’escalade ;
- sa fréquence de revue et sa procédure de retrait.
Cette fiche ne doit pas rester un document statique. Ses informations doivent alimenter le registre des agents, les politiques d’accès, le harness d’exécution et les contrôles de supervision.
Séparer le plan métier du plan de contrôle
L’organisation logique gagne à être divisée en deux plans.
Le plan métier
Il rassemble les agents qui portent les missions opérationnelles. Ils sont organisés par domaine ou capacité : ressources humaines, finance, achats, relation client ou opérations.
Chaque domaine peut choisir ses agents, ses connaissances et ses workflows, à condition de respecter les contrats et politiques communs.
Le plan de contrôle
Il fournit les mécanismes transverses nécessaires pour rendre ces agents gouvernables :
- registre des identités et des capacités ;
- politiques d’autorisation ;
- classification des données et des actions ;
- distribution contrôlée du contexte ;
- journalisation et observabilité ;
- gestion des versions ;
- suspension et révocation.
La règle structurante est simple :
Centraliser la gouvernance ne signifie pas centraliser toute l’exécution.
Un super-agent disposant de toutes les données et de tous les outils créerait une concentration de privilèges et un point de défaillance majeur. Le plan de contrôle doit appliquer des règles communes, tandis que les agents métiers restent distribués et limités à leur domaine.
Exemple : une architecture organisationnelle RH
Le domaine RH permet d’illustrer cette séparation.
L’agent d’interface comprend la demande et traite les interactions à faible risque. Il ne possède pas automatiquement un accès complet aux dossiers RH.
La gateway vérifie l’identité du demandeur, la sensibilité de la demande et l’agent habilité à intervenir. Elle distribue seulement le contexte nécessaire.
Les agents spécialisés disposent chacun d’un périmètre limité. L’agent congés ne partage ni les outils ni les permissions de l’agent paie. Les actions sensibles ou irréversibles passent par une validation humaine ou un workflow déterministe.
Point essentiel : la décision d’autorisation ne doit pas être laissée uniquement à un modèle probabiliste. Un modèle peut classifier la demande ; une politique testable et auditable doit décider si l’action est permise.
L’organisation ne suffit pas : quatre identités doivent encore être reliées
Attribuer une mission à un agent ne prouve pas que l’instance qui agit est légitime. Quatre preuves d’identité doivent être distinguées puis reliées :
- 01 Demandeur L'utilisateur ou le système qui initie la demande.
- 02 Agent logique L'agent déclaré, sa mission et son propriétaire.
- 03 Workload L'identité cryptographique de l'instance réellement exécutée.
- 04 Version La provenance et l'intégrité de l'artefact déployé.
La permission effective devrait ensuite résulter de l’intersection suivante :
Cette formule empêche deux erreurs : transmettre tous les droits de l’utilisateur à l’agent ou laisser l’agent agir avec un compte technique générique impossible à attribuer.
Ces mécanismes seront le sujet du deuxième article.
La souveraineté est un axe de déploiement, pas une autre organisation
La structure organisationnelle ne dépend pas du choix d’un cloud, d’un modèle ou d’un fournisseur. Une mission RH reste identique si l’agent est exécuté sur une plateforme SaaS, dans un cloud européen ou dans une infrastructure interne.
Le profil de souveraineté modifie en revanche le placement et le contrôle des composants :
- où résident les données et les modèles ;
- qui contrôle les identités et les clés ;
- qui opère le plan de contrôle ;
- quelles dépendances externes sont acceptées ;
- comment remplacer un fournisseur ou déplacer une charge.
La souveraineté doit donc être traitée comme une variante d’implémentation appliquée au même modèle logique. Cette distinction évite de confondre sécurité, localisation et autonomie opérationnelle.
Le Cloud Sovereignty Framework de la Commission européenne illustre cette lecture multidimensionnelle en distinguant notamment les dimensions juridiques, données et IA, opérationnelles, chaîne d’approvisionnement, technologiques, sécurité et conformité.
Concevoir l’organisation avant d’accumuler les agents
Une organisation agentique gouvernable commence par quelques décisions simples : inventorier les agents, attribuer chaque capacité à un domaine, désigner un propriétaire, formaliser les périmètres positifs et négatifs, puis classifier les actions selon leur sensibilité.
Les modèles, protocoles et plateformes viennent ensuite appliquer ce cadre. Ils ne peuvent pas le définir à la place de l’organisation.
Une architecture organisationnelle peut ainsi répondre à la première question : qui fait quoi ?
Elle ne prouve pas encore que l’agent qui se présente est bien celui qui a été autorisé, ni qu’il agit réellement dans les limites accordées par l’utilisateur.
Après avoir attribué les missions, la série doit donc répondre à une question plus sensible :
Qui agit au nom de qui, avec quelle identité et quelle autorité ?