Pourquoi les agents ont besoin d'architecture.

Une démo répond à un cas. Un système absorbe des cas. C'est la première frontière, et elle est plus dure à voir qu'on ne le croit. Une démo qui marche est jolie, photogénique, partageable. Elle traverse les feeds. Elle pose la question naturelle : « puisqu'elle marche pour ça, elle marchera pour le reste ». Cette question, qui semble raisonnable, est le piège entier.

Une démo n'a jamais à faire trois choses qu'un système doit absolument tenir : retenir ce qui s'est passé avant, interagir avec d'autres composants sans deviner leurs contrats, et décider sans humain dans la boucle quand l'humain n'est pas là. Ces trois manques sont, à eux seuls, le programme d'une architecture agentique.

On n'extrapole pas une démo en système en lui faisant subir plus de charge. On le rebâtit. C'est la première chose qu'il faut savoir avant d'employer le mot d'« agent » au-delà du registre de la curiosité.

Le premier objet qu'une architecture agentique doit nommer, c'est la capability. Une capability, c'est ce qu'un agent peut faire, pas ce qu'il peut dire. C'est une action à laquelle on a attaché un contrat de signature : ses entrées sont typées, ses sorties sont typées, ses effets de bord sont nommés, sa latence cible est connue, ses échecs sont qualifiés. Réserver un créneau, envoyer un email validé, interroger une base produit, escalader vers un humain : autant d'actions qui méritent d'être pensées comme des fonctions d'un OS, pas comme des outils improvisés dans un prompt.

En démo, on n'écrit pas cela. On donne à un modèle l'accès à quelques outils, on laisse le prompt orchestrer l'appel, on regarde si ça marche. Le moment où l'on s'aperçoit qu'il faut typer, où il faut savoir précisément qui appelle quoi, avec quels arguments, et qui répondra de l'effet, est presque toujours le moment où l'on sort de la démo.

Une capability sans contrat, c'est un prompt déguisé. Une capability avec contrat, c'est une primitive d'architecture.

Un agent isolé n'a pas de mémoire. Il a un contexte. Ce sont deux choses différentes. Un contexte s'éteint à la fin de la conversation. Une mémoire dure au-delà, parce qu'on a décidé ce qui devait durer. La distinction n'est pas un détail technique. Elle conditionne tout ce qui suit : un agent qui ne se souvient pas, c'est un agent qui repose chaque jour les mêmes questions à l'utilisateur, qui ne sait pas qu'il a déjà vu ce dossier, qui retombe à plat à chaque session.

Une architecture sérieuse sépare au moins quatre couches : la mémoire de session (ce qui se passe pendant l'échange en cours), la mémoire métier (ce qui décrit l'organisation, ses règles, ses inventaires), la mémoire de doctrine (ce qui décrit la voix, les contraintes éditoriales, les arbitrages déjà rendus), et la frontière de l'oubli (ce qui doit disparaître, et selon quelle règle). Ces couches ne s'inventent pas au moment où l'agent en a besoin. Elles se posent avant.

À cette infrastructure s'ajoute un deuxième manque, plus fréquent encore : l'absence de contrat entre l'agent et le reste du monde. Un agent isolé promet, en langage naturel, dans son prompt, qu'il va « bien faire les choses ». Un agent en architecture signe un contrat : il déclare ce qu'il accepte en entrée, ce qu'il garantit en sortie, ce qu'il ne fera pas, et qui sera prévenu si quelque chose dévie.

Sans mémoire séparée et sans contrats signés, un agent reste une conversation. Avec, il devient un composant.

Quand on met plusieurs agents ensemble, deux nouvelles infrastructures deviennent obligatoires. Aucune n'est visible dans la démo, et c'est précisément pour cela qu'elles manquent presque toujours.

La première s'appelle gouvernance. Elle ne se confond pas avec la modération : c'est la grille qui décide qui peut décider quoi. Quelle décision est autonome ; laquelle exige une validation ; laquelle nécessite une escalade humaine ; laquelle est interdite tout court. Cette grille n'est pas un slogan moral, c'est un objet d'architecture, écrit, opposable, versionné. Sans elle, chaque cas litigieux re-pose la question depuis zéro, et la dérive opérationnelle est une affaire de semaines.

La seconde s'appelle observabilité. Pas les logs. Pas les dashboards. Un contrat protocole-first : chaque agent émet des événements typés ; chaque session laisse un graphe inspectable ; chaque décision laisse une trace dans un registre. Le but n'est pas de regarder ce qui se passe, c'est de pouvoir, demain, expliquer pourquoi ça s'est passé.

Gouvernance et observabilité sont les deux jambes sur lesquelles tient un système agentique en production. L'une sans l'autre, le système marche en boitant. Aucune des deux n'apparaît dans la démo. Toutes les deux s'écrivent avant qu'on en ait besoin, sinon on les écrit dans l'urgence et elles seront mauvaises.

J'utilise une définition opposable du mot « architecture » : c'est la liste des questions auxquelles on a tranché à l'avance, pour ne pas re-trancher à chaque feature.

Où vit la mémoire, et selon quelles couches ? Comment escalade-t-on vers un humain, et avec quel contexte ? Quels événements émet-on à chaque appel d'agent, et qui les indexe ? Quels contrats les agents signent-ils entre eux ? Quelle est la frontière entre une action autonome et une action sensible ? Qui versionne quoi ?

Tant qu'une équipe re-tranche ces questions à chaque nouveau cas, elle paie le coût plein du re-tranchage. C'est ce coût, et lui seul, qui tue la grande majorité des projets d'agents. Pas le modèle. Pas le prompt. Pas la latence. Le re-tranchage permanent : l'épuisement décisionnel.

Une architecture est ce qui transforme le re-tranchage en application d'un arbitrage déjà rendu. C'est moins glorieux qu'une démo, c'est ce qui rend la suite possible.

Le mot « architecte » a presque disparu pendant dix ans de la tech mainstream. On parlait d'ingénieur full-stack, de lead, de DevOps, de SRE, de tech founder. On évitait « architecte » parce qu'il fleurait l'enterprise lourd, la diapositive Visio, la décision lointaine.

Il revient. Et il reste. Parce qu'il décrit ce qui manque dans la plupart des déploiements d'agents : la personne qui tranche les questions du paragraphe précédent à l'avance. Cette personne n'écrit pas le prompt. Elle décide où vit la mémoire, comment les agents se parlent, quelle gouvernance s'applique, quelle observabilité s'instrumente. Elle décide aussi des absences : ce que le système ne fera pas, ce qu'il refusera, ce qu'il escaladera systématiquement.

Sans cette personne, il n'y a pas d'architecture. Sans architecture, il n'y a pas d'imputabilité. Sans imputabilité, il n'y a pas de système opérable : il y a une démo qu'on continue à secouer en espérant qu'elle tienne.

Ces trois absences sont corrélées. On les voit ensemble ou on ne les voit pas du tout.

Le premier anti-pattern, le plus répandu, est l'agent sans architecture. On reconnaît ses symptômes à l'œil nu.

Les prompts gonflent, parce qu'on y empile, à chaque incident, une instruction de plus pour ne plus reproduire l'erreur de la veille. La mémoire est improvisée : un cache, un fichier, une variable globale, un copier-coller. Les hand-offs entre composants cassent, parce qu'aucun contrat n'a été signé, et que la moindre dérive sémantique d'un côté brise silencieusement l'autre. La latence est imprévisible, parce que chaque appel d'agent ouvre la possibilité d'un appel récursif que personne ne plafonne. L'observabilité se fait par capture d'écran et par lecture rétrospective de logs bruts, le soir, quand un client se plaint.

L'issue de ce chemin est connue. La démo devient un POC. Le POC devient un projet zombie, qui ne marche jamais assez bien pour être généralisé, jamais assez mal pour être tué. On ne refait pas ce système en plus ambitieux. On le rebâtit.

C'est la chose la plus coûteuse à apprendre, et la plus simple à éviter : il fallait l'architecture avant, pas après.

L'anti-pattern symétrique existe aussi, et il est plus discret. Il s'installe dans les organisations qui ont compris le premier, et qui, ayant compris, ont commencé par documenter.

On y trouve de très beaux documents. Des couches identifiées. Des contrats spécifiés. Des schémas d'observabilité protocole-first. Des grilles de gouvernance. Des inventaires de capabilities. Tout est là, sauf l'agent qui exécute quelque chose.

Ce qui devait être une architecture devient une théologie. Le document s'enrichit. Le système, lui, ne se construit pas. Au bout de quelques mois, le document a vieilli sans que personne s'en rende compte : aucune confrontation avec un cas réel n'a fait remonter ses angles morts. Quand un cas réel arrive enfin, l'architecture documentée et le besoin opérationnel ne se reconnaissent pas, et c'est l'architecture qui cède, parce qu'elle a été écrite hors-sol.

Une architecture qui n'héberge pas d'agent reste un schéma. Un schéma qui n'a pas été frotté à un système réel est une opinion bien rangée.

On retombe ici sur l'argument du levier composé. Le 1000× n'apparaît jamais d'un agent. Il n'apparaît jamais non plus d'un schéma. Il apparaît d'une architecture qui héberge des agents : qui leur donne des capabilities typées, une mémoire séparée, des contrats signés, une gouvernance lisible, une observabilité protocole-first.

Chacun de ces objets, isolément, est modeste. Pris ensemble, dans une même architecture, ils déplacent ce qu'une personne peut faire. C'est, mot pour mot, ce que dit la thèse 1000× : « ×2 et ×5 et ×10 et ×10 font ×1000 ; personne ne réalise les quatre multiplicateurs d'un coup ; personne ne devrait essayer ».

Si l'on devait ne garder qu'une phrase de cet essai, ce serait celle-ci : l'architecture est ce qui permet à plusieurs gains modestes de se composer dans la même chaîne, et c'est cette composition, jamais un agent seul, qui produit le levier qu'on appelle 1000×.

Le reste, les outils, les modèles, les protocoles, les démos, n'est ni faux ni méprisable. Mais sans architecture, il reste là où il est : utile, ponctuel, oubliable. Avec elle, il devient un système.

C'est tout ce que dit cet essai.