- Le respect de l’échéancier ne prouve pas que les opérations sont prêtes.
- Six vérifications documentées protègent les processus essentiels.
- Une autorisation sous conditions exige des écarts non bloquants, acceptés et suivis.
- La direction décide; l’intégrateur fournit les preuves de livraison.
Une date de mise en production n'est pas une preuve de préparation. Un projet peut afficher des voyants verts alors que les équipes ne peuvent pas encore expédier, facturer ou rapprocher les comptes dans le nouveau système. Pour donner le feu vert, la direction a besoin d'une décision documentée, pas d'une impression de confiance.
La décision d'autoriser ou de reporter la mise en production répond à une question précise : peut-on faire fonctionner les opérations critiques avec le risque résiduel que l'entreprise accepte? C'est une étape distincte du plan de bascule, qui explique comment exécuter le transfert vers la production.
Six preuves à exiger avant le feu vert
Préparez une pièce justificative consultable, un critère d'acceptation et un responsable pour chaque domaine. Adaptez les seuils à votre entreprise : cette matrice est un outil de décision, pas une règle universelle.
| Contrôle | Preuve exigée | Responsable | Signal de report |
|---|---|---|---|
| 1. Processus critiques | Essais de bout en bout réussis, y compris les exceptions : commande, expédition, facture, paiement, clôture. | Propriétaires des processus | Une opération essentielle n'a pas passé les essais. |
| 2. Données | Rapprochement des soldes, des stocks et des commandes ouvertes après une répétition de migration. | Finances et responsables des données | Écart important non expliqué ou non accepté. |
| 3. Interfaces et sécurité | Échanges réels, gestion des rejets, droits par rôle et contrôles d'accès vérifiés. | TI, sécurité et métiers | Flux critique défaillant ou accès inadéquat. |
| 4. Bascule et retour arrière | Répétition réussie, séquence, sauvegardes, responsables, fenêtre d'exécution et point de non-retour. | Direction de projet et responsables techniques | Retour arrière non viable ou répétition échouée. |
| 5. Équipes et soutien | Formation des rôles clés, procédures, contacts d'escalade et soutien intensif après le lancement. | Opérations et soutien | Une fonction essentielle n'a pas de soutien identifié. |
| 6. Approbation des risques | Écarts restants, impacts, contournements, dates de correction et approbation signée. | Promoteur et comité de direction | Risque bloquant sans décision autorisée. |
Ces domaines rejoignent le guide officiel Microsoft Dynamics 365 de préparation à la mise en production, qui couvre notamment les essais d'acceptation, les intégrations, les données, les dépendances externes et le soutien. Ce guide concerne Dynamics 365 : les exigences spécifiques à votre ERP et votre contexte doivent être validées séparément.
Autoriser, autoriser sous conditions ou reporter?
Autoriser : les preuves critiques sont acceptées
Les scénarios essentiels fonctionnent, les données sont rapprochées selon les seuils convenus, les interfaces et les accès sont validés, et la bascule a été répétée. La direction confirme la portée, consigne sa décision et précise la prochaine vérification.
Autoriser sous conditions : les écarts ne doivent pas bloquer les opérations
Un rapport secondaire peut être reporté si son impact est compris, qu'une solution temporaire a été testée et qu'une personne est responsable de la correction. Une anomalie de facturation critique ou un défaut de sécurité ne devient pas non bloquant parce que la date approche. La formule « on corrigera après » n'est pas un critère d'acceptation.
Reporter : reporter sans perdre le contrôle
Si un rapprochement important échoue, qu'un flux d'expédition ne fonctionne pas ou que le retour arrière n'a pas été sécurisé, la bonne décision peut être le report. Le comité doit alors écrire ce qui bloque, quelle preuve permettra de lever le blocage, qui la produira et quand la décision sera réexaminée.
Exemple : tout est vert, sauf la livraison réelle
Scénario illustratif, pas un cas client. Un distributeur prépare sa mise en production ERP dans trois établissements. Les essais de création de commandes sont réussis, les utilisateurs ont été formés et les fichiers clients ont migré. Or, une livraison partielle ne met pas correctement à jour l'inventaire dans le système d'entrepôt.
Le comité ne devrait pas calculer une moyenne de voyants verts. Il doit vérifier l'impact sur les expéditions et la facturation, faire corriger le flux, refaire un essai complet et accepter explicitement le risque restant. La performance du calendrier ne compense pas une opération critique défaillante.
Une fiche de décision d'une page pour la direction
- Décision et portée : quel environnement, quelles entités, quelles fonctions, à quelle date?
- Six résultats : test, seuil attendu, résultat réel, pièce justificative et signataire pour chaque domaine.
- Écarts ouverts : conséquences, gravité, responsable, mesure compensatoire et date limite.
- Point de non-retour : dernière fenêtre réaliste pour suspendre ou revenir en arrière.
- Décision formelle : Autoriser, conditionnel ou Reporter, avec approbation du promoteur.
Pour approfondir la conception des essais, consultez la stratégie de essais d'un progiciel. Pour la séquence de migration, la répétition et le retour arrière, consultez le plan de bascule ERP. Cette page est centrée sur la décision des dirigeants.
Pourquoi garder un avis indépendant côté client?
L'intégrateur exécute et présente les preuves selon son mandat. Il ne devrait pas, à lui seul, accepter les risques d'opérations ou de clôture financière de votre entreprise. PlanAxion accompagne la gouvernance d'une implantation ERP côté client, sans vendre de licences ni toucher de commission fournisseur. Le rôle est de clarifier les critères, les décisions et les responsabilités, pas de promettre une mise en service sans incident.
Votre mise en production approche et les statuts ne vous rassurent pas? Discutez des preuves à exiger avant d'autoriser la bascule.
Questions fréquentes
Qui autorise ou reporte la mise en production?
Le responsable autorisé par la gouvernance du programme, sur la base d'acceptations documentées des directions TI, finances, opérations et des autres propriétaires concernés. Cette approbation ne devrait pas être implicite.
Doit-on corriger tous les anomalies avant de lancer l'ERP?
Pas nécessairement. Les critères de sortie doivent distinguer les anomalies bloquantes des écarts secondaires. Chaque exception acceptée doit avoir une mesure, une personne responsable et une échéance.
Quelle différence entre la décision de mise en production et le plan de bascule?
Le plan de bascule détaille comment exécuter la mise en production. La décision d'autorisation établit si les preuves et les risques permettent de l'autoriser.
- Microsoft Learn : liste de préparation à la mise en production Dynamics 365, consultée le 10 novembre 2026.
- PlanAxion : plan de bascule ERP.
- Reddit r/Dynamics365 : questions sur les incidents après lancement, échanges qualitatifs d'avril 2026, non représentatifs d'un taux de défaillance.
