Trois mois de travail et des centaines d’ingénieurs hier, trois jours et une seule personne aujourd’hui. Le chiffre que Spotify a sorti à la conférence Code with Claude, à Londres, a fait le tour des résumés en une phrase : « grâce à l’IA d’Anthropic, Spotify industrialise son code ». Pratique, frappant, et largement à côté de la plaque.
Car si l’on s’arrête au modèle, on rate ce que l’entreprise suédoise a réellement construit. Et c’est précisément cette partie-là que tout acheteur d’assistant de programmation devrait regarder avant de signer.
Ce que le raccourci « grâce à Claude » efface
L’agent maison de Spotify s’appelle Honk. Il s’appuie sur Claude, via l’Agent SDK d’Anthropic, la brique qui permet de bâtir ses propres agents plutôt que d’utiliser l’assistant clé en main. Jusque-là, le récit colle : un grand modèle de langage, branché sur une base de code, qui programme à la place des humains.
Sauf que Spotify avait déjà l’accès au modèle. Ce qui lui manquait, ce n’était pas de l’intelligence brute, c’était tout le reste : faire tourner des centaines d’agents en parallèle, de façon autonome et planifiée, à travers des milliers de dépôts, sans qu’un humain valide chaque étape. Le modèle ne sait pas faire cela tout seul. L’infrastructure autour, si.
D’ailleurs, la question que Niklas Gustavsson, chief architect et VP of engineering du groupe, dit s’être posée est révélatrice : pourquoi ne pas avoir simplement pris Claude Code, l’outil prêt à l’emploi ? Réponse : parce que le besoin était industriel, pas conversationnel. On ne pilote pas une flotte de migrations comme on discute avec un assistant. Et le problème dépasse Claude Code : les agents clés en main de la concurrence, le Codex d’OpenAI comme Jules chez Google, reposent sur la même logique : un développeur confie une tâche, l’agent clone un dépôt et ouvre une pull request. Rien à voir avec une flotte qui migre des milliers de dépôts sans supervision.
Le harnais, pas le cerveau
Regardez où Spotify a mis son ingénierie, et vous comprenez où se loge la valeur. Chaque agent tourne dans un pod Kubernetes, ce qui autorise un parallélisme massif. Surtout, Honk ne peut actionner qu’un ensemble d’outils validés en amont. Pas n’importe quelle commande, pas n’importe quel accès : un périmètre défini par l’entreprise.
Parmi ces outils, des vérifications que l’agent déclenche lui-même. Une fois le code modifié, Honk lance un build dans l’intégration continue (le système qui assemble et teste automatiquement le code, dit CI) pour s’assurer que rien n’est cassé. L’agent ne se contente pas de produire : il prouve que sa production tient.
C’est là que se joue l’écart entre une démo bluffante et un déploiement à 3 000 ingénieurs. Le modèle propose ; le harnais contraint, teste et encaisse l’erreur. Retirez les garde-fous, le parallélisme et les boucles de vérification, et il vous reste un modèle qui écrit du code plausible, mais auquel personne ne peut se fier à grande échelle.
Pourquoi les scripts ne suffisaient plus
L’histoire de Spotify est utile parce qu’elle montre d’où vient le besoin. Pendant des années, la base de code a grossi jusqu’à sept fois plus vite que les effectifs. Mécaniquement, maintenir l’existant a fini par dévorer le temps qu’on aurait voulu consacrer aux nouvelles fonctionnalités.
La première parade ne reposait sur aucune IA. Elle s’appelait Fleet Shift : un ingénieur écrivait une règle de transformation, et des scripts l’appliquaient automatiquement à des milliers de dépôts. Redoutable pour les changements simples et répétitifs. Incapable, en revanche, dès qu’une modification devenait complexe ou dépendante du contexte propre à chaque dépôt.
Voilà le point de bascule. L’agent de code n’est pas arrivé pour remplacer des humains, mais pour franchir le mur sur lequel butaient les scripts déterministes : juger au cas par cas. C’est la seule chose qu’un modèle de langage apporte que l’automatisation classique ne savait pas faire. Tout le reste relève de l’outillage.
La leçon que les directions techniques devraient retenir
Gustavsson le concède sans détour sur les débuts : « Les modèles étaient tout simplement trop bêtes, et notre façon de procéder l’était tout autant. » La suite tient en une phrase : les modèles ont gagné en capacités, et les équipes ont fini par identifier les bons schémas. Deux progrès parallèles, pas un seul.
Pour une direction technique tentée d’acheter un assistant de programmation, le constat est inconfortable. Le modèle est désormais un produit banalisé : performant, accessible, partagé par tous vos concurrents. L’avantage durable se construit dans la couche que personne ne vous vend toute faite : la connaissance de votre propre code, les outils que vous autorisez l’agent à manipuler, les tests qui valident son travail, l’orchestration qui le déploie sans surveillance humaine permanente.
Autrement dit, le « trois jours au lieu de trois mois » n’est pas une caractéristique de Claude. C’est le résultat de plusieurs années de bonnes pratiques d’ingénierie chez Spotify, sur lesquelles l’agent vient se greffer. Un détail qui change tout au moment de budgéter un projet : la facture du modèle est connue d’avance, celle du harnais beaucoup moins.
Reste un signal qui en dit long. Conçu pour les migrations de masse, Honk a été aussitôt détourné par les développeurs eux-mêmes, qui l’invoquent désormais pour leurs propres besoins. Quand un outil interne échappe à son cahier des charges, c’est rarement le modèle qu’on remercie. C’est qu’on lui a donné les bons outils.
