Revolut migre 2000 développeurs vers GLM et réduit ses dépenses d'IA de 90 %

Quand les assistants IA pour le code sont apparus, leurs factures semblaient dérisoires face aux salaires. Puis les développeurs ont commencé à faire tourner des agents pendant de longues heures chaque jour, et cette ligne négligeable est devenue un poste budgétaire à part entière. Chez Revolut, ce poste a grimpé jusqu'à 10 000 $ par mois pour certains ingénieurs. La fintech a estimé que les comptes ne tombaient plus juste.

Ce qui a été fait

Selon les informations disponibles, Revolut a fait passer environ 2000 développeurs de Claude Code et Codex au modèle ouvert GLM du chinois Z.ai. Le million de tokens revient désormais à environ 0,30 $, soit 10 fois moins cher qu'avant. Les dépenses totales de l'entreprise en IA auraient diminué de 90 %, d'après les sources.

Le détail principal n'est pas le prix, mais ce qui a été fait des limites. Auparavant, les ingénieurs gardaient un compteur en tête : fallait-il envoyer tout le dépôt au modèle, lancer une exécution supplémentaire de l'agent, demander une seconde variante de solution ? Quand les tokens coûtent cher, on se met à économiser sur les questions, ce qui nuit à la qualité du travail plus qu'on ne le croit. Chez Revolut, les limites de tokens ont été entièrement supprimées.

Ce que cela donne en chiffres

D'après les données de la publication, le temps d'écriture du code a diminué de 60 % et le temps d'exécution des tâches de 70 %. La logique est claire. Si l'agent peut lire librement le contexte, se relire et réécrire, il commet moins d'erreurs bêtes, et l'humain attend moins et intervient moins souvent.

Un exemple simple. Un ingénieur doit migrer un service vers une nouvelle version d'une bibliothèque. Avec une limite stricte, il donne deux ou trois fichiers au modèle et corrige le reste à la main. Sans limite, il confie à l'agent le module entier avec ses tests et lui demande de tout exécuter jusqu'au statut vert. Il consomme bien plus de tokens, mais à 0,30 $ le million, ce n'est plus un problème.

Où rester prudent

Premièrement : les chiffres proviennent pour l'instant d'un récit de seconde main et d'une seule publication. Il n'existe pas d'audit indépendant, et nous ne savons pas comment Revolut a calculé l'économie, combien de tâches sont restées sur des modèles fermés, ni quelle part des corrections les ingénieurs continuent de faire à la main. Le titre « remplacé complètement » peut facilement être lu plus largement que la réalité.

Deuxièmement : 90 % d'économie sur les tokens ne valent pas 90 % de gain. Si GLM résout moins bien les tâches les plus complexes, une partie du temps sera consacrée aux retouches. Les chiffres de 60 % et 70 % paraissent séduisants, mais on ignore sur quelles tâches et selon quelle comparaison ils ont été mesurés.

Troisièmement : pour une fintech, la question ne se limite pas au prix. Les poids ouverts permettent de garder le modèle dans son propre périmètre, un argument important pour les données des clients. Mais il faut alors ajouter à la facture l'infrastructure, la supervision et l'équipe qui assure le tout. Si l'on utilise le modèle via l'API de Z.ai, d'autres questions se posent en matière de juridiction et de conformité.

Que faire en pratique

Il vaut la peine de calculer combien vous dépensez réellement en IA pour le code, ramené à l'ingénieur. Si le chiffre approche des milliers de dollars par mois, la comparaison avec les modèles ouverts se justifie déjà.

Il faut ensuite un pilote honnête. Prenez de vraies tâches de votre équipe, passez-les dans un modèle fermé et un modèle ouvert, et comparez non seulement le prix, mais aussi la part de modifications acceptées. Vérifiez séparément l'effet de la suppression des limites : c'est peut-être elle, et non le modèle lui-même, qui donne l'essentiel du gain de vitesse.

Enfin, cette histoire montre que le marché des assistants de code cesse d'être l'affaire d'un seul leader. Quand un modèle ouvert couvre la majeure partie des tâches quotidiennes pour le dixième du prix, les fournisseurs fermés devront prouver leur avantage sur les cas les plus difficiles, et non sur du code moyen.