60%
des projets ERP en PME dépassent le budget initial de plus de 50%,
les délais de plus de 6 mois, ou n'atteignent pas leurs objectifs fonctionnels.
Source : Panorama Consulting, Gartner — données consolidées 2020-2025

Ce chiffre est stable depuis une décennie. Il ne reflète pas un problème de qualité des éditeurs ou des intégrateurs — il reflète une réalité structurelle : dans la grande majorité des projets ERP en PME, il n'y a pas de chef d'orchestre côté client. Il y a une direction générale qui valide, un responsable informatique qui suit les tickets, et un intégrateur qui pilote. Mais personne pour piloter l'intégrateur.

Les 5 causes d'échec documentées

Un périmètre mal défini en amont

Le projet démarre sans cahier des charges fonctionnel sérieux. Les demandes d'évolution s'accumulent en cours de route (change requests), chaque modification impacte le planning et le budget. En fin de projet, le périmètre livré n'est plus celui qui avait été contractualisé.

Un choix d'éditeur basé sur la démonstration commerciale

Les démos ERP sont conçues pour convaincre, pas pour refléter la réalité de votre environnement. Sans scénarios de test basés sur vos propres cas d'usage et vos données réelles, vous signez sur la foi d'une présentation PowerPoint.

Une contractualisation insuffisante

Contrats trop généraux, absence de jalons binaires (livré / non livré), absence de critères d'acceptation précis, clauses de réversibilité absentes. Quand le projet dérive, l'entreprise n'a souvent aucun levier contractuel.

Absence de sponsor décisionnel actif

Un projet ERP touche tous les processus de l'entreprise. Il nécessite des arbitrages constants entre les directions. Sans sponsor au niveau du CODIR, capable de décider et de faire décider, les blocages s'accumulent.

Sous-estimation de la gestion du changement

Les équipes opérationnelles sont rarement impliquées assez tôt. La formation arrive trop tard ou est insuffisante. Le taux de rejet utilisateur plombe les premiers mois — et les ROI initiaux ne se matérialisent pas.

Le rôle du DSI dans un projet ERP : chef d'orchestre, pas exécutant

Un DSI n'implémente pas l'ERP. C'est le rôle de l'intégrateur. Le DSI construit les conditions dans lesquelles l'intégrateur peut réussir — et sait intervenir quand ce n'est pas le cas. Cette distinction est fondamentale et souvent incomprise.

Les 5 phases où le DSI est décisif

1
Cadrage stratégique

Définir les processus cibles, les besoins fonctionnels réels (pas les spécifications logicielles), les intégrations requises, le budget total ownership incluant licences, intégration, formation et maintenance.

2
Appel d'offres structuré

Rédaction d'un cahier des charges fonctionnel, consultation de 3 à 5 éditeurs, grille de scoring pondérée, démonstrations cadrées sur vos cas d'usage réels — pas sur les démos commerciales standard.

3
Contractualisation rigoureuse

Contrat à jalons avec critères d'acceptation précis, clauses de réversibilité, pénalités de retard, délimitation claire du périmètre. Le contrat ERP est un document critique que peu d'entreprises font relire par un juriste IT.

4
Gouvernance de projet

Comité de pilotage mensuel avec KPIs, gestion des demandes de changement, interlocuteur unique côté client. Le DSI est le chef d'orchestre — il ne fait pas le travail à la place des équipes, il s'assure que le projet avance dans le bon sens.

5
Recette et déploiement

Plan de recette fonctionnelle impliquant les utilisateurs finaux, phases de parallel run, plan de formation, plan de bascule avec retour arrière possible. La go-live n'est pas la fin — c'est le début d'une phase de stabilisation critique.

Les signaux d'alerte en cours de projet

Un DSI expérimenté sait reconnaître les signaux qui annoncent un projet en difficulté — et intervenir avant que la situation soit irrémédiable :

  • L'intégrateur demande des décisions fonctionnelles que vous n'avez pas les moyens de prendre seul
  • Les délais glissent sans explication claire ni plan de rattrapage documenté
  • Les coûts dépassent le budget sans avenant formalisé
  • Les key users ne participent pas aux ateliers de paramétrage
  • Il n'y a pas d'environnement de recette distinct de la production
  • La formation est prévue « juste avant le go-live »

Conclusion

Un projet ERP réussi n'est pas un projet sans problème — c'est un projet dont les problèmes sont identifiés et traités avant de devenir des blocages. Cette capacité d'anticipation est la marque d'une gouvernance de projet mature.

La prochaine fois que vous envisagez un projet ERP, la bonne question à poser n'est pas « quel éditeur choisir ? » — c'est « qui, côté client, va piloter ce projet de bout en bout ? »