- ▸ De l'essaim-navigateur bricolé à l'ingénierie de la coopération
- ▸ Deux étages, deux logiques : planificateurs coûteux, exécutants nombreux
- ▸ 80 % en quatre heures contre une spirale : l'écart mesuré sur SQLite
- ▸ Pourquoi 90 % de la facture part dans les workers
Un essaim d’agents peut atteindre une qualité identique à un autre en dépensant vingt fois moins — ou vingt fois plus. Sur une seule tâche de portage SQLite, la facture d’exécution a oscillé entre 411 et 9 373 dollars pour un résultat final comparable. La question n’est plus « quel modèle est le plus fort », mais « où se loge le coût quand des dizaines d’agents travaillent ensemble ». Trois mesures, trois enseignements, une bascule d’ingénierie.
Ce qu’il faut retenir 1. Reconfiguré, l’essaim atteint 80 % de la suite de tests en quatre heures avec Grok 4.5, là où l’ancienne architecture partait en vrille et devait être stoppée avant sa deuxième heure. 2. Les agents exécutants (workers) portent au moins 69 % des tokens consommés, et plus de 90 % dans la majorité des runs : le coût vit dans l’exécution, pas dans la planification. 3. À qualité finale égale, le coût d’un run a varié entre 411 et 9 373 dollars selon le mix de modèles — un facteur supérieur à vingt. 4. Sous la nouvelle architecture, chaque configuration testée a fini par passer 100 % de la suite ; l’ancienne plafonnait entre 11 % et 77 % au bout de quatre heures. 5. Le mix Opus illustre la bascule : 19 013 lignes notées 97 % dans l’ancien harnais, contre 4 645 lignes notées 100 % dans le nouveau.
De l’essaim-navigateur bricolé à l’ingénierie de la coopération
Les premières démonstrations d’essaims d’agents relevaient de la performance de foire : lâcher plusieurs dizaines de modèles sur un objectif et regarder ce qui en sort. Le projet vitrine de Cursor consistait à faire construire un navigateur web entier, à partir de zéro, par un essaim. Le résultat tenait debout, mais la finition manquait — l’ensemble ressemblait à une maquette convaincante plutôt qu’à un produit maîtrisé.
Le glissement documenté dans le billet de Cursor sur l’économie des essaims tient en une phrase : cesser d’observer l’essaim comme un phénomène pour le concevoir comme un système. On passe de l’empirisme — « ça marche, on ne sait pas trop pourquoi » — à une ingénierie délibérée, où chaque rôle, chaque niveau de modèle et chaque flux de tokens devient un paramètre que l’on règle.
Cette bascule change la nature des questions. Tant qu’un essaim reste une curiosité, on mesure s’il réussit ou non. Dès qu’on l’industrialise, on mesure son coût, sa vitesse de convergence et sa stabilité — trois axes que les données de Cursor rendent enfin comparables.
Deux étages, deux logiques : planificateurs coûteux, exécutants nombreux
L’architecture repose sur une décomposition hiérarchique de la tâche. En haut, des agents planificateurs (planners) découpent l’objectif en sous-tâches et distribuent le travail. En dessous, des agents exécutants (workers) traitent ces unités de travail spécifiques, en parallèle, sans reconstruire à chaque fois la vue d’ensemble.
La logique de peuplement suit cette hiérarchie. Les planificateurs mobilisent les modèles les plus capables, car leurs décisions engagent tout l’essaim : mal découper, c’est propager l’erreur à des dizaines d’exécutants. Les workers, eux, tournent sur des modèles plus rapides et moins chers, parce que leur tâche est bornée et vérifiable. Cette division n’est pas cosmétique : elle décide de la structure de coût, comme on le verra.
Cursor présente ce schéma comme un « superset » des orchestrateurs rigides. Un pipeline classique fige les étapes à l’avance : étape 1, puis 2, puis 3. L’essaim, lui, laisse le nombre d’exécutants et la profondeur de délégation s’adapter à la difficulté rencontrée. Un orchestrateur linéaire devient alors un cas particulier de l’essaim — celui où l’arbre n’a qu’une branche.
Cette souplesse a un revers. Un système qui peut allouer autant d’agents qu’il « juge » nécessaire peut aussi s’emballer, ouvrir des branches inutiles et brûler des tokens sans converger. C’est précisément ce que révèle la comparaison des runs anciens et nouveaux. Pour approfondir la mécanique de délégation, voir aussi notre décryptage de l’orchestration multi-agents.
80 % en quatre heures contre une spirale : l’écart mesuré sur SQLite
Le banc d’essai retenu par Cursor porte sur une tâche de portage autour de SQLite, avec une suite d’évaluation notée en pourcentage de tests réussis et un couperet posé à quatre heures. C’est un cadre honnête : il mesure à la fois la vitesse de convergence et le plafond de qualité atteint dans un temps borné.
Le contraste le plus net vient de Grok 4.5. Dans la nouvelle configuration, l’essaim atteint 80 % de la suite en quatre heures. Dans l’ancienne, le run partait en spirale — multiplication d’agents et de branches sans convergence — au point qu’il fallait le mettre en pause avant même sa deuxième heure. D’un côté, une trajectoire qui monte ; de l’autre, un système qu’on débranche pour éviter qu’il ne s’enfonce.
Agrégée sur l’ensemble des runs, la différence se lit dans la dispersion autant que dans le niveau. Au terme des quatre heures, les nouveaux runs se tenaient entre 73 % et 85 %. Les anciens s’étalaient de 11 % à 77 %.
| Configuration | Réussite à 4 h | Aboutissement |
|---|---|---|
| Ancien essaim (ensemble des runs) | 11 % – 85 % (spread de 66 pts, hors valeur haute) | plafonnait, jusqu’à 97 % côté Opus |
| Nouvel essaim (ensemble des runs) | 73 % – 85 % (spread de 12 pts) | 100 % de la suite |
| Nouvel essaim, Grok 4.5 | 80 % à 4 h | 100 % de la suite |
Deux chiffres résument la reconfiguration. Le premier : l’écart entre le meilleur et le pire run passe de 66 points (11 à 77) à 12 points (73 à 85). La nouvelle architecture est environ cinq fois et demie plus resserrée — elle transforme un résultat aléatoire en résultat prévisible. Pour une équipe qui planifie une charge de travail, la prévisibilité vaut souvent plus que le pic de performance.
Le second chiffre est le plus tranchant : chaque nouvelle configuration a fini par passer 100 % de la suite. Le plancher de 73 % à quatre heures n’est donc pas un plafond, mais un point d’étape sur une trajectoire qui aboutit. L’ancien essaim, lui, laissait certains runs bloqués à 11 % — un échec de fond, pas un simple retard.
Notre lecture : le gain ne tient pas à un modèle plus intelligent, mais à un harnais qui empêche l’essaim de se saborder. La même famille de modèles, mieux encadrée, cesse de gaspiller son temps en branches mortes.
Pourquoi 90 % de la facture part dans les workers
La structure de la dépense est le point le plus stable de toute l’expérience. Sur l’ensemble des runs, les agents exécutants portent au moins 69 % des tokens consommés. Dans la majorité des cas, cette part franchit les 90 %. Autrement dit, quelle que soit la configuration, l’essentiel de la facture se joue à l’étage d’exécution, pas à l’étage de planification.
Ce résultat découle directement de l’architecture en arbre. Un planificateur produit une décision ; des dizaines d’exécutants produisent le code, les tests, les corrections. Le volume de tokens suit le nombre d’acteurs et la longueur de leur travail — deux grandeurs qui explosent à mesure qu’on descend dans l’arbre. La planification est courte et rare ; l’exécution est longue et massive.
La conséquence économique est contre-intuitive. On serait tenté d’optimiser d’abord le modèle du planificateur, puisqu’il est le plus cher à l’unité. Les données disent l’inverse : un point de pourcentage grignoté sur le coût unitaire des workers pèse bien plus lourd, parce qu’ils représentent 69 % à plus de 90 % du total. Le levier de coût, ce n’est pas le cerveau de l’essaim, c’est sa main-d’œuvre.
Cela redéfinit l’arbitrage entre modèles. Placer un modèle premium à l’exécution, c’est appliquer le tarif le plus élevé à la strate qui consomme le plus de tokens — la pire combinaison possible pour la facture. À l’inverse, un modèle rapide et bon marché à l’exécution comprime la ligne budgétaire dominante, à condition qu’il soit assez fiable pour ne pas rallonger la tâche. Tout l’enjeu tient dans cet équilibre entre coût unitaire et taux d’échec.
Même qualité, coûts multipliés par vingt : ce que révèle le mix de modèles
Le constat central de Cursor est que chaque mix de modèles produisait une qualité finale similaire, pendant que les coûts variaient énormément. C’est cette dissociation — qualité stable, prix instable — qui fait de l’essaim un objet économique nouveau. On n’achète plus une performance, on achète une manière de l’atteindre.
Les points de coût observés dessinent l’amplitude. Un run complet avec Opus 4.5 aux deux étages, planificateurs et exécutants, revient à 1 339 dollars. Dans une configuration plus lourde, les workers seuls coûtent 9 373 dollars. Et lorsqu’Opus 4.5 assure l’exécution dans une autre configuration, la flotte d’exécutants ne coûte que 411 dollars.
| Poste mesuré | Coût observé |
|---|---|
| Run complet, Opus 4.5 aux deux étages | 1 339 $ |
| Workers seuls (configuration coûteuse) | 9 373 $ |
| Flotte d’exécutants (Opus 4.5 à l’exécution) | 411 $ |
Le rapport entre le poste d’exécution le plus cher (9 373 $) et le moins cher (411 $) dépasse 22. Pour un livrable de qualité comparable, l’écart de facture d’un facteur vingt et plus ne se justifie par aucune différence de résultat visible. C’est le prix de la mauvaise combinaison, pas d’un meilleur produit.
Ce chiffre — un facteur supérieur à 22 sur le coût d’exécution, à qualité finale égale — mérite d’être posé comme la donnée-phare de tout le dossier. Il déplace la compétence de l’ingénieur. Hier, on choisissait le meilleur modèle. Aujourd’hui, on compose un mix, et c’est la composition qui décide de la rentabilité. La question « quel modèle ? » devient « quel modèle, à quel étage, pour quelle strate de tokens ? ».
Ce raisonnement rejoint un débat plus large sur la place respective des grands et des petits modèles dans les chaînes agentiques — sujet que nous avons abordé dans notre analyse du coût réel de l’inference. L’essaim en donne une illustration chiffrée : le modèle premium n’est rentable que là où sa fiabilité fait gagner du temps, c’est-à-dire rarement à l’étage qui consomme 90 % des tokens.
19 013 lignes à 97 %, ou 4 645 à 100 % : la fin de la métrique au volume
Le mix Opus offre la démonstration la plus parlante de la bascule. Sous l’ancien harnais, l’essaim produisait 19 013 lignes de code pour une note de 97 %. Sous le nouveau, il produit 4 645 lignes pour une note de 100 %.
| Harnais | Lignes produites | Note |
|---|---|---|
| Ancien | 19 013 | 97 % |
| Nouveau | 4 645 | 100 % |
Le nouvel essaim écrit environ 4,1 fois moins de code — une réduction de près de 76 % du volume — tout en franchissant les trois derniers points qui séparaient 97 % de 100 %. Le volume brut n’était donc pas un signe de travail accompli, mais de travail redondant : des lignes ajoutées pour compenser une architecture qui se cherchait, sans rapprocher du but.
Cette inversion invalide une métrique intuitive. Compter les lignes générées, comme on compterait la production d’une équipe, revient à récompenser le gaspillage. Les 19 013 lignes de l’ancien run ne valaient pas mieux que les 4 645 du nouveau — elles valaient moins, puisqu’elles s’arrêtaient à 97 % pour un coût de maintenance quatre fois supérieur. La bonne métrique n’est pas le volume, c’est la précision fonctionnelle atteinte par token dépensé.
Pour une direction technique, l’enseignement est direct. Un essaim qui produit peu et juste bat un essaim qui produit beaucoup et presque juste — non seulement sur la qualité, mais sur le coût aval, car chaque ligne superflue devra un jour être lue, testée et maintenue. La sobriété de code devient un indicateur de maturité de l’architecture.
Ce que ces chiffres ne disent pas encore
Un dossier honnête doit poser ses propres limites. La totalité de ces mesures provient d’une seule source, Cursor, sur une seule famille de tâches autour de SQLite. Aucune réplication indépendante n’est disponible à ce jour, et les configurations exactes derrière les points de coût de 411, 1 339 et 9 373 dollars ne sont pas toutes détaillées publiquement. Traiter ces chiffres comme des lois générales serait prématuré ; les lire comme un signal sérieux, en revanche, se défend.
Deux objections méritent d’être prises au sérieux. La première : la tâche de portage SQLite est vérifiable par une suite de tests, ce qui avantage les essaims — leurs branches convergent vers un critère net. Sur une tâche floue, sans oracle de succès, la spirale de l’ancien essaim pourrait n’avoir aucun garde-fou, et la nouvelle architecture perdre une partie de son avantage. La prévisibilité mesurée ici est peut-être propre aux domaines testables.
La seconde objection porte sur la généralisation économique. Le facteur 22 sur le coût d’exécution vaut pour ce banc précis ; rien ne garantit qu’il se retrouve sur des tâches où les modèles bon marché échouent plus souvent, allongeant les runs et effaçant leur avantage tarifaire. L’équilibre entre coût unitaire et taux d’échec est propre à chaque domaine — l’essaim ne le supprime pas, il le déplace.
Reste que la direction du mouvement est cohérente sur tous les runs rapportés : plus de prévisibilité, moins de code inutile, et un coût qui se pilote par la composition du mix plutôt que par le choix d’un modèle unique. C’est moins une preuve définitive qu’une hypothèse de travail solide, à confronter à d’autres bancs.
Ce qui change pour les équipes qui déploient des agents
La bascule décrite ici déplace la compétence rare. Elle ne réside plus dans l’accès au modèle le plus performant — accessible à tous via API — mais dans le réglage du harnais : comment découper la tâche, combien d’exécutants autoriser, quel modèle placer à quel étage, et quand couper une branche qui diverge. C’est un savoir-faire d’orchestration, proche de l’ordonnancement de calcul distribué.
Pour un responsable de plateforme, trois décisions deviennent chiffrables. Le choix du modèle des workers, qui gouverne 69 % à plus de 90 % de la facture. Le plafond de temps ou de tokens, qui distingue un run qui converge d’un run qu’il faut débrancher. Et la métrique de succès, qui doit mesurer la précision fonctionnelle, non le volume produit — sous peine de récompenser les 19 013 lignes plutôt que les 4 645.
Le coût d’une erreur d’architecture, lui, est désormais lisible : un facteur vingt sur la facture, pour un livrable identique. Ce n’est pas un détail d’optimisation. C’est la différence entre un essaim rentable et un essaim qu’on ne pourra pas se permettre de faire tourner en production.
FAQ
Le nouvel essaim est-il forcément moins cher que l’ancien ?
Pas mécaniquement. Le coût total dépend du mix de modèles retenu, et l’écart observé va de 411 à 9 373 dollars pour un poste d’exécution comparable. Ce que le nouvel essaim apporte, c’est la prévisibilité et la convergence vers 100 %, ce qui réduit le temps perdu ; l’économie vient de là, pas d’un tarif intrinsèquement plus bas.
Quels sont les deux rôles au cœur de cette architecture ?
Les agents planificateurs (planners), qui découpent l’objectif en sous-tâches et les délèguent, et les agents exécutants (workers), qui traitent ces unités de travail. Les premiers tournent sur les modèles les plus capables ; les seconds, plus nombreux, sur des modèles rapides et moins chers — et ils portent la quasi-totalité des tokens consommés.
Pourquoi ne pas mettre le meilleur modèle partout ?
Parce que les workers représentent au moins 69 % des tokens, souvent plus de 90 %. Placer un modèle premium à l’exécution applique le tarif le plus élevé à la strate la plus gourmande : c’est la combinaison la plus coûteuse pour un gain de qualité que les données ne montrent pas, puisque tous les mix aboutissent à une qualité similaire.
Le point le plus concret n’est pas un chiffre, mais une inversion de réflexe : sur un essaim d’agents, la première question à trancher n’est plus quel modèle est le plus fort, mais quelle composition évite qu’il ne parte en vrille. Les prochains bancs, sur d’autres tâches que SQLite, diront si ce réflexe se généralise — ou s’il reste l’apanage des domaines vérifiables.
Sources – Cursor, Agent swarms and the new model economics, 20 juillet 2026 — cursor.com/blog/agent-swarm-model-economics
