Parfois, la dette technique ne résulte pas d’un bricolage maladroit, mais d’une décision raisonnable prise trop tôt. C’est cette réalité que Wise a récemment remise en lumière, lorsque son cofondateur et PDG, Kristo Käärmann, a reconnu sur X que l’entreprise approchait de la limite de l’espace de noms de 32 bits qu’elle avait choisi pour ses identifiants de transferts lors de ses premières lignes de code en 2010.

Cette anecdote possède une touche d’humour intérieur parmi les ingénieurs et illustre une leçon classique en architecture logicielle. Un entier signé de 32 bits peut représenter jusqu’à 2 147 483 647 valeurs positives. Un entier signé de 64 bits étend cette capacité à 9 223 372 036 854 775 807. En théorie, la différence est énorme. Dans la pratique, il était difficile, il y a 16 ans, d’imaginer qu’une fintech pourrait un jour se retrouver si proche de ce plafond.

Quand la croissance rapide transforme une mauvaise décision en fait notable

Käärmann a évoqué le sujet avec une pointe d’ironie. Il a admis qu’il s’agissait d’un choix à court terme, celui d’utiliser int plutôt que long, et a plaisanté en suggérant que ses ingénieurs n’évaluaient peut-être pas à sa juste valeur l’économie de 17 dollars réalisée en stockage sur plusieurs années. Au-delà de cette plaisanterie, son commentaire illustre parfaitement le fonctionnement de la dette technique : une petite décision, à l’origine quasi invisible lors du lancement d’un projet, peut réapparaître des années plus tard sous la forme d’un problème à l’échelle.

Ce qui rend cette situation encore plus intéressante, c’est que Wise n’est pas une start-up qui a mal conçu sa base de données. Au contraire : elle en est arrivée à ce point parce qu’elle a connu une croissance que la majorité des entreprises ne rencontrent jamais. Lors de son exercice fiscal 2025, l’entreprise comptait 15,6 millions de clients actifs et traitait un volume transfrontalier de 145,2 milliards de livres sterling. En somme, le problème des identifiants ne paraît plus comme une erreur dramatique, mais comme la conséquence logique d’une croissance exponentielle dépassant de loin les prévisions initiales.

La base de données ne oublie jamais

Dans le développement logiciel, il y a des décisions qui paraissent triviales lorsque le produit est encore à ses débuts : le type de donnée d’une colonne, le format d’une clé primaire, la longueur d’un champ, la méthode pour modéliser un état, ou la structure initiale d’une table. À un stade très précoce, tout cela paraît facilement réversible. Le problème surgit lorsque ce design doit supporter des centaines de millions, voire des milliards, de données.

Le choix d’un entier de 32 bits pour des identifiants séquentiels fut longtemps une décision tout à fait courante. En réalité, pendant de nombreuses années, cela suffisait pour d’innombrables applications d’entreprise. Mais ce qui change dans des sociétés comme Wise, c’est l’échelle. Quand une plateforme génère depuis des années des identifiants liés à des opérations réelles, modifier cette structure ne se limite plus à une opération simple de changement de schéma : cela impacte toutes les tables, les indices, les API internes, les processus de conciliation, les outils d’analyse, les systèmes hérités, et souvent aussi les intégrations externes.

C’est pourquoi ces incidents ont une dimension pédagogique. La base de données, en réalité, ne oublie jamais. Une ligne programmée au démarrage d’un projet peut rester en production des décennies, dissimulée sous des couches de fonctionnalités, de croissance internationale et d’évolution du produit, jusqu’à ce qu’elle devienne un véritable goulot d’étranglement.

Ce n’est pas le premier signal d’alerte dans l’histoire du logiciel

Ce cas évoque immanquablement d’autres erreurs de perspective technologique, comme la référence à l’année stockée sur deux chiffres dans les anciens systèmes des années 80 et 90, ou encore les choix de capacité ou de format qui, à l’époque, apparaissaient efficaces mais se révèlent aujourd’hui limités.

La différence ici, c’est qu’aucune crise visible ou interruption de service n’a été constatée par le client. Aucun incident opérationnel grave n’a été reporté. Ce qui a émergé, c’est plutôt une marque de maturité : Wise a atteint un stade où ses décisions d’ingénierie initiales commencent à avoir un impact à grande échelle. Et, dans une certaine mesure, c’est une très bonne nouvelle pour une entreprise de logiciels.

Ce scénario révèle aussi une facette essentielle de la construction des produits technologiques : la perfection architecturale est rarement atteinte dès le départ. Les équipes fondatrices font des compromis. Elles priorisent la mise sur le marché, la validation d’un modèle, la livraison d’un produit à des clients, la résolution des problèmes les plus urgents avec les ressources disponibles. Mais, si l’entreprise survit et se développe, tôt ou tard, ces choix se matérialisent en coûts et en limites à dépasser.

Leçon pour les nouvelles startups

Le conseil ne devrait pas être que toute startup doit dès le début concevoir ses systèmes pour supporter des milliards d’opérations. Ce serait peu réaliste, voire contre-productif. Un excès de surdossier dès le départ coûte en temps, en complexité et en argent.

La véritable leçon consiste plutôt à garder une certaine longueur de vue : certaines décisions structurantes méritent d’être réfléchies plus longtemps. Par exemple, choisir un identifiant de 64 bits dans une base de données moderne ne coûtera probablement pas cher à une startup, mais pourra éviter une migration complexe plusieurs années plus tard. De même, il convient de faire attention aux schémas de partitionnement, aux stratégies de versionnage ou aux modèles de clés.

Wise n’a pas encore communiqué en détail sur la solution qu’elle adoptera pour dépasser cette limite, mais l’industrie connaît bien les routes généralement suivies : étendre les types (adopter un bigint), migrer vers de nouveaux types, introduire de nouvelles séquences ou redéfinir la méthode de génération des identifiants sans perturber la compatibilité. Chacune de ces options reste délicate quand le système est en production et qu’il traite des opérations financières en direct.

Une dette technique presque enviable

Il existe une dernière lecture, sans doute la plus saine : dans un secteur où la « dette technique » évoque souvent fragilité, erreurs, ou décisions précipitées, le cas de Wise témoigne d’une forme presque enviable de dette technique : celle causée par une croissance phénoménale.

Il n’est pas anodin qu’un fondateur puisse regarder une décision prise en 2010 et reconnaître, avec humour, qu’elle a été myope. Et moins encore quand cette décision ne devient un problème que parce que l’entreprise a atteint une échelle gigantesque. Beaucoup de technologies naissent en pensant au trimestre suivant. Très peu vivent assez longtemps pour que leurs erreurs initiales soient encore visibles après 16 années.

Questions fréquentes

Combien de valeurs peut contenir un entier signé de 32 bits pour les identifiants ?
Il permet jusqu’à 2 147 483 647 valeurs positives, correspondant à la limite classique lorsqu’on utilise un entier signé de 32 bits.

Pourquoi Wise n’a-t-elle pas utilisé un entier de 64 bits dès le départ ?
Kristo Käärmann a lui-même reconnu qu’il s’agissait d’une décision à court terme, prise en 2010 lors des premières lignes de code.

Le fait que Wise touche la limite de ses identifiants est-il grave ?
Ce n’est pas une catastrophe, mais un enjeu technique important. Cela reflète surtout l’échelle atteinte par l’entreprise, qui doit aujourd’hui corriger une décision ancienne et structurante.

Quelles solutions sont généralement adoptées aujourd’hui pour éviter ce problème ?
On privilégie souvent l’utilisation d’entiers de 64 bits (bigint) pour des identifiants à forte croissance, ou la mise en œuvre de systèmes alternatifs de génération d’identifiants selon le contexte.