Comment Revolut a divisé par dix sa facture IA en moins d'un an
La néobanque britannique a migré ses 2 000 ingénieurs de Claude Code et OpenAI Codex vers des modèles open-weight auto-hébergés. Résultat : 90 % de réduction des coûts d'inférence, et un temps de réponse réduit de dix secondes à 1,6 seconde. Un cas d'école pour les startups qui cherchent à maîtriser leur budget IA.
Fin 2025, Revolut payait ses outils de codage assisté par IA comme la plupart des grandes entreprises tech : à la consommation, via les APIs commerciales d'Anthropic et d'OpenAI. Moins d'un an plus tard, la néobanque affiche une facture divisée par dix. La méthode, présentée par David Abitbol lors de la conférence AI Engineer début novembre 2026, ne relève pas d'une négociation de contrat mais d'un changement d'architecture complet.
GLM au lieu de Claude : le pari du modèle ouvert
Le modèle de remplacement est GLM, un modèle de poids ouverts développé par des équipes de l'université Tsinghua. Revolut l'a déployé en self-hosted sur sa propre infrastructure et en a fait le modèle par défaut pour l'ensemble de ses quelque 2 000 ingénieurs. Le coût d'inférence résultant s'établit à 0,30 dollar par million de tokens en entrée et en sortie combinés, contre environ 3 dollars facturés par les APIs Claude Code ou Codex. La réduction atteint 90 %, soit un facteur dix.
Mais l'argument économique n'est pas le seul. La latence, critère déterminant pour l'adoption quotidienne par les développeurs, a elle aussi été transformée. Le temps de réponse médian est passé de plus de dix secondes à 1,6 seconde, soit une amélioration de 88 %. Ce gain a été obtenu pendant une période où la demande interne avait elle-même progressé de 76 %, selon les chiffres cités par Abitbol. En d'autres termes, plus d'utilisation, moins de coût, moins d'attente.
Fine-tuning et optimisation d'inférence, pas de matériel supplémentaire
La démarche de Revolut repose sur deux leviers techniques. D'une part, un fine-tuning interne de GLM sur les pratiques de codage de l'entreprise, pour aligner le modèle sur les conventions du codebase maison plutôt que sur un corpus généraliste. D'autre part, une optimisation des paramètres d'inférence : parallélisme, batching, quantification. Ces réglages permettent de tirer davantage de chaque unité de calcul, sans augmenter le parc de serveurs.
Ce type d'arbitrage, entre API commerciale clé en main et infrastructure maîtrisée, s'applique à n'importe quelle entreprise dont le volume d'utilisation est suffisamment élevé pour amortir l'investissement opérationnel initial. Pour les startups en phase de croissance, le seuil de rentabilité varie selon les charges : héberger un modèle ouvert exige une équipe MLOps, une gestion des mises à jour et des contraintes de sécurité que les APIs commerciales prennent en charge automatiquement. Revolut dispose de l'échelle et des ressources pour absorber cette complexité.
Un signal pour l'industrie, pas une prescription universelle
L'exemple de Revolut intervient dans un contexte de tension croissante autour des coûts IA dans les entreprises. Comme l'analyse le dossier sur les coûts des agents IA en entreprise, la facture d'inférence est devenue l'une des principales barrières à l'adoption à grande échelle. La réponse de Revolut est l'une des plus documentées à ce jour dans le secteur financier.
Elle arrive quelques jours après qu'une décision inverse a défrayé la chronique : Goldman Sachs a restreint l'accès à Claude Code et Copilot à ses seuls ingénieurs, invoquant des enjeux de risque et de productivité. Les deux événements illustrent la même pression : les modèles commerciaux d'accès à l'IA de code sont en train d'être réévalués par les grandes organisations. Certaines restreignent l'usage, d'autres optimisent l'infrastructure. Revolut a choisi la seconde voie, et les chiffres qu'elle publie vont alimenter ce débat pendant longtemps.
Questions fréquentes
Quel modèle IA Revolut utilise-t-il à la place de Claude Code ?
GLM, un modèle de poids ouverts développé par des équipes de l'université Tsinghua, déployé en self-hosted sur l'infrastructure de Revolut.
Cette approche est-elle transposable à n'importe quelle startup ?
Elle est rentable à partir d'un certain volume d'utilisation. Héberger un modèle open-weight exige une équipe MLOps et des ressources d'infrastructure que les APIs commerciales n'imposent pas. Les petites structures bénéficient souvent davantage des APIs clé en main.
