Playbook du week-end cutover
À jour au 2026-10-04
Traiter le cutover comme une checklist de vol : un runbook heure par heure (tâche · responsable · durée · critère de succès · rollback), répété en dry-run complet. La réconciliation en est le cœur — tie-out formel des comptes de lignes + totaux de key figures nouveau-vs-legacy, avec tolérances convenues à l'avance avec la finance (GL variance zéro). Gates go/no-go avec décideurs nommés, décidés avant le week-end, pas sous pression. Un rollback réel et testé avec un point de non-retour explicite et signé. Rôles : cutover manager · leads techniques · validateurs métier · responsable comm. L'hypercare (2-4 semaines, legacy en lecture seule) suit, sortie par un gate. Un cutover propre réserve les trois missions suivantes.
Ce que vous apprendrez
- Travailler un scénario réaliste : Entreprise de logistique, bascule finance cœur + opérations vers BDC sur un week-end de 3 jours, go-live visible du conseil d'administration.
- Repérer et éviter l'anti-pattern : Aucun dry-run répété — Les timings d'étape sont faux ; le week-end dépasse et les jalons s'enchaînent en cascade.
- Appliquer la décision clé du module : Préparation du runbook — choisir Runbook heure par heure répété contre un environnement copié, pas La première exécution étant le week-end en direct.
- Mesurer la maîtrise avec le KPI : Dry-run complété (cible : ≥ 1 dry-run complet avant le go-live ; signal d'alerte : Le week-end réel est le premier run de bout en bout).
Aperçu du module
Le week-end de cutover, ce sont les quelques dizaines d'heures où des mois de travail de migration atterrissent proprement ou se défont en public. Un consultant senior le traite comme une checklist de vol : chaque tâche scriptée, chaque responsable nommé, chaque gate go/no-go pré-convenu, et un chemin de rollback qui fonctionne réellement. L'improvisation au cutover est la façon dont la confiance meurt.
Le runbook est le livrable. Bien avant le week-end, on écrit un runbook heure par heure : chaque tâche avec heure de début, durée, responsable, dépendance, critère de succès, et action de rollback explicite. Le runbook est répété lors d'au moins un dry-run complet contre un environnement de copie — le dry-run est l'endroit où l'on découvre l'étape qui prend 4 heures au lieu des 30 minutes supposées. Un cutover sans runbook répété est un pari, pas un plan.
Prérequis
- Expérience pratique intermédiaire sur des projets d'analytique SAP
- Revoir d'abord les concepts fondamentaux : C035, C033, C032
Acquis
- Travailler un scénario réaliste : Entreprise de logistique, bascule finance cœur + opérations vers BDC sur un week-end de 3 jours, go-live visible du conseil d'administration.
- Repérer et éviter l'anti-pattern : Aucun dry-run répété — Les timings d'étape sont faux ; le week-end dépasse et les jalons s'enchaînent en cascade.
- Appliquer la décision clé du module : Préparation du runbook — choisir Runbook heure par heure répété contre un environnement copié, pas La première exécution étant le week-end en direct.
- Mesurer la maîtrise avec le KPI : Dry-run complété (cible : ≥ 1 dry-run complet avant le go-live ; signal d'alerte : Le week-end réel est le premier run de bout en bout).
Module complet réservé aux abonnés. Le module complet ajoute : le cadre de décision · le cas guidé de bout en bout · la grille de KPI · les anti-patterns · les blocs de code · le contrôle de connaissances · les schémas.