IMPLEMENT : Transformer votre contrat ERP en réalité opérationnelle Vous venez de signer avec votre intégrateur, les contrats sont bouclés, le cahier des charges validé… et maintenant vous vous demandez comment gérer concrètement les 6 à 12 prochains mois ? Après avoir préparé et sélectionné votre solution durant les phases PREPARE et REQUEST de la méthode PRISM, vous entrez dans IMPLEMENT : la phase où votre projet passe du papier à la production. Dans cet article, découvrez pourquoi cette phase concentre 80% des risques d’échec et comment la structurer en 4 étapes pour arriver au go-live en position de force. 🎯 L’essentielIMPLEMENT transforme vos documents en système vivant : de la gouvernance activée au premier jour de production, en passant par la construction technique et la préparation opérationnelle4 sous-phases structurent cette transformation : Démarrage (4 semaines), Build (3-6 mois), Préparation go-live (parallèle au Build), et Go-Live (basculement + stabilisation)Cette phase concentre 80% des risques d’échec : dérive de périmètre, équipes sous-mobilisées, données polluées — autant de pièges qui se cristallisent dans ces 8 à 14 mois IMPLEMENT : le passage du contractuel à l’opérationnelVous avez un contrat signé. Un cahier des charges de 150 pages. Des processus cibles formalisés. Des matrices RACI sur PowerPoint. Mais maintenant vient le moment de vérité : transformer ces documents en projet vivant, puis en système fonctionnel, et enfin en outil utilisé quotidiennement par vos équipes.IMPLEMENT, c’est cette transformation complète. Elle débute le lendemain de la signature et se termine 4 à 8 semaines après le go-live, quand le système tourne en autonomie. Entre ces deux jalons : 6 à 12 mois qui vont déterminer si vous capturez 75% de votre ROI prévu ou seulement 25%.Les chiffres parlent d’eux-mêmes : entre 55% et 75% des projets ERP échouent à atteindre leurs objectifs initiaux. Le dépassement budgétaire moyen atteint 189%, et les délais s’allongent de 30%. Ces statistiques ne proviennent pas d’erreurs techniques tardives — elles trouvent leur origine dans la façon dont vous structurez et pilotez IMPLEMENT. Exemple En 2012, un groupe pharmaceutique européen démarre son projet SAP avec tous les bons ingrédients : budget validé (18M€), sponsor identifié, intégrateur tier-1. Mais aucune gouvernance opérationnelle n’est activée pendant le démarrage. Résultat : 6 mois plus tard, le périmètre a dérivé de 40%, et le projet sera abandonné après 32M€ investis. L’échec ne venait pas du logiciel, mais de l’absence de structure dès la semaine 1. Les 4 sous-phases d’IMPLEMENT : une progression logique 1. Démarrage (4 semaines) : activer la machine projetTransformer vos documents contractuels en organisation vivante — gouvernance opérationnelle, équipes réellement mobilisées, règles du jeu formalisées.Vous avez défini votre gouvernance pendant REQUEST. Le Démarrage, c’est la rendre vivante : calendrier verrouillé, sponsor visible et actif, Key Users libérés avec un plan de backfill effectif, périmètre gelé via un Change Control Board.Livrable clé : En fin de semaine 4, une gate review valide 9 critères. Si moins de 5 sont OK, c’est NO-GO — vous ne passez pas en Build. Attention : 70% des projets qui échouent présentent des signaux d’alerte dès la semaine 2 : sponsor absent, charte non signée, Key Users à moins de 30% de disponibilité. Build (3 à 6 mois) : du blueprint au système fonctionnelTransformer vos processus cibles en solution logicielle testée et validée.Le Build se déroule en deux temps. D’abord la conception détaillée (Design, 4-8 semaines) : vous traduisez vos processus en spécifications lors d’ateliers. Le livrable : un Blueprint qui servira de référence. Ensuite la construction (8-16 semaines) : configuration du système, développements sur mesure (RICEFW), tests progressifs, et reprise des données.Cette phase concentre 40-45% de l’effort total et le plus fort risque de dérapage. Chaque jour d’indécision coûte 3 jours de retard au go-live.N’oubliez pas : La reprise des données est VOTRE responsabilité. L’intégrateur fournit les scripts, mais c’est vous qui nettoyez et validez. Votre Data Quality Score doit dépasser 95%. « Garbage in, garbage out ».3. Préparation go-live (en parallèle du Build) : anticiper le basculementPréparer tous les éléments nécessaires au basculement avant le jour J, pour arriver en position de force.L’erreur la plus fréquente ? Penser qu’on commence à préparer le go-live une fois le Build terminé. En réalité, la préparation démarre pendant le Build — dès les 30% restants du projet.5 piliers : Complétude du Build (état des lieux lucide), rôles et accès (restrictif plutôt que permissif), formation utilisateurs (par les Key Users), cutover plan (feuille de route objet par objet), et plan de support (3 niveaux + ticketing).4. Go-Live (basculement + stabilisation 4-8 semaines) : le moment de véritéBasculer en production en confiance, gérer les premières semaines et stabiliser.Le Go-Live commence par une décision formelle : la réunion go/no-go réunit les sponsors et pose une seule question : « est-on prêt ? » On passe en revue ce qui est opérationnel et ce qui ne l’est pas encore. Un go-live peut démarrer avec des sujets en suspens — à condition que ce soit un choix assumé.Décision prise, on exécute le cutover plan : arrêt des flux, migration finale, bascule des interfaces, activation des batchs. Puis les premières semaines : qualifier les incidents, surveiller les volumes d’activité réelle, organiser des points réguliers. Mémo Entre 25% et 75% des organisations subissent une baisse de performance au go-live — le « Grand V ». La productivité peut chuter à 60-80% avant de remonter. C’est normal, prévisible, et ça se pilote. Timeline et répartition de l’effortDurée totale : 8 à 14 mois (signature → stabilisation)Répartition :Démarrage : 4 semaines (5% effort, 100% critique)Build : 3-6 mois (40-45% effort, phase la plus intensive)Préparation go-live : Débute aux 30% restants du Build (10-15% effort)Go-Live : Weekend + 4-8 semaines (15-20% effort)Moments de tension maximale : Semaine 4 du Démarrage (gate review), dernier tiers du Build (cumul construction + préparation), Go-Live + 2 premières semaines (pic d’incidents).Les 3 erreurs stratégiques à éviterErreur #1 : Confondre kick-off (2-3h) et Démarrage (4 semaines). Les projets qui investissent dans un démarrage structuré affichent 40% de réduction des dépassements budgétaires.Erreur #2 : Accepter la dérive de périmètre « juste une petite modification ». Le scope creep est responsable de 29% des retards.Erreur #3 : Reporter la préparation go-live après le Build. Cette approche garantit un go-live précipité et à haut risque. Et ensuite ? IMPLEMENT marque la fin de la construction et le début de l’exploitation. Une fois la stabilisation acquise, le projet entre en RUN : optimisation continue et exploitation durable.Plongez dans chaque sous-phase :📋 Démarrage : Les 3 piliers, le déroulé semaine par semaine, les signaux d’alerte🏗️ Build : De la conception au système, les RICEFW, la reprise des données🎯 Préparation go-live : Les 5 piliers, check-lists et critères de validation🚀 Go-Live : La décision go/no-go, le cutover, la courbe de stabilisation ArticlesDémarrage Activer la gouvernance projet Mobiliser les équipes projet Geler le périmètre projet Build Design Configuration & développements Intégration & interfaces Data & migration de données Tests Préparation go-live Évaluer la complétude du Build Valider les rôles et accès utilisateurs Construire le cutover plan Organiser la formation des utilisateurs Mettre en place le plan de support Préparer le rollback plan Go-Live Prendre la décision go/no-go Exécuter le cutover plan Piloter la stabilisation Réaliser la revue post go-live (REX)
