Dix millions d'actifs industriels, sur un seul cloud

Kongsberg Digital construit le logiciel cloud-native qui reflète l’industrie lourde — plateformes pétrolières, raffineries, navires, actifs énergétiques — en jumeau numérique. La plateforme que j’ai rejointe en janvier 2023 tournait déjà. Le travail consistait à la faire passer à l’échelle, tenir sous charge, et rester peu coûteuse à opérer pendant que les clients y branchaient leur prochain million d’actifs.

Quand j’en suis parti en juillet 2025, la plateforme servait plus de dix millions d’actifs industriels en temps réel. Trois choses ont permis ça.

Une architecture qui tient le prochain zéro

La télémétrie de jumeau numérique a une forme particulière : écritures fines à haute fréquence, lectures larges au moment de la requête, planchers de latence durs. Le substrat dont j’ai hérité tenait pour le premier million d’actifs. Le zéro suivant était un autre problème.

J’ai architecturé les services cloud-native sur Microsoft Azure : topologie de microservices orchestrée par Kubernetes, cache Redis sur la couche requête pour les chemins chauds. Express.js et TypeScript sur la couche API ; Angular pour les surfaces opérateurs ; Python et C++ sur le chemin d’ingestion. Terraform tenait l’ensemble sous forme de code. La discipline était de garder les coutures honnêtes — chaque service avait un contrat, chaque contrat était testé, et chaque changement cassant atterrissait derrière un flag.

J’ai porté le déploiement de bout en bout sur trois programmes d’entreprise dans les verticaux IoT industriel et énergie. Chaque jalon tenu, chaque programme franchi du cadrage à la production.

Refonte du substrat temps-série

Le changement le plus conséquent que j’ai fait, c’est la refonte du temps-série. La couche de stockage précédente fonctionnait, mais c’était le chemin chaud à la fois en coût et en latence, et la facture grimpait moins bien que le nombre d’actifs.

J’ai fait migrer vers un substrat hybride TimescaleDB + InfluxDB — TimescaleDB pour l’historique relationnel et requêtable qui intéresse les clients ; InfluxDB pour le flux temps réel à forte cardinalité. La séparation a permis d’ajuster chaque côté à ce qu’il faisait le mieux, de retirer une couche d’infrastructure qui faisait les deux jobs mal, et de consolider la compaction.

Coûts cloud réduits de vingt pour cent. Performance de requête en hausse de trente-cinq. Les deux chiffres ont tenu sous charge.

Les rituels d’équipe qui se sont remboursés tout seuls

Le travail d’architecture comptait. Les rituels autour comptaient davantage.

J’ai durci le CI/CD à l’échelle de l’équipe — chaque changement passait par le même pipeline, chaque pipeline lançait les mêmes tests, et les tests étaient assez rapides pour que les ingénieurs les attendent vraiment. On a resserré les revues de code jusqu’à ce que chaque PR ait un propriétaire clair, un relecteur clair, et une définition de fait claire. Le travail DevOps qui était du pompage d’incendie est remonté en runbooks et tableaux de bord.

Vélocité d’équipe en hausse de vingt-cinq pour cent — mesurée en story points livrés par sprint sur les huit mois qui ont suivi. Les incidents de déploiement sont allés dans l’autre sens. Les heures qu’on perdait en rollbacks sont allées en livraison.

Les deux ans et demi à Kongsberg ont été le travail d’ingénierie le plus profond que j’ai fait. C’est aussi là que j’ai appris que les meilleurs ingénieurs avec qui j’avais travaillé étaient aussi les opérateurs les plus disciplinés — pas parce que l’opérationnel est glamour, mais parce que livrer fiablement à l’échelle est un problème d’ingénierie, pas un problème de gestion de projet.