Un ERP ne se déploie pas avec une équipe IT seule dans un coin. Les recherches de Prosci sur les implémentations ERP montrent que les facteurs humains comptent six fois plus que les facteurs techniques dans l’atteinte des bénéfices attendus (Prosci, 2025). Autrement dit, le choix des personnes qui portent le projet a plus d’impact que le choix du logiciel lui-même.
Pourtant, la composition de l’équipe projet est rarement traitée avec la rigueur qu’elle mérite. On nomme un chef de projet, on désigne quelques “référents métier” et on espère que tout s’emboîte. Le résultat : des zones grises sur les responsabilités, des décisions qui traînent faute d’arbitre légitime, et des utilisateurs qui découvrent le système le jour du go-live.
Cet article détaille les rôles indispensables d’une équipe projet ERP, propose une matrice RACI concrète par phase et identifie les erreurs d’organisation les plus coûteuses.
Pourquoi la composition de l’équipe conditionne tout le reste
Le facteur humain, cause principale d’échec
Selon le Standish Group (CHAOS Reports), seuls 31 % des projets IT aboutissent conformément aux prévisions de périmètre, budget et délai (Standish Group, CHAOS Reports). Le constat se confirme côté ERP : les implémentations qui n’atteignent pas 70 % des bénéfices attendus représentent entre 11 % et 31 % des cas, selon la maturité de l’organisation en conduite du changement (Prosci, 2025).
Les causes reviennent systématiquement : formation insuffisante, désalignement des parties prenantes, absence de conduite du changement structurée, communication floue, collaboration transverse déficiente. Ce ne sont pas des bugs logiciels. Ce sont des problèmes de personnes et de gouvernance.
Le sponsor exécutif, premier facteur de succès
Le CHAOS Report du Standish Group classe le sponsor exécutif comme le premier facteur de succès des projets IT. Quand le sponsor est compétent et impliqué, 74 % des projets aboutissent (Standish Group, CHAOS Report). Quand il est absent ou passif, le taux de succès chute de moitié.
Un ERP touche les processus de plusieurs directions (finance, achats, production, RH, commercial). Sans un sponsor au niveau COMEX capable d’arbitrer les conflits inter-directions, le projet s’enlise dans des compromis politiques qui érodent le périmètre et allongent les délais.
Les 7 rôles indispensables d’une équipe projet ERP
1. Sponsor exécutif (executive sponsor)
Profil : membre du COMEX, souvent le DAF, le DG ou le DSI selon l’enjeu principal du projet.
Responsabilités :
- Porter la vision stratégique du projet et la communiquer à toute l’organisation
- Arbitrer les conflits de périmètre entre directions
- Valider le budget et les décisions de go/no-go à chaque jalon
- Débloquer les ressources quand l’équipe projet est en difficulté
Piège fréquent : nommer un sponsor “de façade” qui signe le budget initial puis disparaît. Un sponsor efficace consacre au minimum une demi-journée par semaine au projet pendant les phases critiques.
2. Chef de projet (project manager)
Profil : chef de projet expérimenté avec une connaissance des processus métier, pas nécessairement un expert technique.
Responsabilités :
- Planifier et suivre le planning, le budget et le périmètre
- Coordonner les travaux entre les équipes internes et l’intégrateur
- Gérer les risques et escalader les points de blocage au sponsor
- Animer les comités de pilotage (COPIL) et les comités projet (COPROJ)
Piège fréquent : confier la gestion de projet uniquement à l’intégrateur. Celui-ci a ses propres intérêts (facturation, planning interne). L’entreprise doit avoir son propre chef de projet pour défendre ses priorités.
3. Responsable conduite du changement (change manager)
Profil : profil senior avec une légitimité transverse, souvent issu des RH, de la communication interne ou d’un cabinet spécialisé.
Responsabilités :
- Cartographier les impacts du nouvel ERP sur chaque population d’utilisateurs
- Concevoir et piloter le plan de communication interne
- Organiser les formations (timing, contenu, format)
- Mesurer l’adoption post-go-live et piloter les actions correctives
Le sous-investissement en conduite du changement est documenté : les organisations qui échouent consacrent moins de 10 % de leur budget total à la formation et à l’accompagnement au changement (ERP Focus). Prosci recommande d’intégrer un volet changement dès le cadrage, pas en fin de projet.
4. Key users (utilisateurs clés)
Profil : experts métier opérationnels, reconnus par leurs pairs, libérés à 50 % minimum pendant les phases de conception et de recette.
Responsabilités :
- Formaliser les processus cibles avec l’intégrateur (ateliers de conception)
- Valider les paramétrages et tester les scénarios métier (recette fonctionnelle)
- Former les utilisateurs finaux de leur service (formation en cascade)
- Servir de relais terrain après le go-live (support de proximité niveau 1)
Combien en faut-il ? Comptez au minimum un key user par module fonctionnel majeur (finance, achats, ventes, production, logistique). Sur un projet PME de 5 modules, cela représente 5 à 8 personnes. Sur un projet ETI multi-sites, 15 à 25.
Piège fréquent : désigner les personnes “disponibles” plutôt que les plus compétentes. Les key users sont les ambassadeurs du futur système : s’ils ne sont pas crédibles auprès de leurs collègues, la formation en cascade ne fonctionnera pas.
5. Architecte technique / DSI
Profil : responsable technique interne (DSI, responsable infra, architecte SI).
Responsabilités :
- Valider l’architecture technique (cloud, on-premise, hybride)
- Piloter les interfaces avec les systèmes existants (CRM, WMS, BI, paie)
- Gérer la reprise de données (extraction, nettoyage, chargement)
- Garantir la sécurité, la performance et la conformité RGPD
6. Responsable données (data owner / data steward)
Profil : profil hybride métier/IT, souvent issu de la direction financière ou de la supply chain.
Responsabilités :
- Définir les règles de qualité des données maîtres (clients, fournisseurs, articles, nomenclatures)
- Piloter le nettoyage des données avant la migration
- Valider les résultats de la reprise de données
- Mettre en place la gouvernance des données post-go-live
Ce rôle est trop souvent négligé. La migration des données est l’une des trois premières causes d’échec des projets ERP, avec la conduite du changement et l’inadéquation de l’équipe projet (ECI Solutions).
7. Intégrateur / partenaire éditeur
Profil : équipe de l’intégrateur (consultant fonctionnel, consultant technique, chef de projet intégrateur).
Responsabilités :
- Apporter l’expertise produit et les bonnes pratiques sectorielles
- Paramétrer le système selon les processus cibles
- Développer les spécifiques validés en comité de pilotage
- Assurer le support de transition pendant la période d’hypercare post-go-live
Point de vigilance : l’intégrateur n’est pas le décideur. Il propose, le comité de pilotage dispose. Un intégrateur qui impose ses choix sans validation métier est un red flag.
La matrice RACI appliquée à un projet ERP
La matrice RACI (Responsible, Accountable, Consulted, Informed) clarifie qui fait quoi sur chaque livrable. Sans elle, les zones grises se transforment en conflits ou en inaction.
- R (Responsible) : réalise le travail
- A (Accountable) : valide et rend des comptes (une seule personne par livrable)
- C (Consulted) : donne un avis avant la décision (échange bidirectionnel)
- I (Informed) : informé après la décision (communication unidirectionnelle)
Matrice RACI type par phase
Phase 1 : cadrage et choix de l’ERP
| Livrable | Sponsor | Chef de projet | Change manager | Key users | DSI | Data owner | Intégrateur |
|---|---|---|---|---|---|---|---|
| Objectifs stratégiques | A | R | C | I | C | I | I |
| Cahier des charges | C | A | C | R | R | C | I |
| Grille d’évaluation éditeurs | C | A | I | C | R | I | I |
| Choix final éditeur/intégrateur | A | R | I | C | C | I | I |
Phase 2 : conception (design)
| Livrable | Sponsor | Chef de projet | Change manager | Key users | DSI | Data owner | Intégrateur |
|---|---|---|---|---|---|---|---|
| Processus cibles (blueprints) | I | A | C | R | C | C | R |
| Analyse des écarts (gap analysis) | I | A | I | R | C | I | R |
| Arbitrage standard vs spécifique | A | R | I | C | C | I | C |
| Plan de migration des données | I | A | I | C | C | R | R |
Phase 3 : réalisation et tests
| Livrable | Sponsor | Chef de projet | Change manager | Key users | DSI | Data owner | Intégrateur |
|---|---|---|---|---|---|---|---|
| Paramétrage ERP | I | A | I | C | C | I | R |
| Développements spécifiques | I | A | I | C | R | I | R |
| Recette fonctionnelle (UAT) | I | A | I | R | C | C | C |
| Migration de données (dry run) | I | A | I | C | R | R | R |
| Plan de formation | I | C | A | C | I | I | C |
Phase 4 : déploiement et go-live
| Livrable | Sponsor | Chef de projet | Change manager | Key users | DSI | Data owner | Intégrateur |
|---|---|---|---|---|---|---|---|
| Décision go/no-go | A | R | C | C | C | C | C |
| Formation utilisateurs finaux | I | C | A | R | I | I | C |
| Bascule technique | I | A | I | I | R | R | R |
| Support hypercare | I | A | I | R | R | I | R |
| Communication interne | C | I | R | I | I | I | I |
Comment lire et utiliser cette matrice
Trois règles fondamentales :
- Un seul A par ligne. Si deux personnes sont “Accountable”, personne ne l’est vraiment. L’accountability ne se partage pas.
- Pas de ligne sans R. Si personne ne réalise le travail, le livrable n’avancera pas.
- Le A a le droit de veto. Le Responsible propose, l’Accountable valide. Si le key user rédige le processus cible (R), le chef de projet valide la conformité au périmètre (A).
Adaptez cette matrice à votre contexte. Sur un projet PME avec 50 utilisateurs, le chef de projet et le change manager sont parfois la même personne. Sur un projet ETI multi-sites, vous aurez un change manager par site et un coordinateur central.
Les 5 erreurs d’organisation les plus coûteuses
1. Pas de sponsor, ou un sponsor fantôme
Le projet perd son levier d’arbitrage. Les conflits entre directions ne se résolvent pas, les décisions remontent et redescendent sans fin, le planning dérive. C’est la première cause d’échec organisationnel.
2. Key users à temps partiel subi
Quand les key users doivent “faire le projet en plus de leur travail quotidien”, les ateliers de conception sont bâclés, la recette est survolée et la formation en cascade n’a pas lieu. Le résultat : un ERP paramétré sur des processus théoriques que personne n’a validés en conditions réelles.
Bonne pratique : négocier dès le cadrage un taux de libération de 50 % minimum pour les key users pendant les phases actives (conception, recette, formation). Formaliser cet engagement avec les managers des key users.
3. Aucun responsable de la conduite du changement
Sans change manager, la formation est réduite à une démonstration technique en salle et la communication se résume à un e-mail du DSI. Les utilisateurs subissent le changement au lieu de le comprendre. L’adoption stagne, les contournements se multiplient (retour à Excel), et le ROI ne se matérialise jamais.
4. Migration des données traitée en dernière minute
Quand personne ne porte la responsabilité des données, le nettoyage est repoussé jusqu’à la dernière semaine avant le go-live. On bascule alors avec des doublons, des fiches clients obsolètes et des nomenclatures incohérentes. Les premiers jours sur le nouvel ERP deviennent un chaos opérationnel.
5. RACI implicite (“tout le monde sait qui fait quoi”)
Dans un projet de 6 à 18 mois impliquant 10 à 30 personnes, les responsabilités implicites ne tiennent pas. Des tâches critiques tombent entre deux chaises (personne ne teste les interfaces, personne ne valide les droits d’accès), et les arbitrages se font dans l’urgence au lieu d’être anticipés.
Dimensionner l’équipe selon la taille du projet
| Critère | PME (50 users) | ETI (200 users) | Grande entreprise (500+ users) |
|---|---|---|---|
| Sponsor | 1 (DG ou DAF) | 1 (membre COMEX) | 1 + comité directeur projet |
| Chef de projet interne | 1 (mi-temps possible) | 1 (temps plein) | 1 + PMO |
| Change manager | 1 (souvent cumulé avec chef de projet) | 1 dédié | 1 coordinateur + relais par site |
| Key users | 3 à 5 | 8 à 15 | 15 à 30 |
| DSI / architecte | 1 | 1 à 2 | Équipe technique dédiée |
| Data owner | 1 (souvent le DAF) | 1 à 2 | 1 par domaine de données |
| Intégrateur | 2 à 3 consultants | 5 à 10 consultants | 10 à 20+ consultants |
Ces ordres de grandeur sont indicatifs. Ajustez en fonction du nombre de modules, du degré de spécifique et du nombre de sites à déployer.
Checklist de lancement : votre équipe est-elle prête ?
Avant de lancer les ateliers de conception, vérifiez ces dix points :
- Un sponsor exécutif est nommé et s’engage sur un créneau hebdomadaire dédié au projet
- Un chef de projet interne est désigné (distinct du chef de projet intégrateur)
- Un change manager est identifié avec un budget formation chiffré
- Les key users sont nommés par module, avec un taux de libération validé par leurs managers
- Un data owner est responsable du plan de migration des données
- La matrice RACI est formalisée et partagée avec toute l’équipe projet
- Les instances de gouvernance sont définies (COPIL mensuel, COPROJ hebdomadaire)
- L’intégrateur a présenté son équipe nominative (pas juste “un consultant senior”)
- Le budget inclut un poste conduite du changement (formation, communication, support)
- Un kit d’onboarding projet est distribué à tous les membres de l’équipe
Si trois points ou plus ne sont pas cochés, prenez le temps de structurer avant de lancer. Un projet ERP bien staffé dès le départ coûte moins cher qu’un projet mal staffé qu’on redresse en cours de route.
Pour approfondir le sujet, consultez notre guide sur la conduite du changement ERP et notre article sur les cinq phases d’un projet ERP réussi. Si vous démarrez un appel d’offres, notre guide pour rédiger un cahier des charges ERP vous aidera à structurer vos exigences dès le cadrage.
