Une équipe duplique les requêtes du legacy vers une nouvelle application et annonce 99,8 % de réponses identiques. En réalité, la cible lit des données plus fraîches, régénère ses identifiants et envoie parfois un webhook de test vers un partenaire réel. Le chiffre rassure, mais la comparaison ne porte pas sur le même monde.
Le problème devient visible avec emails doubles, quotas consommés, lenteur du système historique et écarts classés comme bruit sans owner. Ce risque augmente avec la charge support, le coût complet des calculs dupliqués et les incidents partenaires. Avant les premiers incidents, une forte variation horaire du taux de parité ou son amélioration après chaque nettoyage manuel révèle déjà la dérive.
Le vrai enjeu consiste à comparer deux décisions sur une entrée et un état équivalents, sans que la cible modifie la production. Vous allez comprendre comment dupliquer, corréler, isoler, normaliser puis transformer les écarts en critères de canari et de rollback.
Une expertise en développement d’applications métier relie cette preuve au run. La spécialisation migration d’application legacy l’inscrit ensuite dans une trajectoire de remplacement réellement réversible.
Reconnaître un shadow traffic trompeur
Un shadow fragile copie le trafic mais pas le contexte, compare les payloads bruts et ignore les effets sortants. Il produit beaucoup de données sans répondre à la question qui autorisera une vraie bascule.
Auditer la chaîne avant d’interpréter le score
Le diagnostic suit réception, filtrage, duplication, exécution legacy, exécution cible, dépendances, normalisation et comparaison. Chaque étape porte owner, métriques, erreurs, file et stratégie de repli.
Un deuxième signal faible apparaît quand les écarts sont exclus plus vite qu’ils ne sont expliqués. Une liste d’ignores croissante peut transformer une cible fausse en score artificiellement vert.
La première revue sélectionne vingt corrélations et tente de reproduire entrée, état, sorties et classification. Toute impossibilité révèle une faiblesse du dispositif avant même d’évaluer le code cible.
Définir la preuve recherchée
Le shadow peut prouver compatibilité fonctionnelle, robustesse, latence ou capacité. Chaque objectif exige une population, des métriques et une durée différentes ; un score unique ne couvre pas tous ces risques.
La décision finale est écrite dès le cadrage : ouvrir un canari, différer une cohorte, corriger une règle ou arrêter la cible. Cette sortie attendue détermine le niveau de preuve, les seuils bloquants et l’owner capable de signer le résultat.
Écrire une hypothèse réfutable
Une hypothèse utile indique scénario, cohorte, décision comparée, tolérance, volume, fenêtre et action. Par exemple, le calcul tarifaire doit produire le même total expliqué sur toutes les commandes B2B pendant deux clôtures.
Les non-objectifs sont écrits : le shadow ne prouve pas encore la tenue d’un SLA public, la capacité à écrire en source de vérité ni la réaction des utilisateurs à la nouvelle interface.
Le dossier sépare faits, interprétations et hypothèses. La parité observée devient une preuve seulement lorsque le corpus et les exclusions permettent de réfuter la règle annoncée.
Dupliquer sans ralentir le legacy
La voie historique reste autoritaire et ne doit pas attendre la cible. La duplication est asynchrone, bornée et sacrifiable lorsque sa charge menace le service réellement utilisé.
L’enveloppe est créée après authentification et validation lorsque l’objectif porte sur le métier, ou avant certaines transformations lorsqu’il faut précisément comparer la compatibilité d’entrée. Ce point de capture est versionné, car le déplacer modifie la population observée et rend deux campagnes difficilement comparables.
Placer un tee non bloquant
Le proxy ou l’application sérialise une enveloppe minimale vers une queue, puis poursuit la requête principale. Timeout, seuil de file, échantillonnage et circuit breaker empêchent le shadow d’augmenter la latence utilisateur.
Les corps volumineux utilisent une référence vers un stockage chiffré avec expiration. La copie conserve méthode, route, headers autorisés, identité pseudonymisée, body, timestamp et version de contrat.
Le monitoring distingue trafic éligible, dupliqué, abandonné, rejoué et comparé. Un taux de capture bas invalide la couverture sans transformer les pertes du shadow en incident du legacy.
Corréler les deux exécutions
Une corrélation stable relie demande source, résultat legacy, résultat cible, contexte et comparaison. Elle ne dépend pas d’un identifiant régénéré différemment par chaque application.
Le stockage de preuve possède une contrainte d’unicité par système et exécution attendue. Une arrivée tardive complète la corrélation sans écraser le premier résultat ; un doublon reste visible avec son motif, son payload et la version du consommateur qui l’a produit.
Propager une identité de preuve
L’enveloppe reçoit shadow_id, trace_id, version, cohorte et horodatage. Ces clés traversent logs, appels internes et comparateur sans devenir un identifiant métier stocké dans les données clientes.
Les sorties arrivent parfois dans un ordre différent ; le comparateur attend une fenêtre bornée puis classe timeout, absence ou doublon. Une politique d’expiration empêche les corrélations orphelines de saturer le stockage.
Le rejeu conserve le shadow_id d’origine et ajoute replay_id. L’équipe distingue ainsi une nouvelle exécution de la preuve initiale sans compter deux fois le même cas dans la parité.
Neutraliser tous les effets de bord
La cible ne doit envoyer ni email, ni paiement, ni fichier, ni webhook, ni écriture dans un référentiel de production. Lire seul ne suffit pas si une bibliothèque ou une tâche différée contourne le chemin principal.
L’inventaire des effets part du code, des configurations réseau, des queues, des tâches planifiées et des logs réels. Il inclut aussi compteurs, caches partagés et verrous qui peuvent modifier le comportement du legacy sans produire un effet visible pour le client.
Remplacer les ports par des collecteurs
Chaque effet sort par une interface : mailer, PSP, bus, stockage, impression ou API partenaire. En mode shadow, un collecteur enregistre l’intention et retourne une réponse simulée compatible sans déclencher l’action.
La sortie capturée contient type, destinataire pseudonymisé, payload normalisé, ordre et clé idempotente. Elle devient comparable au legacy sans exposer un tiers à une tentative supplémentaire.
Un test d’egress interdit le réseau hors allowlist, et les credentials du shadow ne possèdent aucun droit d’écriture. Cette défense couvre le code oublié que l’injection de dépendances n’a pas encore isolé.
Aligner données, temps et dépendances
Deux exécutions espacées peuvent lire des états différents. Un stock, une horloge ou une règle modifiée entre les appels produit un écart légitime qui ne renseigne pas la parité du code.
Chaque dépendance reçoit une stratégie : donnée embarquée, snapshot, enregistrement-rejeu, lecture versionnée ou comparaison tolérante. Le choix nomme sa fidélité et ses limites afin qu’un écart classé non-comparable reste quantifié au lieu de disparaître du rapport.
Choisir snapshot, double lecture ou reconstruction
Le scénario idéal fournit à la cible les mêmes entrées matérialisées que le legacy. Sinon, un snapshot versionné, une lecture à date ou une projection d’événements rapproche les deux mondes.
L’horloge, le hasard et les identifiants sont injectés. Les dépendances externes peuvent être enregistrées puis rejouées, avec date, statut et réponse, afin que la cible ne consulte pas une réalité déjà changée.
Si l’état ne peut pas être aligné, alors la comparaison classe non-comparable et mesure cette population. La supprimer du dénominateur sans visibilité donnerait un score vert sur les seuls cas faciles.
Comparer la décision métier
Deux JSON différents peuvent porter la même décision, tandis que deux statuts 200 identiques peuvent cacher des prix ou droits divergents. Le comparateur doit connaître la sémantique utile.
La comparaison suit une hiérarchie : invariant global, décision, composantes puis présentation. Elle s’arrête sur le premier niveau divergent mais conserve les suivants, ce qui permet de distinguer une cause racine d’une cascade de différences mécaniques dans le payload final.
Construire des comparateurs par capacité
Prix, éligibilité, workflow et facturation possèdent leurs invariants. Le comparateur extrait décision, montants, lignes, motifs, événements puis effets attendus avant de produire une classe d’écart.
Les tolérances concernent uniquement un champ et un motif, comme une précision d’affichage. Elles portent owner, expiration et test ; aucune wildcard ne neutralise un objet complet.
La sortie explique chemin, valeur legacy, valeur cible, règle, sévérité et action. Le support peut remonter au premier état différent sans comparer manuellement des payloads de plusieurs milliers de caractères.
Normaliser le bruit légitime
Timestamps, UUID, ordre de listes, traces et champs calculés à la demande créent des différences sans impact métier. Les ignorer exige pourtant une règle précise plutôt qu’un nettoyage opportuniste.
Une règle de bruit doit démontrer que toute valeur du champ est sans influence sur décision, effet ou audit. Si le champ participe parfois à une branche métier, la normalisation le transforme selon une correspondance contrôlée plutôt que de le supprimer entièrement.
Canoniser avant de comparer
La normalisation trie les collections lorsque l’ordre n’est pas contractuel, remplace les identifiants par des alias corrélés et projette les dates sur l’horloge injectée. Elle conserve toujours la valeur brute pour l’audit.
Chaque transformateur possède entrée, sortie, version, owner et tests positifs puis négatifs. Une règle ne doit pas effacer le champ qui porte justement la décision en cours de migration.
La revue surveille le nombre d’ignores, leur couverture et leur ancienneté. Une augmentation sans changement documenté déclenche un no-go, même si le score global s’améliore.
Couvrir scénarios et cohortes
Le trafic courant sous-représente erreurs, clôtures, saisonnalité et clients rares. La preuve associe trafic réel, replays historiques et cas synthétiques de bord pour couvrir les décisions qui autoriseront réellement la bascule.
La matrice de couverture part des capacités et non des seules routes HTTP. Un même endpoint peut porter commande standard, exception contractuelle et reprise support ; chacune devient une ligne avec volume, criticité, comparabilité et résultat attendu.
Mesurer le dénominateur utile
Les cohortes combinent client, parcours, volume, pays, rôle, feature flag et version. Le dashboard affiche reçu, éligible, comparable, conforme, divergent et inconnu pour chacune.
Les événements rares sont rejoués depuis des données pseudonymisées avec une vérité attendue. Les cas synthétiques couvrent limites, erreurs, concurrence et dépendances indisponibles absentes de la fenêtre courante.
La durée inclut au moins un cycle métier complet : clôture, import, renouvellement ou pic. Une semaine calme ne prouve pas un comportement mensuel ou saisonnier.
Protéger capacité, sécurité et données
Dupliquer 100 % du trafic peut doubler calculs, lectures et appels internes. Le shadow est un consommateur avec budget, priorité basse et capacité d’arrêt indépendante.
Un test de charge estime CPU, mémoire, I/O, stockage de preuve et coût par million de requêtes avant l’ouverture. La montée progressive observe aussi les bases partagées : une cible isolée en calcul peut encore saturer la même lecture ou le même cache que le legacy.
Limiter charge et exposition
Échantillonnage adaptatif, rate limit, queue bornée et autoscaling protègent la production. Le dispositif privilégie les cohortes sous-couvertes au lieu d’ajouter toujours les mêmes parcours majoritaires.
Les données sensibles sont minimisées, chiffrées et soumises à une rétention courte. Les accès au corpus puis aux divergences sont journalisés selon les mêmes exigences que la production.
Le seuil de coupure porte CPU, base, latence legacy, retard de file et coût. Le rollback désactive la duplication sans affecter route, données ou réponse autoritaire.
Décider les seuils de bascule
Une moyenne de parité ne suffit jamais à décider seule. Les seuils combinent sévérité, cohorte, durée, couverture et capacité à expliquer chaque divergence restante avant une ouverture réelle.
Les seuils sont absolus pour certaines décisions, comme autorisation ou débit, et statistiques pour d’autres, comme latence ou ordre de présentation. Chaque dépassement indique blocage, correction attendue et niveau auquel le shadow peut continuer sans fausser le dossier.
Passer du shadow au canari
Les erreurs critiques atteignent zéro, les écarts majeurs restent sous un seuil par scénario et les inconnus possèdent un owner. La performance cible satisfait son budget sans dégrader le legacy.
Le canari commence sur une cohorte réversible avec écritures réelles, monitoring et rollback exercé. Il ne réutilise pas la cible shadow si ses collecteurs d’effets sont encore actifs.
La décision de go conserve version, données, exclusions, résultats et signataires. Si une cohorte échoue, alors elle reste sur le legacy sans bloquer nécessairement les populations déjà prouvées.
Dans quel cas appliquer le shadow : moteur de remises
Un distributeur remplace un moteur de remises utilisé par plusieurs canaux. Les règles dépendent du client, du contrat, de la quantité, de la date et d’exceptions commerciales rarement déclenchées.
Comparer décisions puis effets comptables
Chaque demande de prix est dupliquée avec snapshot client et horloge. La cible calcule lignes, motifs et total, mais son port comptable enregistre seulement l’intention d’écriture.
Le comparateur classe différences de règle, précision, ordre et données manquantes. Les cas historiques de fin d’année complètent le trafic d’août pour couvrir des remises rétroactives.
Après deux cycles sans écart critique, un canal interne devient canari. Le rollback replace immédiatement la cohorte sur l’ancien moteur, tandis que les deux décisions restent réconciliables par trace_id.
Neutraliser les erreurs fréquentes du shadow traffic
Les erreurs majeures consistent à attendre la cible, envoyer des effets réels, comparer des états différents, ignorer trop de champs, mesurer une moyenne ou confondre shadow et canari.
Corriger la preuve avant la cible
Une divergence non reproductible ne démontre pas encore un bug applicatif. L’équipe vérifie d’abord corrélation, état, temps, dépendances et normalisation avant de modifier la règle métier.
Une autre erreur consiste à rejouer des données personnelles dans un environnement moins protégé. Le shadow reste production par son contenu, même si ses résultats ne servent aucun utilisateur.
À refuser enfin : un go fondé sur 99,9 % sans détail des 0,1 %. Une seule divergence peut porter paiement, autorisation ou clôture critique.
Plan d’action : passer du miroir au canari en huit semaines
Le plan cible une capacité, construit la preuve puis ouvre une cohorte réelle. Chaque étape possède entrée, sortie, owner, seuil, monitoring, dépendance et rollback.
Semaines 1 et 2 : cadrer et isoler
Définissez hypothèses, cohortes, effets, données et seuils avec leurs responsables. Introduisez ports contrôlables, credentials sans écriture, horloge injectée et identifiant de corrélation propagé dans chaque dépendance.
La sortie comprend menace, matrice d’effets, vingt scénarios, baseline et test d’egress reproductible. Toute dépendance non neutralisée bloque le trafic réel jusqu’à une isolation technique démontrée.
Semaines 3 à 5 : dupliquer et comparer
Déployez le tee asynchrone, alignez l’état, capturez les intentions puis construisez les comparateurs sémantiques. Classez chaque écart avec owner, sévérité, cohorte et preuve complète de reproduction.
Le dashboard suit couverture, comparabilité, sévérité, latence et coût par cohorte. Le runbook décrit rejeu, coupure, restauration et rollback sans dépendre de l’auteur du composant comparé.
Semaines 6 à 8 : prouver et ouvrir
Complétez le trafic avec historiques et bords, tenez un cycle métier, puis gelez exclusions et versions. Exercez le rollback et ouvrez un canari réversible.
La porte finale exige zéro effet shadow, couverture suffisante, écarts critiques nuls, support autonome et retrait planifié de l’ancienne voie après validation du canari.
- D’abord, définir la décision comparée et neutraliser chaque effet externe de la cible avec une défense réseau.
- Ensuite, aligner entrée, état, temps et dépendances sous une corrélation stable, traçable puis rejouable.
- Puis, comparer sémantiquement par scénario et expliquer chaque exclusion ou divergence restante avant le canari.
- À faire enfin : ouvrir un canari réversible, exercer le rollback puis retirer l’ancienne voie sur preuve.
Guides complémentaires de migration applicative
Le shadow traffic intervient après l’identification d’une couture exploitable et avant l’ouverture progressive d’une cible qui devra finalement remplacer puis permettre de retirer l’ancienne voie.
Trouver la frontière et la trajectoire
La méthode des coutures d’une application legacy choisit une frontière réversible et testable. La refonte applicative sans interruption organise strangler, double run, canari et rollback.
Si l’ancienne et la nouvelle écriture doivent coexister, le dual write réconcilié complète le trafic miroir : il rend les écarts d’état observables, attribue une autorité et prépare la sortie progressive d’un des deux chemins.
Le shadow fournit la preuve différentielle entre ces deux étapes. Il ne remplace ni le choix de frontière ni le décommissionnement qui démontre l’autonomie finale.
Protéger données et décision de go
Le budget d’une reprise de données couvre volumétrie, mapping, rejets et recette. Le no-go applicatif formalise ensuite les critères qui imposent de différer une ouverture.
- À prioriser : les capacités déterministes, à forte valeur, dont les effets peuvent être capturés derrière des ports contrôlables.
- À différer : les parcours dont données, horloge ou dépendances ne peuvent pas encore être alignées entre legacy et cible.
- À refuser : tout shadow qui attend la cible, conserve des credentials d’écriture ou masque une cohorte entière sous une règle d’ignore.
Conclusion : basculer sur une preuve comparable
Le shadow traffic utile ne mesure pas seulement deux réponses finales. Il reconstruit deux exécutions comparables, neutralise les effets et explique chaque décision différente jusqu’à sa première cause.
La corrélation protège la preuve, les ports protègent la production et le comparateur protège la sémantique. Les cohortes empêchent ensuite une moyenne de masquer les cas critiques.
La migration progresse lorsque le shadow autorise un canari réversible, puis que le canari autorise le retrait mesuré d’une voie historique devenue inutile et coûteuse à maintenir.
Pour construire cette trajectoire, l’expertise Dawap en développement d’applications métier vous accompagne du premier trafic miroir jusqu’à une bascule mesurée, opérable et réellement réversible.
