L'infrastructure agentique et le nouveau backend
· 12 min read · Filippo Spinella · AI, Agents, Infrastructure, Developer Tools
Nous avons souvent parlé de frameworks agents. LangGraph, CrewAI, AutoGen, divers SDK, boucle, appel d'outils, mémoire, planificateur, critique, superviseur. Tous des mots utiles, pour l’amour de Dieu. Mais plus je regarde les agents réellement utilisés, plus il me semble que la partie intéressante est passée en dessous du niveau framework.
La question n’est plus seulement : quelle bibliothèque utiliser pour faire réfléchir un modèle en étapes ?
La vraie question est : où vit cet agent lorsqu’il cesse d’être un démo ?
Car un agent sérieux n’est pas une fonction qui appelle un modèle et renvoie du texte. C'est un petit système distribué. Il doit lire le contexte, utiliser des outils, exécuter du code, toucher des fichiers, se souvenir des décisions, demander la permission, échouer correctement, redémarrer, laisser des journaux, ne pas brûler le budget et ne pas se transformer en bulldozer à l'intérieur du référentiel de production.
Le cadre est le volant. L'infrastructure, c'est la route, les freins, le garage, l'assurance et la personne qui sait où se trouvent les clés.
Parce qu'on en parle beaucoup maintenant
En 2023 et 2024, la conversation était très centrée sur les modèles. Quel LLM ? Combien de contexte ? Combien ça coûte? À quel point est-il doué en programmation ?
En 2025 et 2026, la conversation a changé. Les modèles sont suffisamment performants pour faire un vrai travail, mais c'est pourquoi les éléments ennuyeux deviennent visibles : l'exécution, la sécurité, les connecteurs, l'identité, l'observabilité, l'exécution du code, le déploiement, la restauration.
C'est la transition naturelle de la magie à l'ingénierie.
Lorsqu’un agent a juste besoin de générer une réponse, un chat suffit. Lorsque vous devez ouvrir une pull request, interroger une base de données, appeler un CRM, démarrer un travail, naviguer sur un site, lire Slack, compiler du code et mettre à jour un document, vous avez besoin d'un système d'exploitation autour.
Pas au sens littéral. Au sens organisationnel.
La première pièce : un environnement d'exécution où l'agent peut durer
Un agent travaille souvent par étapes. Regardez l'état, choisissez une action, utilisez un outil, observez le résultat, mettez à jour le plan, répétez.
Si cette boucle réside dans une seule requête HTTP, vous rencontrez immédiatement un problème. Certaines actions sont lentes. Certains attendent l’intervention humaine. Certains échouent et doivent être réessayés. Certains doivent survivre à un déploiement ou à une expiration.
C’est là qu’entrent en jeu les flux de travail durables, les files d’attente, les antécédents de travail et les machines d’état. Ils ne sont pas glamour, mais ils font la différence entre un agent qui semble intelligent lors d'une démo et un autre que vous pouvez laisser travailler pendant que vous allez prendre un café.
Pour moi le runtime agent doit répondre à des questions très concrètes :
- où puis-je sauvegarder l'état entre une étape et une autre ?
- que se passe-t-il si le processus s'arrête à mi-chemin ?
- puis-je faire une pause et demander l'approbation ?
- puis-je rejouer un run pour comprendre pourquoi il a fait ce choix ?
- can I limit duration, memory, tools and cost?
Vercel travaille dur sur ce front avec des SDK d'IA, des fonctions, des flux de travail et des outils permettant de créer des agents au sein d'applications Web. Mais il ne s’agit pas uniquement de Vercel. Le fait est que l’agent a besoin d’un foyer opérationnel, et non d’un seul point de terminaison.
La deuxième pièce : le bac à sable, car l'agent doit pouvoir se salir sans se casser
Dès qu'un agent écrit du code ou exécute des commandes, un bac à sable est nécessaire.
Cela semble être un mot technique, mais l'idée est domestique : vous lui offrez un établi. Il peut ouvrir des fichiers, installer des dépendances, exécuter des tests, faire des expériences, générer des sorties. S'il se trompe, vous avez limité les dégâts. Si cela fonctionne, faites la promotion du résultat.
Un bac à sable agent doit avoir certaines propriétés :
- système de fichiers isolé ;
- Limites de CPU, de mémoire et de temps ;
- réseau contrôlé ;
- les secrets montés uniquement en cas de besoin ;
- journaux complets;
- possibilité d'exporter des artefacts ;
- une réinitialisation propre entre les exécutions, si nécessaire.
Vercel Sandbox va exactement dans cette direction : des environnements isolés pour exécuter du code, installer des dépendances, travailler avec des fichiers et produire des artefacts sans tout exécuter dans le runtime principal de l'application.
Cette chose est plus importante qu’il n’y paraît. De nombreux prototypes agents passent directement du modèle au système réel. Le modèle peut appeler un outil. Les outils peuvent faire des choses. Tout semble élégant jusqu'à la première mauvaise commande, la première dépendance installée au mauvais endroit, le premier token qui se retrouve dans un log.
Le bac à sable est la manière adulte de dire : allez-y, mais ici.
La troisième pièce : MCP et le problème du connecteur
Le Model Context Protocol est devenu l'une des parties les plus intéressantes de l'écosystème car il tente de standardiser quelque chose qui autrement devient rapidement ingérable : la façon dont un modèle découvre et utilise des outils externes.
Sans standard, chaque intégration est un petit îlot. Un connecteur pour GitHub fait dans un sens, un pour Slack dans un autre, un pour les bases de données avec une sémantique différente, un pour l'automatisation du navigateur qui ne ressemble à rien.
MCP propose un langage commun entre client et serveur : outils, ressources, invites, autorisations, transport, découverte. Cela ne résout pas comme par magie la gouvernance et la sécurité, mais cela donne une grammaire.
Et la grammaire compte. Lorsqu’un agent peut se connecter à de nombreux outils, la question n’est pas seulement « peut-il le faire ? ». Le problème est « est-ce qu'il comprend ce qu'il peut faire, dans quelles limites, au nom de qui et en laissant quelle trace ? ».
Pour moi, MCP n'est pas à la mode car il "fait des appels d'outils". Nous l'avons déjà fait. C'est un battage médiatique car cela déplace le centre de gravité de l'intégration unique vers le catalogue opérationnel d'outils.
Dans une bonne architecture agentique, MCP devient une sorte de panneau de brassage :
- GitHub pour le code et les problèmes ;
- Slack pour le contexte conversationnel ;
- Linear ou Jira pour les travaux planifiés ;
- base de données en lecture seule pour l'analyse ;
- navigateur ou scraper contrôlé pour les sites externes ;
- le stockage des documents ;
- environnements d'exécution isolés ;
- systèmes internes exposés avec des autorisations strictes.
Le problème est qu’un catalogue d’outils sans politique n’est qu’un moyen plus élégant de créer le chaos.
La quatrième pièce : identité et autorisations
C’est le domaine sur lequel de nombreuses démos ferment les yeux.
Un agent agit au nom de quelqu'un. Il doit donc être clair qui est l'objet de l'action.
Est-ce qu'il utilise les autorisations des utilisateurs ? D'un compte de service ? D'un espace de travail ? Avez-vous un accès temporaire ou permanent ? Pouvez-vous tout lire ou seulement quelques ressources ? Pouvez-vous écrire ? Pouvez-vous annuler ? Peut-il envoyer des SMS à de vraies personnes ?
Si vous ne répondez pas bien à ces questions, vous construirez tôt ou tard un assistant avec les clés de la maison et aucun souvenir de qui les lui a données.
La règle générale que j’aime est la suivante : l’agent doit être capable de faire moins que l’humain, pas plus que l’humain. Et quand il doit faire quelque chose de plus risqué, il doit s’arrêter et demander.
Cela signifie OAuth, portée du jeton, gestion des secrets, journal d'audit, politique de l'outil, liste verte, étape d'approbation. Des trucs pas très romantiques. Des trucs nécessaires.
La cinquième pièce : mémoire et contexte, mais sans accumuler de déchets
Les agents ont besoin de mémoire, mais la mémoire est dangereuse lorsqu'elle devient un grenier.
Il existe au moins trois types de mémoire :
- mémoire d'exécution : que s'est-il passé lors de cette exécution ;
- mémoire du projet : conventions, décisions, contraintes ;
- mémoire personnelle ou d'équipe : préférences, ton, rituels, processus.
Tout mettre dans l'invite est le raccourci. Cela fonctionne jusqu'à ce que cela ne fonctionne plus. La mémoire utile doit être soignée : indexée, mise à jour, expirée, vérifiée, rendue citable.
Un agent qui se souvient mal est pire qu'un agent qui ne se souvient pas. Parce qu'il parle avec confiance.
L'infrastructure doit donc inclure la récupération, les fichiers d'instructions, la base de connaissances, l'intégration en cas de besoin, mais aussi le nettoyage. Nous avons besoin d’une culture de la mémoire : ce qui entre, qui l’approuve, quand cela se détériore, comment puis-je le corriger.
La sixième pièce : observabilité, évaluation et relecture
Si un agent fait une erreur, le journal « appelé le modèle » ne suffit pas.
Vous voulez voir l'itinéraire. Quel contexte a-t-il reçu ? Quels outils étaient disponibles ? Quel outil as-tu choisi ? Avec quels arguments ? Quelle réponse avez-vous eu ? Combien ça a coûté ? Où est-il resté coincé ? L’humain approuvait-il quelque chose ? L'erreur concerne-t-elle le modèle, l'outil, l'invite, les données ou l'autorisation ?
Ici, les agents ressemblent plus à des systèmes distribués qu’à des chatbots.
Vous avez besoin de traces lisibles, pas seulement de journaux textuels. Vous devez être capable de rejouer une course. Il est nécessaire de comparer deux versions d'un même agent sur des tâches connues. Il faut mesurer les régressions : non seulement il « répond mieux », mais il « clôture le bon ticket sans toucher aux fichiers non sollicités ».
Les évaluations agents sont plus difficiles que les évaluations textuelles car elles incluent des actions. Il ne suffit pas de comparer une chaîne attendue. Il faut regarder les séquences, les effets secondaires, la qualité de l'artefact, le temps, le coût, le nombre d'interventions humaines.
Ce qui est drôle, c'est qu'on y revient toujours : le génie logiciel. Tests, environnements, traces, rollbacks. Sauf que le code décide désormais également de la marche à suivre.
La septième pièce : les interfaces humaines
L'agent n'est pas obligé de simplement vivre dans un chat.
Certains agents ont besoin d'un tableau. D'autres une page avec statut et journal. D'autres d'un bouton "approuver". Plus de commentaires en ligne. D'autres encore d'une CLI.
L'interface utilisateur change de comportement. Si la seule façon de contrôler un agent est d’écrire un long message, l’utilisateur donnera à l’agent des instructions vagues. Si toutefois il voit le plan, les diff, les sources, les risques et la prochaine action, il peut intervenir avec précision.
Une infrastructure d’agents décente comprend des surfaces de contrôle :
- l'état actuel ;
- plan modifiable ;
- des objets produits ; -diff;
- les demandes d'approbation ;
- chronologie ;
- bouton d'arrêt ;
- bouton réessayer ;
- autorisations visibles.
Cela semble trivial, mais ce n'est pas le cas. La différence entre « IA effrayante » et « assistant fiable » réside souvent simplement dans le fait que ce dernier vous montre où il met les mains.
La pile mentale
Si je devais le dessiner aujourd'hui, la pile minimale d'agents serait la suivante :
- Modèle : raisonnement, génération, appel d’outils, multimodal si nécessaire.
- Orchestration : boucle, étape, planificateur, politique, humain dans la boucle.
- Durée d'exécution durable : flux de travail, file d'attente, nouvelle tentative, pause, reprise.
- Sandbox : exécution de code, système de fichiers isolé, limitations, artefacts.
- Couche d'outils : MCP, API interne, navigateur, base de données, référentiel.
- Couche d'identité : OAuth, portée, secret, audit, politique.
- Couche mémoire : contexte du projet, récupération, instructions, expiration.
- Observabilité : mesures de traçage, de relecture, d'évaluation, de coût et de qualité.
- Surface du produit : discutez lorsque cela est suffisant, tableau de bord lorsque cela est nécessaire, examinez lorsque cela est important.
Le cadre agentique couvre principalement les points 2 et une partie du point 1. Le reste constitue le vrai travail.
Ce que je ferais en pratique
Si une équipe me disait « nous voulons des agents en production », je ne commencerais pas avec dix agents.
Je commencerais par un petit flux de travail répétitif et observable. Par exemple : ouvrir les PR de maintenance, mettre à jour la documentation à partir des problèmes résolus, préparer une révision hebdomadaire, trier les bogues en double, générer des tests pour les fichiers concernés.
Ensuite, je fixerais des limites très claires :
- pas d'écriture sans branches ni bac à sable ;
- aucun secret dans l'invite ;
- outils en liste blanche ;
- l'approbation humaine des actions extérieures ;
- journal et trace obligatoires ;
- budget par course ;
- sortie toujours inspectable.
Ce n'est qu'alors que je pourrais développer.
Les agents n’échouent pas simplement parce que les modèles se trompent. Ils échouent parce que nous les plaçons dans des environnements flous, avec des autorisations confuses et des attentes théâtrales.
Ma lecture
L’infrastructure agent est ennuyeuse de la meilleure des manières.
Ce n'est pas la partie qui vous fait applaudir dans la démo. C'est la partie qui vous permet d'utiliser réellement la démo le lundi matin, avec de vraies personnes, de vraies données et de vraies conséquences.
L’avenir des agents ne sera pas uniquement décidé par celui qui aura le meilleur modèle. Ce sera à celui qui construira le meilleur endroit pour le faire travailler : isolé quand il expérimente, connecté quand il le faut, toujours observable, autorisé avec des critères et assez humble pour s'arrêter quand il ne sait pas.
C'est là que les agents cessent d'être des jouets et deviennent des infrastructures.
##Sources