Revolut relègue Claude Code derrière un modèle chinois auto-hébergé : ce que cachent les 90 % d'économie

Mardi soir, The Register a titré que Revolut avait sorti Claude de ses outils de développement et divisé par dix sa facture d'IA. En vingt-quatre heures, la nouvelle a fait le tour des réseaux, souvent réduite à une formule : une banque européenne remplace Claude Code par un modèle chinois et économise 90 %.

Je suis allé voir à la source. Tout vient d'une intervention de quinze minutes de David Abitbol, responsable des opérations IA et de l'infrastructure chez Revolut, à la conférence AI Engineer de New York le 13 octobre 2026. La transcription est publique. Elle est plus nuancée, plus technique et franchement plus utile que les titres. Les chiffres tiennent, mais ils ne démontrent pas ce qu'on croit, et c'est justement ce qui intéresse une entreprise qui réfléchit à la mise en production d'une IA au quotidien.

Revolut et Claude Code : l'essentiel en cinq points

• Environ 2 000 ingénieurs de Revolut codent par défaut avec GLM, un modèle à poids ouverts du laboratoire chinois Z.ai (ex-Zhipu AI), que la banque héberge elle-même.
• Le modèle, GLM-5.1 au démarrage en avril 2026 puis GLM-5.3 aujourd'hui, tourne sur 56 GPU Nvidia B200 pour un coût moyen d'environ 0,30 dollar par million de tokens.
• La facture des modèles représente un dixième de ce que Revolut payait à Anthropic et OpenAI. Ce calcul n'intègre ni le matériel ni l'équipe qui l'exploite.
• Claude Code et Codex restent disponibles, réservés aux cas difficiles et aux tâches qui demandent de lire des images.
• Le gain de productivité annoncé, 60 % sur le temps de codage et 70 % sur le délai de livraison, vient surtout de la fin du rationnement des tokens, d'après Abitbol lui-même.

D'où viennent ces chiffres

Revolut n'a publié ni communiqué ni étude. L'intervention s'intitulait « Shipping like a startup, regulated like a bank », livrer comme une start-up en restant réglementé comme une banque. Les organisateurs ont mis en ligne la vidéo et la transcription, StartupHub.ai en a fait un compte rendu le 29 octobre, puis Tobias Mann l'a repris dans The Register le 3 novembre. TechRadar, Trending Topics et une dizaine de sites ont suivi, parfois avec des erreurs sur la version du modèle.

Une précision qui compte : ce sont des mesures internes, présentées par l'entreprise elle-même, sans audit extérieur. Pour situer l'échelle, Revolut revendique 80 millions de clients dans 45 marchés, et rappelle qu'en tant que banque réglementée dans l'Union européenne elle relève du régime de conformité le plus strict.

Gemini, Claude Code, puis GLM : la chronologie

Revolut suit deux indicateurs sur un échantillon d'environ 2 000 ingénieurs. Le temps de codage, mesuré en heures. Et le délai de livraison, mesuré en jours entre le moment où un développeur prend une fonctionnalité et celui où elle est fusionnée, prête à partir en production.

En janvier 2025, la banque ouvre Gemini à ses équipes : 10 % de gain sur le délai de livraison, 20 % sur le temps de codage. Abitbol l'explique simplement, les développeurs passent moins de temps sur Stack Overflow et dans la documentation.

Claude Code arrive ensuite, testé dès 2025 puis déployé à grande échelle début 2026. Le constat est sévère : peu d'effet mesurable. Certains ingénieurs dépensaient entre 1 000 et 10 000 dollars par mois en tokens sans retour évident. La direction réagit comme le ferait n'importe quel directeur financier, avec des plafonds de dépense stricts par personne.

En avril 2026, Revolut commence à héberger GLM-5.1 sur ses propres GPU. Sur le graphique présenté, les courbes décrochent nettement. Le modèle a depuis été remplacé par GLM-5.3, publié par Z.ai en août.

Sources : intervention de David Abitbol à AI Engineer NYC le 13 octobre 2026, The Register du 3 novembre 2026.

Le vrai sujet : des développeurs qui n'osaient plus s'en servir

C'est la partie la plus intéressante, et elle n'a rien à voir avec la Chine. Personne, pas même Abitbol, ne prétend que GLM écrit du code 60 % meilleur que Claude. Il qualifie d'ailleurs les derniers modèles d'Anthropic et d'OpenAI de « fantastiques ». Ce qui a changé entre les deux périodes, c'est le rapport des équipes au compteur.

Avec des tokens rationnés, raconte-t-il, les ingénieurs les gardaient pour la tâche de code la plus difficile, ou pour la fin du trimestre. Avec un accès quasi illimité, ils ont délégué tout le reste : le débogage, la boîte mail, les tickets Jira, les pages Confluence. C'est là que le délai de livraison a fondu, plus que le temps de codage. Sa conclusion : le goulot d'étranglement de l'ingénierie n'est pas forcément l'écriture du code.

On voit la même chose chez nos clients, à une autre échelle. Une équipe à qui on donne un outil IA avec un budget serré l'utilise peu, et souvent pour les mauvaises choses. Personne n'ose lancer l'agent sur la refonte d'un module, on ne relance pas une génération de tests qui a raté, on n'automatise pas les comptes rendus. Apprendre aux équipes à déléguer ces tâches périphériques pèse autant que le choix de l'outil, et c'est l'essentiel de ce qu'on travaille dans une formation Claude Code en entreprise.

Il faut garder un œil critique, comme le rappellent les organisateurs de la conférence dans leur synthèse : la comparaison interne n'isole pas l'effet du changement de modèle des autres causes possibles. Un an d'évolution des pratiques, des outils et de l'organisation pèse aussi dans ces courbes.

Ce que coûte vraiment un modèle auto-hébergé

Les 0,30 dollar par million de tokens sont un coût moyen calculé par Revolut sur sa propre infrastructure, avec son propre taux d'utilisation. Selon l'analyse de StartupHub.ai, la comparaison laisse de côté le cloud, le personnel et la supervision. Il faut y ajouter, au minimum, l'amortissement ou la location des GPU, l'électricité et les appels qui continuent de partir vers les modèles commerciaux.

Le matériel d'abord. GLM est un modèle massif : environ 754 milliards de paramètres, dont 40 milliards actifs à chaque token. D'après The Register, il faut à peu près 380 Go de mémoire GPU rien que pour charger les poids, puis 6 à 26 Go par utilisateur pour le contexte selon la précision. D'où les 56 B200, soit sept serveurs de calcul haut de gamme. On parle d'un investissement qui se compte en millions, que la banque achète ou loue.

L'exploitation ensuite. Abitbol est cash : chargez les poids sur des GPU, lancez l'inférence telle quelle, et vous obtiendrez des performances « terribles ». En avril, le service traitait environ 3 requêtes par seconde avec plus de 10 secondes d'attente avant le premier token, jusqu'à 14 secondes au plus fort de la migration. En août, avec exactement les mêmes 56 GPU, il en traitait plus de 7 avec 1,6 seconde d'attente. 76 % de demande en plus, et une attente divisée par huit, uniquement grâce aux réglages.

Ses leviers, pour ceux que la technique intéresse :

• limiter la fenêtre de contexte à 256 000 tokens alors que le modèle en accepte un million (« le long contexte est une arnaque », lâche-t-il), pour libérer de la mémoire au profit des requêtes simultanées ;
• quantifier le modèle en FP4 sur les puces Blackwell, ce qui réduit selon lui d'environ 40 % l'empreinte mémoire par rapport au FP8, sans perte de précision mesurée ;
• répartir le modèle sur huit GPU plutôt que quatre, pour laisser assez de place au cache d'attention (le KV cache) ;
• viser plus de 90 % de réutilisation du cache sur les tâches de code, puis tester le décodage spéculatif et la séparation des phases de lecture du contexte et de génération.

Son conseil de fond : résister à la tentation d'ajouter des GPU tant que la configuration existante n'est pas réglée. Ce travail a occupé des ingénieurs infrastructure pendant des mois, et il n'apparaît nulle part dans les 0,30 dollar.

Nous avions détaillé ces postes dans notre article sur le coût mensuel d'un agent IA en production : passé un certain volume, les tokens ne sont qu'une ligne de la facture, et rarement la plus lourde.

Un modèle chinois dans une banque européenne, est-ce raisonnable ?

Abitbol consacre la fin de son intervention aux DSI présents dans la salle. Il reconnaît la défiance qui entoure les modèles chinois, puis distingue deux choses que le débat mélange souvent. Utiliser le service en ligne de Z.ai, c'est envoyer ses requêtes vers la Chine. Télécharger les poids pour les faire tourner chez soi, c'est autre chose. Revolut fait la seconde, sur des serveurs situés aux États-Unis. Pour lui, tant que les données restent dans un pays couvert par un accord d'équivalence en matière de protection des données (il cite les États-Unis, l'Union européenne, le Royaume-Uni et Israël), la question du partage de données est réglée.

Le reste du dispositif est classique, et solide :

• les agents de code ne sont pas autonomes : ils tournent dans un bac à sable avec des règles d'approbation (on autorise une recherche dans le code, on bloque le lancement d'un build), ce qui permet de présenter au régulateur un outil sous supervision humaine plutôt qu'un agent autonome ;
• ce bac à sable protège aussi des usages malveillants en interne et de l'injection de prompt ;
• une journalisation complète permet de remonter le fil en cas d'incident, avec les mêmes réflexes que pour sécuriser un serveur MCP en entreprise.

Sur la fuite de données, l'argument tient. Il ne règle pas tout. Un modèle dont on ignore les données d'entraînement reste une boîte noire, même hébergé chez soi, et Z.ai présente GLM-5.3 comme particulièrement doué pour la recherche de vulnérabilités, ce qui mérite au minimum une analyse de risque. Les organisateurs de la conférence le soulignent : la lecture réglementaire d'Abitbol vaut pour la situation de Revolut, pas comme règle générale. Pour un outil qui produit du code relu avant fusion, le risque reste maîtrisable. Pour un agent qui déciderait seul sur des données clients, je serais nettement plus prudent. Et rappelons que tout cela concerne l'outil de développement des employés, pas les systèmes bancaires.

Dernier détail, rarement mentionné : la licence. GLM-5.2 était publié sous licence MIT. GLM-5.3 est distribué sous une licence propre à Z.ai, large pour un usage interne, mais avec des conditions particulières pour les entreprises qui revendent l'accès au modèle. À lire avant de s'engager.

Claude Code et Codex restent dans la boîte à outils

Le titre « Revolut sort Claude » est trompeur. Abitbol le dit sans ambiguïté : la banque continue d'utiliser Claude Code et Codex, mais comme des exceptions. GLM ne lit que du texte. Les requêtes qui contiennent des images, une maquette ou une capture d'écran, passent par un routeur local vers Gemini ou un modèle d'OpenAI, et les designers d'interface utilisent une version légère et multimodale de GLM.

Autre point pratique : les modèles hébergés exposent une API compatible avec celle d'OpenAI. Les développeurs gardent donc leur outil habituel, OpenCode ou Codex par exemple, et seul le modèle change en coulisse. C'est ce qui a rendu la bascule supportable pour 2 000 personnes.

Le schéma ressemble à ce que font déjà beaucoup d'équipes techniques, en plus industrialisé. Un modèle bon marché pour le volume quotidien : tests, corrections simples, documentation, tickets. Un modèle de pointe pour l'architecture, les bugs tordus et les refontes risquées. Savoir aiguiller chaque tâche vers le bon modèle devient une compétence à part entière.

Revolut n'est pas un cas isolé

Le jour même où The Register publiait l'article sur Revolut, le même titre rendait compte d'une note du cabinet Gartner signée Mark Petty et Raymond Paquet. Leur thèse : dans un agent IA d'entreprise, la grande majorité des étapes sont routinières (classer, extraire, appeler un outil, vérifier), et un modèle ouvert les traite pour une fraction du prix d'un modèle fermé. Ils avancent un coût quatre fois inférieur au modèle fermé le moins cher à performance égale, jusqu'à vingt fois inférieur à un modèle de pointe, tout en reconnaissant que les modèles ouverts, plus bavards et plus enclins à recommencer, ramènent l'écart réel autour de cinq ou six. Leur prévision : d'ici 2030, 90 % des étapes des agents opérationnels en entreprise tourneront sur des modèles ouverts.

C'est une projection d'analystes, pas une mesure. Mais elle pointe dans la même direction que Revolut : utiliser un modèle de pointe partout et tout le temps devient un luxe, et la valeur se déplace vers la couche qui décide quel modèle traite quelle tâche. On avait déjà vu, avec Klarna et son service client, à quel point les annonces spectaculaires d'une fintech méritent d'être relues quelques mois plus tard.

Et pour une PME ou une ETI française ?

Soyons francs : une PME de dix développeurs ne va pas installer sept serveurs DGX. Le calcul de Revolut repose sur un volume énorme et continu de requêtes, qui occupe les GPU du matin au soir. Une petite équipe ne les remplirait qu'une fraction du temps, et son coût par token s'envolerait. À cette taille, des abonnements à Claude Code ou Codex reviennent bien moins cher qu'un seul ingénieur infrastructure.

Ce qui se transpose, en revanche :

• mesurer ce que vos limites d'usage coûtent en productivité, et pas seulement ce qu'elles économisent sur la facture ;
• suivre le délai de livraison et pas uniquement le temps de codage, puisque c'est là que Revolut a vu le plus grand effet ;
• séparer les usages de volume des usages critiques, pour ne pas payer un modèle de pointe à reformater un fichier ;
• pour les données vraiment sensibles, envisager un modèle ouvert hébergé en France ou en Europe sur un périmètre limité, qu'il vienne de Chine, des États-Unis ou d'Europe comme ceux de Mistral ;
• garder un bac à sable, des règles d'approbation et une relecture humaine, quel que soit le modèle.

Le bon arbitrage dépend du volume, du type de tâches et de la sensibilité des données. C'est typiquement ce qu'on tranche pendant un audit IA : on regarde les usages réels, on chiffre les options, et on évite d'acheter des GPU pour un besoin qui tient dans un abonnement.

Ce que j'en retiens

Revolut n'a pas prouvé qu'un modèle chinois vaut Claude. Elle a montré qu'à très grande échelle, un modèle ouvert correct, bien réglé et sans plafond d'usage peut battre économiquement un modèle de pointe rationné. Les 90 % sont réels sur la ligne « modèles », beaucoup moins sur le coût total. Et l'essentiel du gain de productivité tient à une décision presque managériale : laisser les équipes se servir de l'outil sans surveiller le compteur.

Si vous dirigez une équipe technique, la question n'est probablement pas de quitter Claude Code. Elle est de savoir si vos développeurs s'en servent vraiment, et pour quoi faire.

Sources

• David Abitbol (Revolut), « Shipping like a startup, regulated like a bank », AI Engineer NYC, 13 octobre 2026 : vidéo et transcription
• The Register, Tobias Mann, 3 novembre 2026
• StartupHub.ai, 29 octobre 2026
• TechRadar, novembre 2026
• The Register, note Gartner sur les modèles ouverts, 3 novembre 2026