Moderniser un système patrimonial sans tout réécrire d’un coup

Un système patrimonial est rarement un mauvais logiciel — c’est un logiciel qui contient vingt ans de décisions que personne n’a consignées ailleurs. C’est exactement pour cette raison que le plan de modernisation habituel, la réécriture en bloc, échoue aussi régulièrement : il mise toutes les opérations sur la reproduction simultanée de toutes ces décisions, à partir d’un cahier des charges qui ne les a jamais contenues. L’approche qui fonctionne est plus terne et plus sûre — placer une couche d’aiguillage devant l’ancien système, faire passer un processus à la fois vers le nouveau, fermer l’ancien chemin pour ce processus, et recommencer jusqu’à ce que le système patrimonial soit une archive plutôt qu’une dépendance. La réécriture a bien lieu; elle ne se fait simplement jamais d’un seul coup.

Là où ça dérape :

La réécriture en bloc échoue le jour de la bascule. Tout réécrire et basculer en une fin de semaine, c’est exiger que chaque règle non documentée, chaque cas particulier et chaque intégration fonctionnent le même jour, sans retour possible. La plupart des projets de réécriture n’échouent pas pendant le développement — ils échouent dans les deux premières semaines de production, quand l’entreprise découvre ce que l’ancien système prenait discrètement en charge.

Les règles vivent dans le code et dans la tête de deux personnes. L’exception de prix pour un client de longue date, le traitement des taxes ajouté en 2011, le champ qui ne veut pas dire la même chose avant une certaine date — rien de cela ne figure dans un document. Une modernisation qui part d’un cahier des charges neuf au lieu de retrouver ces règles, c’est un plan pour les redécouvrir un incident à la fois.

L’ancien système porte des charges que personne n’a documentées. Des rapports, des exportations, un fichier nocturne dont un autre service dépend, une intégration qu’un fournisseur a bâtie il y a dix ans — les systèmes patrimoniaux accumulent des utilisateurs que personne ne recense. Éteindre un de ces systèmes sans inventaire complet de tout ce qui y puise, c’est ainsi qu’une clôture comptable déraille trois semaines après un lancement réussi.

Le gel des fonctionnalités tue le projet avant même la livraison. Une réécriture qui s’étire sur plusieurs trimestres s’accompagne habituellement d’un gel des fonctionnalités de l’ancien système. L’entreprise, elle, ne gèle pas. À la livraison, le nouveau système correspond aux opérations telles qu’elles étaient au début du projet, et l’écart se comble avec les mêmes solutions de contournement que la réécriture devait éliminer.

La modernisation devient un déménagement chez un nouveau propriétaire. Quitter un ancien fournisseur pour une plateforme que vous ne contrôlez pas davantage, c’est échanger une dépendance contre une autre au marketing plus habile. Si, au terme de la modernisation, votre organisation n’est pas propriétaire de son modèle de données, de son code et de ses comptes, seule la facture a changé, pas votre position.

Comment on le bâtit vraiment :

Inventorier ce que le système fait vraiment. Pas ce que dit le manuel — ce qui s’exécute réellement. Retracer l’usage réel : quels écrans sont utilisés, quelles tâches se déclenchent, quels fichiers sortent du système et qui s’en sert. Un système patrimonial traîne toujours du poids mort, et c’est dans l’inventaire qu’on trouve le tiers du système que personne n’a utilisé depuis 2019, et qu’on cesse de payer pour le reproduire.

Retrouver les règles dans le comportement et les données, pas seulement dans le code source. Le code source dit ce que le système fait; les données disent ce qu’on lui a réellement demandé de faire. Lire les deux, et consulter les gens qui l’utilisent, c’est ce qui fait remonter les exceptions non documentées avant la bascule plutôt qu’après. Ce travail de récupération est le vrai coût d’une modernisation, et toute proposition qui l’escamote chiffre une démo.

Placer une couche d’aiguillage devant, puis remplacer un processus à la fois. Les nouvelles requêtes passent par une couche qui décide si c’est l’ancien ou le nouveau système qui les traite. Un processus migre au complet, son ancien chemin est fermé, et le suivant emboîte le pas. À tout moment, l’organisation fonctionne sur un seul chemin actif par processus — jamais deux systèmes qui font le même travail en parallèle indéfiniment.

Traiter les données comme un chantier à part entière. Mettre en correspondance, nettoyer, rapprocher et répéter le transfert de plusieurs années de données, c’est un projet dans le projet, avec son propre responsable et son propre échéancier. Le sujet est traité en détail à la page sur la migration de données, et c’est la partie que la plupart des soumissions de modernisation sous-estiment le plus largement.

Mesurer ce qui passe encore par l’ancien système. Le retrait se mesure par un chiffre, pas par une impression : combien de transactions, d’utilisateurs et d’intégrations touchent encore l’ancien chemin ce mois-ci par rapport au mois dernier. Quand le chiffre tombe à zéro pour un processus, l’ancien code de ce processus est éteint délibérément — pas laissé en marche parce que personne n’est certain.

Terminer avec l’ancien système en archive en lecture seule. Tout ne migre pas. L’historique ancien qu’on consulte une fois par année a sa place dans une archive en lecture seule, avec une durée de conservation définie — au Canada, cette décision devrait se prendre en tenant compte de la LPRPDE (PIPEDA) et, pour les données du Québec, de la Loi 25 — plutôt que d’être traîné dans le nouveau système pour le ralentir à jamais.

La question de l’IA :

L’IA a transformé le travail sur les systèmes patrimoniaux plus que presque tout autre type de projet, parce que lire du vieux code est une chose où elle excelle réellement. Retrouver les règles d’un traitement par lots en COBOL ou de dix ans de procédures stockées — un travail qui prenait des mois à un spécialiste — se fait maintenant en quelques jours. Ce que l’IA ne peut pas faire, c’est décider lesquelles de ces règles méritent de survivre, quel système sera ensuite propriétaire de chaque champ, et dans quel ordre les opérations peuvent absorber le changement sans risque. Ce sont des questions de jugement, et c’est là que les modernisations échouent vraiment.

VX-N utilise l’IA sur toute la boucle — pour fouiller l’ancien système, bâtir le nouveau et tester les deux côtés de chaque bascule. C’est pourquoi le premier livrable arrive dans les 24 heures suivant le premier appel, et que des remplacements qu’on avait chiffrés en années se livrent processus par processus, en quelques semaines.

Notre verdict : Gardez le système patrimonial s’il est stable, qu’il convient encore à vos opérations et que la pression pour le remplacer est esthétique plutôt qu’opérationnelle — vieux et laid ne constitue pas un argument d’affaires. Modernisez graduellement quand il bloque activement le travail : environnement d’exécution qui n’est plus pris en charge, fournisseur qui garde vos données, intégrations qu’il ne permet pas, ou une seule personne capable d’en assurer l’entretien. Réservez la vraie bascule en bloc au cas rare où la plateforme sous-jacente meurt à une date fixe — fin de vie du matériel, abandon imposé par le fournisseur — et même là, découpez en étapes tout ce que l’échéance permet. La réécriture à partir de zéro comme stratégie de choix est la seule option que nous déconseillons, pratiquement sans exception.

Combien de temps prend la modernisation d’un système patrimonial?

Bien découpée, la modernisation devrait mettre un premier processus en service sur le nouveau système en quelques semaines — cette première tranche valide la couche d’aiguillage, le chemin des données et la méthode de déploiement. La durée totale dépend du nombre de processus et d’intégrations que porte l’ancien système, et la réponse honnête vient après l’inventaire, pas avant.

Faut-il arrêter l’entreprise pendant ce temps?

Non, et un plan qui l’exige est un mauvais plan. Remplacer un processus à la fois veut dire que les opérations continuent de fonctionner sur le chemin actif de chaque processus. Les bascules se font une à la fois, chacune assez petite pour être répétée et annulée.

Le fournisseur a disparu et nous avons à peine le code source. Est-ce sans espoir?

C’est courant, pas sans espoir. Le comportement du système et sa base de données contiennent encore les règles, et les outils modernes en récupèrent une quantité remarquable. Le travail est plus lent sans le code source, mais la méthode, un processus à la fois, reste la même — et c’est justement la situation où la réécriture en bloc est la plus dangereuse.

Devrions-nous passer aux microservices?

Seulement si le problème opérationnel l’exige, ce qui, habituellement, n’est pas le cas à l’échelle d’une entreprise de taille moyenne. Les microservices répondent à des problèmes de croissance organisationnelle que vivent les grandes équipes d’ingénierie. La plupart des organisations qui modernisent un système patrimonial ont besoin d’un seul système bien structuré, avec des points d’intégration propres — pas d’une architecture distribuée à exploiter en plus de tout le reste.

Passer à l’infonuagique, est-ce la même chose que moderniser?

Non. Déplacer un vieux système vers un hébergement infonuagique change l’endroit où il tourne, pas ce qu’il est — vous gardez les mêmes règles, les mêmes lacunes et les mêmes contournements, avec une nouvelle facture. L’hébergement infonuagique fait souvent partie de la destination, mais la modernisation, c’est le modèle de données et les processus, pas l’adresse.

Dernière révision le 28 août 2026