Remplacement d'un système hérité étape par étape : Strangler Pattern, exploitation en parallèle et cohérence des données lors du déploiement

Un remplacement d’un système hérité échoue rarement à cause de la « construction » de la nouvelle solution, mais lors de la transition : les données doivent rester correctes, les interfaces ne doivent pas se rompre, et l’exploitation doit continuer pendant la bascule. Dans de nombreuses entreprises, un Big-Bang-Cutover n’est donc pas une option – les dépendances sont trop importantes, les coûts d’arrêt trop élevés, la remise en état trop complexe.

Dans la pratique, une approche progressive s’avère efficace avec le Strangler Pattern (les parties fonctionnelles sont transférées progressivement), le fonctionnement parallèle (l’ancien et le nouveau système coexistent temporairement) et des règles claires pour la cohérence des données. Cet article montre comment combiner ces éléments de manière à ce qu’ils soient viables au quotidien pour la direction informatique, l’administration et les responsables de projet – y compris les schémas d’erreur typiques, les conséquences pour l’exploitation et les points de décision lors du déploiement.

Pourquoi l’approche pas-à-pas est souvent le remplacement réaliste d’un système hérité

Les systèmes hérités sont rarement « juste une application ». Souvent y sont liés : des traitements batch, des interfaces de fichiers (dossiers SFTP, lecteurs réseau), des processus d’impression et de numérisation, des outils locaux, des extractions BI, des relais e-mail, du matériel spécialisé, des dérivations Shadow-IT et des contournements manuels. Dans un Big Bang, tous ces flux doivent fonctionner le même week-end – et cela inclut les autorisations, les données de référence, les historiques et les cas particuliers.

L’approche pas-à-pas réduit le risque, mais ne le reporte pas automatiquement « vers le bas ». Elle rend les risques plus visibles et gérables, mais exige en contrepartie des décisions claires d’architecture et d’exploitation : où est le routage ? Qui est le maître des données ? Quelle cohérence est indispensable sur le plan fonctionnel, où une latence temporelle est-elle acceptable ? Et comment éviter que le fonctionnement parallèle ne devienne un chantier permanent ?

Strangler Pattern in der Unternehmensrealität: nicht „Microservices“, sondern klare Schnittkanten

Le Strangler Pattern signifie : vous développez de nouvelles fonctions à côté du système existant et redirigez progressivement le trafic jusqu’à ce que l’ancienne partie devienne superflue. Important : il ne s’agit pas d’une guerre de religion de l’architecture (« Monolith vs. Microservices »), mais d’un patron de migration. Il fonctionne même si l’architecture cible reste un monolithe – simplement plus moderne, plus maintenable et mieux intégrable.

La décision la plus importante : découpez par processus, pas par tables

Dans de nombreuses migrations, le découpage est guidé par les données (« Nous prendrons d’abord les tables clients et commandes »). Cela entraîne souvent un fonctionnement parallèle douloureux, car les processus s’étendent à travers ces données. Mieux vaut un découpage orienté processus, par ex. « création de devis », « réception des marchandises », « traitement des réclamations » ou « ticket de service jusqu’à la facture ».

Règle pratique : une étape Strangler doit couvrir un processus fonctionnellement fermé, qui peut être exploité et surveillé de bout en bout dans le nouveau système. Cela inclut les entrées (UI, API, Import), le traitement (règles métier) et les sorties (impression, export, comptabilisation, notification).

Le Strangler nécessite un « détourneur » : passerelle, proxy ou couche de routage

Afin que les utilisateurs et les systèmes connectés n’aient pas à apprendre à chaque fois de nouveaux endpoints, une couche de routage est souvent mise en place. Selon la situation initiale, il peut s’agir d’un reverse proxy devant les applications web, d’un API-Gateway pour les endpoints de service ou d’une couche d’intégration qui centralise les interfaces fichiers et les events. L’essentiel est l’opérabilité : configuration centrale, logs clairs, monitoring et rollback contrôlé.

Pour les administrateurs, il est important que cette couche ne devienne pas une boîte noire. Ils ont besoin de routages traçables (quelle requête est allée où), de corrélation via les logs (p. ex. Request-ID) et de timeouts/règles de retry définis, afin d’éviter que les erreurs ne restent « collées ».

Le fonctionnement en parallèle est un mode d’exploitation – pas une « astuce de projet »

Fonctionnement en parallèle signifie : anciens et nouveaux composants fonctionnent pendant un temps simultanément en production. C’est normal, mais coûteux — surtout pour l’exploitation. Vous avez plus d’éléments en mouvement, plus de monitoring, plus de potentiel d’incidents et des responsabilités plus complexes. C’est pourquoi le fonctionnement en parallèle doit être planifié comme un mode d’exploitation à durée limitée, incluant des critères d’arrêt.

Modèles typiques de fonctionnement en parallèle (et quand ils conviennent)

• Basculement par groupes d’utilisateurs (groupe pilote → vagues) : adapté lorsque les rôles utilisateurs sont clairement séparables et que les processus ne traversent pas les groupes.
• Basculement par mandant/site : pertinent pour des structures de succursales/ateliers, lorsque les flux de données entre sites sont limités.
• Basculement par étapes de processus : p. ex. « saisie nouvelle, facturation encore ancienne » — risqué s’il existe beaucoup de rétroactions, mais parfois inévitable.
• Basculement par type d’objet : p. ex. nouveaux actifs immobilisés dans le nouveau système, anciens stocks dans l’ancien — peut fonctionner si des règles claires d’historique/reporting existent.

Du point de vue de l’exploitation, concevez le fonctionnement en parallèle de façon à ce que les domaines d’erreur restent restreints : une défaillance dans le nouveau composant ne doit pas entraîner le système legacy (p. ex. via des interfaces bloquantes ou des verrous de base de données), et inversement le legacy ne doit pas saboter l’ensemble des nouveaux processus par des exports instables.

Feature Flags et règles de routage : contrôle plutôt que « on déploie et on espère »

Les Feature Flags sont des commutateurs qui permettent d’activer/désactiver des fonctionnalités de manière ciblée — sans nouveau déploiement. Pour la direction IT et les responsables de projet, ce n’est pas le détail technique qui compte, mais la gouvernance : qui est autorisé à basculer ? Comment est documentée la raison du changement ? À quelle vitesse peut-on revenir en arrière ? Quelles dépendances apparaissent (p. ex. si des données ont déjà été produites au nouveau format) ?

Une bonne pratique consiste en un petit protocole de changement (Decision Log) pour chaque action de basculement : moment, propriétaire, groupe d’utilisateurs concerné, effet attendu, indicateurs de monitoring, condition de rollback. Cela évite le classique « plus personne ne sait pourquoi le routage est ainsi ».

Consistance des données lors du rollout : le cœur dont dépendent de nombreuses migrations

La cohérence des données signifie que les données sont correctes d’un point de vue métier, complètes et disponibles dans l’ordre attendu. En exploitation parallèle, cela devient difficile, car deux systèmes écrivent simultanément ou revendiquent chacun la « vérité ». C’est ici que se joue la stabilité du remplacement du système hérité : soit il fonctionne de manière stable, soit vous passez des mois à effectuer des rapprochements de deltas.

Clarifier d’abord : qui est le « System of Record » pour chaque domaine de données ?

Vous devez, pour chaque domaine de données (par ex. Debitoren, articles, prix, commandes, mouvements de stock, pièces), définir quel système est maître. Ce n’est pas qu’une question d’architecture, mais opératoire :

• Où sont effectuées les corrections en cas de support ?
• Où se situe le processus d’approbation (double validation, SoD/séparation des fonctions) ?
• Quelles traces d’audit sont nécessaires (qui a modifié quoi et quand) ?
• Comment éviter les retouches lors de la clôture mensuelle ?

Dans les phases initiales du pattern Strangler, il est souvent judicieux de laisser d’abord le système hérité comme source principale de données et de faire en sorte que le nouveau composant se contente de consommer. Plus tard, vous inversez la responsabilité. Ce changement de gouvernance est un jalon à part entière et nécessite une fenêtre de basculement claire ainsi qu’un plan de communication et de validation.

Schémas de synchronisation : Dual Write, CDC et événements — avec des attentes réalistes

Il existe plusieurs manières de synchroniser les données entre l’ancien et le nouveau. Aucune n’est « gratuite ».

• Dual Write : une action écrit dans les deux systèmes (p.ex. création d’une commande → Legacy et nouveau système). Avantage : disponibilité rapide. Inconvénient : les cas d’erreur sont complexes (que se passe-t-il si le système A écrit mais pas le système B ?), de plus des dépendances apparaissent et il y a souvent des risques de performance.
• Change Data Capture (CDC) : les modifications sont extraites du log de la base de données ou via triggers/replication sous forme de deltas. Avantage : découple l’application et la synchronisation. Inconvénient : vous répliquez aussi des modifications « techniques » et devez reconstruire les événements métier ; de plus, les modifications de schéma du système hérité deviennent soudainement un risque d’intégration.
• Intégration basée sur les événements : le système publie des événements métier (p.ex. « commande validée ») que d’autres systèmes consomment. Avantage : sémantique métier claire. Inconvénient : exige des définitions d’événements propres, l’idempotence (traitement multiple sans effet secondaire) et un concept d’exploitation robuste pour la messagerie.

Il est essentiel pour les décideurs : la cohérence des données n’est pas binaire. Certains processus exigent une cohérence forte (immédiatement correcte, p.ex. autorisations de paiement), d’autres tolèrent une cohérence éventuelle (délai court, p.ex. index de recherche, reporting, notifications). Cette classification doit être convenue tôt avec le métier et le contrôle interne / l’audit.

Conflits et doublons : planifiez explicitement le « chemin d’exception »

En exploitation parallèle, les conflits surviennent typiquement ainsi : deux systèmes modifient le même objet selon des règles différentes. Ou un import s’exécute en double parce qu’un retry est intervenu « trop tôt ». Ou un utilisateur corrige des données dans le Legacy alors que la nouvelle interface a déjà été basculée.

Vous avez besoin de règles contraignantes pour cela :

• Résolution des conflits : « Last write wins » est rarement correct d’un point de vue métier. Mieux valent des priorités (le système maître l’emporte) ou des règles de fusion métier (p. ex. données de base du contact vs. conditions).
• Idempotence : chaque intégration doit tolérer des traitements multiples sans générer de doublons (p. ex. même numéro de document, même référence externe).
• Dead-Letter/Quarantaine : les deltas non traitables doivent être traçables, avec une responsabilité claire et un mécanisme de relance.

Sans ces règles, la cohérence des données dérive vers des « conciliations Excel » et du travail manuel de rattrapage — avec la frustration associée et des coûts indirects difficiles à quantifier.

Conception du rollout : vagues, recettes et retours arrière sans surcharger l’exploitation

Un bon rollout, ce n’est pas juste « déploiement + formation ». En exploitation parallèle, il faut articuler rollout et exploitation : qui assure le support de premier niveau en cas d’erreur ? Quels logs sont immédiatement disponibles ? Comment s’effectuent les escalades ? Quels processus ne doivent pas être modifiés au cours d’une vague (p. ex. clôture mensuelle, inventaire, changement de prix) ?

Planification en vagues avec critères stricts

Une planification en vagues assortie de critères d’entrée clairs — pas seulement des dates — s’est avérée efficace. Exemples de critères stricts :

• Les tableaux de bord de monitoring et l’alerting pour la nouvelle composante sont en production et testés (y compris la réduction du « bruit d’alerte »).
• Des runbooks pour les incidents types existent (timeouts, engorgement de queues, imports défectueux, erreurs d’autorisation).
• La réconciliation des deltas est automatisée et fournit des rapports compréhensibles (différences par type d’objet, fenêtre temporelle, classe de cause).
• Le mécanisme de rollback est pratiqué (au minimum joué de façon réaliste en staging/pre-prod).

Ce dernier point est souvent sous-estimé : rollback ne signifie pas « on repasse simplement en arrière ». Si le nouveau système a déjà généré des données, il faut savoir comment ces données seront visibles dans le legacy ou comment migrer/neutraliser correctement les données créées.

Mini-cutovers de basculement plutôt que Big Bang

Même avec le Strangler Pattern, il y a des cutovers — mais de taille réduite. Typiquement, des mini-cutovers interviennent lors du changement d’une étape de processus ou du basculement de la responsabilité des données. Chaque mini-cutover nécessite :

• Gel de données (court, mais contraignant) : qui est autorisé à modifier quoi pendant ce laps de temps ?
• Réconciliation : qu’est-ce qui a été modifié depuis la dernière synchronisation ?
• Basculement : routage/feature flags, jobs, calendriers, permissions.
• Vérification : smoke tests métier (p. ex. créer une commande → bon de livraison → facture), plus contrôles techniques (queues, taux d’erreur, charge DB).

Pour la direction IT, il est essentiel que ces étapes soient documentées comme un processus répétable et sécurisées sur le plan des ressources humaines. Sinon, le succès du projet dépend de personnes individuelles qui « savent comment faire ».

Stabiliser d’abord les interfaces : le fondement sous-estimé de la désactivation du legacy

Beaucoup de systèmes legacy communiquent via des interfaces héritées : exports CSV dans des dossiers, jobs nocturnes, accès directs à la base de données par des outils tiers, workflows basés sur e‑mail. Une désactivation progressive devient nettement plus simple si vous commencez par inventorier le paysage des interfaces et consolidez à quelques points stratégiques.

Concrètement, cela signifie : identifiez les points d’intégration critiques pour le système (p. ex. comptabilité financière, expédition, retours de production, identités/autorisations) et établissez-y des contrats clairs. « Contrat » n’est pas ici juridique, mais technique : gestion de versions, champs univoques, IDs stables, gestion des erreurs documentée, SLA définis pour la livraison des données.

Si vous mettez en place un modèle de gouvernance interne pour les API/intégrations (propriétaire, règles de dépréciation, chemins de test/staging), le risque qu’une modification dans le legacy mette soudainement votre nouvelle composante hors service diminue. Un point d’ancrage thématique pertinent pour un maillage interne serait par exemple un article sur la gouvernance des API et les stratégies de dépréciation.

Sécurité, autorisations et audit : le fonctionnement en parallèle accentue le sujet

En fonctionnement en parallèle, il existe souvent des modèles d’utilisateurs et de rôles en double. Cela crée des droits « fantômes » : un utilisateur peut être correctement restreint dans le nouveau système, mais disposer encore de droits étendus dans le legacy — et finir par emprunter la « voie la plus simple ». S’y ajoutent les comptes techniques (comptes de service) pour la synchronisation, les imports, les queues et les jobs batch.

Points concrets à clarifier tôt :

• Source d’identité : d’où proviennent les utilisateurs et les groupes ? AD/Entra ID ? Un IAM interne ? Il est important que la provision soit traçable.
• Mapping des rôles : si les rôles ne correspondent pas 1:1, il faut des rôles transitoires, limités dans le temps et soumis à recertification.
• Comptes de service : droits minimaux, rotation des secrets, journalisation rigoureuse. Les comptes de synchronisation sont souvent une porte d’entrée et difficiles à auditer.
• Traçabilité des audits : si la responsabilité principale des données change, il doit être clair où se trouve la preuve des modifications et comment elle reste consultable à travers les deux systèmes.

Important pour les décideurs : la sécurité n’est pas un « périmètre additionnel », elle influence la faisabilité du déploiement. Rattraper ensuite les autorisations en exploitation parallèle coûte généralement plus cher qu’une découpe pragmatique précoce des rôles et des comptes de service.

Monitoring, Logging und Betriebsübergabe: Ohne Observability wird Parallelbetrieb blind

En fonctionnement en parallèle, les symptômes d’erreur sont souvent indirects : un delta reste bloqué, un retry tourne indéfiniment, une queue se bouche, ou un job sensible au temps entre en conflit avec un verrou de base de données. Si vous ne le voyez que via des tickets utilisateurs, il est déjà trop tard. Vous avez donc besoin dès le départ d’un minimum d’observabilité : supervision (état), journalisation (événements) et — lorsque pertinent — traçage (chaîne à travers les systèmes).

Signaux pratiques et exploitables par exemple :

• Arriéré de synchronisation (combien de modifications « attendent »), plus l’âge de l’entrée la plus ancienne.
• Taux d’erreur par interface et par classe d’erreur (validation, timeout, auth, conflit de données).

Pour la passation en exploitation, l’important n’est pas tant l’outil utilisé que la clarté des responsabilités et des runbooks. Si vous avez une astreinte ou une équipe de garde, l’exploitation doit pouvoir agir en cas d’incidents typiques sans travail de détective par des développeurs.

Quand le Strangler Pattern ne convient pas (ou seulement avec des restrictions claires)

Il existe des situations où un remplacement progressif fonctionne seulement de façon limitée :

• Couplage transactionnel extrêmement étroit : lorsque presque chaque opération traverse tous les modules et exige une consistance stricte, l’exploitation en parallèle devient rapidement incontrôlable.
• Accès directs à la base de données par des systèmes tiers : si plusieurs outils écrivent/lisent directement dans des tables legacy, il faut d’abord arrêter ou contrôler cette prolifération.
• Propriété des données non définie : si on ne peut pas déterminer qui est maître des données, les conflits sont assurés — et la migration devient politique plutôt que technique.
• Absence de discipline d’exploitation : sans environnements propres, déploiements reproductibles et monitoring, chaque étape intermédiaire devient un risque.

Cela ne signifie pas que vous soyez contraint au Big Bang. Mais il faut alors changer l’ordre : stabiliser d’abord les points d’intégration, centraliser les accès aux données, clarifier les rôles et la propriété des données — puis seulement ensuite procéder au strangling.

Un plan d’exécution opérationnel pour la migration progressive des systèmes legacy en étapes

Comme repère pour les responsables de projet, un déroulé en étapes claires s’est avéré efficace. La forme exacte dépend du système et du secteur, mais la logique est robuste :

1. Inventaire & dépendances : interfaces, jobs, flux de données, groupes d’utilisateurs, fenêtres critiques (clôture, inventaire).
2. Définir les interfaces : modules de processus, responsabilité des données par domaine, contrats d’intégration.
3. Mettre en place le routage & les bascules : Gateway/Proxy, Feature Flags, journalisation centralisée.
4. Définir le parcours des données : CDC/Event/Dual Write, règles de gestion des conflits, quarantaine, rapports de réconciliation.
5. Pilote avec charge réelle : pas seulement une démo, mais avec des cas réels, y compris les exceptions.
6. Déploiement par vagues : critères d’entrée, checklists de cutover, exercices de rollback.
7. Désactivation & nettoyage : désactiver les chemins legacy, supprimer les jobs, révoquer les droits, mettre la documentation à jour.

Le dernier point est essentiel : de nombreuses organisations laissent des composants legacy « pour sécurité » continuer de fonctionner. Résultat : coûts doublés, risque flou, personne n’ose procéder à l’arrêt. Planifiez la mise hors service comme sous-projet avec date, responsables et preuves (p. ex. « aucune connexion depuis X semaines », « tous les exports transférés », « exigences d’audit remplies »).

Conclusion : remplacer par étapes signifie traiter la consistance et l’exploitation comme un produit

Une migration progressive des systèmes legacy n’est pas automatiquement plus simple — mais c’est dans de nombreuses entreprises la seule option réaliste. Le Strangler Pattern fonctionne si vous définissez des interfaces de processus claires pour chaque étape, planifiez le fonctionnement parallèle comme un véritable état d’exploitation et ne laissez pas la consistance des données au hasard. Décisifs sont des décisions précoces sur la propriété des données, des modèles de synchronisation robustes avec règles de conflit, ainsi qu’un design de déploiement avec vagues, phases d’acceptation et procédures de repli éprouvées.

Si vous prévoyez un remplacement et souhaitez discuter de manière structurée des interfaces, du fonctionnement en parallèle ou du concept de cohérence des données, vous pouvez nous joindre via .

Discuter d’un projet ou d’une modernisation avec Net-Base.