Checklist d'implémentation ERP — Les 90 premiers jours
Les 90 premiers jours d'une implémentation ERP déterminent la trajectoire de l'ensemble du projet. Les déploiements ERP qui tournent mal dans les PME et ETI échouent rarement au moment de la bascule ; ils échouent durant les trois premiers mois, lorsque la charte est floue, le sponsor désengagé, le lancement du nettoyage des données reporté et que la dérive du périmètre commence. Le temps que le projet atteigne la phase de réalisation, les schémas qui déterminent le succès ou l'échec sont largement figés.
Cette checklist s'articule autour de trois fenêtres — jours 1 à 30, jours 31 à 60, jours 61 à 90 — avec un ensemble clair de livrables, de jalons et de signaux d'alerte pour chacune. Elle est rédigée pour des projets de PME et ETI françaises de 50 à 500 salariés, où l'équipe projet est réduite, le sponsor est le directeur financier (DAF) ou le directeur des opérations (COO), et où le partenaire assure l'essentiel du travail technique. Les chiffres et observations proviennent de projets PME/ETI typiques ; la ligne éditoriale reste neutre.
Jours 1 à 30 : mise en place du projet et fondations
Le premier mois consiste à asseoir le projet sur des bases procédurales solides. Les livrables sont ici peu spectaculaires — chartes, documents de gouvernance, plans de communication, rythmes de réunion — mais chaque projet qui les a négligés l'a regretté par la suite.
Semaine 1 (jours 1 à 7)
- Atelier de lancement (kickoff) avec le comité de pilotage, l'équipe projet, les key users et le partenaire. Une journée complète, en présentiel si possible, avec un ordre du jour clair couvrant le périmètre, les critères de succès, les risques et les 90 jours à venir.
- Charte de projet validée par le sponsor exécutif et le comité de pilotage. La charte désigne le sponsor, le périmètre, les critères de succès, l'enveloppe budgétaire et le calendrier macro. Les chartes jamais validées deviennent des projets sans ancrage.
- Outillage projet mis en place : plan de projet dans MS Project, Smartsheet, Jira ou équivalent ; espace documentaire avec une arborescence claire ; canaux de communication (Teams ou Slack).
Semaines 2 et 3 (jours 8 à 21)
- La documentation des processus existants (as-is) démarre pour les processus stratégiques — pas tous les processus, seulement les 8 à 15 qui comptent. Visez des cartographies de processus tenant sur une page, avec les principaux points de transfert, décisions et points de douleur actuels signalés.
- Attribution des rôles confirmée : chef de projet (temps plein), business analyst (temps plein ou partiel), key users par module (typiquement 30 à 60 % de leur temps pour la durée du projet), responsable technique côté partenaire, sponsor exécutif disposant d'un créneau hebdomadaire.
- Rythme du comité de pilotage établi : toutes les 4 à 6 semaines pour les décisions go/no-go, les escalades et le suivi budgétaire. Évitez un pilotage hebdomadaire — il dilue la réunion et le sponsor se désengage.
- Premier environnement bac à sable (sandbox) provisionné par le partenaire pour que l'équipe projet puisse commencer à explorer le système.
Semaine 4 (jours 22 à 30)
- Démarrage des premiers ateliers fit-gap, typiquement une demi-journée par module (finance, achats, ventes, entrepôt, production le cas échéant). Le partenaire présente le standard, les key users décrivent le processus réel, et les écarts sont documentés.
- Cadrage initial de la migration des données : quelles entités (référentiel clients, référentiel fournisseurs, référentiel articles, transactions ouvertes, historique) doivent être migrées, dans quels volumes, depuis quels systèmes sources ?
- Revue de fin de mois 1 : charte signée, plan validé, équipe en place, sandbox disponible, premiers ateliers fit-gap réalisés. Le sponsor confirme le feu vert pour poursuivre.
Migration des données : commencer tôt, pas à la fin
La migration des données est la cause unique la plus fréquente d'échec ou de retard des projets ERP. L'erreur classique consiste à la traiter comme une activité de week-end de bascule plutôt que comme un chantier qui s'étend sur toute la durée du projet. Dans une fenêtre de 90 jours bien menée, la migration des données est déjà en cours dès la sixième semaine, et non la seizième.
Le chantier de migration des données durant les 90 premiers jours doit produire :
- Inventaire des systèmes sources : une liste documentée de chaque système détenant des données à migrer — l'ancien ERP, le CRM autonome, le tableur de l'entrepôt, le fichier Excel fournisseurs tenu par les achats — avec les volumes de données et le niveau de qualité de chacun.
- Document de mapping au niveau des champs : pour chaque entité (client, fournisseur, article, commande ouverte, écriture comptabilisée), chaque champ source mis en correspondance avec le champ cible correspondant, avec les règles de transformation si nécessaire. Ce document est itératif ; la première version est imparfaite mais elle doit exister.
- Plan et lancement du nettoyage : l'effort de nettoyage des données de référence est presque toujours plus long que ce que l'équipe projet anticipe (typiquement 3 à 6 mois d'effort dédié) et doit démarrer en parallèle du fit-gap, pas après. Désignez le responsable dédié à la qualité des données au plus tard au jour 45.
- Première migration de test : au jour 75 à 90, la première migration de test de bout en bout d'un sous-ensemble significatif du référentiel clients et fournisseurs dans le bac à sable, avec rapprochement par rapport à la source.
Le signal d'alerte caractéristique d'un projet qui dérape : au jour 60, personne n'est désigné comme responsable du nettoyage des données, et l'hypothèse retenue est « on traitera les données plus près du go-live ». Les projets qui disent cela décalent toujours la bascule de 4 à 8 semaines. Consultez notre guide de migration ERP pour une approche structurée.
Jours 31 à 60 : configuration, personnalisation et premiers tests
Le deuxième mois passe des fondations au fond. Le fit-gap s'achève, le périmètre des développements spécifiques est arrêté, et l'approche de test est définie.
Semaines 5 et 6 (jours 31 à 42)
- Conclusion des ateliers fit-gap. Chaque responsable de module produit un document fit-gap recensant les processus qui collent au standard (aucune action), ceux qui nécessitent une configuration (modification de paramètres dans le standard) et ceux qui nécessitent une personnalisation (développement de code ou d'extension).
- Spécification des développements spécifiques : pour chaque écart nécessitant un développement, une spécification écrite avec exigences fonctionnelles, approche technique et estimation de charge. Le partenaire les produit ; le métier les valide. Les spécifications non validées deviennent plus tard la source de l'argument classique de dérive du périmètre.
- Budget des développements spécifiques arrêté. La charge totale de personnalisation est comparée au budget initial. Presque toujours, le premier passage dépasse le budget — le comité de pilotage tranche sur ce qui est conservé, ce qui est reporté en phase 2 et ce qui est abandonné.
Semaines 7 et 8 (jours 43 à 56)
- Démarrage de la configuration de l'environnement de développement. Le partenaire configure le système selon le standard convenu plus les configurations ; le développement des spécifiques démarre en parallèle pour les éléments déjà spécifiables.
- Conception des interfaces : chaque intégration à un système tiers (plateforme e-commerce, partenaires EDI, paie, banque, BI) fait l'objet d'un document de conception écrit — protocole, format d'échange des données, gestion des erreurs, logique de relance, supervision. Les interfaces sont la deuxième cause la plus fréquente de glissement de la bascule, après la migration des données.
- Stratégie de test définie : quels cycles de test (unitaire, module, intégration, recette utilisateur, performance, bout en bout), qui les exécute, ce qui passe et ce qui échoue. Sans stratégie de test documentée, les tests sont toujours sous-dimensionnés.
- Plan de formation des key users : le partenaire produit un plan de formation précisant quand les key users sont formés (typiquement aux mois 4 à 6 du projet), sous quel format, avec quels supports. La formation des key users est un multiplicateur de force pour la formation des utilisateurs finaux par la suite.
Semaine 9 (jours 57 à 60)
- Revue de mi-projet : périmètre, calendrier, budget et registre des risques tous passés en revue par le comité de pilotage. Statut rouge/orange/vert pour chacun. Ajustements opérés si nécessaire.
- Jalon de fin de mois 2 : fit-gap terminé et validé, spécifications des développements spécifiques validées, conceptions d'interfaces terminées, stratégie de test documentée, plan de formation en place. Migration des données en cours.
Formation et conduite du changement
La formation et la conduite du changement ne sont pas des activités du troisième mois rajoutées à la fin — elles requièrent une attention explicite dès les 90 premiers jours, même si l'essentiel de la formation a lieu plus tard. La raison : la stratégie de conduite du changement et la structure du programme de formation doivent être posées tôt pour être efficaces.
Ce que les 90 premiers jours doivent produire côté conduite du changement :
- Cartographie des parties prenantes : qui dans l'organisation est impacté, comment, et quelle est son attitude actuelle (champion, soutien, neutre, sceptique, opposant). À mettre à jour chaque trimestre tout au long du projet.
- Plan de communication : le rythme des points d'avancement projet vers l'ensemble de l'entreprise — newsletter mensuelle, réunion plénière trimestrielle, briefings des managers. La première communication part au plus tard au jour 30, pas au go-live.
- Réseau de key users : 1 key user pour 10 à 15 utilisateurs finaux, nommé, briefé et disposant de temps protégé. Les key users sont les relais de la formation des utilisateurs finaux et les dépanneurs locaux durant l'hypercare.
- Décision sur le format de formation : présentiel, e-learning, atelier pratique, formation de formateurs ? Le bon mix dépend de la population d'utilisateurs — les opérateurs de ligne de production n'apprennent pas comme les membres de l'équipe finance. Décidez le mix au jour 75.
- Engagement des instances représentatives du personnel (CSE) : pour tout nouveau système touchant aux données RH, au suivi du temps ou au contrôle de la productivité, le Code du travail impose l'information-consultation du comité social et économique (CSE). Engagez le dialogue avec le CSE dès le jour 30, avec une réunion d'information formelle au plus tard au jour 60.
Les projets qui repoussent la conduite du changement aux deux derniers mois subissent presque toujours un effondrement de productivité durant la première semaine du go-live — non parce que le logiciel est défaillant, mais parce que les utilisateurs n'ont pas été embarqués. C'est le mode d'échec évitable le plus important des projets ERP.
Jours 61 à 90 : avancement de la configuration et revue du jour 90
Le troisième mois consolide ce qui a été construit et prépare le passage en phase de réalisation. La plupart des projets PME/ETI ne basculent pas en production durant les 90 premiers jours — l'horizon réaliste est de 9 à 18 mois au total — mais le jalon du jour 90 constitue le go/no-go explicite pour passer de la conception à la construction.
Semaines 10 et 11 (jours 61 à 77)
- Configuration de l'environnement de test substantiellement achevée. Les premiers scénarios intégrés de bout en bout sont déroulés dans le système — créer un devis, le convertir en commande de vente, allouer le stock, expédier, facturer, comptabiliser au grand livre, rapprocher avec la banque.
- Le développement des interfaces progresse sur les intégrations prioritaires. Au jour 75, au moins les interfaces du système financier, bancaire et EDI cœur disposent d'une première version fonctionnelle dans l'environnement de test.
- Nettoyage des données de référence visiblement en cours. Le responsable qualité des données fournit un statut hebdomadaire : référentiel clients à 78 % nettoyé, référentiel fournisseurs à 65 %, référentiel articles à 52 %. Si ces chiffres ne sont pas mesurables au jour 75, la migration des données est en difficulté.
- Les communications de conduite du changement démarrent pour de bon. La première newsletter destinée à l'ensemble des salariés, les premiers briefings managers, le premier document de FAQ.
Semaines 12 et 13 (jours 78 à 90)
- Plan de test détaillé prêt. Cas de test rédigés pour chaque module (typiquement 30 à 100 cas par module), avec résultats attendus et critères de réussite/échec. Scripts de recette utilisateur rédigés pour les processus métier clés.
- Plan de test d'intégration prêt : quels scénarios de bout en bout sont testés, dans quel ordre, avec quelles dépendances entre modules.
- Revue go/no-go du jour 90. Le comité de pilotage examine l'avancement par rapport au plan initial, les risques ouverts, la consommation budgétaire et la date de go-live réaliste projetée. Les projets honnêtes acceptent un glissement à ce stade s'il est réel ; les projets malhonnêtes font comme si la date initiale tenait encore et le paient plus tard.
La revue du jour 90 est le moment de gouvernance le plus important du projet. À ce stade, l'équipe projet sait si le plan initial est réaliste ou chimérique. Un comité de pilotage qui utilise le jour 90 pour une replanification honnête plutôt que pour des réassurances de façade donne au projet les meilleures chances d'atterrir correctement.
Risques et pièges typiques des 90 premiers jours
Cinq modes d'échec dominent les statistiques des 90 premiers jours pour les projets ERP de PME et ETI en France.
Charte non validée. L'échec fondamental le plus courant. Sans charte signée par la direction, le projet dérive — le périmètre s'élargit silencieusement, les critères de succès évoluent, le sponsor se désengage. La parade : refuser de démarrer tout travail de fond tant que la charte n'est pas signée.
Désengagement du sponsor. Le DAF ou le COO est enthousiaste la première semaine et absent à la huitième. Les réunions de pilotage deviennent opérationnelles plutôt que directionnelles, les décisions difficiles sont reportées, la dérive du périmètre s'accélère. La parade : des points hebdomadaires de 30 minutes avec le sponsor, dont les décisions sont explicitement documentées.
Dérive du périmètre dès la troisième semaine. Une fois que les key users voient le nouveau système, ils commencent à demander des ajouts — « tant qu'on y est, pourrait-on aussi… ». Chaque demande est raisonnable isolément, et ensemble elles doublent le projet. La parade : un processus formel de demande de changement dès le premier jour, avec validation du comité de pilotage pour tout ajout.
Nettoyage des données lancé trop tard. Si au jour 45 personne n'a été désigné comme responsable de la qualité des données, la migration est déjà en difficulté. Le nettoyage est toujours plus long que prévu et révèle toujours des problèmes nécessitant des décisions côté métier (quelle fiche client est la bonne, quel article doit être archivé). La parade : nommer le responsable qualité des données au jour 30.
Surpromesse du partenaire au lancement. Un partenaire qui promet une implémentation de 9 mois pour un périmètre qui en demande réalistement 14 condamne le projet à l'échec à la revue du jour 90. La parade : un challenge du partenaire lors de la sélection — lui demander de dérouler des projets similaires avec des clients de référence, calendriers réalistes à l'appui.
Conformité et exigences réglementaires
Le travail de conformité durant les 90 premiers jours consiste surtout à documenter ce que le système doit prendre en charge, pas à le mettre en œuvre. Les principaux sujets spécifiques à la France :
- Piste d'audit fiable (PAF) et obligations comptables : les règles françaises de tenue et de conservation des écritures comptables. Le nouvel ERP doit garantir des enregistrements comptables inaltérables, une piste d'audit pour chaque écriture, ainsi que la conservation des documents pendant la durée légale (jusqu'à 10 ans). Documentez la conformité du système (notamment le format FEC pour le Fichier des Écritures Comptables) dans le dossier projet au jour 60.
- Intégration avec l'expert-comptable : la quasi-totalité des PME françaises s'appuie sur un expert-comptable. Le nouvel ERP doit exporter les écritures dans un format exploitable (FEC, formats standard d'import comptable). Précisez le mode d'intégration au jour 60 — XML, fichier plat, connecteur natif.
- Préparation à la facturation électronique : Factur-X pour les factures hybrides PDF/XML en B2B, et Chorus Pro pour la facturation à la sphère publique (B2G). La France impose la facturation électronique B2B selon un déploiement progressif. Le nouvel ERP doit émettre des factures conformes et recevoir des flux entrants conformes. Confirmez la capacité de l'éditeur au jour 60.
- RGPD et loi Informatique et Libertés : entrées au registre des traitements pour le nouveau système, modalités d'effacement des données personnelles (en particulier les données salariés), mécanismes de consentement le cas échéant.
- Spécifique au secteur : exigences de l'ACPR pour les filiales de services financiers, GMP pour la fabrication pharmaceutique, HACCP pour l'agroalimentaire, et réglementations sectorielles applicables aux opérateurs d'importance vitale.
Le chantier de conformité durant les 90 premiers jours doit produire un registre de conformité écrit recensant chaque exigence, la personne responsable, l'échéance et la preuve à produire. Sans ce registre, les problèmes de conformité surgissent au moment de la bascule et imposent des improvisations de dernière minute.
Au-delà du jour 90 : la suite du projet
Le jour 90 marque la transition de la phase de conception vers la phase de réalisation. Les livrables des 90 premiers jours — charte signée, fit-gap achevé, périmètre des développements spécifiques arrêté, conceptions d'interfaces, stratégie de test, plan de formation, conception de la migration des données — deviennent les entrées des 6 à 12 mois suivants de construction, de test et de bascule. La structure macro du reste du projet pour une implémentation PME/ETI typique :
- Mois 4 à 6 : construction. Développements spécifiques terminés, interfaces fonctionnelles en test, nettoyage des données de référence à 80-90 %, formation des key users dispensée.
- Mois 7 à 9 : test. Test module, test d'intégration, recette utilisateur, test de performance. Formation des utilisateurs finaux dispensée par vagues. Première migration de test du périmètre de données complet.
- Mois 10 et 11 : préparation de la bascule. Plan de bascule finalisé, répétitions générales de migration, intensification de la communication, modèle d'hypercare convenu avec le partenaire.
- Mois 12 : bascule. Week-end de go-live, support intensif en semaine 1, stabilisation jusqu'au mois 2.
- Mois 13 à 15 : hypercare. Support intensif, correction des anomalies, transfert progressif vers les opérations courantes.
- Mois 15 et au-delà : amélioration continue. Modules de phase 2, intégrations supplémentaires, optimisation continue.
Le moment de gouvernance le plus important après le jour 90 est la décision go/no-go de bascule, typiquement 4 à 6 semaines avant le go-live prévu. À ce stade, les résultats des tests, les répétitions générales de migration et l'achèvement des formations donnent tous un signal clair sur la faisabilité de la date de go-live, ou sur la pertinence d'un report de 4 à 6 semaines comme choix responsable. Les projets qui ont passé outre un signal no-go l'ont presque toujours payé par un hypercare prolongé.