Le manuel de répétition du plan de bascule D365 Finance : les 2 répétitions qui sécurisent le go-live
Quand un go-live D365 déraille, ce n’est presque jamais « la techno ». C’est le manque de discipline du plan de bascule : rôles flous, timings absents, pas de plan de retour en arrière, aucune mesure de débit. Voici le playbook en deux répétitions qui évite ça.
Résultat : deux répétitions complètes avec timings mesurés, RACI clair, critères d’acceptation signés et plan de retour en arrière réellement testé.
Pourquoi les plans de bascule échouent (et comment l’éviter)
- Pas de propriétaire nommé par domaine → définir un RACI et des points de validation.
- Dérive sur l’historique → geler tôt via un registre des décisions.
- Une seule répétition symbolique → faire deux répétitions à volumes complets.
- Aucune métrique de débit → mesurer chaque étape (minutes, enreg./min, % erreurs).
Vue d’ensemble du playbook
- Répétition #1 (J-45 à J-30) : import à volumes complets, défauts connus tolérés ; objectif timings + goulots.
- Répétition #2 (J-14) : import complet avec critères go/no-go (qualité + durée). C’est votre répétition générale.
RACI du plan de bascule (rôles clés)
| Domaine / Étape | Propriétaire (A/R) | Support (C/I) | Validation |
|---|---|---|---|
| Gel des transactions (fenêtre de code freeze) | PMO (A) | IT Ops, Leads Métier (C) | PMO + Sponsor |
| Delta final des référentiels (Fournisseurs/Clients/Articles/Projets) | Propriétaires de domaine (A) | Équipe Data (R), Intégrateur (SI) (C) | Lead de domaine |
| Échéances ouvertes (AP/AR/Banque/Projets) | Propriétaires AP/AR/Projets (A) | Équipe Data (R) | Directeur Finance |
| Soldes d’ouverture GL | Contrôleur (A) | Équipe Data (R) | Contrôleur + Auditeur (si requis) |
| Bascule des rôles (sécurité) | Sécurité IT (A) | Intégrateur (C) | PMO |
| Tests de bon fonctionnement & validation | Propriétaires de processus (A) | Key Users (R), Intégrateur (C) | PMO + Sponsor |
(A = Accountable / garant, R = Responsable, C = Consulté, I = Informé)
Répétition #1 — timings & goulots
Objectif : établir les durées + débits et remonter les blocages.
Périmètre
- Volumes complets : référentiels (Fournisseurs, Clients, Articles, Projets), soldes d’ouverture, AP/AR/Banque ouverts, WIP Projets si applicable.
- Tests de bon fonctionnement « happy path » : profils de validation, saisie des dimensions, calcul de taxes, proposition de paiement, import du rapprochement bancaire.
À mesurer (minimum)
| Étape | Cible | Propriétaire | Réalisé | Notes |
|---|---|---|---|---|
| Début du gel des exports | 19:00 | PMO | ||
| Import du delta référentiels | 40 min | Équipe Data | Débit (enreg./min) | |
| Chargement AP/AR ouverts | 30 min | Propriétaires AP/AR | Erreurs ? | |
| Soldes d’ouverture GL | 20 min | Contrôleur | Équilibrage ? | |
| Bascule sécurité | 10 min | Sécurité IT | ||
| Tests de bon fonctionnement | 45 min | Propriétaires de processus | OK/KO |
Livrables : feuille de timings (1 page), liste de goulots avec propriétaires, cibles révisées.
Répétition #2 — critères go/no-go
Objectif : prouver que le plan de bascule est reproductible, dans le temps, et réversible.
Critères de réussite (exemples)
- Imports à ±10 % des cibles (après optimisations de la #1).
- Taux d’erreur ≤ 0,5 % (exceptions connues listées).
- Durée totale ≤ 6 h (fenêtre respectée).
- Plan de retour en arrière testé : un import échoue volontairement ; exécution du retour en arrière puis re-run en < 45 min.
Signatures requises
- AP, AR, GL, Projets valident les chiffres vs source.
- PMO signe le « livre du plan de bascule » (timings, propriétaires, points d’acceptation).
Salle de pilotage (war room) — minute par minute
- Canal unique (Teams/Slack) avec feuille de déroulé + registre des décisions épinglés.
- Maître du temps annonce début/fin de chaque étape ; publie les horodatages.
- Tableau Rouge/Orange/Vert (ROV) par stream ; seul le PMO peut changer le statut.
- Registre des décisions : Décision, Impact, Propriétaire, Heure, Chemin de retour.
Politique de retour en arrière (à tester vraiment)
- Définir des déclencheurs (erreur > X %, durée > cible + Y).
- Pour chaque étape, préciser le chemin de retour (suppression du lot, restauration sauvegarde, retour sécurité).
- Nommer un propriétaire du retour en arrière distinct du propriétaire de l’étape.
Pièges fréquents & correctifs
- « La data » en une seule ligne → découper par domaine et nommer un propriétaire.
- Historique qui gonfle → l’excédent va dans l’entrepôt de données, pas dans l’ERP.
- Sécurité sous-estimée → répéter la bascule des rôles et les validations.
- Pas d’horloge → nommer un maître du temps et afficher l’horloge dans le canal.
Mini-checklist (copier/coller)
- [ ] Propriétaires + RACI nommés et briefés
- [ ] Modèle de registre des décisions prêt
- [ ] Deux répétitions planifiées (J-45/J-30 et J-14)
- [ ] Feuille de timings + cibles de débit
- [ ] Plan de retour en arrière rédigé et testé
- [ ] Tests de bon fonctionnement définis + critères d’acceptation signés
