Pourquoi Stripe a abandonné localhost pour piloter des centaines d'agents — 12 heures d'expérience pour comprendre

La règle du hackathon hier soir était simple : à 20h, je pose les specs et monte le harnais, puis je m’éloigne du clavier jusqu’à 8h du matin. Douze heures pour construire un produit entier avec des agents, sans intervention humaine.

Cette expérience m’a permis de comprendre de l’intérieur pourquoi Stripe, en présentant sa plateforme Minions, et Ramp, en partageant le retour d’expérience de leur agent background Inspect, ont tous les deux prononcé le même verdict : localhost, c’est terminé.

Faire tourner des agents en parallèle sur un portable, c’est se préparer à souffrir

Quand plusieurs agents partagent la même machine, les états se corrompent. Les secrets entrent en collision, les ports se chevauchent, et le moindre passage en veille de la machine suffit à faire tomber une boucle de 12 heures d’un seul coup.

Quand Stripe et Ramp ont publié leurs architectures d’agents, un point commun sautait aux yeux : les deux ont opté pour une VM indépendante et un conteneur de développement dédiés à chaque agent.

Les Minions de Stripe s’exécutent dans un environnement isolé qu’ils appellent « devbox ». Même type de machine que celle utilisée par les ingénieurs, mais complètement coupée des ressources de production et d’internet. Le démarrage prend moins de dix secondes, et les tâches parallèles s’exécutent sans le surcoût des git worktrees.

Inspect de Ramp repose sur Modal Sandbox. Chaque session dispose de son propre stack complet — Postgres, Redis, Temporal, RabbitMQ — sans aucune contention entre sessions, et démarre quasi instantanément grâce aux snapshots du système de fichiers.

Un agent de codage a besoin de mon ordinateur et de ma concentration. Un agent background, non. La nuit dernière, j’en ai eu la preuve concrète : un seul passage en veille a stoppé net toute la boucle. Sur une VM cloud, ça n’arrive pas.

Donner les tâches les unes après les autres, c’est se condamner aux fonctionnalités simples

C’est le point qui m’a le plus marqué pendant ce hackathon. En mode séquentiel, les agents produisent du CRUD correct. Mais dès qu’apparaissent des dépendances, ça déraille : un agent qui termine plus tard écrase ou casse ce qu’un autre a déjà livré. En boucle.

Il faut ici distinguer deux patterns : le fleet et le swarm.

Un fleet d’agents sert à appliquer un même changement sur des dizaines de dépôts simultanément. C’est ce qui permet à Stripe de fusionner plus de 1 000 PR par semaine : la même migration, le même correctif de lint, poussés en une seule fois sur des centaines de services.

Un swarm d’agents consiste à confier des parties différentes d’un même objectif à des agents distincts — frontend, backend, tests — et à tout rassembler sous forme de PR.

Sans exécution parallèle suivie d’une fusion par PR, un produit complexe est hors de portée. Je l’ai vérifié en pratique : l’approche parallèle avec revue de merge donne un résultat incomparablement plus abouti que le mode séquentiel.

Le rate limiting et la coordination entre agents se règlent au niveau de l’infra, pas du prompt

Sur douze heures de boucle, tomber sur un rate limit était inévitable. Et il fallait en plus que les commits produits par un agent puissent être relus par un autre, et que les zones d’ambiguïté dans les specs soient tranchées automatiquement.

Il y a une formule qui résume parfaitement la situation : « Écrire “ne supprime pas les fichiers” dans le prompt système, c’est une prière, pas un contrôle. » C’est exactement ça.

Stripe a résolu le problème au niveau de la couche d’exécution. Les Minions sont isolés des ressources de production et d’internet par défaut, ce qui les rend sûrs à faire tourner sans vérification de permissions au cas par cas. Plus de 400 outils MCP sont hébergés sur un serveur interne appelé « Toolshed », et chaque agent ne peut accéder qu’à un sous-ensemble curé de ces outils.

Ramp a pris une autre approche : toutes les PR créées par Inspect passent obligatoirement par un compte utilisateur réel via OAuth GitHub — pas un ID d’application. Résultat : structurellement, aucun code ne peut être fusionné sans revue humaine.

Verrouiller les permissions au niveau de l’exécution, conserver des journaux d’audit, limiter le rayon d’impact des erreurs. Sans tout ça, aucune équipe sécurité ne signera pour des agents autonomes.

Un individu peut accélérer sans que l’organisation en bénéficie

J’appelle ça le « faux sommet » : dès qu’on introduit des agents de codage, les PR s’accumulent, mais le cycle time ne bouge pas. Les revues débordent, la CI casse, les conflits de merge s’entassent.

Pendant le hackathon, la vitesse de génération de code n’était pas le problème. C’est l’intégration et la validation de tout ce code qui a consommé la majorité du temps.

Stripe règle ce goulot d’étranglement par l’automatisation. Les Minions utilisent une orchestration hybride qui entrelace boucles agentiques et opérations déterministes : lint, tests, opérations git — tout est garanti de se terminer, sans pour autant bride la créativité des agents. Les tests CI sont limités à deux tentatives maximum pour éviter les boucles infinies.

Ramp mesure le succès au nombre de PR effectivement fusionnées. Plus de 50 % des PR créées par Inspect sont mergées, et plus de 80 % d’Inspect lui-même a été écrit par Inspect.

Pour que l’organisation accélère vraiment, les agents background doivent traiter les revues de PR, analyser les échecs CI et résoudre les conflits de merge avant les humains. Le basculement de « in the loop » (piloter directement) à « on the loop » (valider les résultats) est au cœur du sujet.

La vraie question, ce n’est pas la vitesse de production, c’est la structure d’intégration

Produire du code rapidement avec des agents, c’est un problème résolu. Stripe génère plus de 1 000 PR par semaine via des agents ; chez Ramp, les agents représentent plus de la moitié de toutes les PR.

Le véritable enjeu, c’est de concevoir le système qui permet d’intégrer en toute sécurité ce que les agents produisent : environnements d’exécution isolés, architecture parallèle avec merge, gouvernance au niveau de l’infra, et validation automatisée. Sans ces quatre piliers, les agents ne sont que des jouets rapides.