Voici ma thèse, posée d'entrée de jeu : l'architecture d'agent qu'Anthropic vient de publier comme une percée est celle que PHP nous impose depuis le début, et la plupart d'entre nous construisent des agents qui la jettent à la poubelle. Dans un billet d'ingénierie intitulé « Scaling Managed Agents: Decoupling the brain from the hands », Lance Martin, Gabe Cemaj et Michael Cohen racontent comment ils ont découpé leur agent mono-conteneur en trois pièces indépendantes — le harnais qui boucle sur le modèle, la sandbox où s'exécute le code généré, et la session sous forme de journal durable en append-only. Résultat : un time-to-first-token en baisse d'environ 60 % au p50, de plus de 90 % au p95, et toute une classe d'attaques par vol de credentials rendue structurellement impossible. Retire le vocabulaire IA et tu regardes un processus stateless qui reconstruit son monde depuis un stockage externe à chaque réveil. C'est une requête PHP. On fait ça depuis mod_php.

Le design d'origine était ce que le folklore infra appelle un animal de compagnie : un conteneur unique abritant la boucle du modèle, la sandbox de code et le journal d'événements, le tout blotti ensemble. Rapide à construire, pénible à maintenir. Déboguer signifiait se connecter en shell sur une machine qui contenait aussi des données utilisateur, donc en pratique personne ne pouvait déboguer. Atteindre le réseau privé d'un client exigeait du peering réseau ou de l'auto-hébergement, parce que le harnais supposait que tout habitait la porte d'à côté. Et le pire : le code généré par le modèle tournait dans le même conteneur que les credentials — une injection de prompt n'avait pas besoin d'exploit, il lui suffisait de demander au modèle de lire ses propres variables d'environnement. Si tu as déjà commité un fichier .env ou vu un plugin WordPress compromis lire wp-config.php, tu sais exactement comment cette histoire se termine.

Le correctif donnera une impression de déjà-vu à quiconque a fait passer une application PHP à l'échelle. Le harnais est devenu jetable : il démarre avec wake(sessionId), rejoue le journal via getSession, ajoute les nouvelles étapes avec emitEvent, et ne détient rien qui mérite d'être pleuré quand il plante. C'est tout le principe de PHP-FPM — le processus ne vaut rien, le stockage de session est sacré. La sandbox n'est provisionnée que lorsqu'un appel d'outil en a réellement besoin, et c'est précisément pourquoi les chiffres de latence ont bougé aussi violemment : dans le design couplé, chaque session payait le boot du conteneur et le clonage du dépôt avant le premier token, y compris les sessions qui n'exécutaient jamais une ligne de code. Le provisionnement paresseux n'est pas une idée nouvelle. C'est la raison pour laquelle tu n'ouvres pas de connexion à la base de données dans le bootstrap de ton framework pour une route qui sert une page en cache.

Le pattern des credentials est la partie que je ferais tatouer sur toute base de code d'agent, PHP ou pas. Anthropic utilise deux manœuvres : embarquer le credential dans la ressource au moment du setup — le token Git est utilisé exactement une fois pour cloner et configurer le remote, puis jeté, de sorte que push et pull fonctionnent sans que l'agent ne le détienne jamais — ou parquer les tokens dans un coffre-fort derrière un proxy. Le modèle appelle un outil MCP avec un token de session à courte durée de vie ; le proxy l'échange contre le vrai credential OAuth et effectue l'appel sortant. Le harnais n'apprend même jamais le secret. Compare ça à l'application Laravel ou Symfony moyenne qui appelle aujourd'hui l'API OpenAI ou Anthropic : la clé réside dans le même processus qui interpole des entrées utilisateur dans les prompts. Si tu laisses un LLM générer et exécuter du code — et la moitié des tutoriels d'agents destinés aux équipes PHP font exactement ça avec shell_exec et une prière — le token ne doit pas être atteignable depuis ce runtime. Point final.

Maintenant, le contre-argument honnête, parce qu'il est solide : trois interfaces, ça veut dire trois modes de défaillance, des sauts réseau et des frontières de sérialisation là où un processus unique avait des appels de fonction. Anthropic opère une plateforme managée pour des milliers de tenants ; toi, tu fais peut-être tourner un seul agent qui trie les tickets de support d'une seule entreprise. Pour ça, le script monolithique est franchement le bon choix aujourd'hui — un système distribué dont tu n'as pas besoin est un pire animal de compagnie que l'animal de compagnie. Je le concède sans ciller. Mais j'atterris quand même du côté découplé pour tout ce que tu comptes garder, pour une raison que le billet cloue parfaitement : chaque harnais encode des hypothèses sur ce que le modèle ne sait pas encore faire. Sonnet 4.5 avait tendance à bâcler la fin des tâches quand son contexte se remplissait, alors ils ont ajouté des resets de contexte ; sur Opus 4.5 le comportement a disparu et les resets sont devenus du poids mort. Ton contournement astucieux a une demi-vie plus courte que tes interfaces. Tout coupler, c'est rendre la crasse porteuse.

Il y a aussi dans le billet une idée plus discrète qui mérite plus d'attention que le graphique de latence : la session n'est pas la fenêtre de contexte. Toutes les solutions classiques au débordement de contexte — résumé, élagage, compaction — détruisent de l'information avant que tu saches si tu en auras besoin. Anthropic garde au contraire le journal d'événements complet hors de la fenêtre et laisse le harnais en extraire des tranches positionnelles, rembobiner jusqu'aux prémices d'une décision, remodeler les événements pour maximiser les hits du cache de prompts. Le journal ne promet que la durabilité ; toute l'astuce vit dans une couche que tu peux réécrire. C'est de l'event sourcing, et le monde PHP a un outillage mûr pour ça — EventSauce, Prooph, Broadway. Si tu intègres des fonctionnalités d'agent dans une application PHP, une table d'événements en append-only que tu peux rejouer bat un résumé glissant avec pertes dans presque tous les cas, et tu sais déjà l'exploiter.

Cette philosophie déborde même sur leur surface d'API. Le 22 juillet 2026, l'endpoint de listing de mémoire des Managed Agents a commencé à ignorer les paramètres order_by et order et à renvoyer les résultats dans un ordre stable défini côté serveur, avec invalidation des anciens curseurs de pagination pour que tu repartes de la première page. À première vue, une note de bas de page. En réalité, c'est le même principe : une interface étroite que la plateforme peut garantir à travers toutes ses implémentations futures vaut mieux qu'une interface configurable qu'elle ne peut pas garantir. Sois dogmatique sur les interfaces, humble sur les implémentations — ce qui, au passage, est aussi le meilleur résumé en une ligne de la raison pour laquelle les interfaces PSR ont mieux vieilli que la plupart des bibliothèques concrètes qui les ont implémentées en premier.

Alors voilà où j'attends ton contre-feu. Ma thèse, c'est que la discipline shared-nothing que PHP nous a inculquée — le processus meurt, l'état vit ailleurs, les secrets restent hors du runtime — est la meilleure fondation possible pour l'architecture d'agents, et que le démon d'agent stateful longue durée qu'enseignent la plupart des tutoriels est une régression dans laquelle nous marchons les yeux ouverts. Mais peut-être que je sur-ajuste à la plateforme que j'aime. Si tu as mis un agent en production depuis une stack PHP : l'as-tu construit comme une boucle stateless et reprenable sur un journal d'événements, ou comme un processus béni que tu soignes désormais à 2 h du matin — et sachant ce que ça coûte, lequel construirais-tu la prochaine fois ?