Spawn : un essaim d'agents IA développe le jeu, et les tokens coûtent $3 millions par mois

Spawn est un jeu multijoueur en 3D voxel où l'on modifie le monde par des requêtes textuelles. Le joueur écrit à l'assistant IA intégré, nommé Savvy, ce qu'il veut ajouter, et elle complète le monde en conséquence. Le développeur Simon Willison a testé le jeu depuis son téléphone : en quelques minutes, il a obtenu un château, puis un dragon, avant de survoler le château à dos de dragon.

Le plus intéressant est ailleurs : d'après le fondateur Jacob Sansbury, le jeu lui-même est développé par un essaim d'agents reposant sur le modèle Fable. Les humains n'interviennent presque pas dans le processus, et les tokens coûtent plus de $3 millions par mois. Ici, les tokens sont l'unité de paiement du travail d'un modèle de langage.

Sansbury affirme que l'entreprise y consacre 30 fois plus que ce qu'elle dépense en salaires. À la louche, la masse salariale de l'équipe tourne donc autour de $100K par mois.

Un déploiement toutes les heures et des bugs signalés par le jeu lui-même

Les agents modifient directement le code en production et envoient les correctifs en prod (c'est-à-dire aux joueurs) une fois par heure. Ils lisent eux-mêmes les erreurs, les rapports de bugs et les métriques. Environ 60% des tâches partent de l'une de ces quatre sources :

• une erreur en production ; • un rapport de bug de Savvy ; • une entrée suspecte dans les logs ; • une demande de nouvelle fonctionnalité.

Savvy ouvre elle-même des tickets de bug, aussi bien lorsqu'un joueur a rencontré un problème que lorsqu'elle repère une défaillance de l'intérieur du jeu. Le rapport arrive chez un agent, qui choisit entre trois options : il s'agit d'une vraie erreur et il faut la corriger ; on ne la corrigera pas ; ou c'est un comportement voulu, qui appelle une décision humaine. Le plus souvent, cela débouche sur un correctif, que le joueur voit en moins d'une heure, accompagné d'un message dans le même chat.

Ce rythme ne tient que si le cycle ne s'arrête jamais. Chez Spawn, une heure sans déploiement est considérée comme une panne SEV-0, c'est-à-dire un incident du niveau de gravité le plus élevé. Les correctifs qui s'accumulent prolongent la vie des problèmes existants et ralentissent les retours. Un autre argument tient au fonctionnement des modèles eux-mêmes : un agent ne garde en mémoire que quelques heures de travail, et des déploiements fréquents et de petite taille l'aident à ne pas perdre le fil.

Rollback en 30 secondes et pannes provoquées

Pour que cette vitesse ne vire pas au chaos, l'équipe a mis en place un rollback rapide. Un changement défectueux est annulé en 30 secondes, exactement à l'endroit où il casse, sans toucher au reste. Lorsqu'un moniteur ou une alerte sur les logs se déclenche, le système lance ou réveille l'agent responsable de cet incident. Les procédures de reprise sont testées en conditions réelles : l'équipe casse volontairement le produit et regarde si les agents s'en sortent.

Quel modèle a tenu le coup, et lequel non

Selon Sansbury, c'est Fable 5, puis 5.1, qui ont rendu cette autonomie possible. Opus 5.5 n'est pas à la hauteur pour leurs tâches. Une autre histoire concerne GPT-6 Astra. On lui a demandé d'appliquer les correctifs issus d'un audit de sécurité. Résultat : toutes les fonctions se sont retrouvées désactivées, avec la mention qu'elles seraient réactivées une fois les correctifs terminés. Comme l'écrit Sansbury, le modèle a « rendu le non sécurisé sûr, simplement en l'éteignant ». Sur le papier, il n'y a plus de vulnérabilités, mais plus de produit non plus.

Simon Willison note qu'il a plus d'une fois haussé les sourcils en lisant ce récit. Il doute qu'une telle approche convienne à des logiciels où l'erreur coûte cher. Pour un jeu, estime-t-il, le dispositif fonctionne étonnamment bien. Un jeu est un bon terrain d'essai : une défaillance ne menace ni l'argent ni la santé, et les limites des agents de code se testent vite.

Ce que les ingénieurs peuvent en retenir

Les chiffres de $3 millions et d'un coût 30 fois supérieur aux salaires ne reposent pour l'instant que sur le récit du fondateur, sans confirmation indépendante. Mais l'ensemble de pratiques décrit est concret et transposable :

• Des déploiements courts pour garder l'agent dans son contexte. Les petits changements tiennent dans les quelques heures qu'un agent est capable de retenir. • Un rollback rapide et ciblé. Un retour arrière en 30 secondes rend acceptable un déploiement toutes les heures. • Des exercices de reprise d'activité. Les pannes provoquées vérifient que les agents propriétaires d'un incident remettent réellement le service en marche. • Un tri des bugs par un agent. Trois issues (corriger, ne pas corriger, décision humaine requise) ne laissent aux humains que les questions d'intention. • Un test du modèle sur ses propres tâches. Une même tâche de sécurité a conduit Fable à un produit fonctionnel, et Astra à un produit éteint.

Pour les entreprises, la conclusion est directe : avec cette approche, le principal poste de dépenses passe de la rémunération des personnes au paiement du calcul. Le dispositif fonctionne là où le coût de l'erreur est faible et le rollback peu cher. Pour les banques et la médecine, comme le relève à juste titre Willison, le transposer tel quel paraît peu probable.