Anatomie d'une plateforme agentique
« On va coller un agent là-dessus. »
Dans la même réunion : pour l'un, c'est un appel LLM avec un prompt système. Pour l'autre, c'est un orchestrateur multi-agents avec mémoire persistante et sandbox d'exécution. Personne ne bronche. Tout le monde hoche la tête.
LLM, agent, agentique, mémoire long / moyen / court terme, MCP, RAG, A2A… comment ranger tout ça, que dois-je prioriser : acheter, construire, héberger, louer, distribuer, centraliser ?
D'où cette cartographie : sept couches, deux préoccupations transverses. Pas de classement, pas de fournisseur à te recommander — juste de quoi situer chaque terme et comprendre de quelle couche vient ton prochain problème.
Attention, ce n'est pas un modèle neutre. Deux partis pris le traversent — traiter sécurité et observabilité comme des parois plutôt que comme des couches, et lire la même cartographie de deux façons opposées — et je les assume plus loin. D'autres cartographies existent ; celle-ci a un point de vue.
La cartographie
Reprenons l'étagère. Sept niveaux empilés, un pour chaque type de jouet : une place par étage, et la règle qui vaut partout — on ne laisse rien traîner par terre. Ranger, ce n'est pas caser au hasard ; c'est savoir de quel étage relève chaque chose.
Sept dalles empilées, donc, et deux parois qui les longent sur toute la hauteur : les préoccupations transverses. Chaque dalle porte ses composants types peints au sol, colorés selon leur nature — brique différenciante à construire, service managé, infrastructure, standard ouvert, surface utilisateur, ou composant encore émergent.
Pourquoi sécurité et observabilité sont transverses et pas des couches à part ? Parce qu'elles ne se glissent pas entre deux strates : elles s'appliquent à chacune. Une permission gouverne aussi bien l'appel d'outil (couche 4) que la surface d'interface (couche 7) ; une trace instrumente aussi bien l'inférence (couche 1) que la coordination multi-agents (couche 6). Les ranger dans une couche, c'est les rétrograder au rang de simple module — et se rendre compte trop tard qu'elles auraient dû être partout. La règle « on ne laisse rien traîner par terre » ne vit pas sur un étage : elle vaut pour tous.
Les sept couches
| # | Couche | Responsabilité | Composants types |
|---|---|---|---|
| 1 | Compute & inférence | Faire tourner les modèles et router les requêtes | Accélérateurs (GPU/TPU), serving (vLLM, TGI), model gateways, routing multi-modèles |
| 2 | Modèles | Fournir la capacité de raisonnement/génération | Foundation models, fine-tunes, petits modèles spécialisés (SLM) |
| 3 | Orchestration / runtime | Exécuter la boucle agentique et gérer l'état | Boucle act-observe-verify, planning, gestion d'état, mémoire de session |
| 4 | Outils & intégrations | Donner à l'agent des capacités d'action | Function calling, MCP, connecteurs, sandbox d'exécution |
| 5 | Mémoire & connaissance | Fournir le contexte durable et récupérable | RAG, vector stores, knowledge graphs, mémoire persistante |
| 6 | Coordination multi-agents | Faire collaborer plusieurs agents | Orchestrateur/workers, délégation, sous-agents, protocoles (A2A) |
| 7 | Interface & surfaces | Exposer l'agent à l'humain et aux systèmes | Chat, IDE, dashboards, exécution planifiée (cron), webhooks |
Où ça casse
La cartographie devient vraiment utile quand tu t'en sers comme grille de diagnostic. Une étagère rangée se dérange toute seule dès que personne ne sait plus de quel étage relève quoi — chaque symptôme ci-dessous, c'est un jouet remis au mauvais niveau, ou laissé par terre.
| Symptôme | Couche en cause |
|---|---|
| La facture explose sans qu'on sache pourquoi | 1 — pas de gateway, donc pas de mesure par appel |
| Changer de modèle t'oblige à toucher au code métier | 1 — accès aux modèles non centralisé |
| L'agent « oublie » au milieu d'une tâche longue | 3 — pas d'état après compaction du contexte |
| Chaque outil te coûte une intégration sur mesure | 4 — pas de protocole standard |
| L'agent a fait un truc destructeur | A — rayon d'impact non borné, pas d'approbation |
| Impossible de dire si la v2 est meilleure que la v1 | B — sans evals, la fiabilité, c'est une opinion |
| Ajouter un canal (cron, webhook) = tout réécrire | 7 — logique agentique couplée à la surface |
Si plusieurs lignes te parlent, il y a de fortes chances qu'elles ne pointent pas vers le même responsable dans ton organisation. Et c'est souvent ça, le vrai problème.
Deux lectures de la même cartographie
Si tu portes l'architecture
Ce que tu cherches à optimiser : la cohérence, une dette maîtrisée, des dépendances lisibles.
- Couche 1 — le gateway, c'est le seul point qui dure. Centraliser l'accès aux modèles derrière une interface unique, ça découple tout le reste du fournisseur. Trois jours de boulot qui t'en épargnent trente.
- Couche 3 — c'est là que se joue le produit. Ce qui te différencie, ce n'est pas le framework d'orchestration, c'est la gestion d'état : reprise après compaction, idempotence des étapes. Le framework, tu le remplaces ; un état mal pensé, tu le paies.
- Couche 4 — MCP transforme « N agents × M outils » en « N + M ». Et le sandboxing arrête d'être négociable dès l'instant où l'agent exécute du code.
- Couche 7 — c'est ton test de maturité. Si la logique agentique sait sur quelle surface elle tourne, chaque nouveau canal devient une réécriture. Découpler le runtime de la surface, c'est exactement ce qui sépare une vraie plateforme d'une démo.
- Transverses — reformule la question. Pas « est-ce que l'agent est sûr ? » mais « quelle est sa pire action possible, et qui l'approuve ? ».
Si tu portes la décision d'achat
Ce que tu cherches à optimiser : le risque, le coût total, la dépendance, la maturité.
| Couche | Build vs Buy | Coût dominant | Lock-in | Maturité |
|---|---|---|---|---|
| 1. Compute & inférence | Buy | Usage (tokens / heure GPU) | Élevé sans gateway | Élevée |
| 2. Modèles | Buy / Build (fine-tunes) | Prix par token, fine-tuning | Moyen (portable via gateway) | Élevée |
| 3. Orchestration / runtime | Build ou framework OSS | Ingénierie interne | Moyen à élevé si propriétaire | Moyenne |
| 4. Outils & intégrations | Buy + standard (MCP) | Intégration & maintenance | Faible si protocole standard | Moyenne |
| 5. Mémoire & connaissance | Buy / Build | Stockage + requêtes vectorielles | Moyen | Moyenne-élevée |
| 6. Coordination multi-agents | Build | Ingénierie | Faible | Faible (early) |
| 7. Interface & surfaces | Buy / Build | Licences par siège | Moyen | Élevée |
Cinq questions à poser avant de signer quoi que ce soit :
- Est-ce que l'accès aux modèles passe par un gateway standard ?
- Est-ce que les outils passent par un protocole ouvert (MCP) ?
- Est-ce que la mémoire est exportable — et dans quel format ?
- Est-ce que les traces et les coûts s'exportent vers ton observabilité déjà en place ?
- Est-ce que la sécurité et l'audit sont natifs, ou vendus plus tard en add-on ?
Une réponse floue sur l'une des cinq, ça passe. Deux, c'est un pattern.
Ce que cette cartographie ne dit pas
Ce qu'elle t'apporte est modeste, mais utile : un vocabulaire commun. Le jour où l'architecte dit « c'est un problème de couche 3 » et que l'acheteur comprend pourquoi ça ne se réglera pas en changeant de fournisseur, la cartographie a fait son job. La chambre n'est jamais rangée une fois pour toutes — mais au moins, tout le monde sait enfin de quel étage relève quoi.
Un mot sur les normes, tant qu'on y est. Sous la couche 2, une norme ISO existe déjà : ISO/IEC 23053 décompose l'anatomie d'un système d'apprentissage automatique — modèle, entraînement, inférence, tâche. C'est le dictionnaire normatif de ta couche 2, et du bord de la couche 1. Mais il s'arrête au modèle : la boucle agentique, MCP, la coordination multi-agents, les surfaces (couches 3 à 7) n'ont aucun équivalent ISO. Quant aux deux parois, elles relèvent d'autres normes de la même famille (SC 42) — 42001 pour la gouvernance, 23894 pour le risque — pas de 23053. Autrement dit : la moitié basse de l'étagère a un dictionnaire officiel, la moitié agentique n'en a pas encore. Ce n'est pas un trou dans la cartographie, c'est pourquoi elle est utile.
Reste une question qu'elle ne tranche pas : est-ce qu'elle tient la route face à ce que la CNCF, le platform engineering et les analystes décrivent de leur côté ? Elle converge avec eux sur la plupart des frontières, diverge sur deux points que j'assume — et bute sur une distinction que personne ne fait vraiment : celle entre l'agent qu'on produit et l'agent qui produit. C'est justement le sujet d'un second billet.