Pourquoi 70 % des projets de modernisation échouent ou stagnent?
L'appel est arrivé un mercredi après-midi en 2014. Un VP Ingénierie dans une compagnie d'assurances à Montréal, quelqu'un avec qui j'avais travaillé des années plus tôt, avait besoin d'aide. Urgence. Son projet de modernisation de mainframe, dix-huit mois d'investissement et à peu près 4 millions de dollars dépensés, était complètement planté. Le nouveau système gérait peut-être 60 % des scénarios d'affaires que l'ancien faisait automatiquement. Personne ne pouvait expliquer où vivait l'autre 40 % dans le code legacy. (J'aimerais vous dire que c'était inhabituel. Pantoute.)
Ce projet a fini par s'en sortir, mais ça a pris quatorze mois de plus et une approche complètement différente. L'équipe originale avait traité la modernisation comme un problème technologique : on swap le vieux stack pour un neuf. Ce qu'ils avaient manqué, et ce que la majorité des équipes manquent, c'est que les systèmes legacy sont des entrepôts de connaissances institutionnelles encodées en logiciel. Des règles d'affaires accumulées sur quinze ou vingt ans de changements réglementaires, de cas limites clients, et de décisions organisationnelles que personne n'a documentées parce que «le système gère ça tout seul».
Voici le patron que j'ai vu se répéter à travers peut-être une quarantaine de mandats de modernisation sur 25 ans. Les équipes partent avec enthousiasme, avancent vite sur les morceaux simples, puis frappent un mur vers le mois six quand elles tombent sur la logique profondément embarquée. Des calculs de taxes encodés en 1998. Des sous-routines COBOL qui gèrent des scénarios de conformité réglementaire que personne dans l'équipe actuelle n'a jamais vu se déclencher. Un batch job qui roule chaque troisième jeudi et réconcilie les données entre deux systèmes, dont un qui devait être décommissionné en 2009 mais qui sert encore, mystérieusement. Exact. Le batch job du troisième jeudi, ça arrive plus souvent qu'on pense.
Stall. Les équipes qui s'en sortent sont celles qui arrêtent, reculent, et font le travail de découverte qu'elles avaient sauté. Celles qui ne s'en sortent pas abandonnent le projet ou livrent quelque chose qui nécessite de faire rouler les deux systèmes indéfiniment. Et ça, c'est le pire scénario, parce que là on maintient deux de tout.
À quoi ressemble concrètement une migration à risque contrôlé?
Version courte : on extrait avant de bâtir. Chaque mandat de modernisation chez Specira commence par une phase de découverte que la plupart des équipes sautent parce que ça semble lent. On cartographie le système existant au complet : chaque règle d'affaires, chaque point d'intégration, chaque cas limite que le système gère, chaque batch et chaque job planifié. On parle aux gens qui l'utilisent vraiment, pas juste aux architectes qui l'ont conçu il y a dix ans. L'opérateur d'entrepôt qui fait un workaround manuel chaque vendredi après-midi connaît des affaires sur votre système que votre documentation ne capte pas.
Pourquoi c'est si important? Parce que le coût de découvrir une règle d'affaires manquée pendant le développement est à peu près dix fois plus élevé que de la découvrir durant l'analyse des exigences. La découvrir après le déploiement? Multipliez par dix encore. J'ai vu un seul calcul réglementaire manqué coûter 340 000 $ à un client en services financiers en corrections manuelles et pénalités réglementaires après un lancement de modernisation. Trois cent quarante mille dollars. Pour une règle qui existait dans une sous-routine COBOL que personne n'avait pensé vérifier.
Migration à risque contrôlé, ça veut dire trois choses en pratique. Premièrement : extraction complète de la logique d'affaires avant qu'une seule ligne de code soit écrite ou qu'une architecture soit conçue. On utilise l'analyse assistée par IA pour lire les codebases legacy et identifier les règles d'affaires embarquées, mais on valide chaque découverte avec les experts du domaine parce que l'analyse de code seule manque le contexte. Deuxièmement : livraison incrémentale avec exécution en parallèle, pour vérifier que le nouveau système produit des résultats identiques à l'ancien avant le basculement. Troisièmement : capacité de rollback à chaque étape, parce qu'aucun plan ne survit au contact avec les données de production sans modifications.
Modernisation du système bancaire central de Commonwealth Bank of Australia : Dans l'un des plus gros projets de modernisation legacy de l'histoire bancaire, Commonwealth Bank a remplacé sa plateforme bancaire centrale vieille de 30 ans par un système moderne basé sur SAP. Le projet a pris cinq ans et coûté environ 1 milliard AUD, mais il a été considéré comme un succès parce que la banque a priorisé l'exécution en parallèle pour chaque ligne de produits avant le basculement. (Source : ITnews Australia)
Le point clé de l'approche CBA? Leur refus du big-bang. Ils ont migré un produit à la fois, en commençant par le plus simple (comptes épargne) et en terminant par le plus complexe (hypothèques). Chaque produit roulait sur les deux systèmes simultanément jusqu'à ce que la banque vérifie des résultats identiques. L'exécution en parallèle a ajouté du temps et des coûts, mais ça a éliminé le risque catastrophique de découvrir de la logique d'affaires manquante en production.
Pas tout le monde a un budget d'un milliard. Mais le principe scale : extraire les règles d'abord, migrer de façon incrémentale, vérifier avant le basculement. Specira applique la même méthodologie à une fraction du coût en utilisant l'analyse de code assistée par IA pour accélérer la phase de découverte que CBA a fait manuellement.
Quelles approches de modernisation est-ce que Specira supporte?
Aucune approche unique ne convient à toutes les situations. J'ai vu des équipes s'engager dans une réécriture complète quand un strangler fig aurait livré de la valeur en un quart du temps. J'ai aussi vu des équipes essayer de wrapper une API autour d'un système tellement fragile que le wrapper est devenu plus complexe qu'une réécriture l'aurait été. En fait, l'approche dépend de l'âge de votre système, de sa complexité, de la qualité de sa documentation, et honnêtement, de combien de connaissances institutionnelles ont quitté l'entreprise avec les années.
On supporte quatre approches principales, et la majorité des mandats finissent par en combiner deux ou trois à travers différentes parties du système.
Patron Strangler Fig
Nommé d'après les figuiers qui enveloppent graduellement leur arbre hôte et le remplacent. On bâtit les nouvelles fonctionnalités en parallèle de l'ancien système, on redirige le trafic vers les nouveaux composants une route à la fois, et éventuellement l'ancien système n'a plus rien à faire. Idéal pour : les applications web monolithiques avec des frontières de modules claires. Mauvais pour : les systèmes de traitement batch fortement couplés où tout dépend de tout.
API Wrapping
Exposer les fonctionnalités legacy via des interfaces REST ou GraphQL modernes sans changer le code sous-jacent. L'ancien système devient un service que les nouvelles applications consomment. Rapide à implémenter. Bon quand le code legacy est stable et correct mais que l'interface utilisateur ou la couche d'intégration est le goulot. Dangereux quand le système sous-jacent est fragile, parce que là on ajoute de la charge et des patrons d'accès pour lesquels il n'a pas été conçu.
Replatforming
Déplacer l'application vers une infrastructure moderne (cloud, conteneurs, services gérés) sans changements de code significatifs. Parfois appelé «lift and shift», même si ça sous-estime le travail impliqué. On ne réécrit pas, mais on adapte : gestion de la configuration, pipelines de déploiement, monitoring, politiques de mise à l'échelle. Bon pour : les systèmes avec des architectures propres qui ont juste besoin d'infrastructure moderne. Risqué quand : l'application fait des suppositions sur les systèmes de fichiers, la topologie réseau, ou l'état du serveur que les environnements cloud ne garantissent pas.
Réécriture sélective
Identifier les modules les plus risqués ou à plus haute valeur et réécrire seulement ceux-là, en laissant les composants stables en place. C'est l'approche que je recommande le plus souvent parce qu'elle concentre l'investissement là où ça compte. Le 20 % de votre système qui cause 80 % de votre fardeau de maintenance reçoit du code moderne; le 80 % qui fonctionne bien reste tel quel jusqu'à ce qu'il y ait une raison d'affaires d'y toucher.
À retenir
La bonne approche de modernisation dépend de votre système, pas des tendances technologiques. La plupart des modernisations réussies combinent plusieurs approches : strangler fig pour les composants web, API wrapping pour les systèmes batch stables, réécriture sélective pour les modules les plus problématiques. La phase de découverte détermine quelle approche convient à chaque partie de votre paysage.
- Le strangler fig fonctionne mieux pour les applications web avec des frontières de modules claires
- L'API wrapping préserve la logique stable tout en permettant l'intégration moderne
- Le replatforming livre des bénéfices d'infrastructure sans changement de code
- La réécriture sélective concentre l'investissement sur les modules les plus risqués
- La majorité des projets combinent deux ou trois approches à travers différents composants
Comment le processus de modernisation fonctionne-t-il étape par étape?
Chaque mandat suit la même structure en quatre phases, même si la durée de chaque phase varie énormément selon la taille et la complexité du système. Un monolithe de 50 000 lignes, c'est un animal différent d'un parc mainframe de 2 millions de lignes avec quarante ans de logique d'affaires accumulée.
Phase 1 : Découverte et extraction de la logique d'affaires (4 à 8 semaines)
C'est ici que la majorité de la réduction du risque se produit, et c'est la phase que la plupart des équipes bâclent ou sautent complètement. On analyse le codebase existant avec des outils assistés par IA qui identifient les règles d'affaires embarquées dans le code, les fichiers de configuration, les triggers de base de données et les procédures stockées. Mais (et c'est critique) on valide chaque découverte avec les gens qui utilisent le système au quotidien. L'analyse de code dit ce que le système fait. Les experts du domaine disent pourquoi il le fait et ce qui arrive quand il ne le fait pas.
Livrables de la découverte : un catalogue complet de règles d'affaires, une carte de dépendances montrant comment les composants interagissent, une évaluation des risques classant chaque module par complexité et criticité d'affaires, et une approche de modernisation recommandée pour chaque composant. Ce document devient le contrat pour le reste du mandat. Rien n'avance sans l'approbation du client sur les règles extraites.
Phase 2 : Architecture et planification de la migration (2 à 4 semaines)
Concevoir l'architecture cible en fonction de ce que la découverte a révélé, pas en fonction de ce qui avait l'air beau dans une présentation de vendeur. Choisir l'approche de modernisation pour chaque composant. Définir la séquence de migration : quels composants bougent en premier, lesquels attendent, et pourquoi. Bâtir l'infrastructure d'exécution en parallèle qui permettra à l'ancien et au nouveau système de coexister durant la transition.
Phase 3 : Migration incrémentale (durée variable)
Bâtir et migrer un composant à la fois. Chaque composant passe par : implémentation, tests automatisés contre les règles d'affaires extraites, exécution en parallèle avec le système legacy, vérification de la parité des résultats, et basculement. Rinse and repeat. Plate? Oui. Efficace? Systématiquement.
Phase 4 : Vérification et décommissionnement (2 à 4 semaines par composant)
Après le basculement, on surveille les cas limites que l'exécution en parallèle n'a pas attrapés. Il y en a toujours, peu importe à quel point la phase de découverte a été rigoureuse, parce que les données de production ont des patrons que les données de test n'ont pas. Une fois que le nouveau composant roule proprement pour la période de vérification convenue (généralement deux à quatre semaines), on décommissionne l'ancien. On garde les backups. Vous allez mieux dormir.
Comment Specira IA réduit-elle le risque de migration legacy?
La partie la plus difficile de la modernisation legacy, c'est pas bâtir le nouveau système. C'est comprendre l'ancien. Specira IA accélère la phase de découverte qui détermine si votre projet réussit ou rejoint les 70 % qui stagnent.
Concrètement. Notre IA lit les codebases legacy (COBOL, RPG, Java, .NET, PHP, peu importe ce sur quoi votre système roule) et extrait les règles d'affaires dans un catalogue structuré. Pas juste «cette fonction calcule la taxe», mais la logique spécifique : conditions d'entrée, étapes de calcul, gestion des exceptions, formats de sortie. L'IA identifie les règles qui interagissent entre elles, signale les contradictions entre les modules (vous seriez surpris à quel point deux parties d'un système legacy implémentent souvent la même règle d'affaires différemment), et fait surface les dépendances non documentées.
Est-ce que l'IA remplace le jugement humain? Non. Elle remplace les mois de lecture manuelle de code que les humains font mal parce que le code legacy est dense, mal documenté, et écrit dans des styles que les développeurs modernes peinent à déchiffrer. L'IA fait l'extraction initiale; les experts du domaine valident et annotent les résultats. Plus vite. Et surtout, plus complet, parce que des humains qui lisent 500 000 lignes de COBOL vont manquer des affaires. C'est inévitable.
La deuxième façon dont Specira IA réduit le risque, c'est par les tests de régression automatisés. Une fois les règles d'affaires extraites et validées, elles deviennent des cas de test. Chaque nouveau composant doit produire des résultats identiques au système legacy pour chaque scénario d'affaires documenté. Pas des tests échantillons sur une poignée de cas. Des tests complets contre le catalogue de règles au complet. C'est ça qui attrape le cas limite qui vous aurait coûté 340 000 $ en production.
J'ai changé d'avis sur quelque chose au cours des dernières années. Je pensais que le choix technologique (quel cloud, quel langage, quel framework) était la décision la plus importante dans un projet de modernisation. Ça l'est pas. La décision la plus importante, c'est combien de temps on investit à comprendre ce qu'on remplace. Manquez ça et aucune technologie va vous sauver. Réussissez ça et à peu près n'importe quel stack technologique moderne va faire la job.
Quelles sont les questions les plus fréquentes sur la modernisation d'applications?
