Le go-live est passé. Les équipes ont applaudi, les prestataires ont signé le PV de recette, et la direction a reçu un diaporama rassurant. Trois semaines plus tard, la comptable utilise encore son fichier Excel pour les rapprochements de facturation, les commerciaux saisissent leurs commandes deux fois, et le service informatique reçoit 40 tickets par jour.
Ce scénario n’est pas un échec d’implémentation. C’est un manque de pilotage post go-live. La mise en production n’est pas la fin d’un projet ERP — c’est le début de son utilisation réelle. Les 90 premiers jours déterminent si votre investissement ERP produit ses effets dans 12 mois, ou dans 3 ans.
Ce guide vous donne une méthodologie phásée et une checklist opérationnelle pour traverser cette période critique.
Pourquoi les 90 premiers jours sont le vrai test d’un projet ERP
La plupart des chefs de projet mesurent le succès d’un déploiement ERP à la date de go-live. C’est le mauvais indicateur. Ce qu’il faut mesurer, c’est l’adoption réelle par les utilisateurs trois mois après la mise en production.
La distinction entre “go-live réussi” et “ERP vraiment adopté” est fondamentale. Un go-live réussi signifie que le système est techniquement opérationnel, que les données ont été migrées, et que les utilisateurs ont été formés. Un ERP adopté signifie que les processus métier passent réellement par l’outil, que les données sont fiables, et que les équipes n’ont plus besoin de leurs anciens systèmes parallèles.
Entre les deux, il y a 90 jours de travail intensif.
La majorité des problèmes d’adoption se concentrent dans les 30 premiers jours : les utilisateurs découvrent l’écart entre la formation théorique et la réalité opérationnelle, les volumétries réelles révèlent des problèmes de performance non détectés en recette, et les cas d’usage atypiques — ceux qui n’ont pas été couverts dans les tests de recette — remontent massivement. C’est la période la plus risquée, et la moins bien encadrée dans la plupart des projets.
Phase 1 (J0-J30) : hypercare et gestion des incidents critiques
Définir la cellule hypercare avant le go-live
L’hypercare est la période de présence renforcée des consultants intégrateurs immédiatement après le go-live. Elle dure généralement 2 à 4 semaines. Son efficacité dépend entièrement de ce qui a été contractualisé avant la mise en production.
La cellule hypercare doit être définie avec précision dans votre contrat de TMA :
- Composition : nommez les personnes physiques, pas des rôles abstraits. “1 consultant fonctionnel senior disponible de 8h à 18h” est une clause opposable. “Un support disponible selon les besoins” ne l’est pas.
- Canaux d’escalade : définissez un circuit clair P1/P2/P3 avec des délais de réponse contractuels par niveau de criticité.
- Durée et conditions de sortie : la cellule hypercare ne se ferme pas parce que le calendrier l’indique, mais parce que des critères mesurables sont atteints (volume de tickets P1 inférieur à un seuil, taux de connexion quotidien supérieur à un pourcentage).
Sans cette contractualisation, l’intégrateur part au bout de deux semaines “comme prévu”, et vous vous retrouvez seul face à un flux de tickets que votre équipe interne ne peut pas absorber.
Les KPIs à surveiller quotidiennement en J1-J30
Pendant la phase hypercare, vous devez monitorer quatre catégories de métriques quotidiennement :
| KPI | Fréquence | Seuil d’alerte |
|---|---|---|
| Tickets P1 ouverts | Quotidien | > 3 simultanés |
| Tickets P2 non résolus > 48h | Quotidien | > 10 tickets |
| Taux de connexion utilisateurs par module | Quotidien | < 80 % de la cible |
| % de transactions passant hors ERP | Quotidien | > 15 % |
| Délai moyen de résolution P1 | Hebdomadaire | > 8h ouvrées |
| Satisfaction utilisateurs (sondage rapide) | Hebdomadaire | Note < 3/5 |
Le dernier indicateur — les transactions hors ERP — est le plus important et le plus difficile à mesurer. Il s’agit de détecter les utilisateurs qui continuent à traiter leurs opérations en dehors du système, soit par habitude, soit parce que l’ERP ne répond pas encore à leur besoin. Vous le détectez par rapprochement : si le volume de commandes dans l’ERP est inférieur de 20 % au volume réel, il y a une fuite quelque part.
Checklist J1-J7 : les 10 vérifications indispensables
Dans les sept premiers jours post go-live, validez systématiquement ces points :
- Accès utilisateurs : 100 % des comptes activés, mots de passe initiaux distribués, droits vérifiés par profil
- Performance système : temps de réponse des transactions clés mesurés et comparés aux SLA contractuels
- Interfaces actives : toutes les interfaces avec les systèmes tiers (banque, logistique, e-commerce) confirmées opérationnelles
- Sauvegarde et reprise : premier backup de production exécuté et restauration testée
- Données migrées : contrôle de cohérence sur les soldes comptables, le stock, les encours clients
- Circuit de validation : les workflows d’approbation (commandes, factures) sont opérationnels et testés par les managers
- Impression et EDI : les documents légaux (factures, bons de livraison) sont conformes aux exigences réglementaires
- Hotline interne : vos key users disposent d’un numéro dédié et d’un circuit de remontée clair
- Communication équipes : message de la direction rappelant le soutien au projet et les canaux d’aide disponibles
- Journal des incidents : un fichier centralisé (ou un outil de ticketing) est opérationnel pour tracer tous les problèmes remontés
Phase 2 (J31-J60) : stabilisation et montée en compétence
Détecter le shadow IT ERP avant qu’il devienne la norme
Le shadow IT ERP — terme désignant les pratiques parallèles que les utilisateurs développent pour contourner le nouveau système — est le signe le plus fiable d’un problème d’adoption. Il prend plusieurs formes :
- Des fichiers Excel partagés via Teams ou SharePoint qui “centralisent” des données normalement dans l’ERP
- Des tableaux de bord PowerBI branchés directement sur des extractions manuelles plutôt que sur les APIs de l’ERP
- Des validations par email sur des opérations qui devraient passer par les workflows de l’ERP
Pour les détecter, ne vous fiez pas aux remontées spontanées — les utilisateurs n’admettent pas facilement qu’ils contournent l’outil. Utilisez trois techniques :
Analyse des logs de connexion : si un module a un taux de connexion inférieur à 60 % des utilisateurs cibles à J45, le module a un problème d’adoption, pas juste d’apprentissage.
Rapprochements comptables non réconciliés : si les soldes comptables de l’ERP ne correspondent pas aux données bancaires sans intervention manuelle, des transactions passent encore hors système.
Entretiens individuels avec les key users : posez une question directe — “Avez-vous des processus que vous gérez encore en dehors de l’ERP ?” Les key users vous répondront honnêtement si vous leur garantissez que l’objectif est de corriger le problème, pas de les sanctionner.
Fermer l’hypercare de façon contractuelle
La fermeture de la phase hypercare doit être formalisée, pas tacitement acceptée. Avant de réduire la présence des consultants intégrateurs, validez que :
- Le volume de tickets P1 est stable depuis au moins 2 semaines sous votre seuil d’alerte
- Vos key users internes sont autonomes sur les cas d’usage standards
- Les procédures de support niveau 1 sont documentées et votre équipe peut les appliquer
- Le périmètre de la TMA post-hypercare est signé (voir notre guide sur la négociation des contrats TMA)
Ne laissez pas l’intégrateur “diminuer” progressivement sa présence sans formalisme. Chaque réduction de disponibilité doit être actée par écrit et conditionnée à des critères mesurables.
Corriger les paramétrages via un process allégé
La phase J31-J60 révèle systématiquement des besoins de corrections : un workflow trop rigide, une règle de calcul qui ne correspond pas à votre réalité opérationnelle, un état non disponible pour un usage fréquent. Ces corrections sont légitimes et attendues — aucune configuration ERP n’est parfaite au go-live.
Le risque est de les traiter de façon anarchique. Mettez en place un processus minimal :
- Formulaire de demande de correction : toute demande passe par un canal unique (email dédié ou outil de ticketing)
- Qualification hebdomadaire : les key users et le chef de projet qualifient ensemble les demandes — correctif, évolution ou formation manquante
- Prioritisation par impact métier : P1 (bloquant), P2 (gênant avec contournement), P3 (amélioration)
- Aucune modification en production sans validation : même les “petits” changements de paramétrage passent par un environnement de test et une validation formelle
Ce process allégé n’est pas de la bureaucratie. C’est ce qui vous permettra de retracer dans 18 mois pourquoi votre ERP se comporte différemment de sa configuration d’origine — et de répercuter ces corrections dans votre documentation.
Phase 3 (J61-J90) : optimisation et industrialisation
La première clôture mensuelle sous ERP : préparez le double du temps normal
La première clôture mensuelle post go-live est le moment de vérité pour vos équipes comptables et financières. Sans préparation, vous risquez une clôture qui prend deux fois plus de temps que prévu, dans un contexte où les équipes sont déjà épuisées.
Préparez cet événement une semaine en avance :
- Brief comptabilité : séance de travail dédiée pour revoir les nouvelles procédures de clôture dans l’ERP, identifier les étapes qui changent par rapport à l’ancien système
- Plan B documenté : si une fonctionnalité critique de clôture ne fonctionne pas comme prévu, quelle est la procédure de contournement ? Elle doit exister sur papier avant que le problème survienne
- Disponibilité consultant : contractualisez la présence d’un consultant fonctionnel sur la première clôture, même si l’hypercare est terminée
- Timeline allongée : communiquez à la direction que les délais de clôture du premier mois seront supérieurs à la normale — ne le découvrez pas le dernier jour du mois
Identifier 3 à 5 quick wins fonctionnels visibles
Entre J60 et J90, les équipes ont absorbé les chocs initiaux et commencent à stabiliser leurs pratiques. C’est le moment de montrer la valeur de l’ERP aux sceptiques internes.
Identifiez 3 à 5 améliorations rapides qui étaient impossibles avec l’ancien système et qui peuvent être livrées sans développement lourd :
- Un nouveau tableau de bord automatisé remplaçant un reporting Excel hebdomadaire
- Une alerte de stock automatique sur les références critiques
- Un état de relance client disponible en un clic
- Une validation de commande dématérialisée supprimant un échange d’emails
Ces quick wins servent à deux objectifs. D’abord, ils motivent les équipes qui se sont investies dans la transition et commençaient à douter du retour sur investissement. Ensuite, ils transforment les sceptiques en ambassadeurs — rien ne convainc mieux qu’une amélioration concrète sur leur propre poste de travail.
Préparer la revue de projet finale et le plan de vie ERP
À J90, organisez une revue de projet formelle avec les parties prenantes clés : direction générale, responsables métier, DSI, et intégrateur. Cette revue couvre :
- Bilan des 90 jours : incidents critiques rencontrés, décisions prises, écarts par rapport au plan initial
- Taux d’adoption réel par module : données factuelles sur l’utilisation, pas des estimations
- Périmètre fonctionnel livré vs prévu : ce qui est en production, ce qui a été reporté, et pourquoi
- Plan de vie ERP : les évolutions prioritaires pour les 12 prochains mois, le rythme des mises à jour, le gouvernance du changement
Ce dernier point est souvent négligé. Le plan de vie ERP formalisé dès la fin des 90 jours évite que l’ERP ne devienne un système figé dans sa configuration initiale, déconnecté des évolutions de votre entreprise.
Les 10 indicateurs à monitorer pendant 90 jours
| KPI | Fréquence | Responsable | Seuil d’alerte |
|---|---|---|---|
| Tickets P1 ouverts | Quotidien | Chef de projet | > 3 simultanés |
| Tickets P2 > 48h non résolus | Quotidien | DSI | > 10 tickets |
| Taux de connexion (% utilisateurs actifs) | Quotidien | DSI | < 80 % cible |
| % transactions hors ERP | Hebdomadaire | Key users | > 15 % |
| Satisfaction utilisateurs (note /5) | Hebdomadaire | Chef de projet | < 3/5 |
| Délai résolution P1 moyen | Hebdomadaire | Intégrateur | > 8h ouvrées |
| Demandes de correction qualifiées | Hebdomadaire | Chef de projet | > 20 non traitées |
| Rapprochements comptables écart | Mensuel | DAF | Tout écart > 1 % |
| Délai clôture mensuelle vs baseline | Mensuel | DAF | > 2× la baseline |
| NPS interne utilisateurs | J30, J60, J90 | Chef de projet | Score < 6/10 |
Les 5 erreurs les plus fréquentes en post go-live
1. Dissoudre l’équipe projet trop tôt
Le go-live signé, le chef de projet est rappelé sur d’autres missions et les key users retournent à leurs fonctions opérationnelles à 100 %. La phase post go-live n’a plus de pilote. Contre-mesure : maintenez un chef de projet dédié à au moins 50 % pendant les 60 premiers jours, et organisez des points hebdomadaires formels pendant 90 jours.
2. Ne pas contractualiser la sortie de l’hypercare
L’intégrateur part “comme prévu” sans que des critères d’exit aient été définis. Vous découvrez que votre équipe n’est pas prête. Contre-mesure : incluez dans le contrat de TMA des critères mesurables pour la fermeture de l’hypercare (voir la section ci-dessus).
3. Accepter les corrections “dans la prochaine version”
Les problèmes fonctionnels identifiés en J1-J30 sont régulièrement reportés à la “prochaine livraison” par l’intégrateur. Trois mois plus tard, rien n’a changé et les utilisateurs ont développé leurs propres contournements. Contre-mesure : exigez un plan de correction daté pour chaque anomalie qualifiée P1 et P2.
4. Négliger la communication vers les équipes non informatiques
Les équipes métier savent que l’ERP a été lancé, mais elles ne comprennent pas pourquoi certaines fonctionnalités ne sont pas encore disponibles et perçoivent les problèmes comme des défaillances définitives. Contre-mesure : envoyez une communication hebdomadaire simple (5 lignes, pas de jargon technique) indiquant l’état du système, les corrections en cours et les améliorations à venir.
5. Ne pas documenter les procédures au fil de l’eau
Les corrections de paramétrage et les nouvelles procédures métier ne sont pas documentées “parce qu’on n’a pas le temps”. Six mois plus tard, un collaborateur quitte l’entreprise et personne ne sait comment fonctionne tel processus. Contre-mesure : imposez une règle simple — toute correction validée est documentée dans les 48 heures, pas plus tard.
Template de reporting hebdomadaire pour le CODIR
Ce format en 5 métriques couvre l’essentiel sans noyer le comité de direction dans des détails opérationnels :
| # | Métrique | Valeur semaine N | Valeur semaine N-1 | Tendance |
|---|---|---|---|---|
| 1 | Volumétrie transactions ERP | X saisies | Y saisies | ↑ / ↓ |
| 2 | % utilisateurs actifs | X % | Y % | ↑ / ↓ |
| 3 | Incidents ouverts / fermés | X / Y | A / B | ↑ / ↓ |
| 4 | Satisfaction utilisateurs (sondage) | X / 5 | Y / 5 | ↑ / ↓ |
| 5 | Actions correctives en cours | N actions | M actions | ↑ / ↓ |
Complétez ce tableau avec deux lignes contextuelles : “Faits marquants de la semaine” et “Décisions attendues du CODIR”. Ce format prend 30 minutes à préparer et donne à la direction une lecture claire sans requérir de compétence technique.
Pour approfondir les deux sujets qui conditionnent le succès de votre post go-live, lisez notre guide sur la conduite du changement ERP — notamment les sections sur l’identification des résistances et les indicateurs d’adoption — et notre guide complet sur la négociation d’un contrat TMA, qui vous donnera les clauses contractuelles à intégrer avant même le go-live pour sécuriser votre support post-déploiement.
