3 min de lecture

Revolut a fait passer ses développeurs de Claude à GLM

RevolutGLMopen-weight модели

Revolut aurait fait de GLM, un modèle chinois open-weight, l'assistant de code par défaut d'environ 2 000 ingénieurs et réduit ses dépenses IA d'environ 90 %. Ce cas compte car les tâches de code routinières peuvent migrer vers une infrastructure interne moins chère, tout en réservant les modèles frontier aux exceptions complexes.

Ce que Revolut a modifié dans sa stack IA

Pour moi, le fait majeur n'est pas l'origine chinoise du modèle, mais l'ampleur du basculement : Revolut aurait fait de GLM open-weight le modèle de code standard pour environ 2 000 ingénieurs. Dealroom évoque le remplacement de Claude Code, mais d'autres publications précisent que les outils coûteux restent disponibles pour les tâches complexes et multimodales.

Le checkpoint exact prête à confusion. Certains articles parlent de GLM 5.3 de Z.ai, d'autres de GLM-4.5 ; il est donc impossible d'attribuer le résultat avec certitude à une version précise. Ce n'est pas un détail pour une analyse d'ingénierie : les versions impliquent des niveaux de qualité, des besoins d'infrastructure et une reproductibilité différents.

L'économie annoncée est agressive : environ 56 Nvidia B200 pour l'hébergement interne, près de 0,30 dollar par million de tokens selon un calcul mixte et une baisse estimée à 90 % des dépenses précédentes chez Anthropic et OpenAI. Mais les 0,30 dollar correspondent à une estimation interne d'infrastructure, non à un tarif API public. Les comparer directement aux prix distincts des tokens d'entrée et de sortie d'un modèle commercial serait trompeur.

Le tableau de la qualité est moins spectaculaire que celui des coûts. Dans le benchmark GDPx évoqué, GLM a obtenu 2,7 %, contre 12,0 % pour Claude Opus 5.5. Artificial Analysis Intelligence Index v5 ne confirme pas une comparaison distincte menée par Revolut : ses résultats publiés concernent d'autres conditions et d'autres modèles.

Une amélioration de 70 % du engineering lead time a également été rapportée, mais ce chiffre est moins étayé que l'estimation des coûts. Je ne l'attribuerais pas au seul changement de modèle sans données sur les types de tâches, le taux d'acceptation des suggestions et le volume des corrections ultérieures.

Les économies sont réelles, pas l'équivalence des modèles

Ce n'est pas l'histoire d'un GLM bon marché devenu soudainement plus intelligent que Claude. C'est une histoire de routage par niveau de qualité : le flux routinier va vers un modèle interne peu coûteux, tandis que les outils frontier sont réservés aux exceptions où l'erreur coûte plus cher que les tokens.

Cette approche est avantageuse pour de gros volumes de travail répétitif. Toutefois, un modèle moins performant peut transférer discrètement les coûts de la facture d'inférence vers la revue, les requêtes répétées et les corrections de code. Avant un benchmark moyen, j'examinerais le temps de réalisation, la fréquence des retours arrière et les défauts après fusion.

La réaction des développeurs peut aussi être négative, même si le modèle financier est solide. L'ingénieur perçoit immédiatement une réponse moins bonne, alors que l'entreprise voit les économies agrégées plus tard. La question centrale reste simple : où se situe le seuil à partir duquel un token bon marché produit un code trop coûteux ?

Nous avons déjà analysé comment le prix de Claude Opus, les coûts de contexte et les choix de configuration façonnent l'économie des déploiements d'IA. Cette analyse éclaire la décision de Revolut de remplacer Opus par une alternative moins coûteuse.