J’ai déployé des ERP dans des groupes industriels multi-pays, des entreprises d’enseignement supérieur, des groupes de communication internationaux. Divalto, SAP, Sage, Microsoft Dynamics, Maconomy — sur des périmètres allant de 50 à plusieurs milliers d’utilisateurs, de la France au Royaume-Uni, à l’Inde, à la Pologne, à la Hongrie et à la République Tchèque.
Et dans chacun de ces contextes, j’ai vu les mêmes erreurs se répéter. Pas parce que les dirigeants sont incompétents. Pas parce que les éditeurs sont mauvais. Mais parce que les vraies causes d’échec d’un projet ERP ne sont presque jamais techniques.
Les études sectorielles estiment que 60 à 75% des projets ERP dépassent leur budget initial, leurs délais, ou n’atteignent pas les objectifs fixés. Dans les PME, ce chiffre est probablement plus élevé — parce que les ressources pour absorber les imprévus sont plus limitées et que le pilotage est souvent moins structuré.
Voici ce que j’observe réellement sur le terrain — et ce que les commerciaux des éditeurs ERP ne vous diront jamais lors de la démonstration.
Cause 1 — L’ERP a été choisi avant que les besoins soient définis
C’est la cause numéro un. Le dirigeant assiste à une démonstration commerciale impressionnante, l’éditeur présente toutes les fonctionnalités possibles, et la décision est prise sur la base de ce que l’ERP peut faire — pas sur ce que l’entreprise a réellement besoin qu’il fasse.
Le résultat : un ERP surpuissant et surdimensionné, déployé sur des processus métiers qui n’ont jamais été formalisés, avec des utilisateurs qui ne comprennent pas pourquoi leur façon de travailler doit changer.
Ce que j’ai vu en mission : une PME industrielle qui avait choisi un ERP « parce que c’est ce que font les grandes entreprises du secteur ». Trois ans après le déploiement, 40% des modules achetés n’étaient pas utilisés. Le module de gestion de production — le cœur du métier — avait été paramétré sans impliquer les chefs d’atelier. Il ne correspondait à aucun de leurs processus réels.
La bonne démarche : avant de choisir un ERP, passez 4 à 8 semaines à cartographier vos processus métiers actuels, identifier vos vrais points de douleur et définir ce que vous attendez concrètement du futur outil. Le cahier des charges précède le choix — jamais l’inverse.
Cause 2 — La direction générale délègue le projet à l’IT
Un projet ERP n’est pas un projet informatique. C’est un projet de transformation de l’entreprise qui touche tous les processus — comptabilité, achats, ventes, production, RH, logistique. Si la direction générale le traite comme un sujet technique et le délègue entièrement au responsable informatique, le projet est condamné dès le départ.
Pourquoi ? Parce qu’un responsable informatique n’a pas l’autorité pour imposer des changements de processus aux directeurs métiers. Quand le DAF refuse de modifier sa façon de faire les clôtures mensuelles, quand le responsable commercial ne veut pas saisir les commandes dans le nouvel outil, seul le DG peut trancher. Et s’il n’est pas impliqué, personne ne tranchera.
Ce que j’ai vu en mission : un projet ERP bloqué pendant 8 mois parce que deux directeurs métiers ne s’accordaient pas sur la définition d’un « client actif » dans le nouveau système. Un arbitrage de 30 minutes du DG aurait débloqué la situation. Il n’était « pas disponible pour ces détails techniques ».
La bonne démarche : le DG doit être sponsor du projet — présent aux comités de pilotage, disponible pour les arbitrages métiers, visible dans sa communication interne sur l’importance du projet. Sans ce signal fort, les équipes ne s’engageront pas.
Cause 3 — Le contexte culturel est ignoré dans les déploiements multi-pays
C’est une cause rarement évoquée — et pourtant déterminante dès lors qu’un projet ERP dépasse les frontières d’un seul pays. Les processus métiers varient selon les cultures, les pratiques comptables diffèrent selon les législations locales, et la relation à l’outil informatique n’est pas la même au Royaume-Uni, en Inde, en Pologne ou en Hongrie.
Ce que j’ai vécu en mission : lors du déploiement de l’ERP Maconomy dans un groupe mondial de communication — sur un périmètre couvrant le Royaume-Uni (4 000 utilisateurs), l’Inde (1 000 utilisateurs), la Pologne, la Hongrie et la République Tchèque —, l’objectif était de consolider la brique finance de l’ensemble de ces entités sur un système unique pour la direction financière groupe.
La dimension culturelle s’est imposée à plusieurs niveaux :
- Rapport à la hiérarchie : dans certaines équipes, les utilisateurs n’osaient pas signaler les problèmes de paramétrage à leurs managers — ce qui a retardé la détection de blocages critiques en phase de recette.
- Pratiques comptables locales : chaque pays avait ses spécificités réglementaires et ses habitudes de clôture mensuelle. La standardisation imposée par l’ERP groupe a nécessité des arbitrages délicats entre les exigences locales et la vision consolidée du groupe.
- Rythme et rapport au projet : les équipes indiennes travaillaient avec un niveau de formalisme très élevé dans la documentation mais une prise de décision plus longue. Les équipes britanniques attendaient une autonomie plus forte dans le paramétrage local. Les équipes d’Europe centrale étaient très rigoureuses sur les processus mais moins à l’aise avec les outils de collaboration à distance.
- Langue et communication : les réunions de projet en anglais excluaient de facto une partie des utilisateurs finaux dont ce n’était pas la langue de travail. Des supports de formation adaptés à chaque langue locale ont dû être produits en cours de projet — ce qui n’avait pas été anticipé dans le planning initial.
La bonne démarche : dans tout projet ERP multi-pays, nommez un référent local dans chaque pays dès le cadrage. Ce référent connaît la culture, les contraintes réglementaires locales et peut servir de relais de communication entre l’équipe projet centrale et les utilisateurs finaux. Prévoyez des supports de formation dans la langue locale et adaptez le rythme des comités de pilotage aux fuseaux horaires et aux cultures de réunion de chaque entité.
Cause 4 — La conduite du changement est budgétisée à zéro
Dans la quasi-totalité des projets ERP en PME, le budget est réparti entre les licences, l’intégration et la formation. La conduite du changement — communication interne, accompagnement des utilisateurs, gestion des résistances — n’est soit pas budgétisée, soit réduite à quelques heures de formation en fin de projet.
C’est une erreur fatale. Un ERP n’échoue jamais parce que le logiciel est mauvais. Il échoue parce que les utilisateurs ne l’adoptent pas — parce que personne ne leur a expliqué pourquoi leur façon de travailler doit changer, ce qu’ils y gagnent personnellement, et comment les accompagner dans la transition.
Ce que j’ai vu en mission : un déploiement techniquement réussi — go-live dans les délais, paramétrage conforme au cahier des charges — mais avec un taux d’utilisation de 30% six mois après le lancement. Les utilisateurs avaient maintenu leurs anciens fichiers Excel en parallèle « par sécurité ». Deux systèmes coexistaient, aucun n’était fiable.
La bonne démarche : consacrez entre 15 et 25% du budget total à la conduite du changement. Identifiez vos ambassadeurs internes par service, communiquez dès le cadrage, formez avant le go-live et accompagnez pendant les 3 premiers mois. En savoir plus sur la conduite du changement.
Cause 5 — Le périmètre n’est pas figé au démarrage
Le projet démarre avec un périmètre défini. Puis, au fil des réunions, les demandes s’accumulent. Ce phénomène — le scope creep — est la cause la plus fréquente de dépassement de budget et de délais. Chaque ajout semble raisonnable pris isolément. L’accumulation transforme un projet de 6 mois en marathon de 18 mois.
Ce que j’ai vu en mission : un projet initialement estimé à 180 000 € qui a terminé à 340 000 € — sans que le périmètre initial ait été livré complètement. Chaque ajout avait été validé individuellement par le DG sans vision de l’impact cumulatif sur le budget et les délais.
La bonne démarche : figez le périmètre de la phase 1 avant le démarrage et traitez toute demande de modification comme une demande de changement formelle avec évaluation d’impact sur le budget et les délais. Un comité de pilotage mensuel avec le DG est le seul moyen de tenir ce cap.
Cause 6 — L’intégrateur n’est pas challengé
L’intégrateur ERP est votre prestataire — pas votre partenaire. Il a des intérêts qui ne sont pas toujours alignés avec les vôtres : chaque demande de modification est facturable, chaque journée de retard prolonge la mission, chaque complexité ajoutée justifie des jours supplémentaires.
Sans maîtrise d’ouvrage forte côté client — un chef de projet IT expérimenté capable de lire les plannings, comprendre les livrables et challenger les estimations — l’intégrateur pilote le projet à sa place. Et il le pilote dans son intérêt.
Ce que j’ai vu en mission : un intégrateur qui avait sous-estimé le paramétrage initial dans son offre commerciale pour remporter le contrat, puis facturé les dépassements en régie. Le budget initial de 120 000 € avait atteint 210 000 € au go-live — avec des avenants signés au fil de l’eau sans que le DG mesure l’accumulation.
La bonne démarche : exigez un contrat au forfait sur le périmètre défini, avec des jalons de paiement liés à des livrables validés. Désignez un chef de projet IT interne ou externe capable de piloter l’intégrateur — pas de lui faire confiance aveuglément.
Cause 7 — La migration des données est sous-estimée
Dans tous les projets ERP, la migration des données est systématiquement sous-estimée. Les équipes découvrent en phase de recette que les données existantes sont incomplètes, incohérentes, mal structurées — et que leur nettoyage prend 3 à 5 fois plus de temps que prévu.
Dans un contexte multi-pays, ce défi est multiplié par le nombre d’entités — chacune avec ses propres systèmes sources, ses propres conventions de codification, ses propres historiques. La consolidation financière visée par l’ERP groupe n’est possible que si les données de chaque entité sont fiables, homogènes et compatibles avec le référentiel commun.
Ce que j’ai vu en mission : lors du déploiement Maconomy, l’harmonisation des plans comptables entre les entités britanniques, indiennes et d’Europe centrale a été l’un des chantiers les plus chronophages — chaque entité avait ses propres codes analytiques, ses propres centres de coûts, ses propres conventions de consolidation. Ce travail de standardisation ne peut pas être fait par l’intégrateur seul — il nécessite une implication forte des directeurs financiers locaux et un arbitrage du groupe.
La bonne démarche : lancez l’audit et le nettoyage des données dès le démarrage du projet — pas en phase de recette. Dans un contexte multi-pays, impliquez les DAF locaux dès la phase de cadrage pour définir le référentiel commun. Prévoyez au minimum 3 migrations de test avant la migration définitive.
Ce qui fait réussir un projet ERP
Après avoir livré des projets ERP dans des contextes variés — PME industrielle multi-sites, groupe d’enseignement supérieur, groupe de communication international — voici les facteurs de succès constants que j’ai identifiés :
- Un sponsor DG visible et impliqué — présent aux comités de pilotage, disponible pour les arbitrages, porteur du message en interne.
- Un cahier des charges métier précis — rédigé avant toute démonstration d’éditeur, validé par les responsables de chaque domaine fonctionnel.
- Un chef de projet IT expérimenté côté client — capable de piloter l’intégrateur, de gérer le périmètre et de reporter à la direction avec des indicateurs simples.
- Des référents locaux dans chaque entité pour les projets multi-sites ou multi-pays — relais de communication, garants de l’adéquation aux contraintes locales.
- Une conduite du changement budgétisée dès le départ — ambassadeurs internes identifiés, communication planifiée, formation avant le go-live, supports adaptés aux contextes culturels.
- Un audit des données lancé en semaine 1 — pas en semaine 20 quand il est trop tard pour corriger sans repousser le go-live.
- Un périmètre figé et défendu — avec un processus formel de gestion des demandes de modification incluant l’évaluation d’impact sur le budget et les délais.
Vous avez un projet ERP à lancer ou à reprendre ?
Un premier échange de 30 minutes permet de cadrer les risques et de définir une approche adaptée à votre contexte.
Questions fréquentes — Projet ERP en PME
Combien coûte un projet ERP pour une PME ?
Les fourchettes varient considérablement selon l’ERP et le périmètre : de 30 000 € pour une PME simple avec un ERP cloud SaaS, à plusieurs centaines de milliers d’euros pour un déploiement multi-sites avec personnalisations importantes. La règle générale : prévoyez 1,5 à 2 fois l’estimation initiale de l’intégrateur — les dépassements sont la norme, pas l’exception.
Combien de temps dure un projet ERP en PME ?
Entre 6 et 18 mois pour la phase 1 selon la complexité. Pour un déploiement multi-pays, comptez 18 à 36 mois selon le nombre d’entités et la complexité des processus à harmoniser. Une phase 1 courte et ciblée vaut toujours mieux qu’un projet exhaustif qui n’aboutit pas.
Faut-il choisir un ERP généraliste ou un ERP sectoriel ?
Dépend de votre secteur et de la maturité du marché. Les ERP sectoriels (industrie, BTP, distribution, agences de communication) offrent des fonctionnalités métiers préconfigurées qui réduisent le paramétrage. Les ERP généralistes (SAP, Dynamics, Sage) s’adaptent à des configurations complexes et multi-entités. Le choix dépend de votre contexte spécifique — pas d’une règle universelle.
Comment reprendre un projet ERP en cours d’échec ?
Première étape : un diagnostic rapide — comprendre où en est le projet, ce qui bloque réellement, et distinguer les problèmes techniques des problèmes organisationnels. Dans 80% des cas, les blocages sont organisationnels. Découvrez notre offre de pilotage de projets IT.
AM Consulting 