Ordésoft — moderniser un SI de 30 ans sans tout casser

Le contexte

Ordésoft édite et exploite un système d'information métier construit sur trois décennies : applications de bureau WinDev, base HFSQL, front Angular 10, et une documentation accumulée en centaines de pages de PDF. Ça marche — c'est même précisément le problème. Un SI qui tourne et dont dépendent des utilisateurs quotidiens ne se réécrit pas le temps d'un été.

La contrainte de départ était simple à énoncer et structurante pour tout le reste : rien ne doit jamais s'arrêter. Pas de fenêtre de bascule, pas de gel des évolutions, pas de « on rouvre dans trois mois ». Chaque chantier devait donc pouvoir avancer par morceaux livrables, avec l'ancien et le nouveau qui cohabitent aussi longtemps que nécessaire.

Six chantiers, un seul principe

Le principe, c'est le remplacement progressif — ce que les anglophones appellent une stratégie strangler : on enveloppe l'existant, on déplace une fonction à la fois, on éteint l'ancien quand il ne reste plus rien dedans. Concrètement :

• Un entrepôt décisionnel et son API — consolidation nocturne de bases régionales dans un entrepôt unique, calcul des indicateurs réglementaires et exposition en API REST. C'est la brique qui a permis d'arrêter de produire les chiffres à la main.
• La sortie d'Angular 10 — réécriture du front en React et Vite, écran par écran, avec un harnais de non-régression qui compare le nouveau à l'ancien. Le code legacy reste dans l'arbre comme référence de vérité tant que la reprise n'est pas terminée.
• Une passerelle REST au-dessus d'HFSQL — un worker réplique la base HFSQL vers Postgres, une API lit Postgres et ne touche jamais au driver natif. Les deux moitiés ne communiquent que par la base : quand la synchro tombe, l'application continue de servir.
• Une application de planning — application web complète, authentification par l'annuaire d'entreprise, construite de zéro plutôt que reprise.
• La reprise du back d'une GED métier — portage d'une API Django vers NestJS, route par route. Plutôt que de relire l'ancien code pour deviner ce qu'il fait, on l'interroge : un oracle rejoue les quelque 370 routes du legacy et confronte ses réponses à celles du nouveau back, une à une. Près de 1 800 réponses comparées, et chaque écart tranché — bug de l'ancien ou régression du nouveau.
• Une plateforme de documentation et un assistant de recherche — chantier en cours : rendre navigables et interrogeables trente ans de documentation qui n'existaient qu'en PDF.

Ce que ça demande vraiment

Reprendre un SI de cette taille, ce n'est pas un problème de framework. C'est un problème d'archéologie et de discipline. Il faut lire du code écrit par des gens qui ne sont plus là, comprendre pourquoi une règle métier bizarre est en fait la bonne, et résister à l'envie de tout réécrire proprement — parce que la réécriture est la décision la plus chère du métier, et la plus facile à prendre pour de mauvaises raisons.

Le travail utile est ailleurs : découper en morceaux livrables, se donner les moyens de vérifier qu'on n'a rien cassé — d'où les harnais de comparaison qui reviennent sur deux chantiers, parce qu'une opinion sur le comportement de l'ancien code ne vaut pas une mesure — et accepter que l'ancien et le nouveau vivent côte à côte pendant des mois. C'est moins spectaculaire qu'une refonte annoncée, et c'est ce qui fait qu'un an et demi plus tard le système tourne toujours.

Aller plus loin