Le 2 octobre 2026, Bpifrance Université a publié le replay de sa formation « Projet ERP : anticiper les pièges, se poser les bonnes questions ». Le message central dépasse le choix du logiciel : la réussite dépend aussi de l’organisation du projet, des équipes et des décisions prises avant la mise en production.
Parmi ces décisions, la stratégie de déploiement est structurante. Faut-il remplacer l’ancien système en une seule bascule, procéder par lots métiers ou commencer par un périmètre pilote ? La bonne réponse dépend moins de la taille de l’entreprise que de ses interdépendances, de sa capacité interne à arbitrer et du coût d’une interruption d’activité.
Le choix qui se pose
La décision réelle n’est pas « rapide ou prudent ». Elle consiste à choisir où placer le risque :
- Le big bang concentre le risque sur une bascule unique, mais limite la coexistence entre les systèmes.
- Le déploiement par lots répartit le risque dans le temps, mais prolonge les interfaces temporaires et les doubles traitements.
- Le pilote réduit l’incertitude avant généralisation, mais peut créer un faux sentiment de sécurité si son périmètre n’est pas représentatif.
Avant de valider une méthode, le dirigeant doit demander au responsable du projet un document d’une page répondant à quatre questions : quels flux doivent obligatoirement basculer ensemble, quels processus peuvent fonctionner temporairement dans deux systèmes, quelles données doivent rester synchronisées et quelle procédure permettrait de revenir à l’ancien fonctionnement ?
Ce document doit être validé avant de figer le contrat d’intégration. Sinon, le mode de déploiement sera choisi par défaut selon les habitudes de l’éditeur ou de l’intégrateur. Le risque est comparable à celui décrit dans notre article sur le projet ERP au forfait : transférer une responsabilité contractuelle ne supprime pas les décisions qui restent à la charge de l’entreprise.
Les options en présence
Le big bang
L’ancien système est arrêté et le nouvel ERP devient la référence pour l’ensemble du périmètre à une date commune. Cette méthode évite une longue coexistence entre deux référentiels et réduit les interfaces transitoires.
Elle convient surtout lorsque les processus sont fortement intégrés : commandes, stocks, achats, comptabilité et facturation partagent alors les mêmes données et doivent rester cohérents. En contrepartie, la migration, la recette, les habilitations, la formation et le support doivent être prêts simultanément.
Le déploiement par lots métiers
L’ERP est activé progressivement par processus, établissement, filiale ou population d’utilisateurs. Un lot peut par exemple couvrir le cycle vente-facturation, puis les achats, puis la gestion des stocks.
Le découpage doit suivre des flux métier complets, pas simplement le catalogue de modules de l’éditeur. Activer les ventes sans traiter les données clients, les tarifs, les stocks et les écritures associées peut déplacer les difficultés vers des interfaces provisoires.
France Num recommande notamment un déploiement progressif des fonctionnalités ERP afin de corriger les problèmes au fil de l’adoption et d’éviter une surcharge pour les utilisateurs.
Le pilote avant généralisation
Un site, un service ou une population représentative utilise réellement l’ERP avant son extension. Il ne s’agit pas d’une démonstration : le pilote doit traiter des opérations réelles, avec les interfaces, les données, les droits et le support prévus pour la cible.
Ses critères de sortie doivent être écrits avant le démarrage : scénarios métier exécutés, anomalies bloquantes fermées, rapprochements de données validés, support opérationnel et décisions de paramétrage documentées. Sans ces critères, le pilote peut se prolonger sans produire de décision claire.
Les critères qui comptent vraiment
| Option | Coût | Délai | Dépendance | Compétences internes | Réversibilité |
|---|---|---|---|---|---|
| Big bang | Forte concentration des dépenses de migration, recette et support autour de la bascule | Couverture complète plus rapide si la préparation est achevée | Forte dépendance à l’intégrateur pendant la préparation et le démarrage | Équipe métier disponible pour tester, arbitrer et assister les utilisateurs | Faible après la bascule si l’ancien système est arrêté |
| Lots métiers | Coût étalé, mais interfaces temporaires et licences parallèles possibles | Plus long jusqu’à la couverture totale | Dépendance prolongée à l’ancien système et aux mécanismes de synchronisation | Capacité à administrer temporairement deux modes opératoires | Bonne à l’échelle d’un lot, plus difficile après plusieurs vagues |
| Pilote | Investissement initial limité au périmètre choisi, puis coût d’industrialisation | Généralisation différée par la phase d’apprentissage | Dépendance forte aux utilisateurs pilotes et à la représentativité du périmètre | Référents capables de documenter les écarts et de distinguer défaut local et problème global | Élevée tant que la généralisation n’a pas commencé |
Le coût à comparer n’est donc pas seulement celui du prestataire. Il faut intégrer la disponibilité des référents, les licences maintenues en parallèle, les développements temporaires, les rapprochements manuels, le support renforcé et la remise en état éventuelle de l’ancien système.
Dans quel cas choisir quoi
Choisissez le big bang si toutes les conditions sont réunies
Le périmètre doit être homogène, les processus stabilisés, la reprise de données répétée, les interfaces testées de bout en bout et le retour arrière techniquement réalisable. Les responsables métiers doivent également disposer d’une capacité réelle d’arbitrage.
SAP recommande que les membres clés d’une équipe ERP puissent consacrer au moins 25 % de leur temps au projet, soit environ dix heures par semaine. Si cette disponibilité n’existe pas chez vos responsables finance, opérations, ventes ou logistique, une bascule globale devient difficile à sécuriser, quelle que soit la qualité de l’intégrateur. Cette recommandation et les principales stratégies de déploiement sont détaillées dans le guide SAP sur la mise en œuvre d’un ERP.
Une seule interface critique non testée ou une migration impossible à répéter doit suffire à exclure le big bang jusqu’à correction.
Choisissez les lots métiers si les flux peuvent être séparés
Cette approche est pertinente lorsque chaque vague peut produire un résultat exploitable sans multiplier les ressaisies. Le responsable de projet doit alors fournir, pour chaque lot, une matrice indiquant le système de référence de chaque donnée, les échanges temporaires, le propriétaire du contrôle et la condition de passage au lot suivant.
Prenons un scénario type, à titre d’illustration : les ventes, les stocks et la facturation utilisent le même référentiel d’articles. Un découpage strict par modules risquerait d’imposer des synchronisations complexes. Un lot couvrant tout le flux de la commande à la facture serait plus cohérent, même s’il mobilise plusieurs modules techniques.
Choisissez un pilote lorsque l’incertitude est organisationnelle
Le pilote est adapté lorsque les sites travaillent différemment, que certaines règles métier sont encore discutées ou que l’adhésion des utilisateurs reste incertaine. Le périmètre retenu doit cependant contenir les difficultés que l’on souhaite résoudre ; choisir l’équipe la plus disponible mais la moins représentative ne valide pas le futur déploiement.
Dans un avis relatif à un projet de système financier commun à plusieurs agences publiques, la DINUM a considéré qu’une bascule simultanée de six agences présentait un risque élevé et a recommandé une agence pilote, suivie d’un retour d’expérience avant industrialisation. Ce cas ne fournit pas une règle universelle, mais illustre l’intérêt du pilote lorsque les organisations présentent des spécificités locales. Consulter l’avis de la DINUM.
Retenez une trajectoire hybride si aucune option pure ne convient
Une trajectoire fréquente consiste à tester un flux représentatif, à généraliser ensuite par lots, puis à réaliser une bascule commune pour le noyau qui ne peut pas être fractionné. L’hybride n’est toutefois pas une absence de choix : chaque étape doit avoir un responsable, des critères d’entrée, des critères de sortie et un mécanisme de retour arrière.
Les pièges de chaque option
Le coût caché du big bang
Le principal coût caché est le pic de mobilisation interne. Pendant la bascule, les mêmes personnes doivent contrôler les données, répondre aux utilisateurs, arbitrer les anomalies et assurer l’activité habituelle.
Avant toute répétition générale, le chef de projet doit livrer un plan de bascule ordonnancé, un annuaire d’escalade, une liste des contrôles et une procédure de retour arrière testée. La signature d’un procès-verbal de recette ne remplace pas cette préparation ; notre guide sur la recette fonctionnelle avant signature du PV détaille les contrôles attendus.
Le coût caché des lots
Le provisoire dure souvent plus longtemps que prévu. Les interfaces temporaires deviennent critiques, les référentiels divergent et certains collaborateurs entretiennent deux procédures.
Pour chaque vague, le responsable des données doit tenir un registre de rapprochement : source officielle, fréquence de synchronisation, anomalies ouvertes et date de suppression du dispositif temporaire. Une interface sans date de retrait devient rapidement une composante permanente du système d’information.
Le coût caché du pilote
L’équipe pilote peut demander des adaptations propres à son fonctionnement. Si elles sont intégrées sans arbitrage, le projet industrialise des exceptions au lieu de construire un modèle commun.
Le sponsor doit donc organiser une revue de généralisation à la fin du pilote. Le livrable attendu classe chaque demande en trois catégories : standard commun, variante locale justifiée ou demande refusée. Le pilote n’est terminé que lorsque ces décisions sont documentées.
Comment nous procédons chez D1 Consulting
Notre intervention commence par transformer la discussion « big bang ou progressif » en décision vérifiable. Dans le cadre de notre offre de Direction de projet IT, nous travaillons côté entreprise, indépendamment du planning commercial de l’éditeur ou de l’intégrateur.
Notre méthode produit quatre livrables opérationnels :
- Une note d’arbitrage : options comparées, hypothèses, critères d’exclusion et décision du sponsor.
- Une cartographie des dépendances : processus, données, interfaces, acteurs et systèmes qui doivent basculer ensemble.
- Une trajectoire de déploiement : ordre des vagues, critères de passage, responsabilités métier et conditions de retour arrière.
- Un dossier de mise en production : plan de bascule, contrôles, support, communication et registre des décisions.
Nous organisons ensuite les comités de décision, coordonnons l’intégrateur et les responsables métier, suivons la recette et préparons la conduite du changement. Cette fonction est particulièrement utile lorsque l’entreprise ne dispose pas d’un responsable informatique pouvant consacrer son temps au projet, comme expliqué dans notre article sur le pilotage d’un projet IT sans DSI.
👉 Réservez un diagnostic gratuit de 30 minutes pour comparer vos scénarios de déploiement et repartir avec les décisions à documenter avant votre prochaine bascule.
