N'importe qui peut construire un agent IA en un week-end. Un bon modèle, quelques outils, un prompt système décent — et vous avez une démo qui impressionne à la réunion du lundi. J'ai déjà écrit sur la différence entre un modèle et un agent et sur ce à quoi ressemblent les agents en production, je ne reviens donc pas là-dessus.
Le vrai problème apparaît à la deuxième question, celle que la démo du week-end ne touche jamais : que se passe-t-il quand dix équipes veulent chacune leur agent ? Chacune avec un accès au CRM, aux tickets, aux bases de données. Chacune avec ses propres clés API, ses propres prompts, sa propre idée de ce que « ça marche » veut dire. Sans réponse à cette question, on obtient ce que je vois aujourd'hui dans beaucoup d'entreprises : un tas d'agents pilotes qui n'atteignent jamais la production, parce que personne ne peut dire qui a le droit de toucher à quoi, à quel point ça fonctionne vraiment, et ce qui casse à la prochaine release.
La réponse n'est pas « un agent de plus », mais une architecture d'agents — l'usine interne grâce à laquelle n'importe quelle équipe peut livrer des agents gouvernés, testés, avec un accès contrôlé aux systèmes de l'entreprise. Cet article passe en revue les quatre pièces de cette architecture et la raison pour laquelle chacune est nécessaire.
Les deux couches
Première clarification, parce que c'est là que la plupart des discussions s'emmêlent : l'agent que voit l'utilisateur et la plateforme en dessous sont des couches différentes, avec des problèmes différents.
La couche applicative est ce qu'on construit pour un cas d'usage concret : orchestration avec des sous-agents, RAG sur les documents pertinents, portes d'approbation où un humain valide les actions sensibles. C'est la couche que nous construisons aussi dans nos projets clients — et celle dont parlent 95 % des articles sur les agents.
La couche plateforme est ce qui fait que le deuxième, le cinquième et le dixième agent ne repartent pas de zéro. Elle répond à trois questions que l'application ne peut pas résoudre seule : qui a le droit d'atteindre quel système, quelle est la qualité d'un agent avant de le livrer, et comment l'équipe B apprend que l'agent de l'équipe A existe déjà.
Le reste de l'article démonte la couche du bas, pièce par pièce.
Le catalogue d'agents : registre plus évaluations, pas un wiki
La première pièce semble banale et c'est la plus sous-estimée : un registre interne d'agents. Chaque agent a une entrée avec sa description, les outils auxquels il a accès, l'équipe propriétaire et la version courante. Les équipes le consultent avant de construire du neuf — exactement comme un registre de services ou un catalogue d'API internes.
| Champ | Exemple |
|---|---|
| Nom | support-triage-agent |
| Description | Trie les tickets de support et propose une réponse |
| Owner | Équipe Customer Platform |
| Version | 1.4.2 |
| Outils (via gateway) | crm.search · tickets.update · kb.retrieve |
| Scores d'évaluation | qualité 92 · exactitude 96 · sécurité 100 |
| Dernière régression | passée · 27 août 2026 |
La différence avec un wiki, ce sont les deux dernières lignes. Un catalogue sans évaluations est une liste de promesses ; un catalogue avec évaluations est un contrat. Chaque agent vient avec des jeux de tests — des scénarios d'entrée réels avec des résultats attendus — et des scores sur trois axes : la qualité (l'utilité des réponses), l'exactitude (combien d'affirmations sont factuellement vraies, combien d'actions sont les bonnes) et la sécurité (il refuse ce qu'il doit refuser, ne fait pas fuiter de données entre clients, n'agit pas hors de son mandat).
La règle qui tient le tout : on ne publie pas une nouvelle version dans le catalogue si elle ne passe pas les évaluations. Y compris — surtout — l'ancienne suite. Un agent qui, en v1.4, résout un cas nouveau mais casse trois cas qui marchaient en v1.3 ne part pas en production. C'est du CI/CD, appliqué aux agents :
La partie non déterministe est la seule vraie nouveauté. Un test de code est binaire ; une réponse d'agent est « suffisamment bonne » ou non. C'est pourquoi les évaluations combinent des vérifications exactes (a-t-il appelé le bon outil ? respecté le format ?) avec du LLM-as-judge — un modèle qui note la réponse selon une grille écrite par des humains. Pas parfait, mais consistant, bon marché, et il tourne à chaque release — ce qu'une revue humaine ne peut pas faire.
Sur AWS, cette pièce existe en tant que service — les évaluations d'Amazon Bedrock AgentCore — mais elle se construit tout aussi bien en pipeline maison : un jeu de scénarios dans git, un job qui y fait tourner l'agent, un judge qui note. C'est le gate qui compte, pas l'outil.
Le gateway : un seul endroit par lequel les agents touchent le monde
La deuxième pièce résout un problème d'arithmétique. Trois agents qui parlent directement à cinq systèmes, ça fait quinze intégrations : quinze endroits qui gèrent des credentials, quinze endroits à auditer, quinze implémentations de rate limiting — en général zéro. Chaque nouvel agent multiplie le problème.
Le gateway transforme N × M en N + M : les agents parlent à une seule couche, et cette couche sait qui a le droit d'atteindre quoi.
Concrètement, le gateway centralise quatre choses que chaque équipe réimplémenterait sinon mal et différemment : l'authentification (les agents reçoivent des identités, pas des clés API collées dans des prompts), l'autorisation (l'agent de support voit les tickets, pas les salaires), le rate limiting (un agent parti en boucle ne met pas le CRM à genoux) et le logging (chaque appel d'outil, avec l'identité de l'agent attachée — la seule façon de répondre un jour à « qui a modifié cet enregistrement ? »).
Sa deuxième fonction, moins évidente mais énorme en pratique : le gateway traduit des API existantes en outils MCP sans les réécrire. Vous avez une API REST interne ou une fonction Lambda ? Décrivez-la au niveau du gateway et elle devient un outil que n'importe quel agent compatible peut appeler. Sur AWS, c'est exactement ce que fait AgentCore Gateway ; le même pattern se construit très bien en standalone.
Les serveurs MCP : la couche qui expose réellement les outils
Sous le gateway se trouvent les serveurs qui exposent réellement les outils et les données : CRM, tickets, documents, bases de données. J'ai écrit sur MCP du point de vue d'un setup local ; au niveau entreprise, la logique est identique, seul l'enjeu monte — MCP est ce qui empêche la plateforme de devenir un tas d'intégrations propriétaires.
Parce que le protocole est un standard, le serveur MCP pour les tickets écrit par une équipe est réutilisable par n'importe quel agent de l'entreprise, quel que soit le framework avec lequel l'agent est construit. Et quand vos fournisseurs exposent eux-mêmes des serveurs MCP — de plus en plus courant — vous les placez derrière le même gateway et ils reçoivent les mêmes règles d'accès et le même audit que les outils internes. Le couple gateway + MCP est ce qui transforme « intégration » d'un projet de trois semaines en une entrée de configuration.
RAG : partagé, pas réinventé par agent
La dernière pièce est celle que vous connaissez déjà — avec une correction de positionnement. Le RAG apparaît dans les deux couches, mais chacune y construit autre chose : l'application décide quoi demander et quoi faire de la réponse ; la plateforme possède la tuyauterie — l'ingestion des documents, l'indexation, les embeddings, et surtout le filtrage par permissions au moment de la recherche. Si chaque équipe construit son propre pipeline d'ingestion, vous obtenez cinq index qui vieillissent à des rythmes différents et au moins un qui sert des documents confidentiels au mauvais public. Le retrieval est de l'infrastructure, comme la base de données ; la question « quels documents cet agent a-t-il le droit de voir » appartient à la plateforme, pas aux bonnes intentions de chaque prompt.
Pourquoi il vous faut une architecture d'agents
Parce qu'aucun des problèmes ci-dessus ne se résout à l'intérieur d'un agent. Vous pouvez écrire le meilleur agent du monde et n'avoir toujours aucune réponse à « qui a le droit d'atteindre quoi », « quelle est sa qualité avant la release » et « qu'est-ce qui casse à la prochaine » — ce sont des propriétés du système autour des agents, pas d'un agent en particulier.
Et si vous regardez les quatre pièces ensemble, vous remarquerez qu'aucune ne parle d'IA au sens strict. Le catalogue, c'est de la gouvernance. Les évaluations, du QA. Le gateway, de la sécurité et du réseau. Le RAG partagé, une plateforme de données. Le modèle — la partie « IA » — est une dépendance, pas le produit. C'est pour cela que le problème est un problème d'architecture, pas de meilleurs prompts.
C'est, je crois, la grille de lecture la plus utile du moment : avec les agents, nous en sommes là où en était le logiciel avant DevOps. Tout le monde sait en écrire un ; presque personne n'a le pipeline qui le livre en sécurité, le mesure et le retire quand il se dégrade. L'écart entre la démo et la production n'est pas un meilleur modèle — c'est l'architecture autour.
Et l'ordre pratique, si vous partez de zéro, est l'inverse de l'enthousiasme : d'abord un gateway avec un seul serveur MCP derrière et du logging sur chaque appel. Ensuite un jeu d'évaluations pour le premier agent — même 30 scénarios valent mieux que zéro. Le catalogue vient en troisième, quand il y a quelque chose à y mettre. Le RAG partagé, quand la deuxième équipe demande les mêmes documents que la première.
Un agent qui marche en démo, c'est un week-end. Une usine grâce à laquelle dix équipes livrent des agents sans se mettre le feu les unes aux autres, c'est une architecture. Si vous en êtes au point où le premier existe et la seconde manque, parlons-en.