ARCHITECTURE
Valider une migration de données repose sur une double exécution encadrée : l'ancien système et la nouvelle plateforme traitent les mêmes données en parallèle, des contrôles automatisés comparent volumes, totaux, valeurs distinctes, indicateurs métier et délais, chaque écart est expliqué, puis la bascule est décidée lorsque des critères écrits à l'avance sont atteints.
Les données sont chargées, les traitements tournent sur la nouvelle plateforme, les tableaux de bord affichent des chiffres. Une question bloque pourtant le projet pendant des semaines : peut-on couper l'ancien système et demander aux utilisateurs de ne plus regarder que les nouveaux chiffres ?
Beaucoup d'équipes répondent à cette question par une recette ponctuelle. Quelques requêtes vérifient que le nombre de lignes correspond, un utilisateur clé compare deux ou trois rapports sur un mois donné, et la bascule est programmée. Une recette de ce type prouve que les données sont arrivées, elle ne prouve pas qu'elles sont justes. Les écarts qui comptent apparaissent rarement sur un échantillon : ils surgissent à la clôture mensuelle, sur un segment de clientèle particulier, ou le jour où une source envoie un fichier incomplet.
À l'opposé, certaines organisations font tourner les deux environnements en parallèle sans cadre précis. Chaque nouvel écart relance la discussion, personne ne se sent en position de déclarer la confiance suffisante, et les coûts des deux systèmes s'additionnent pendant des mois.
Entre la validation trop rapide et la comparaison sans fin, la double exécution peut devenir une période courte, outillée et conclue par une décision. Cela suppose de savoir exactement quoi comparer, de confier la comparaison à des contrôles automatisés plutôt qu'à des exports manuels, d'écrire les seuils de tolérance avant de constater les écarts, et de désigner la personne qui tranche.
La double exécution d'une migration de données désigne la période pendant laquelle l'ancien système et la nouvelle plateforme reçoivent les mêmes sources et produisent leurs résultats en parallèle, dans les conditions réelles de production. La différence avec un test réside dans ce réalisme : vrais volumes, vrai calendrier, aucune donnée sélectionnée.
Pendant toute la double exécution, un seul des deux systèmes fait foi pour les décisions de l'entreprise. Le plus souvent, l'ancien système reste la référence officielle : les rapports diffusés et les indicateurs présentés en comité continuent d'en sortir.
Cette règle paraît évidente, mais elle doit être formulée et communiquée. Sans elle, certains utilisateurs adoptent la nouvelle plateforme avant qu'elle soit validée, d'autres restent sur l'ancienne, et deux versions d'un même chiffre circulent dans l'entreprise. La double exécution n'est sereine que si chacun sait quel chiffre est officiel.
La double exécution démontre que la nouvelle plateforme produit les mêmes résultats que l'ancien système, ou des résultats différents pour des raisons connues et acceptées. Elle démontre aussi que les traitements tiennent dans la durée, cycle après cycle, avec les aléas habituels des sources : retards, fichiers vides, corrections rétroactives.
La double exécution ne démontre pas que les résultats de l'ancien système étaient justes : une règle de calcul erronée depuis des années, fidèlement migrée, produira une parfaite concordance. La comparaison ne démontre pas non plus que la nouvelle plateforme répond aux nouveaux usages, puisqu'une fonctionnalité absente de l'ancien système ne peut pas être comparée. Ces deux limites justifient une recette fonctionnelle menée par les utilisateurs, en complément de la comparaison automatisée.
La qualité d'une validation dépend d'abord du choix des comparaisons. Tout comparer, champ par champ, produit une masse d'écarts impossible à analyser ; comparer trop peu laisse passer des erreurs que les utilisateurs découvriront après la bascule. Une démarche efficace empile plusieurs niveaux de contrôle, du plus grossier au plus fin.
Le contrôle des volumes compare le nombre de lignes par table, par période de chargement et par source. C'est le contrôle le plus simple à mettre en place et celui qui détecte le plus vite les pertes massives : un filtre mal transposé, une jointure qui exclut une partie des enregistrements, un fichier source non chargé. Un écart de volume ne dit pas où se trouve l'erreur, mais il indique avec certitude qu'une erreur existe.
Le contrôle des totaux complète celui des volumes. Il porte sur les grandeurs additives qui structurent l'activité : montants facturés, quantités livrées, heures travaillées, effectifs. Ces totaux sont calculés par grande catégorie (entité juridique, mois, famille de produits) afin de localiser rapidement un écart. Deux tables peuvent avoir exactement le même nombre de lignes et des totaux différents : c'est typiquement le cas lorsqu'une conversion de type tronque des décimales ou lorsqu'un signe est inversé sur les avoirs.
Le contrôle des valeurs distinctes compte le nombre de clients, de produits, de contrats ou de sites présents dans chaque environnement. Il révèle des anomalies que les volumes et les totaux masquent. Un enregistrement dupliqué et un enregistrement perdu se compensent dans un comptage de lignes ; ils apparaissent immédiatement dans une comparaison des identifiants.
Pour les tables de référence les plus sensibles, la comparaison descend au niveau des clés elles-mêmes, ce qui permet de produire trois listes exploitables :
Ces listes transforment une alerte abstraite (« il manque 412 clients ») en identifiants que l'équipe peut examiner un par un.
Les indicateurs métier constituent le niveau de contrôle le plus proche des usages : chiffre d'affaires, marge, taux de service. Une migration peut être irréprochable sur les tables détaillées et produire un indicateur différent, parce qu'une règle de calcul a été réécrite dans l'outil de restitution ou qu'un filtre implicite de l'ancien rapport n'a pas été repris.
La liste des indicateurs à comparer se construit avec le responsable métier. Elle se limite aux indicateurs réellement utilisés, avec leur définition précise et leur maille de calcul. Lorsque cette définition n'existe pas par écrit, la double exécution oblige à l'établir, ce qui rejoint le travail décrit dans l'article sur le référentiel d'indicateurs. Chaque KPI comparé est calculé période par période, et pas seulement sur le cumul, car des écarts mensuels de sens opposé peuvent s'annuler sur l'année.
Une nouvelle plateforme qui produit des chiffres justes à onze heures, alors que l'ancien système les livrait à sept heures, ne rend pas le même service. Le délai de mise à disposition fait partie des engagements implicites pris auprès des métiers, et il doit être comparé au même titre que les valeurs.
Le contrôle porte sur l'heure de fin de chaque chaîne de traitement et sur sa régularité. Une chaîne qui exige une intervention manuelle une fois par semaine n'est pas prête pour la production, même si ses résultats sont exacts.
La réconciliation manuelle, à partir d'exports comparés dans un tableur, fonctionne pendant quelques jours, puis se dégrade à mesure que les périodes à comparer s'allongent. Une réconciliation qui n'est pas automatisée finit toujours par être faite moins souvent, puis plus du tout. L'automatisation est donc une condition de fiabilité, pas seulement un gain de temps.
Les contrôles de migration s'exécutent à chaque cycle de traitement, juste après la fin des chargements dans les deux environnements. Ils sont intégrés à l'orchestration du pipeline de données, de sorte qu'un cycle n'est considéré comme terminé qu'une fois la comparaison effectuée et son résultat enregistré.
La principale difficulté technique tient à la synchronisation des deux systèmes. Si l'ancien système charge les données à deux heures et la nouvelle plateforme à quatre heures, les sources ont pu évoluer entre-temps, et la comparaison détecte des écarts qui n'ont rien à voir avec la migration. Plusieurs règles limitent ces faux écarts :
L'outillage importe moins que la discipline. Des requêtes planifiées dans l'orchestrateur existant suffisent dans la plupart des cas ; des outils spécialisés dans le contrôle d'intégrité, comme ceux présentés dans l'article sur KNIME et l'intégrité des données, facilitent la comparaison de sources hétérogènes.
Le résultat brut d'une comparaison automatisée est une table technique, indispensable à l'équipe data mais illisible pour le responsable métier. Un rapport d'écarts utile traduit ces résultats dans les termes de l'activité.
Ce rapport présente, pour chaque cycle, les contrôles réussis et les contrôles en échec, l'écart exprimé en valeur et en pourcentage, le seuil de tolérance applicable et le statut de l'explication (en cours d'analyse, expliqué, corrigé, accepté). L'historique des cycles précédents montre la tendance : une plateforme dont les écarts diminuent cycle après cycle inspire une confiance que ne donne pas un seul cycle parfait.
Les contrôles écrits pour la double exécution ne disparaissent pas avec l'ancien système. Une partie d'entre eux se transforme en contrôles de qualité permanents : cohérence des volumes d'un jour à l'autre, totaux rapprochés d'une source de référence, nombre de valeurs distinctes surveillé dans le temps.
Cette réutilisation fournit une base concrète pour choisir les indicateurs de qualité à suivre, une question développée dans l'article Que faut-il réellement mesurer pour piloter la qualité des données ?
Les seuils de tolérance et les critères de bascule se fixent avant le premier cycle de comparaison. Fixés après, ils sont inévitablement influencés par les écarts déjà constatés : un seuil est relevé parce qu'un écart persiste, un critère est assoupli parce que l'échéance approche. Un critère de bascule écrit après avoir vu les résultats n'est plus un critère, c'est une justification.
Un seuil global, du type « moins de 1 % d'écart », n'a pas de sens opérationnel : négligeable sur un nombre de visites, le même écart est inacceptable sur le montant des factures émises. Le seuil se fixe donc indicateur par indicateur, selon les conséquences d'une erreur.
Plusieurs familles de seuils coexistent généralement dans un même document :
Chaque seuil s'accompagne de sa justification. Lorsqu'un seuil est contesté pendant la double exécution, cette justification permet de revenir à la raison initiale plutôt que de négocier au cas par cas.
Le document de critères de bascule est court, signé par le responsable métier et par le responsable de l'équipe data, et rédigé avant le démarrage de la comparaison. Son contenu tient en quelques rubriques :
Le document de critères doit rendre la décision vérifiable par un tiers : à sa lecture et à celle du rapport d'écarts, une personne extérieure au projet doit pouvoir dire si les critères sont atteints.
Un cycle parfait ne suffit pas à valider une migration, car certaines anomalies n'apparaissent qu'avec certains volumes ou certaines configurations de données. Exiger plusieurs cycles consécutifs sans écart hors seuil garantit que la concordance est stable.
Le nombre de cycles dépend de la fréquence des traitements. Pour un chargement quotidien, une à deux semaines de cycles consécutifs réussis donnent généralement une confiance suffisante. Pour un traitement mensuel, chaque cycle compte davantage, et la double exécution doit couvrir au moins deux ou trois occurrences. Un écart hors seuil remet le compteur à zéro, sauf si l'écart est expliqué par une cause extérieure à la migration et accepté comme tel.
Le traitement des écarts constitue le cœur du travail de double exécution. Chaque écart déclenche le même enchaînement : la comparaison le détecte, l'équipe data en recherche la cause, l'écart est corrigé ou validé comme justifié, puis la comparaison est relancée sur le cycle suivant. Cette boucle se répète jusqu'à ce que les critères de bascule soient atteints, et c'est seulement à ce moment que la bascule devient possible.
Face à un écart, la première question est simple : lequel des deux systèmes produit le bon résultat ? La réponse n'est pas toujours celle que l'on attend. Une partie des écarts révèle une erreur introduite par la migration : règle mal transposée, conversion de format, filtre oublié. Ces écarts se corrigent dans la nouvelle plateforme et ne demandent pas d'arbitrage particulier.
Une autre partie des écarts révèle un défaut de l'ancien système, resté invisible faute de point de comparaison. Une règle de gestion appliquée différemment selon les sources, une table de correspondance figée depuis plusieurs années, un traitement qui ignorait les lignes mal formées sans le signaler : la nouvelle plateforme, construite proprement, produit alors un résultat différent et plus juste. Ces défauts relèvent souvent des causes structurelles de mauvaise qualité que l'on retrouve dans la plupart des systèmes d'information.
Pour faire le tri, l'équipe data remonte à la donnée source et recalcule le résultat attendu à la main, sur quelques enregistrements concernés. Ce recalcul indépendant tranche la question sans s'en remettre à l'un ou l'autre système. Le résultat de l'analyse est consigné, avec la cause identifiée et la décision proposée.
Lorsqu'un écart révèle un défaut ancien, deux options existent : reproduire le défaut dans la nouvelle plateforme pour obtenir des chiffres identiques, ou conserver le résultat corrigé et expliquer aux utilisateurs pourquoi les chiffres changent.
La correction est presque toujours préférable, mais elle a des conséquences qui dépassent l'équipe data. Un indicateur corrigé peut modifier un historique présenté en comité, une base de calcul de primes ou une donnée déjà transmise à l'extérieur. La décision appartient donc au responsable métier, pas à l'équipe technique. Lorsqu'il choisit la correction, l'écart est classé comme expliqué et accepté, et la communication aux utilisateurs est préparée avant la bascule, pas après.
La reproduction volontaire d'un défaut reste possible dans des cas précis, par exemple lorsqu'une série doit rester comparable jusqu'à la fin d'un exercice. Elle doit alors être documentée, datée et assortie d'une échéance de correction, faute de quoi le défaut s'installe durablement dans la nouvelle plateforme.
Certains écarts n'ont aucune cause fonctionnelle. Ils proviennent d'un décalage d'horaire entre les chargements, d'une source corrigée entre deux extractions ou d'une entité ajoutée dans un environnement et pas encore dans l'autre. Ces écarts de calendrier sont sortis rapidement de l'analyse, sans être ignorés pour autant : un décalage récurrent peut masquer un véritable écart de traitement.
Les écarts rencontrés se répartissent en quelques familles, qui se distinguent par leur cause habituelle, par l'action qu'ils appellent et par la personne qui tranche. Les classer dès leur détection accélère l'analyse et oriente la décision vers le bon interlocuteur.
La recette de migration mobilise plusieurs acteurs, mais une seule personne signe la décision de bascule. Lorsque cette responsabilité n'est pas attribuée explicitement, la validation se dilue entre l'équipe technique, qui estime que les données sont conformes, et les métiers, qui attendent qu'on leur prouve que les chiffres sont justes.
Le responsable métier du périmètre migré est la personne qui connaît l'usage des données et qui répond de leur exactitude auprès de sa direction. Il valide la liste des indicateurs comparés et leurs seuils, arbitre les écarts qui révèlent un défaut ancien et prononce la bascule au vu du rapport d'écarts. Son rôle correspond à celui du data owner décrit dans la plupart des cadres de gouvernance.
Le responsable métier n'a pas besoin de comprendre le détail des traitements, mais il doit être disponible aux moments clés : rédaction des critères, revues d'écarts et décision finale. Indisponible, il allonge mécaniquement la double exécution, car aucun écart ne peut être accepté sans lui.
👉 À lire aussi : Data Owner, Data Steward, Data Custodian : le triptyque pour réussir sa gouvernance des données
L'équipe data exploite les contrôles de migration, analyse les écarts et corrige les erreurs introduites par la migration. Elle ne décide pas de l'acceptation d'un écart métier, mais garantit que chaque écart soumis à décision est documenté, chiffré et accompagné d'une cause.
Sur les périmètres importants, un data steward fait le lien entre les deux équipes : il traduit les écarts techniques en conséquences métier et prépare les arbitrages, ce qui évite de nombreux allers-retours.
Les contrôles automatisés vérifient les chiffres ; ils ne vérifient pas que les utilisateurs retrouvent leurs repères. Quelques utilisateurs clés, choisis parmi ceux qui consultent les données le plus souvent, testent la nouvelle plateforme sur leurs usages quotidiens : filtres habituels, exports, enchaînements de rapports, accès aux historiques.
Les retours des utilisateurs clés portent rarement sur l'exactitude des données : un libellé modifié, un tri différent, un filtre disparu. Les ignorer conduit les utilisateurs à revenir vers l'ancien système dès qu'il reste accessible.
La durée d'une double exécution ne se décrète pas en nombre de semaines. Elle découle de deux éléments : les cycles métier que la comparaison doit couvrir et le nombre de cycles consécutifs réussis exigé par les critères de bascule. Une durée fixée à l'avance sans référence à ces deux éléments est soit trop courte, soit inutilement longue.
Certains traitements ne s'exécutent qu'à des moments précis : clôture mensuelle, calcul trimestriel des commissions, inventaire annuel, déclaration périodique. Si le périmètre migré comprend de tels traitements, la double exécution doit en couvrir au moins une occurrence, faute de quoi une partie du périmètre bascule sans avoir été comparée.
Pour un périmètre alimenté chaque jour et sans traitement périodique particulier, quelques semaines suffisent généralement. Pour un périmètre qui comprend une clôture mensuelle, la double exécution couvre au moins une, et de préférence deux fins de mois. Les traitements annuels posent un problème particulier : attendre une année entière n'est pas raisonnable, et ils sont alors validés par un rejeu sur les données de l'exercice précédent, dans un environnement de recette.
Une double exécution qui se prolonge au-delà de ce que justifient les cycles métier coûte cher : deux environnements à exploiter et une équipe immobilisée sur la comparaison. Le dépassement de la durée prévue doit être traité comme un signal, pas comme une fatalité. Plusieurs symptômes permettent de le repérer tôt :
Chacun de ces signaux appelle une décision en comité de projet : reprendre l'analyse d'une règle, réduire le périmètre de la bascule, réaffirmer les critères initiaux ou désigner un arbitre. La pire réponse consiste à prolonger la comparaison sans rien changer à son organisation.
La double exécution se termine par une décision formelle, prise à une date connue et consignée par écrit. Cette décision porte sur deux points : la bascule elle-même, c'est-à-dire le moment où la nouvelle plateforme devient la référence, et les conditions dans lesquelles un retour à l'ancien système resterait possible.
Le comité de bascule réunit le responsable métier, le responsable de l'équipe data et, souvent, un représentant de l'exploitation. Il examine le rapport d'écarts, le registre et le document de critères. Si les critères sont atteints, la bascule est prononcée ; s'ils ne le sont pas, le comité fixe les corrections attendues et la date de la revue suivante.
Lorsque les critères ont été écrits avant la comparaison, le comité constate un résultat plutôt qu'il ne négocie une décision. Les discussions difficiles ont eu lieu plus tôt, au moment de fixer les seuils et d'arbitrer les écarts métier.
La décision de bascule s'accompagne d'une communication aux utilisateurs : date à partir de laquelle la nouvelle plateforme fait foi, écarts acceptés et leur explication, interlocuteur à contacter en cas de doute. Les utilisateurs qui découvrent un chiffre différent sans explication attribuent spontanément l'écart à la nouvelle plateforme, même lorsqu'elle corrige une erreur ancienne.
Le retour arrière consiste à rendre à l'ancien système son statut de référence si un problème grave apparaît après la bascule. Il suppose que l'ancien système reste alimenté, ou puisse l'être à nouveau rapidement.
Le document de critères précise trois éléments à ce sujet. Il définit d'abord les situations qui déclencheraient le retour arrière, par exemple un écart majeur sur un indicateur financier ou une indisponibilité prolongée de la plateforme. Il fixe ensuite la durée pendant laquelle ce retour reste possible, généralement un ou deux cycles métier après la bascule. Il désigne enfin la personne habilitée à le décider, qui est en principe la même que celle qui a prononcé la bascule.
Passé ce délai, l'ancien système cesse d'être une option de repli. Son alimentation peut être interrompue et son arrêt organisé selon le calendrier prévu dans le plan de migration, une étape traitée dans l'article Migrer ses données vers le cloud : par quoi commencer et que laisser en place ? au titre du séquencement des vagues.
Une double exécution réussie ne se reconnaît pas à l'absence d'écarts. Elle se reconnaît au fait que chaque écart a été détecté par un contrôle automatisé, rattaché à une cause et tranché par la bonne personne, avant une date de décision connue de tous. Les projets qui butent au moment de la bascule ont rarement un problème de technique ; ils ont presque toujours un problème de critères, de responsabilités ou de calendrier.
Trois éléments, réunis avant le premier cycle de comparaison, évitent la plupart de ces blocages : la liste des contrôles et de leurs seuils, signée par le responsable métier ; le registre des écarts, partagé avec l'équipe data ; la date du comité de bascule et les conditions du retour arrière. La double exécution devient alors une étape de projet avec un début, une fin et un livrable.
Le bénéfice dépasse le premier périmètre migré : les contrôles, les seuils et le registre des écarts servent de modèle aux vagues suivantes, qui basculent plus vite parce que la méthode est connue.
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
