Smalltalk en 2026 : moderniser un système critique sans le réécrire

Dans certaines banques et compagnies d'assurance, le moteur de calcul du risque, le référentiel des contrats ou le système de tarification tourne encore en Smalltalk. Ces systèmes ont trente ans, ils fonctionnent, et personne ne veut être celui qui les casse. La question n'est pas de savoir s'il faut les moderniser, mais comment le faire sans arrêter l'activité.

Un langage de 1972 qui porte encore des systèmes critiques

Smalltalk est né au Xerox PARC au début des années 1970, sous l'impulsion d'Alan Kay, Dan Ingalls et Adele Goldberg. La version Smalltalk-80, diffusée à partir de 1981, est devenue la base de toutes les implémentations commerciales qui ont suivi, et le standard ANSI ratifié en 1998 reste la référence du langage. C'est un environnement objet pur, réflexif, où le code se modifie pendant que le système tourne. Cette souplesse explique pourquoi les équipes financières des années 1990 l'ont choisi pour des applications complexes qui devaient évoluer vite.

L'exemple le plus connu reste Kapital, le système de gestion du risque et de valorisation de JPMorgan, développé au début des années 1990 avec VisualWorks et la base d'objets GemStone/S. Selon une étude de cas publiée en 2007 sur le blog GemStone Soup, la banque estimait alors qu'un autre langage aurait exigé au moins trois fois plus de ressources. Ce n'est pas un vestige : au printemps 2025, JPMorganChase publiait encore une offre de « Software Engineer III, Smalltalk Developer » pour son équipe Rates Risk and PnL à Bengaluru, avec du code de production en Smalltalk et une préférence pour Python en compétence secondaire. Le message est clair : le système vit, on le fait évoluer, et on cherche des gens capables de le faire dialoguer avec le reste du monde.

Le même schéma se retrouve chez OOCL, le transporteur de conteneurs de Hong Kong, dont le système IRIS-2 en GemStone/S et Cincom Smalltalk gère environ 1,5 milliard d'objets pour 5 800 employés dans 150 bureaux, ou dans des assureurs européens dont le cœur de contrat repose sur Cincom ObjectStudio ou VisualWorks, aujourd'hui en version 9.5.

Le vrai coût n'est pas la licence, c'est l'immobilisme

Le débat sur le legacy est souvent mal posé. Le coût d'un système ancien n'est pas son maintien courant, c'est tout ce qu'il empêche de faire. Une étude PwC et Ignatica sur les systèmes legacy de l'assurance, reprise par Insurance Journal en avril 2024, rappelle que le maintien des systèmes existants absorbe en moyenne 70 % des budgets IT, et que développer et tester un nouveau produit d'assurance sur ces systèmes prend six à neuf mois pour un coût de 400 000 à 900 000 dollars, d'après la Society of Actuaries.

Le deuxième coût est humain. Les entreprises ont perdu en moyenne 23 % de leur main-d'œuvre legacy sur cinq ans et 63 % de ces postes restent non pourvus, selon une enquête Forrester Consulting de 2018 citée dans la même étude. Les développeurs Smalltalk existent, mais ils sont rares, chers et souvent proches de la retraite. Chaque départ emporte une partie de la connaissance métier que le code encode sans la documenter.

Le troisième coût est le risque de rupture. Quand un système ne peut plus être testé ni déployé en confiance, chaque modification devient un pari. La panne RBS de 2012, qui a gelé 12 millions de comptes et coûté 175 millions de livres, a été attribuée par la direction à des systèmes vieux de plusieurs décennies mal entretenus. Aucune banque ne veut être la suivante.

Trois options, et une seule est vraiment mauvaise

Face à un cœur Smalltalk, nous voyons trois chemins.

• Garder et encapsuler. Le système reste le maître des données et des règles, mais on l'expose derrière des API propres (REST, événements, GraphQL). Les nouveaux canaux, les outils d'analyse et les agents IA consomment ces API sans toucher au cœur. ObjectStudio embarque d'ailleurs des connecteurs CICS, MQ Series ou APPC précisément pour ce type d'intégration. C'est l'option la moins risquée et la plus rapide à livrer.

• Extraire progressivement. On sort du cœur, domaine par domaine, les fonctions qui bougent le plus (tarification, reporting, portail client) vers des services modernes, en Java ou dans une plateforme low-code, pendant que le legacy continue de porter le portefeuille en vigueur. PwC décrit cette approche produit par produit : les contrats migrent au fil des opérations, et les enregistrements legacy deviennent dormants. C'est le motif « strangler fig », et c'est celui que nous recommandons dès que la roadmap métier dépasse deux ans.

• Réécrire d'un bloc. Tout remplacer en une seule bascule. Cette option séduit sur le papier et échoue dans la pratique, parce que personne ne connaît l'intégralité des règles métier enfouies dans trente ans de code. Le risque de régression est maximal, le retour sur investissement arrive en dernier, et l'organisation s'épuise avant la mise en production.

Un chiffre résume le sujet : selon une enquête Saritasa de 2025 auprès de plus de 500 professionnels IT, 62 % des organisations dépendent encore de logiciels legacy et 50 % reportent la modernisation parce que « le système actuel fonctionne encore ». Ce raisonnement est compréhensible, mais il ne fait que déplacer le risque vers le moment où il n'y aura plus personne pour intervenir.

Ce que l'IA change dans l'équation

Deux choses ont changé depuis deux ans. D'abord, les modèles de langage lisent très bien le Smalltalk. Ils ne remplacent pas un développeur senior, mais ils permettent de documenter des classes jamais commentées, de générer des tests de caractérisation qui figent le comportement actuel avant toute modification, et de proposer des traductions de règles métier vers Java ou vers une spécification lisible par un analyste. Sur une mission récente, cette étape de documentation assistée a divisé par trois le temps de compréhension d'un module de tarification.

Ensuite, les agents IA ont besoin d'API stables pour agir. Un cœur Smalltalk encapsulé derrière des services bien définis devient une source de vérité exploitable par un assistant de souscription ou un agent de gestion de sinistres. Sans cette couche, l'IA reste cantonnée à des expérimentations en périphérie.

Ce que nous en retenons

Un système Smalltalk en production n'est pas un problème à faire disparaître, c'est un actif à protéger et à ouvrir. La bonne séquence est presque toujours la même : figer le comportement par des tests, exposer des API, extraire ce qui bouge, et ne jamais planifier une bascule unique. Chez 39 Advisory, nous accompagnons des institutions financières sur exactement ce type de trajectoire, avec des équipes qui connaissent à la fois le legacy et les plateformes modernes.

Si votre cœur de système freine votre roadmap, parlons-en : un diagnostic de deux semaines suffit généralement à choisir entre encapsuler et extraire.