5 questions à poser en comité de pilotage pour savoir si votre projet ERP est réellement sous contrôle
Si vous êtes sponsor d’un programme ERP, ce sentiment vous est peut-être familier.
Les comités de pilotage sont bien remplis.
Les présentations sont soignées.
Les statuts sont rassurants.
Et pourtant, en sortant de la réunion, un doute persiste :
Sommes-nous vraiment en contrôle… ou simplement en train de suivre l’activité ?
Ce doute n’est généralement pas lié à l’engagement ou aux compétences des équipes.
Il signale plutôt que le comité de pilotage ne fait pas émerger la réalité du projet, mais uniquement son avancement.
C’est un schéma fréquent dans les programmes ERP où la gouvernance existe formellement, sans réellement jouer son rôle opérationnel — un sujet que FitGap explore plus en détail dans son analyse de la gouvernance ERP au-delà de la théorie.
Ce ne sont pas des questions de statut. Ce sont des questions de diagnostic.
Un comité de pilotage sert à réduire l’incertitude et à forcer les décisions.
Si les questions posées peuvent être systématiquement répondues par « en cours », le projet dérivera — discrètement.
Les cinq questions ci-dessous fonctionnent à toutes les phases d’un projet ERP et révèlent immédiatement si le programme est réellement sous contrôle.
1. Charte de comptes (Plan comptable) et dimensions
Quels besoins de reporting ont déjà été validés avec la nouvelle charte de comptes (nouveau plan comptable) et les dimensions — et quelles lacunes de conception restent ouvertes ?
Pourquoi c’est critique :
Une charte de comptes (plan comptable) peut être techniquement finalisé tout en restant inadapté aux besoins réels de pilotage et de reporting.
Ce que le comité de pilotage doit entendre :
- Quels états de gestion ont été validés avec la nouvelle structure
- Ce qui ne se réconcilie pas encore ou ne fait pas sens
- Quelles décisions de conception sont toujours ouvertes — et qui en est responsable
Signaux d’alerte :
- « Le mapping est terminé »
- « La finance a validé »
- « On ajustera après le go-live »
Ces sujets réapparaissent souvent tardivement, car des décisions business ont été traitées comme de simples choix de configuration (voir la nuance ici).
2. Migration de données et répétition générale
Avons-nous réalisé au moins une répétition complète avec des données réelles ou quasi réelles — et quels ont été les trois principaux échecs ou écarts constatés ?
Pourquoi c’est critique :
Les risques de migration ne sont visibles qu’en situation réelle : volumes, performances, rapprochements.
Ce que le comité de pilotage doit entendre :
- Taux d’erreurs et rejets
- Écarts de rapprochement et causes racines
- Problèmes de performance ou de délais
Signaux d’alerte :
- « Globalement, la migration a fonctionné »
- « Les problèmes étaient mineurs »
- « On corrigera au prochain cycle »
De nombreux échecs attribués à la « qualité des données » sont en réalité des problèmes non affrontés assez tôt (analyse connexe).
3. Préparation des utilisateurs clés
Quels groupes d'utilisateurs clés pourraient exécuter leurs processus demain avec un minimum de support projet — et lesquels ne le pourraient clairement pas ?
Pourquoi c’est critique :
La préparation n’est jamais homogène. Faire semblant du contraire masque un risque opérationnel réel.
Ce que le comité de pilotage doit entendre :
- Une liste claire par processus ou fonction
- Les zones de dépendance persistante vis-à-vis de l’équipe projet
- Des écarts de préparation concrets
Signaux d’alerte :
- « Les utilisateurs sont à l’aise »
- « La formation est en cours »
- « Ça dépend »
La préparation des utilisateurs est autant humaine et organisationnelle que technique (voir la dimension humaine).
4. Adoption des décisions clés
Quelles décisions majeures ont été prises, mais sont encore contournées dans les pratiques quotidiennes ?
Pourquoi c’est critique :
Une décision qui n’est pas appliquée ne protège pas le projet.
Ce que le comité de pilotage doit entendre :
- Où Excel ou les habitudes héritées persistent
- Quelles règles ou conceptions ne sont pas réellement respectées
- Pourquoi
Signaux d’alerte :
- « Les équipes ont besoin de plus de temps »
- « La gestion du changement s’en occupe »
- Le silence
Ce décalage entre décision et comportement est souvent le premier signal d’une gouvernance défaillante.
5. Tests de bout en bout sous contraintes réalistes
Quel processus critique a été testé de bout en bout dans des conditions réalistes — volumes, cut-offs, circuits d’approbation et rôles de sécurité — et qu’est-ce qui a echoué ?
Pourquoi c’est critique :
La majorité des tests « réussissent » parce qu’ils évitent la réalité.
Par « réaliste », on entend :
- Des rôles de sécurité finaux (pas des accès administrateur)
- De vrais circuits d’approbation
- Des volumes et des timings réels
- Une pression de clôture ou opérationnelle
Signaux d’alerte :
- « Le scénario a été testé avec succès »
- « Les rôles définitifs ne sont pas encore en place »
- « Ce sera traité plus tard »
Ignorer les rôles de sécurité et les validations en phase de test conduit presque systématiquement à des incidents post go-live.
En conclusion
Si ces questions n’obtiennent pas de réponses claires, factuelles et étayées, le projet est déjà en train de dériver — même si tous les indicateurs sont au vert.
Les comités de pilotage n’échouent pas par manque d’efforts.
Ils échouent parce qu’ils ne forcent pas la clarté assez tôt.
La gouvernance n’est pas une question de visibilité.
C’est une question de rendre la réalité inévitable.
Cet article fait partie de la série FitGap™ Finance — une approche pragmatique et orientée business de la gouvernance ERP, de la prise de décision et du contrôle au-delà du go-live.
🇬🇧 English version available here : https://www.fitgapfinance.com/erp-steering-committee-questions/
