L'infrastructure agentique et le nouveau backend

spinny:~/writing $ vim agentic-infrastructure-stack.md

1~
2Nous 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.
3~
4La question n’est plus seulement : quelle bibliothèque utiliser pour faire réfléchir un modèle en étapes ?
5~
6La vraie question est : où vit cet agent lorsqu’il cesse d’être un démo ?
7~
8Car 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.
9~
10Le 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.
11~
12## Parce qu'on en parle beaucoup maintenant
13~
14En 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 ?
15~
16En 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.
17~
18C'est la transition naturelle de la magie à l'ingénierie.
19~
20Lorsqu’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.
21~
22Pas au sens littéral. Au sens organisationnel.
23~
24## La première pièce : un environnement d'exécution où l'agent peut durer
25~
26Un 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.
27~
28Si 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.
29~
30C’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é.
31~
32Pour moi le runtime agent doit répondre à des questions très concrètes :
33~
34- où puis-je sauvegarder l'état entre une étape et une autre ?
35- que se passe-t-il si le processus s'arrête à mi-chemin ?
36- puis-je faire une pause et demander l'approbation ?
37- puis-je rejouer un run pour comprendre pourquoi il a fait ce choix ?
38- can I limit duration, memory, tools and cost?
39~
40Vercel 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.
41~
42## La deuxième pièce : le bac à sable, car l'agent doit pouvoir se salir sans se casser
43~
44Dès qu'un agent écrit du code ou exécute des commandes, un bac à sable est nécessaire.
45~
46Cela 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.
47~
48Un bac à sable agent doit avoir certaines propriétés :
49~
50- système de fichiers isolé ;
51- Limites de CPU, de mémoire et de temps ;
52- réseau contrôlé ;
53- les secrets montés uniquement en cas de besoin ;
54- journaux complets;
55- possibilité d'exporter des artefacts ;
56- une réinitialisation propre entre les exécutions, si nécessaire.
57~
58Vercel 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.
59~
60Cette 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.
61~
62Le bac à sable est la manière adulte de dire : allez-y, mais ici.
63~
64## La troisième pièce : MCP et le problème du connecteur
65~
66Le 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.
67~
68Sans 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.
69~
70MCP 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.
71~
72Et 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 ? ».
73~
74Pour 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.
75~
76Dans une bonne architecture agentique, MCP devient une sorte de panneau de brassage :
77~
78- GitHub pour le code et les problèmes ;
79- Slack pour le contexte conversationnel ;
80- Linear ou Jira pour les travaux planifiés ;
81- base de données en lecture seule pour l'analyse ;
82- navigateur ou scraper contrôlé pour les sites externes ;
83- le stockage des documents ;
84- environnements d'exécution isolés ;
85- systèmes internes exposés avec des autorisations strictes.
86~
87Le problème est qu’un catalogue d’outils sans politique n’est qu’un moyen plus élégant de créer le chaos.
88~
89## La quatrième pièce : identité et autorisations
90~
91C’est le domaine sur lequel de nombreuses démos ferment les yeux.
92~
93Un agent agit au nom de quelqu'un. Il doit donc être clair qui est l'objet de l'action.
94~
95Est-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 ?
96~
97Si 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.
98~
99La 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.
100~
101Cela 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.
102~
103## La cinquième pièce : mémoire et contexte, mais sans accumuler de déchets
104~
105Les agents ont besoin de mémoire, mais la mémoire est dangereuse lorsqu'elle devient un grenier.
106~
107Il existe au moins trois types de mémoire :
108~
109- mémoire d'exécution : que s'est-il passé lors de cette exécution ;
110- mémoire du projet : conventions, décisions, contraintes ;
111- mémoire personnelle ou d'équipe : préférences, ton, rituels, processus.
112~
113Tout 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.
114~
115Un agent qui se souvient mal est pire qu'un agent qui ne se souvient pas. Parce qu'il parle avec confiance.
116~
117L'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.
118~
119## La sixième pièce : observabilité, évaluation et relecture
120~
121Si un agent fait une erreur, le journal « appelé le modèle » ne suffit pas.
122~
123Vous 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 ?
124~
125Ici, les agents ressemblent plus à des systèmes distribués qu’à des chatbots.
126~
127Vous 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 ».
128~
129Les é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.
130~
131Ce 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.
132~
133## La septième pièce : les interfaces humaines
134~
135L'agent n'est pas obligé de simplement vivre dans un chat.
136~
137Certains 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.
138~
139L'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.
140~
141Une infrastructure d’agents décente comprend des surfaces de contrôle :
142~
143- l'état actuel ;
144- plan modifiable ;
145- des objets produits ;
146  -diff;
147- les demandes d'approbation ;
148- chronologie ;
149- bouton d'arrêt ;
150- bouton réessayer ;
151- autorisations visibles.
152~
153Cela 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.
154~
155## La pile mentale
156~
157Si je devais le dessiner aujourd'hui, la pile minimale d'agents serait la suivante :
158~
1591. Modèle : raisonnement, génération, appel d’outils, multimodal si nécessaire.
1602. Orchestration : boucle, étape, planificateur, politique, humain dans la boucle.
1613. Durée d'exécution durable : flux de travail, file d'attente, nouvelle tentative, pause, reprise.
1624. Sandbox : exécution de code, système de fichiers isolé, limitations, artefacts.
1635. Couche d'outils : MCP, API interne, navigateur, base de données, référentiel.
1646. Couche d'identité : OAuth, portée, secret, audit, politique.
1657. Couche mémoire : contexte du projet, récupération, instructions, expiration.
1668. Observabilité : mesures de traçage, de relecture, d'évaluation, de coût et de qualité.
1679. Surface du produit : discutez lorsque cela est suffisant, tableau de bord lorsque cela est nécessaire, examinez lorsque cela est important.
168~
169Le cadre agentique couvre principalement les points 2 et une partie du point 1. Le reste constitue le vrai travail.
170~
171## Ce que je ferais en pratique
172~
173Si une équipe me disait « nous voulons des agents en production », je ne commencerais pas avec dix agents.
174~
175Je 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.
176~
177Ensuite, je fixerais des limites très claires :
178~
179- pas d'écriture sans branches ni bac à sable ;
180- aucun secret dans l'invite ;
181- outils en liste blanche ;
182- l'approbation humaine des actions extérieures ;
183- journal et trace obligatoires ;
184- budget par course ;
185- sortie toujours inspectable.
186~
187Ce n'est qu'alors que je pourrais développer.
188~
189Les 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.
190~
191## Ma lecture
192~
193L’infrastructure agent est ennuyeuse de la meilleure des manières.
194~
195Ce 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.
196~
197L’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.
198~
199C'est là que les agents cessent d'être des jouets et deviennent des infrastructures.
200~
201##Sources
202~
203- [Vercel : Comment créer des agents IA avec Vercel et le SDK IA](https://vercel.com/kb/guide/how-to-build-ai-agents-with-vercel-and-the-ai-sdk)
204- [Vercel Docs : Bac à sable](https://vercel.com/docs/sandbox)
205- [Vercel Docs : Travailler avec Sandbox](https://vercel.com/docs/sandbox/working-with-sandbox)
206- [Vercel Docs : MCP](https://vercel.com/docs/mcp)
207- [Protocole de contexte de modèle : Spécification](https://modelcontextprotocol.io/spécification)
208- [OpenAI : Nouveaux outils pour les agents de construction](https://openai.com/index/new-tools-for-building-agents/)
209- [Blog Cloudflare : Agents sur Cloudflare](https://blog.cloudflare.com/agents-on-cloudflare/)
210~

NORMAL · agentic-infrastructure-stack.md [readonly]210 lines · :q to close

2Nous 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.

4La question n’est plus seulement : quelle bibliothèque utiliser pour faire réfléchir un modèle en étapes ?

6La vraie question est : où vit cet agent lorsqu’il cesse d’être un démo ?

8Car 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.

10Le 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.

11~

12## Parce qu'on en parle beaucoup maintenant

13~

14En 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 ?

15~

16En 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.

17~

18C'est la transition naturelle de la magie à l'ingénierie.

19~

20Lorsqu’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.

21~

22Pas au sens littéral. Au sens organisationnel.

23~

24## La première pièce : un environnement d'exécution où l'agent peut durer

25~

26Un 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.

27~

28Si 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.

29~

30C’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é.

31~

32Pour moi le runtime agent doit répondre à des questions très concrètes :

33~

34- où puis-je sauvegarder l'état entre une étape et une autre ?

35- que se passe-t-il si le processus s'arrête à mi-chemin ?

36- puis-je faire une pause et demander l'approbation ?

37- puis-je rejouer un run pour comprendre pourquoi il a fait ce choix ?

38- can I limit duration, memory, tools and cost?

39~

40Vercel 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.

41~

42## La deuxième pièce : le bac à sable, car l'agent doit pouvoir se salir sans se casser

43~

44Dès qu'un agent écrit du code ou exécute des commandes, un bac à sable est nécessaire.

45~

46Cela 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.

47~

48Un bac à sable agent doit avoir certaines propriétés :

49~

50- système de fichiers isolé ;

51- Limites de CPU, de mémoire et de temps ;

52- réseau contrôlé ;

53- les secrets montés uniquement en cas de besoin ;

54- journaux complets;

55- possibilité d'exporter des artefacts ;

56- une réinitialisation propre entre les exécutions, si nécessaire.

57~

58Vercel 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.

59~

60Cette 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.

61~

62Le bac à sable est la manière adulte de dire : allez-y, mais ici.

63~

64## La troisième pièce : MCP et le problème du connecteur

65~

66Le 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.

67~

68Sans 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.

69~

70MCP 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.

71~

72Et 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 ? ».

73~

74Pour 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.

75~

76Dans une bonne architecture agentique, MCP devient une sorte de panneau de brassage :

77~

78- GitHub pour le code et les problèmes ;

79- Slack pour le contexte conversationnel ;

80- Linear ou Jira pour les travaux planifiés ;

81- base de données en lecture seule pour l'analyse ;

82- navigateur ou scraper contrôlé pour les sites externes ;

83- le stockage des documents ;

84- environnements d'exécution isolés ;

85- systèmes internes exposés avec des autorisations strictes.

86~

87Le problème est qu’un catalogue d’outils sans politique n’est qu’un moyen plus élégant de créer le chaos.

88~

89## La quatrième pièce : identité et autorisations

90~

91C’est le domaine sur lequel de nombreuses démos ferment les yeux.

92~

93Un agent agit au nom de quelqu'un. Il doit donc être clair qui est l'objet de l'action.

94~

95Est-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 ?

96~

97Si 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.

98~

99La 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.

100~

101Cela 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.

102~

103## La cinquième pièce : mémoire et contexte, mais sans accumuler de déchets

104~

105Les agents ont besoin de mémoire, mais la mémoire est dangereuse lorsqu'elle devient un grenier.

106~

107Il existe au moins trois types de mémoire :

108~

109- mémoire d'exécution : que s'est-il passé lors de cette exécution ;

110- mémoire du projet : conventions, décisions, contraintes ;

111- mémoire personnelle ou d'équipe : préférences, ton, rituels, processus.

112~

113Tout 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.

114~

115Un agent qui se souvient mal est pire qu'un agent qui ne se souvient pas. Parce qu'il parle avec confiance.

116~

117L'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.

118~

119## La sixième pièce : observabilité, évaluation et relecture

120~

121Si un agent fait une erreur, le journal « appelé le modèle » ne suffit pas.

122~

123Vous 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 ?

124~

125Ici, les agents ressemblent plus à des systèmes distribués qu’à des chatbots.

126~

127Vous 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 ».

128~

129Les é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.

130~

131Ce 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.

132~

133## La septième pièce : les interfaces humaines

134~

135L'agent n'est pas obligé de simplement vivre dans un chat.

136~

137Certains 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.

138~

139L'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.

140~

141Une infrastructure d’agents décente comprend des surfaces de contrôle :

142~

143- l'état actuel ;

144- plan modifiable ;

145- des objets produits ;

146 -diff;

147- les demandes d'approbation ;

148- chronologie ;

149- bouton d'arrêt ;

150- bouton réessayer ;

151- autorisations visibles.

152~

153Cela 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.

154~

155## La pile mentale

156~

157Si je devais le dessiner aujourd'hui, la pile minimale d'agents serait la suivante :

158~

1591. Modèle : raisonnement, génération, appel d’outils, multimodal si nécessaire.

1602. Orchestration : boucle, étape, planificateur, politique, humain dans la boucle.

1613. Durée d'exécution durable : flux de travail, file d'attente, nouvelle tentative, pause, reprise.

1624. Sandbox : exécution de code, système de fichiers isolé, limitations, artefacts.

1635. Couche d'outils : MCP, API interne, navigateur, base de données, référentiel.

1646. Couche d'identité : OAuth, portée, secret, audit, politique.

1657. Couche mémoire : contexte du projet, récupération, instructions, expiration.

1668. Observabilité : mesures de traçage, de relecture, d'évaluation, de coût et de qualité.

1679. Surface du produit : discutez lorsque cela est suffisant, tableau de bord lorsque cela est nécessaire, examinez lorsque cela est important.

168~

169Le cadre agentique couvre principalement les points 2 et une partie du point 1. Le reste constitue le vrai travail.

170~

171## Ce que je ferais en pratique

172~

173Si une équipe me disait « nous voulons des agents en production », je ne commencerais pas avec dix agents.

174~

175Je 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.

176~

177Ensuite, je fixerais des limites très claires :

178~

179- pas d'écriture sans branches ni bac à sable ;

180- aucun secret dans l'invite ;

181- outils en liste blanche ;

182- l'approbation humaine des actions extérieures ;

183- journal et trace obligatoires ;

184- budget par course ;

185- sortie toujours inspectable.

186~

187Ce n'est qu'alors que je pourrais développer.

188~

189Les 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.

190~

191## Ma lecture

192~

193L’infrastructure agent est ennuyeuse de la meilleure des manières.

194~

195Ce 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.

196~

197L’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.

198~

199C'est là que les agents cessent d'être des jouets et deviennent des infrastructures.

200~

201##Sources

202~

203- [Vercel : Comment créer des agents IA avec Vercel et le SDK IA](https://vercel.com/kb/guide/how-to-build-ai-agents-with-vercel-and-the-ai-sdk)

204- [Vercel Docs : Bac à sable](https://vercel.com/docs/sandbox)

205- [Vercel Docs : Travailler avec Sandbox](https://vercel.com/docs/sandbox/working-with-sandbox)

206- [Vercel Docs : MCP](https://vercel.com/docs/mcp)

207- [Protocole de contexte de modèle : Spécification](https://modelcontextprotocol.io/spécification)

208- [OpenAI : Nouveaux outils pour les agents de construction](https://openai.com/index/new-tools-for-building-agents/)

209- [Blog Cloudflare : Agents sur Cloudflare](https://blog.cloudflare.com/agents-on-cloudflare/)

210~