Les agents décident. Le code exécute. Le travail est de savoir où passe la ligne.

Une phrase circule dans les conseils d'administration, qui sonne comme l'avenir et se comporte comme une facture : les agents vont remplacer les applications. Elle mérite d'être prise au sérieux, parce que la part qui est vraie est réellement nouvelle, et la part qui ne l'est pas sera payée par celui qui construira dessus.

La question utile n'est pas s'il faut utiliser des agents. C'est où passe la ligne entre ce qu'un agent décide et ce que le code exécute. Placez-la au mauvais endroit et vous obtenez un système lent, coûteux, impossible à auditer, et de temps en temps sûr de lui à propos d'une chose qui n'a jamais eu lieu.

Ce qui a réellement changé

Les modèles sont devenus bons dans trois choses où le logiciel était historiquement mauvais : lire une instruction écrite par une personne, la découper en étapes, et choisir le bon outil pour chaque étape. Ce n'est pas un petit changement. Cela dispense d'anticiper toutes les formulations qu'un utilisateur pourrait choisir, ce qui représente l'essentiel de ce qui rend les interfaces traditionnelles rigides.

Ce qui n'a pas changé, c'est tout ce qui se trouve en dessous. Une règle fiscale reste une règle fiscale. Un paiement est réglé ou ne l'est pas. Une vérification de droits a une seule bonne réponse et aucune marge d'interprétation. Ces choses n'ont jamais été difficiles parce qu'elles étaient fastidieuses à exprimer. Elles ont été difficiles parce qu'elles doivent être exactement justes, à chaque fois, et démontrables après coup.

Le cerveau et le squelette

La comparaison qui survit au contact d'un vrai projet est anatomique. Le modèle est le cerveau : il comprend, pèse et décide. Les outils sont les bras : ils se tendent et agissent. Le code est le squelette, et sans lui le cerveau n'a rien à mouvoir.

Les squelettes ne font pas de spectacle. Personne n'en fait la démonstration en conférence. Mais l'analogie vaut la peine parce qu'elle prédit le mode de défaillance : un système construit avec un cerveau et des bras, sans squelette, ne s'effondre pas de manière spectaculaire. Il fonctionne à la démonstration, fonctionne une semaine, puis se met à produire des réponses plausibles et fausses, à un coût par requête que personne n'avait budgété.

Réserve-moi un vol

L'exemple canonique mérite d'être parcouru, parce que la ligne passe à un endroit très précis.

L'agent doit comprendre qu'un voyage à Berlin mardi prochain signifie partir après la réunion du matin. Il doit comparer les options, remarquer qu'économiser deux heures coûte trois cents euros, et demander si cet arbitrage en vaut la peine. Tout cela relève du jugement sur une demande ambiguë, et c'est exactement à cela que sert un modèle.

L'agent ne doit pas débiter la carte. Non parce que le modèle ne serait pas fiable, mais parce que débiter une carte est une transaction : soit elle a lieu une fois, soit la comptabilité est fausse. Il faut de l'idempotence, une politique de reprise, un chemin d'annulation et une trace qui survive à un audit. Rien de tout cela n'est une décision. Ce sont des garanties, et les garanties vivent dans le code.

Où passe la ligne

Le motif n'est pas arbitraire. La colonne de gauche, c'est tout ce qui doit être identique à chaque exécution, démontrable après coup, et juste même quand l'entrée est étrange. Celle de droite, c'est tout ce qui gagne à lire le contexte et à exercer un jugement.

Tout ce que l'on voudrait couvrir par un test unitaire appartient à gauche.

L'erreur que nous voyons sans cesse

L'erreur d'architecture la plus courante est de mettre la logique métier dans le prompt. Cela marche tout de suite, et c'est ce qui la rend dangereuse.

Les règles vont dans le prompt système, puis les exceptions, puis les exceptions aux exceptions. Six mois plus tard le prompt fait quatre mille jetons, chaque requête les paie tous, et personne ne peut dire avec assurance ce que fera le système face à une entrée inhabituelle, parce que la réponse n'est écrite nulle part où elle se lise comme de la logique. Changer une règle risque d'en changer trois autres, et aucun test ne l'attrape.

Les mêmes règles écrites en code coûtent moins cher à chaque requête, se relisent dans une pull request, et se testent. Le prompt fait alors ce qu'il sait faire : décider laquelle de ces règles s'applique à cette situation.

L'agent ne touche jamais la base de données

S'il y a une règle à retenir de cet article, c'est celle-ci.

Une question comme « quels clients n'ont pas de sauvegarde ? » ne doit pas devenir du SQL écrit par un modèle. Elle doit devenir un appel à quelque chose qui existe déjà :

# L'API est le contrat. L'agent choisit de l'appeler ;
# le code décide ce que cela signifie et qui a le droit de demander.
@router.get("/customers/without-backup")
def clients_sans_sauvegarde(user: User = Depends(current_user)):
    if not user.can("read:customers"):
        raise Forbidden()
    return depot.clients_sans_sauvegarde(tenant=user.tenant)

L'agent choisit l'outil. Le code impose qui peut demander, sur quel client, et ce que la question signifie. Si le modèle de droits change, une fonction change et tous les appelants en héritent, y compris l'agent.

Écrit à l'envers, avec le modèle générant des requêtes contre la base, le modèle de droits se met à vivre dans un prompt, et un prompt est une suggestion.

C'est la même frontière que celle dont nous parlions dans l'assistant IA qui ne lit que ce que l'utilisateur peut lire : l'assistant n'est jamais plus sûr que la couche qui se trouve dessous.

À quoi sert le MCP

Le Model Context Protocol est la partie de tout cela qui a avancé le plus vite, et il vaut la peine d'être précis sur le problème qu'il résout.

Avant lui, chaque assistant parlait à chaque outil à sa manière. Connecter un modèle à un système interne obligeait à écrire un adaptateur pour ce modèle, puis à le réécrire pour le suivant. Le MCP normalise cette conversation : l'outil décrit ce qu'il sait faire, et tout client qui parle le protocole peut l'utiliser.

Le dépôt de la spécification est devenu public en septembre 2024 et la collection de serveurs a suivi en novembre. Cette collection porte aujourd'hui plus de quatre-vingt mille étoiles sur GitHub, ce qui en dit moins sur la qualité que sur le manque que la norme comblait.

Ce qui compte du point de vue de l'architecture, c'est que le MCP est une couche de description, pas d'exécution. Il indique à un modèle ce que fait un outil et comment l'appeler. Il ne rend pas l'outil sûr, correct ni auditable. Cela reste une propriété de ce qui se trouve derrière le point d'entrée, c'est-à-dire une propriété de votre code.

Là où cela aide vraiment

La version honnête de la valeur est plus étroite que le discours et plus utile.

Un agent gagne sa place là où l'entrée est ambiguë et l'action délimitée. Lire le courriel d'un fournisseur et proposer à quelle commande il correspond. Transformer la description d'un problème en la bonne requête vers des systèmes qui ne partagent pas de schéma. Lire un contrat et signaler les clauses qui diffèrent du modèle. Dans chaque cas, la partie difficile est l'interprétation, et l'action qui suit passe par du code qui s'exécuterait à l'identique si une personne avait cliqué sur le bouton.

Il ne gagne rien là où l'entrée est déjà structurée et les règles déjà connues. Si un formulaire a huit champs et que la validation est une liste de conditions, un agent ajoute de la latence, du coût et de l'incertitude en échange de rien.

Ce que cela signifie pour l'architecture

Les agents sont une couche nouvelle, pas un remplacement de celles qui sont dessous. La pile que nous construisons est la même qu'avant, avec un ajout au sommet :

La couche d'API est l'endroit où cela se gagne ou se perd. Elle existait avant les agents, et si elle a été bien construite elle n'a presque besoin de rien pour les servir : elle sait déjà qui demande, ce que cette personne peut voir, et ce que chaque opération signifie.

Ce qui constitue la conclusion inconfortable pour qui espère que les agents rendront l'ancien travail inutile. Ils le rendent plus précieux. Une organisation dotée d'API propres et d'un vrai modèle de droits met un agent devant elles en quelques semaines. Une organisation qui en est dépourvue n'est pas lente faute d'agents. Elle est lente parce que les fondations n'ont jamais été posées, et poser un modèle par-dessus rend cela plus visible, pas moins.

La partie qui vieillit bien

Les outils vont changer. Le modèle aujourd'hui en production sera remplacé deux fois avant que ceci ne soit vieux, et le protocole peut être remplacé lui aussi.

Ce qui ne changera pas, c'est la répartition du travail. Le jugement d'un côté, les garanties de l'autre. Les systèmes qui les gardent séparés changent de modèle sans toucher aux règles, et changent les règles sans rien réentraîner. Ceux qui les mélangent doivent reconstruire les deux chaque fois que l'un d'eux bouge.

Nous écrivions récemment que l'IA a résolu la syntaxe, pas le jugement. Voici la version architecturale de la même conclusion. Les meilleurs systèmes construits aujourd'hui avec des agents ne sont pas ceux qui ont remplacé leur logiciel. Ce sont ceux qui ont su quelle moitié valait la peine d'être gardée.