Un tweet humoristique de Kristo Käärmann, cofondateur et PDG de Wise, a mis en lumière l’une des réalités les plus instructives de l’ingénierie logicielle à grande échelle : en 2010, lors de l’écriture des premières lignes de code de la fintech, un simple choix de type de donnée — int plutôt que long — est aujourd’hui sur le point d’atteindre sa limite physique. Après 16 ans et 145,2 milliards de livres sterling de volumes transfrontaliers traités, Wise approche du plafond de 2 147 483 647 valeurs positives d’un entier signé de 32 bits. Ce n’est pas une catastrophe opérationnelle. C’est, paradoxalement, la preuve d’une réussite exceptionnelle — et une leçon d’architecture que tout ingénieur devrait connaître.

La dette technique de Wise n’est pas née d’un manque de rigueur. Elle est née d’une décision raisonnable, prise à un moment où personne ne pouvait anticiper l’échelle que cette startup atteindrait. C’est précisément ce qui rend cette situation si emblématique du cycle de vie des systèmes logiciels modernes.

Contexte et enjeux : quand la croissance dépasse les hypothèses initiales

Wise — anciennement TransferWise — a été fondée en 2011 avec une promesse simple : proposer des transferts internationaux sans frais cachés. Ce positionnement a séduit des millions d’utilisateurs dans le monde entier. En 2025, la plateforme comptait 15,6 millions de clients actifs et traitait un volume transfrontalier annuel de 145,2 milliards de livres sterling. Ces chiffres illustrent une croissance que peu de fintechs ont réussi à atteindre.

Mais cette croissance exponentielle a un coût architectural. Chaque transfert génère un identifiant unique dans la base de données. Lorsque ces identifiants sont codés sur un entier signé de 32 bits, le stock de valeurs disponibles est limité à un peu plus de deux milliards. Pour une plateforme qui traite des dizaines de millions d’opérations par an, ce plafond devient inévitablement une contrainte. Le secteur financier numérique vit cette tension en permanence, comme l’ont montré d’autres acteurs lors de leur transformation technologique dans la banque et les assurances.

Le cas de Wise s’inscrit dans un contexte plus large : la gestion de la dette technique dans les entreprises technologiques à croissance rapide. Des outils comme MongoDB AMP, lancé en 2025, cherchent précisément à outiller les équipes pour identifier et résoudre ce type de problèmes structurels avant qu’ils ne deviennent critiques.

Les faits : int vs long, 17 dollars d’économies et 16 ans plus tard

Sur le réseau social X, Käärmann a posté un message qui a rapidement circulé dans les communautés d’ingénieurs :

« Now that we’re soon running out of 32-bit namespace for transfer IDs at Wise, the engineers are annoyed with me choosing int over long when I wrote the first lines of code in 2010. But why don’t they appreciate the $17 of savings in storage cost over years!? »

— Kristo Käärmann, PDG de Wise, 15 avril 2026

Derrière l’humour, le constat est technique et précis. Un entier signé de 32 bits (int en Java ou INTEGER en SQL) peut stocker des valeurs de -2 147 483 648 à 2 147 483 647. Pour des identifiants séquentiels positifs, cela représente environ 2,1 milliards de valeurs. Un entier signé de 64 bits (long ou BIGINT) monte à 9 223 372 036 854 775 807 — soit plus de neuf quintillions de valeurs. La différence en stockage ? Quatre octets contre huit octets par identifiant. Sur des millions de lignes, cela représentait à l’époque quelques dizaines de dollars de stockage supplémentaire. En 2010, avec des bases de données beaucoup moins volumineuses, ce choix était parfaitement rationnel.

La blague des « 17 dollars d’économies » résume parfaitement l’ironie de la situation : l’optimisation de coût réalisée en 2010 génère aujourd’hui un chantier de migration dont le coût réel — en temps ingénieur, en risque opérationnel et en coordination — sera sans commune mesure avec ces quelques dollars économisés.

Analyse : la dette technique structurante, un phénomène inévitable à grande échelle

Ce qui distingue le cas Wise d’une simple anecdote d’ingénierie, c’est sa portée systémique. Modifier le type d’un identifiant dans une base de données de production ne se limite pas à une opération ALTER TABLE. Dans un système financier de l’envergure de Wise, cela implique :

• Toutes les tables liées : chaque référence à l’identifiant de transfert dans d’autres tables doit être mise à jour simultanément pour éviter les incohérences.
• Les indices et contraintes : reconstruire les index sur des milliards de lignes est une opération longue et risquée.
• Les API internes et externes : tout système qui consomme ou produit cet identifiant doit être adapté. Les intégrations partenaires sont particulièrement délicates.
• Les processus de réconciliation : dans un système financier, chaque transaction doit être traçable. Une migration implique de garantir la continuité des audits et des rapports réglementaires.
• Les outils analytiques : data warehouses, pipelines ETL, tableaux de bord — tout doit être synchronisé.
• Les systèmes hérités : des décennies d’intégrations accumulées font de ce type de migration un exercice de coordination multi-équipes.

C’est pourquoi des entreprises comme NTT DATA et AWS ont développé des offres spécifiques pour la modernisation des systèmes hérités en entreprise, un marché qui continue de croître à mesure que les fintechs et les entreprises technologiques arrivent à maturité.

La dette technique de Wise a également une dimension temporelle rarement évoquée : elle est invisible pendant des années. Une ligne de code écrite en 2010 reste en production, enfouie sous des couches de fonctionnalités, de versions, de migrations partielles et de refontes d’interface, jusqu’au jour où elle devient un véritable goulot d’étranglement. La base de données ne oublie jamais.

Perspectives : quelles solutions pour dépasser la limite des 32 bits ?

Wise n’a pas encore communiqué publiquement le plan technique détaillé pour résoudre cette contrainte. Mais l’industrie connaît bien les approches disponibles, chacune avec ses avantages et ses risques :

• Migration vers BIGINT (64 bits) : l’approche la plus directe. Elle nécessite une migration en plusieurs phases — créer une nouvelle colonne, copier les données, basculer les références, supprimer l’ancienne colonne — tout en maintenant le service en production. Sur un système transactionnel à fort volume, chaque phase doit être planifiée avec précision.
• Identifiants UUID : des identifiants de 128 bits au format universellement unique. Ils éliminent le problème de capacité mais augmentent la taille de stockage et peuvent dégrader les performances des index séquentiels.
• Systèmes distribués de génération d’IDs : des algorithmes comme Snowflake (Twitter/X) ou ULID génèrent des identifiants uniques sur 64 bits avec horodatage intégré, adaptés aux architectures distribuées.
• Double système temporaire : maintenir l’ancien espace de noms pour les transferts historiques et introduire un nouveau format pour les nouveaux transferts, avec une couche d’abstraction applicative.

Quelle que soit l’option choisie, la migration devra être menée sans interruption de service dans un contexte réglementaire strict. Wise opère dans de nombreuses juridictions soumises aux régulateurs financiers européens, britanniques et américains. Chaque modification des systèmes de traitement des paiements doit être documentée, testée et validée avant déploiement en production.

Une leçon d’architecture valable pour tout système à fort potentiel de croissance

Il serait réducteur de conclure que toute startup devrait dès le premier jour concevoir ses systèmes pour supporter des milliards d’opérations. La sur-ingénierie précoce est elle-même un anti-pattern coûteux : elle ralentit le time-to-market, complexifie la codebase et consomme des ressources qui seraient mieux employées à valider le modèle d’affaires.

La véritable leçon est plus nuancée : certaines décisions structurantes méritent une réflexion asymétrique. Choisir BIGINT plutôt que INTEGER pour une clé primaire en 2010 aurait coûté quatre octets supplémentaires par ligne. Ce coût marginal, négligeable même à l’époque, aurait évité une migration complexe 16 ans plus tard. C’est le principe du « cheap insurance » en architecture logicielle : quelques décisions de conception à faible coût qui protègent contre des risques à fort impact.

Les points d’attention prioritaires pour les équipes qui construisent aujourd’hui des systèmes susceptibles de croître :

• Utiliser des types larges par défaut pour les identifiants et les compteurs (BIGINT, pas INTEGER)
• Préférer les formats de date avec timezone dès le début (éviter les bugs de fuseau horaire)
• Concevoir les schémas de partitionnement avec la croissance en tête
• Documenter les hypothèses implicites de capacité pour chaque composant critique
• Prévoir des alertes sur les seuils : un identifiant à 80% de sa capacité devrait déclencher une alerte automatique

Questions fréquentes sur la dette technique de Wise

Qu’est-ce qu’un entier signé de 32 bits et pourquoi est-il limité pour Wise ?

Un entier signé de 32 bits peut stocker des valeurs jusqu’à 2 147 483 647. Pour une plateforme comme Wise qui génère des millions d’identifiants de transfert chaque année, ce plafond est atteint après 16 ans d’exploitation intensive. La migration vers un entier 64 bits permettrait de stocker jusqu’à 9,2 quintillions de valeurs, soit une capacité pratiquement illimitée pour les décennies à venir.

Pourquoi Wise n’a-t-elle pas utilisé un entier de 64 bits dès le départ ?

En 2010, au lancement de Wise, personne ne pouvait anticiper que la plateforme atteindrait 15,6 millions de clients actifs et 145 milliards de livres sterling de volume annuel. L’utilisation d’un entier 32 bits était une décision rationnelle à l’époque : elle économisait quatre octets par ligne, simplifiant légèrement le stockage. Le PDG Kristo Käärmann a lui-même reconnu avec humour qu’il s’agissait d’un choix à court terme.

Quelles sont les solutions techniques pour migrer vers des identifiants 64 bits en production ?

Plusieurs approches existent : la migration vers BIGINT en plusieurs phases (ajout d’une colonne parallèle, copie des données, bascule des références), l’adoption d’UUID 128 bits ou de systèmes distribués comme Snowflake ID ou ULID. Chaque option présente des compromis en termes de performance, de compatibilité et de complexité de migration. Dans un système financier réglementé comme Wise, la continuité de service et l’intégrité des audits sont des contraintes non négociables.

Ce problème est-il spécifique à Wise ou affecte-t-il d’autres entreprises tech ?

Ce type de dette technique structurante est commun à de nombreuses entreprises technologiques ayant connu une forte croissance. Twitter a rencontré un problème similaire avec ses identifiants de tweets, ce qui l’a conduit à développer le système Snowflake. Instagram, MySQL par défaut et de nombreux systèmes d’entreprise ont dû gérer la transition de INTEGER vers BIGINT à mesure de leur croissance. C’est un rite de passage pour les plateformes qui atteignent une véritable échelle.

Wise a-t-elle subi des interruptions de service à cause de ce problème ?

Aucun incident opérationnel majeur n’a été signalé en lien avec cette limite. Wise a révélé le problème de façon proactive, avant que le plafond ne soit atteint, ce qui témoigne d’une surveillance active de ses systèmes. La communication transparente du PDG illustre une maturité d’ingénierie : identifier et communiquer sur les limites structurelles avant qu’elles ne deviennent des crises.

Combien coûte réellement une migration d’INTEGER vers BIGINT sur un système financier de l’envergure de Wise ?

Le coût direct — temps ingénieur, infrastructure de migration, tests — se chiffre en centaines de milliers à plusieurs millions d’euros pour un système de cette taille. Le coût indirect inclut les risques d’interruption, la coordination multi-équipes, les mises à jour des intégrations partenaires et les validations réglementaires. C’est la définition même de la dette technique : une décision à coût quasi nul en 2010 devient un investissement majeur 16 ans plus tard.