Pour une PME, l’approche modulaire consiste à déployer son ERP domaine par domaine (par exemple les stocks, puis les ventes, puis la facturation) plutôt que de remplacer tout le système d’information le même jour. Elle réduit le risque, livre de la valeur dès les premiers mois et permet d’ajuster la suite du projet à partir de l’usage réel. Sa contrepartie est une période de coexistence entre l’ancien et le nouveau système, qui doit être organisée avec soin. Dans la grande majorité des PME, c’est la stratégie la plus sûre.
Voici comment la mettre en œuvre : ordre des modules, architecture, données, et les situations où le big bang reste justifié.
Qu’est-ce qu’un ERP, et pourquoi le projet fait-il peur ?
Un ERP (Enterprise Resource Planning) est un système qui réunit dans un même outil, avec une base de données commune, les grands processus de gestion de l’entreprise : ventes, achats, stocks, production, facturation, parfois comptabilité et ressources humaines. Son intérêt principal : une seule version de chaque donnée, partagée par tous les services.
Le projet fait peur à juste titre. KPMG décrit un projet ERP pour une ETI ou une PME comme mobilisant sur une période de 12 à 24 mois l’ensemble des équipes métiers et informatiques, et souligne que l’organisation humaine du projet est « une raison majeure de l’échec » (KPMG). Pendant ce temps, l’entreprise doit continuer à vendre, produire et facturer.
Big bang ou modulaire : quelles différences concrètes ?
Le big bang remplace l’existant en une seule fois. Le déploiement modulaire (on parle aussi de déploiement progressif ou par lots) met en service un domaine après l’autre.
| Critère | Big bang | Approche modulaire |
|---|---|---|
| Date de mise en service | Une seule, pour tout le périmètre | Plusieurs, une par module |
| Concentration du risque | Maximale : tout se joue le jour J | Répartie : chaque module est un test grandeur nature |
| Premiers bénéfices | À la fin du projet | Dès le premier module |
| Charge sur les équipes | Pic très fort avant et après la bascule | Étalée, service par service |
| Coexistence ancien et nouveau | Aucune (ou très courte) | Plusieurs mois, avec échanges de données temporaires |
| Capacité à corriger le tir | Faible une fois les choix figés | Élevée : on apprend à chaque module |
| Cas favorable | Petite structure, processus simples, système existant à l’agonie | La plupart des PME et ETI |
Martin Fowler, référence en architecture, a popularisé ce principe de remplacement progressif sous le nom de « strangler fig » (le figuier étrangleur) : le nouveau système grandit autour de l’ancien et reprend ses fonctions une à une. Il note que les remplacements « tout d’un coup » échouent souvent, notamment parce que le comportement de l’existant est difficile à spécifier et que les utilisateurs ne peuvent pas attendre des années les nouvelles fonctionnalités (Martin Fowler). Nous détaillons la méthode dans notre article sur la modernisation d’une application historique.
Le mouvement de fond : du monolithe au cœur léger
L’approche modulaire n’est pas qu’une méthode de projet ; c’est aussi une tendance d’architecture. SAP rappelle que Gartner a forgé le terme ERP en 1990, puis décrit dès 2014 l’« ERP postmoderne », où le monolithe unique cède la place à des architectures fédérées. Le terme plus récent d’ERP composable désigne des capacités modulaires, connectées par API, que l’on peut réassembler quand les besoins changent (SAP).
Pour une PME, la traduction est simple : un cœur de gestion solide (référentiels, facturation, comptabilité) et, autour, des modules spécialisés, du marché ou sur mesure, qui communiquent proprement. C’est la logique que nous suivons dans nos projets d’ERP et de back-office sur mesure.
Par quel module commencer ?
L’intuition pousse souvent à commencer par la comptabilité ou par « le socle ». C’est rarement le meilleur choix : la comptabilité fonctionne généralement, elle est très normée, et ses utilisateurs ne voient pas de gain immédiat. Le bon premier module combine trois caractéristiques :
- Une douleur métier forte et visible : ressaisies massives, erreurs fréquentes, délais qui pénalisent les clients.
- Des dépendances limitées : le module peut fonctionner avec peu d’échanges vers l’ancien système.
- Un périmètre maîtrisable : livrable en quelques sprints, avec un groupe d’utilisateurs identifié.
Prenons une entreprise de négoce hypothétique de 80 personnes. Ses commandes sont saisies dans un vieil outil de gestion commerciale, ses stocks suivis dans des tableurs, sa comptabilité tenue dans Sage. Elle commence par un module stocks et réceptions : la douleur est quotidienne (ruptures, inventaires faux), le périmètre est clair, et il suffit d’un flux vers l’outil commercial pour publier les disponibilités. Viennent ensuite les commandes et devis, puis la facturation connectée à la plateforme agréée, la comptabilité restant dans Sage via un connecteur. Les secteurs comme la distribution et le négoce se prêtent particulièrement bien à ce découpage.
Comment découper l’ERP en modules cohérents ?
Un module bien découpé correspond à un domaine métier qui a son propre vocabulaire et ses propres règles. En conception, on parle de « contexte délimité » (bounded context) : une frontière à l’intérieur de laquelle chaque terme a un sens précis. Martin Fowler cite l’exemple d’une entreprise d’électricité où le mot « compteur » désignait trois choses différentes selon les services (Martin Fowler). Dans une PME, « client » ou « article » posent souvent le même problème entre le commerce, la logistique et la comptabilité.
Concrètement, chaque module :
- possède ses données et ses règles, et expose ce dont les autres ont besoin par une interface documentée (API) ;
- partage le référentiel commun (clients, articles, fournisseurs, sites) plutôt que d’en créer une copie ;
- peut être mis en service, testé et amélioré sans immobiliser les autres.
Le référentiel avant tout
Le référentiel commun est la fondation. Si les codes articles sont dupliqués ou les fiches clients incohérentes, chaque nouveau module importera le désordre. Fiabiliser ces données de référence (dédoublonnage, identifiants uniques, règles de création) est la première étape, avant même le premier module. Notre article sur les données de référence détaille la démarche.
Organiser la coexistence entre l’ancien et le nouveau
C’est la partie qui demande le plus de rigueur. Pendant plusieurs mois, deux systèmes vivent côte à côte. Il faut décider, pour chaque donnée, quel système fait foi et comment l’autre est tenu informé.
| Question | Exemple de réponse à formaliser |
|---|---|
| Qui crée un nouvel article ? | Le nouveau module stocks ; l’ancien outil le reçoit chaque nuit |
| Qui fait foi pour le stock disponible ? | Le nouveau module, interrogé en temps réel par l’outil commercial |
| Que se passe-t-il si un échange échoue ? | Alerte au référent, reprise automatique, journal consultable |
| Quand l’échange temporaire disparaît-il ? | À la mise en service du module commandes |
Ces échanges temporaires sont du code destiné à disparaître. Fowler les appelle une architecture de transition et rappelle qu’ils semblent un gaspillage mais que la réduction du risque les justifie largement. Les budgéter dès le départ évite une mauvaise surprise.
La reprise des données, elle, se fait module par module, ce qui la rend plus maîtrisable qu’une migration globale. Notre checklist de migration de données s’applique à chaque lot.
Les pièges de l’approche modulaire
L’approche modulaire n’est pas magique. Elle échoue pour des raisons identifiables :
- Un découpage technique plutôt que métier : des modules « base de données », « écrans », « API » ne livrent aucune valeur aux utilisateurs.
- Une coexistence qui s’éternise : sans calendrier de décommissionnement, l’entreprise maintient deux systèmes indéfiniment.
- Des modules trop petits qui multiplient les échanges et les bascules, ou trop gros, qui recréent un mini big bang.
- Un pilotage absent : sans comité qui arbitre l’ordre des modules et suit les indicateurs, le projet dérive au gré des urgences.
- Une conduite du changement oubliée : chaque module change les habitudes d’un service ; la conduite du changement se rejoue à chaque lot.
Quand le big bang reste-t-il le bon choix ?
Il existe des cas où une bascule unique est préférable : une très petite structure dont les processus tiennent en quelques écrans, un système existant qui ne peut plus être maintenu du tout, une contrainte réglementaire à date fixe qui impose de tout changer, ou des processus si imbriqués qu’aucun découpage ne tient. Même dans ces cas, une migration à blanc complète et une période de fonctionnement en parallèle réduisent le risque.
Si vous hésitez entre un ERP du marché et un développement spécifique, notre comparatif Odoo ou ERP sur mesure présente les deux options avec honnêteté. Et pour identifier le premier module qui apportera le plus de valeur chez vous, décrivez votre organisation dans notre diagnostic de projet : nous vous proposerons un premier découpage.
