Plan de migration : les quatre lignes que tout le monde oublie

Le plan comptait trente-quatre tâches, charge affectée, dépendances tracées et chemin critique surligné en rouge. Il avait été relu par trois personnes et validé par le comité de pilotage. Une ligne disait : « Nettoyage des données : 3 semaines, équipe migration ».

Cette ligne était fausse d’une manière qu’aucune relecture n’aurait attrapée. Le nettoyage n’était pas trois semaines de travail pour l’équipe migration. C’était onze semaines de décisions prises par quatre bureaux d’études de site à qui personne n’avait dit qu’ils étaient sur le projet, portant sur 9 000 articles en doublon où aucune règle ne pouvait désigner un gagnant. L’équipe migration pouvait préparer les décisions, les acheminer et les consigner. Elle ne pouvait pas les prendre.

Le plan n’était pas incomplet. Il était complet sur les mauvais sujets.

Ce que tous les plans contiennent

Ouvrez n’importe quel plan de migration de données et vous trouverez le même squelette : extraction, mapping, règles de transformation, chargement, tests, bascule, hypercare. Une durée sur chacun. C’est une description raisonnable du travail, et c’est la partie que les logiciels de planification savent traiter.

Ces tâches ont leurs propres incertitudes : performances à volume réel, limites de la cible, dépendances techniques. Elles ont au moins une case où inscrire une mesure et une marge. D’autres travaux, pourtant décisifs, restent souvent noyés dans une ligne de nettoyage ou de tests.

Voici quatre lignes à rendre visibles pour que la date repose sur autre chose que les seules durées techniques.

1. Le temps d’arbitrage, qui n’est pas du temps de développement

À la fin de l’audit de données, vous pouvez estimer quelle part des enregistrements passe sur une règle déterministe validée, et quelle part exige qu’un humain tranche. Prenons, pour le calcul, une répartition de 95 / 5 sur un périmètre donné.

Les 95 % relèvent de l’ingénierie. L’effort peut être estimé et réparti lorsque les tâches sont parallélisables. Ajouter des personnes n’accélère toutefois ni une dépendance bloquée ni une cible déjà à sa limite de débit.

Les 5 % sont d’une autre nature. Chacun de ces cas a besoin de quelqu’un qui ait autorité pour dire quelle valeur est la bonne, et ce quelqu’un est un professionnel du métier qui a déjà un poste à plein temps. Il peut ne disposer que de quelques heures par semaine. Les ingénieurs peuvent préparer les dossiers, mais ils ne remplacent pas cette autorité. Sans capacité métier réservée, la file d’arbitrage peut devenir le chemin critique.

Inscrivez-la au plan comme un chantier à part entière, avec trois choses attachées :

• Un volume, en décisions, pas en enregistrements. Dix mille doublons regroupés en 900 lots de décision font une file de 900 éléments, et c’est ce nombre-là qui compte.
• Un responsable nommé par famille de données, côté métier, avec l’autorité pour trancher. Pas un comité. Une migration bloquée sur des arbitrages est bloquée sur l’organigramme, pas sur la technique.
• Une cadence, en décisions par semaine, convenue avec ces personnes avant que la date soit engagée. Dans cet exemple de calcul, distinct du cas présenté en ouverture, les quatre équipes traitent ensemble 80 décisions par semaine. La file de 900 éléments demande donc 900 / 80 = 11,25 semaines : elle se termine pendant la douzième semaine, à cadence constante et sans nouveaux cas. La répartition entre équipes et les absences peuvent encore allonger ce délai.

Le mode de défaillance est subtil. Personne ne refuse de faire les arbitrages. Ils les font simplement à la vitesse d’une tâche secondaire, qui est la vitesse que le plan n’a jamais supposée.

2. La fenêtre de delta

Tous les plans contiennent le mot « gel ». Très peu expliquent ce qui se passe de part et d’autre.

La donnée source continue de vivre jusqu’à l’arrêt de ses écritures. Le delta couvre les créations, modifications et suppressions depuis le dernier point de données effectivement couvert par l’extraction, jusqu’au gel. Ce point doit être matérialisé par un repère cohérent, comme une position de journal ou un marqueur d’extraction ; ce n’est pas simplement l’heure de fin du dernier chargement. Un delta manqué peut laisser un article absent, un fournisseur obsolète ou une commande encore ouverte dans la cible.

Votre plan doit répondre explicitement à quatre questions :

• Quand la source gèle-t-elle, et pour combien de temps ? « Le week-end » n’est pas une réponse si trois usines sont sur des fuseaux horaires différents.
• Quelle interruption des écritures le métier peut-il tolérer ? La capture continue peut réduire la fenêtre, mais il reste à organiser le transfert de l’autorité d’écriture. Si la fenêtre mesurée ne tient pas, il faut revoir le dispositif et la stratégie de bascule avant le dry run.
• Comment couvre-t-on les changements du dernier point extrait jusqu’au gel ? Par journal de modifications, horodatage fiable ou ré-extraction cohérente et comparaison. Un horodatage porté par les lignes restantes ne révèle pas les suppressions physiques ; il faut un mécanisme qui les conserve ou les détecte. Microsoft distingue ainsi la copie par marqueur de la capture des créations, modifications et suppressions.
• Qui applique le delta final et le réconcilie, et pour quand ? Il faut un responsable, une échéance et une preuve que toutes les modifications jusqu’au repère de gel ont été traitées ou placées dans une liste d’exceptions explicitement acceptée. Toute écriture exceptionnellement autorisée après le gel doit être tracée et réconciliée séparément avant la validation finale.

Le delta peut réutiliser les mêmes règles métier que le chargement initial, dans une chaîne batch ou asynchrone. Il exige en plus une capture complète des changements, l’ordre des mises à jour et des dépendances, le traitement des suppressions et un rejeu idempotent. Un statut par enregistrement aide à suivre le résultat ; il ne suffit pas à détecter le delta. Ces capacités de reprise ciblée se préparent et se testent avant la bascule.

3. La décision de rollback

Demandez à n’importe quel directeur de programme ce qui déclenche un rollback et vous obtiendrez une variante de « si ça se passe mal, on revient en arrière ». Ce n’est pas une règle de décision. C’est une intention, et à 4 h du matin, avec un chargement partiel et un métier qui attend, une intention produit de la paralysie.

La règle de décision de rollback doit au minimum préciser trois éléments :

• Une personne, nommée, qui prend la décision, plus un suppléant nommé. Joignable, réveillée, et avec l’autorité pour trancher contre l’avis de la salle.
• Un seuil, mesurable et validé pour le périmètre. Pas « trop d’erreurs ». Par exemple : plus de 2 % d’articles rejetés après replay, ou tout rejet dans la famille des commandes ouvertes. Ces seuils illustrent une règle à faire accepter, pas une tolérance universelle.
• Une heure, sur l’horloge. « Si nous n’avons pas atteint le point de go/no-go à 5 h 00, nous revenons en arrière » est une décision qui se prend calmement le mardi et s’exécute mécaniquement le dimanche.

Cette règle évite de découvrir à 4 h du matin qui peut arrêter la bascule. Elle doit renvoyer à une procédure de retour testée et chronométrée. L’heure limite tient compte du temps nécessaire pour restaurer le service. Après des écritures dans la cible, il faut aussi décider comment les préserver ou les réconcilier ; AWS distingue explicitement ce cas d’un retour sans nouvelles données.

4. Les itérations ciblées et les répétitions complètes

Si l’on me confiait un plan à relire, je chercherais les deux types d’exécution, leurs objectifs et le temps réservé aux corrections.

Les boucles Run / Fix peuvent commencer sur un périmètre fonctionnel dès que ses règles sont disponibles. Elles servent à résoudre les rejets et à vérifier les corrections avec leurs dépendances. Les répétitions complètes viennent ensuite éprouver toute la chaîne à volume réel : chargement initial, delta final, contrôles métier et durée de bascule. Elles demandent des créneaux, des environnements et des interlocuteurs réservés.

Il n’existe pas de seuil universel de vingt ou trente passes. Deux ou trois répétitions complètes peuvent suffire sur un périmètre déjà qualifié par de nombreuses itérations ciblées ; elles peuvent aussi laisser des risques majeurs ouverts. Le critère est la couverture obtenue, la stabilité des résultats, la capacité à tenir la fenêtre et les anomalies restantes. C’est ce que détaille ce qu’un test réussi prouve vraiment.

Mesurez la durée d’une répétition complète et de sa correction pour vérifier ce qui tient réellement au calendrier. Une reprise ciblée réduit le coût des itérations intermédiaires, mais ne remplace pas la répétition du parcours complet. Si le plan ne laisse pas de créneau pour corriger puis revérifier un défaut découvert tard, il manque une marge concrète.

Le plan s’écrit après l’audit, ou il est provisoire

Une date engagée avant l’audit est une date engagée sur un périmètre non mesuré. Ce n’est pas un plan, c’est un espoir entouré d’un diagramme de Gantt.

C’est inconfortable, parce que les programmes veulent une date tôt et que l’audit se situe au début, au moment où personne n’a envie de passer trois semaines à mesurer. Le compromis praticable consiste à le dire à voix haute : publiez un plan provisoire avec les phases et les dépendances, marquez chaque durée comme non qualifiée, et n’engagez les dates qu’une fois que l’audit a rendu les volumétries, les taux d’anomalies et la taille de la file d’arbitrage. Un plan qui dit « onze semaines d’arbitrage, mesurées » survit à un comité de pilotage. Un plan qui dit « trois semaines de nettoyage, supposées » survit jusqu’au premier chargement réel.

Le plan et la checklist ne sont pas le même document

La distinction mérite d’être posée, parce qu’on les confond. La checklist est ce que vous vérifiez : extraction complète, doublons dénombrés, périmètre de l’historique tranché, seuil de rollback défini. Le guide de la migration de données ERP recense les pièges à passer en revue sur votre périmètre avant tout engagement.

Le plan est ce que vous séquencez : qui fait quoi, dans quel ordre, avec quelle durée et quelle dépendance. Un point de checklist comme « réserver du temps d’arbitrage côté métier » devient, dans le plan, un chantier nommé avec un volume, un responsable et une cadence hebdomadaire.

Passer la checklist vous dit si votre plan oublie quelque chose. Elle n’écrit pas le plan. L’ordre est : audit, puis checklist, puis plan, puis dates. Les programmes qui font audit, plan, dates, checklist découvrent au quatrième mois que la checklist aurait déplacé la date, et à ce stade la date est un engagement plutôt qu’une estimation.

L’enchaînement complet des cinq phases dans lequel tout cela s’inscrit est sur notre page méthodologie.

Ces quatre lignes demandent des mesures sur les données réelles, des capacités confirmées par les équipes et des décisions métier explicites. L’audit de préparation établit les premières mesures ; les essais et les répétitions qualifient ensuite les durées et le dispositif de bascule.