Cloudflare, Meta et Shopify ont inventé la même chose. Sans se concerter.
En 1814, Mary Anning extrait un crâne d'une falaise à Lyme Regis. L'animal ressemble à un poisson — mais c'est un reptile. On nomma ces reptiles des ichtyosaures. Sous la pression de leur environnement, ces animaux ont évolué de la même manière que les dauphins et les requins de manière totalement indépendante, sous la même pression : l'océan. C'est ce qu'on appelle l'évolution convergente.
Le mécanisme
Le principe est simple : des lignées sans lien commun, soumises aux mêmes contraintes environnementales, finissent par développer les mêmes solutions. Les ichtyosaures, les dauphins et les requins n'ont aucun ancêtre commun récent — et pourtant, ils ont tous convergé vers la même forme hydrodynamique : le même rapport longueur/profondeur de corps (entre 3 et 5 m), le même profil fusiforme, la même organisation des nageoires. L'océan ne se soucie pas de l'arbre généalogique. Il sélectionne la forme qui fonctionne.
Ce mécanisme n'est pas une curiosité paléontologique. Il se reproduit partout où une pression suffisamment forte rencontre un espace de solutions suffisamment contraint.
Trois équivalences
Il y a trois semaines, trois sociétés — Cloudflare, Meta, Shopify — ont publié des post-mortems détaillés de systèmes qu'elles ont construits indépendamment. En les lisant côte à côte, on réalise qu'elles décrivent des évolutions similaires.
1. La même pression environnementale : la review humaine est le goulot
Trois domaines différents. Trois goulots d'étranglement qui ont la même forme : le temps de jugement humain.
Chez Cloudflare, c'est la code review qui ralentit le merge. Chez Meta, c'est le triage de régression de performance — dix heures par incident. Chez Shopify, c'est la pipeline de build et la suite de tests, trop lentes pour itérer vite.
Dans les trois cas, la ressource rare n'est pas la puissance de calcul. C'est l'attention des ingénieurs.
2. La même rupture technologique : le seuil de fiabilité
Les trois équipes ne sont pas arrivées à leurs systèmes par curiosité intellectuelle. Elles y sont arrivées parce que les LLMs ont, simultanément et dans leurs domaines respectifs, franchi un seuil de fiabilité : assez prévisibles pour qu'un pipeline de validation automatique puisse trancher entre une proposition acceptable et une à rejeter. Pas parfaits. Fiables.
Avant ce seuil, confier la génération de code à un LLM dans une boucle autonome était un pari. Après ce seuil, ne pas le faire est une inefficacité.
3. La même architecture : agent → validation → PR
Résultat : les trois équipes ont convergé vers la même boucle. Un agent observe (codebase, métrique, benchmark). Il génère une proposition de changement. Un pipeline de validation automatisée tranche. Si la proposition passe, elle atterrit en PR, prête à être reviewée — pas appliquée. L'humain ne disparaît pas du cycle. Il change de position.
Cloudflare : la code review industrialisée
Pourquoi. À l'échelle de Cloudflare, le volume de merge requests dépasse ce qu'une équipe humaine peut reviewer avec rigueur. Les standards (sécurité, performance, conformité, documentation) se dégradent mécaniquement avec le volume — sauf si on industrialise.
Comment. Un agent coordinateur basé sur OpenCode lance jusqu'à sept revieweurs spécialisés en parallèle — sécurité, performance, qualité de code, documentation, release management, conformité. Il déduplique les résultats et rend une décision (approuvé ou bloqué). Les modèles lourds sont réservés à la synthèse finale, pas à chaque ligne de code.
Résultats. 131 246 reviews en 30 jours. 48 095 merge requests. 5 169 dépôts couverts. Coût moyen : 1,19 $/review (P99 à 4,45 $). Délai médian : 3 minutes 39 secondes. Taux de cache hit sur les prompts : 85,7 % — les prefixes répétés (conventions de code, AGENTS.md, instructions de review) ne sont facturés qu'une fois, ce qui réduit la facture LLM à environ 10 % du prix sans cache. Économie mensuelle : cinq chiffres. Les ingénieurs ne relisent plus les PR mécaniquement — ils se concentrent sur les 4 % de PRs pour lesquelles un problème réel a été identifié. Le système est désormais obligatoire sur l'ensemble des dépôts de l'entreprise.
Meta : la défense à 3 milliards d'utilisateurs
Pourquoi. À 3 milliards d'utilisateurs, une régression de performance de 0,005 % se traduit en centaines de mégawatts gaspillés. Et pourtant, chaque incident prenait dix heures de triage manuel — un coût invisible mais constant.
Comment. Une plateforme d'agents sur deux couches. La couche MCP Tools standardise les interfaces d'accès aux données (profiling, résultats d'expériences, historique de configuration, recherche de code). La couche Skills encode les raisonnements d'ingénieurs seniors par domaine. Le même socle alimente deux modes : offense (trouver des optimisations proactivement) et défense (détecter les régressions et générer automatiquement les PRs correctrices).
Résultats. FBDetect détecte les régressions à partir de 0,005 %. Le triage passe de dix heures à trente minutes. Des centaines de mégawatts récupérés — l'équivalent de l'alimentation électrique de centaines de milliers de foyers. La même infrastructure, une fois posée, a alimenté plusieurs cas d'usage additionnels sans coût d'intégration proportionnel. C'est l'effet de plateforme appliqué aux agents : le retour sur investissement composé avec chaque nouveau skill ajouté.
Shopify : l'optimiseur qui ne dort pas
Pourquoi. Les builds de tests et les pipelines CI étaient devenus un frein à la vélocité d'ingénierie. Les optimisations de performance des outils internes sont systématiquement déprioritisées sous la pression des features. Personne n'a le temps — sauf un agent avec le bon budget de calcul et un critère clair.
Comment. pi-autoresearch est une boucle itérative : identifier une métrique cible → établir un baseline → générer des hypothèses → tester une implémentation → garder si meilleure, abandonner sinon. Elle tourne de manière autonome jusqu'à convergence ou épuisement du budget. Les crashes et les expériences ratées sont des données, pas des échecs.
Résultats. Builds VRT 65 % plus rapides. Parse+render Liquid 53 % plus rapide. Allocations d'objets réduites de 61 %. Tests unitaires 300 × plus rapides dans certains cas. Le dépôt pi-autoresearch : 3 600+ étoiles GitHub, 200+ forks. En interne, un canal Slack #autoresearch-wins est devenu un tableau de bord en temps réel. Les gains s'accumulent en continu sur des domaines que personne ne traiterait à la main. C'est l'intérêt clé de la boucle itérative sur la génération one-shot : l'espace de solutions est trop large pour une seule requête. La boucle est le produit.
Ce que ces trois systèmes n'ont pas fait
Ils n'ont pas éliminé l'intervention humaine.
Cloudflare continue de faire des revues manuelles pour les décisions architecturales et les intégrations cross-systèmes. Meta génère des PRs — que des ingénieurs mergent. Shopify soumet des hypothèses que le pipeline valide, pas directement des commits en production.
Le goulot ne s'est pas évaporé. Il s'est déplacé.
Avant : l'humain était l'auteur de la solution. Il triait, diagnostiquait, écrivait le correctif, ouvrait la PR. Après : l'humain relit les propositions de l'IA. L'agent trie, diagnostique, écrit le correctif, ouvre la PR.
C'est un changement de rôle, pas une éviction. Et c'est un changement plus profond qu'il n'y paraît : le jugement humain, concentré sur l'évaluation plutôt que sur la construction, est bien plus scalable. Un ingénieur peut reviewer dix PRs générées par des agents dans le temps qu'il lui aurait fallu pour en écrire une.
L'évolution convergente, elle, est aveugle. L'ichtyosaure ne savait pas qu'il redécouvrait la forme du poisson. Il n'a pas pu nommer le pattern, ni construire un SDK autour.
Les ingénieurs, eux, peuvent. Et c'est exactement ce qu'Anthropic vient de faire avec la feature Outcomes de Claude Managed Agents : déclarer formellement le pattern "l'agent boucle jusqu'à ce que les critères de succès soient atteints" comme une primitive d'architecture à part entière. Donner un nom à la forme, c'est permettre de la reproduire délibérément — sans attendre que chaque équipe la redécouvre seule sous la pression.
L'océan ne se soucie pas de d'où tu viens. Mais contrairement à l'ichtyosaure, tu as accès au fossile sur le web et peux décider de ce que tu vas construire ensuite.