La méthode agile ne convient pas aux projets ERP. Ce raccourci, souvent entendu en réunion de lancement, reflète une compréhension trop étroite des deux termes. Un ERP n’est pas un produit logiciel que l’on développe de zéro ; Scrum n’est pas une recette magique que l’on plaque sur n’importe quel projet sans adaptation. Mais l’idée que les deux seraient incompatibles par nature est fausse.
Ce guide pratique s’adresse aux chefs de projet ERP, aux DSI et aux consultants qui souhaitent moderniser leur approche méthodologique sans naïveté. Vous verrez comment adapter les principes agiles aux contraintes réelles d’un déploiement ERP : dépendances inter-modules, paramétrage en cascade, go-live unique, et implication des key-users. L’objectif n’est pas de faire du Scrum pur sur SAP S/4HANA, mais de reprendre ce qui fonctionne réellement de l’agile et de l’intégrer intelligemment dans votre projet.
Pourquoi l’ERP résiste à l’agile pur
Le paradoxe ERP et agilité : des contraintes réelles
Un ERP est un système fortement couplé. Le module comptabilité dépend du plan de comptes, qui conditionne la valorisation des stocks, qui elle-même alimente le contrôle de gestion. Cette cascade de dépendances rend difficile le découpage en incréments totalement indépendants, pierre angulaire de Scrum classique. Si un sprint modifie la logique de validation des commandes achats, l’impact se propage immédiatement sur la comptabilité fournisseurs et potentiellement sur le reporting fiscal.
À cela s’ajoute la contrainte du go-live. Dans un projet produit SaaS, on peut livrer une fonctionnalité à 10 % des utilisateurs, mesurer l’adoption, corriger, puis élargir. Dans un déploiement ERP, le jour J est souvent binaire : soit tout le monde bascule, soit personne. Un ERP à moitié déployé n’a pas de valeur opérationnelle. Cela contredit le principe agile du “livrable utilisable à chaque sprint”.
Enfin, les éditeurs ERP eux-mêmes ont historiquement structuré leurs implémentations sur des modèles en cascade. SAP proposait une approche ASAP en phases linéaires depuis les années 1990. Microsoft Sure Step, la méthodologie officielle pour Dynamics, suivait le même modèle séquentiel. Ces méthodes ont façonné les habitudes des intégrateurs pendant vingt ans.
Ce que les projets waterfall classiques ratent systématiquement
Le modèle waterfall en ERP produit des livrables tardifs et des retours utilisateurs trop rares. La phase de recette arrive après des mois de paramétrage, alors que les key-users découvrent pour la première fois ce que l’équipe projet a construit. Les écarts entre ce qui a été spécifié et ce qui est nécessaire en pratique émergent tardivement, quand les corrections coûtent cher.
Le deuxième problème est l’accumulation de la dette de validation. Dans un projet waterfall typique, les processus sont validés sur papier en conception, puis de nouveau lors des tests de recette. Entre les deux, pendant la phase de réalisation, l’équipe métier n’est pratiquement pas impliquée. Résultat : des mois de travail sur des hypothèses que personne n’a testé en conditions réelles.
L’agile ne résout pas ces problèmes par magie, mais il force à les traiter plus tôt et plus fréquemment.
Trois modèles d’agilité adaptée au projet ERP
Scrum adapté : sprints de 3 semaines centrés sur un périmètre fonctionnel
La première adaptation concerne la durée et l’unité d’un sprint. Un sprint Scrum classique dure 1 à 4 semaines et vise un incrément logiciel livrable. En contexte ERP, un sprint de 3 semaines centré sur un périmètre fonctionnel est plus pertinent qu’un sprint de 2 semaines sur du code brut.
Concrètement : un sprint couvre la configuration d’un processus métier précis (par exemple, le cycle complet “commande achat - réception - facture fournisseur” sur l’ERP cible), sa validation par les key-users concernés, et la documentation du paramétrage réalisé. Ce n’est pas toujours un “livrable utilisateur final” au sens strict, mais c’est une configuration validée et documentée, ce qui constitue un avancement réel.
Un industriel de 200 personnes déployant Odoo v17, par exemple, peut organiser ses sprints autour des modules dans l’ordre suivant : achats et stock en sprints 1 et 2, ventes et CRM en sprint 3, comptabilité en sprint 4. Cette séquence respecte les dépendances fonctionnelles tout en forçant des validations régulières.
SAFe (Scaled Agile Framework) pour les déploiements multi-sites
Pour les projets de grande envergure couvrant plusieurs entités, plusieurs pays ou plusieurs métiers simultanément, Scrum seul ne suffit pas. SAFe (Scaled Agile Framework) propose un cadre de coordination entre plusieurs équipes agiles qui travaillent en parallèle.
Dans un contexte ERP multi-sites, SAFe permet de synchroniser les sprints de différentes équipes (par exemple, une équipe finance, une équipe logistique, une équipe RH) via des “Program Increments” (PI) de 10 à 12 semaines. Chaque PI se termine par une revue d’ensemble et un PI Planning pour le suivant. Les dépendances inter-modules sont gérées au niveau du “PI Board” partagé entre les équipes.
SAFe est pertinent quand le projet implique plus de 5 équipes parallèles et un budget supérieur à 2 millions d’euros. En deçà, son overhead organisationnel dépasse souvent ses bénéfices.
Modèle hybride waterfall/agile : quand il est justifié
Le modèle hybride conserve une phase de cadrage et de conception en mode waterfall (définition du périmètre, choix des modules, cartographie des processus cibles), puis bascule en mode agile pour la phase de réalisation et de test. Ce modèle est particulièrement adapté quand :
- les contraintes réglementaires imposent une documentation exhaustive avant tout développement (secteur bancaire, pharmaceutique, défense) ;
- le go-live est multi-pays simultané et ne supporte pas d’incertitude sur le périmètre ;
- l’intégrateur travaille au forfait et a besoin d’un cahier des charges stable pour se protéger contractuellement.
Le risque du modèle hybride est de basculer progressivement vers du waterfall pur, la phase agile se réduisant à une recette déguisée. Pour l’éviter, le Product Owner côté client doit rester impliqué dans les revues de sprint dès la phase de réalisation, même si le cadrage a été fixé en amont.
Le backlog fonctionnel ERP : comment le structurer
User stories vs épics de configuration
En ERP, le backlog ne contient pas des user stories au sens SaaS du terme (“en tant qu’acheteur, je veux pouvoir créer une commande depuis mon mobile”). Le backlog ERP est organisé en épics de configuration correspondant à des processus métier complets, décomposés en stories de paramétrage.
Exemple d’épic : “Processus de commande achat avec validation trois niveaux”. Stories associées : paramétrage des groupes d’approbation, configuration des workflows d’autorisation, création des types de commandes, paramétrage des devises et des taxes, tests du cycle complet avec les key-users.
Cette granularité permet d’estimer l’effort en jours-consultants par story, de prioriser les stories bloquantes pour les dépendances modules, et de tracer l’avancement réel en sprints.
Prioriser avec la technique MoSCoW dans un contexte ERP
La technique MoSCoW (Must have, Should have, Could have, Won’t have) s’applique bien au backlog ERP, mais avec une nuance importante : en ERP, un “Must have” est souvent imposé par la réglementation ou par les processus noyau de l’entreprise, pas par la préférence utilisateur.
Un processus fiscal (DAS2, TVA intracommunautaire, FEC en France) est toujours Must have, même si les utilisateurs s’en moquent. Un portail fournisseur self-service est typiquement un Could have pour une première mise en production.
La règle pratique : si l’absence de la fonctionnalité empêche l’entreprise de fonctionner légalement ou opérationnellement le jour du go-live, c’est un Must have. Tout le reste peut être différé.
Gérer les dépendances entre modules
Les dépendances inter-modules en ERP suivent une logique assez stable : la comptabilité générale est en aval de presque tous les modules transactionnels (achats, ventes, stock, paie). Le paramétrage du plan de comptes et des règles comptables doit donc précéder la configuration des modules qui génèrent des écritures.
Un outil simple pour visualiser ces dépendances : un tableau de précédence des modules. Pour chaque module, on liste les modules qui doivent être validés avant lui. Ce tableau pilote la séquence des sprints et les dépendances entre équipes dans un contexte SAFe.
Les cérémonies Scrum adaptées au contexte ERP
Sprint planning : comment découper en incréments livrables en ERP
La difficulté du sprint planning en ERP est de définir ce qui est “livrable” à la fin du sprint. Un module ERP n’est pas livrable tant que tous ses processus cœur ne sont pas configurés et validés. La solution est de définir des “tranches verticales” à l’intérieur d’un module.
Pour le module achats par exemple : sprint 1 couvre le cycle achats de base (bon de commande, réception, facture) pour les fournisseurs domestiques ; sprint 2 ajoute les fournisseurs intra-UE avec la TVA intracommunautaire et le suivi des acomptes. Chaque sprint produit un sous-ensemble fonctionnel qui peut être validé indépendamment.
Sprint review avec les key-users : format pratique
La sprint review est la cérémonie la plus précieuse du cycle Scrum en ERP. Elle réunit les key-users métier concernés par le périmètre du sprint (pas toute l’entreprise, juste les 3 à 5 personnes qui vont valider le processus configuré). Durée recommandée : 2 heures maximum.
Format type : 15 minutes de rappel du périmètre du sprint, 60 minutes de démonstration interactive sur l’environnement de recette (le consultant pilote, le key-user valide ou challenge), 30 minutes de priorisation des points ouverts pour le sprint suivant, 15 minutes de vote de validation du sprint.
La validation doit être formalisée par écrit : un PV de sprint signé par le key-user représente un engagement, pas une simple impression de réunion.
Rétrospective après chaque module mis en production
La rétrospective post-module est différente de la rétrospective de sprint. Elle intervient quand un module complet est mis en production partielle (go-live d’un module sur le périmètre, avant le go-live global) ou quand tous les sprints d’un module sont terminés. Elle interroge trois dimensions : ce qui a bien fonctionné dans l’organisation du travail, les blocages récurrents, et les ajustements à apporter pour les modules suivants.
Definition of Done (DoD) pour un module ERP configuré
Le DoD en ERP doit couvrir au minimum : la configuration dans l’environnement de recette est documentée (captures d’écran, description des règles paramétrées), les tests du cycle complet ont été réalisés et leurs résultats sont tracés, les key-users concernés ont validé le sprint review, les données de test ont été purgées et les données de référence migrées dans le scénario testé.
Sans DoD explicite, les sprints finissent “à peu près finis” et l’effet de queue-de-poisson rallonge les projets de plusieurs semaines en fin de réalisation.
Cinq erreurs à éviter quand on mélange agile et ERP
1. Vouloir faire du Scrum pur sur SAP S/4HANA sans adapter. SAP Activate, la méthodologie officielle SAP pour S/4HANA, est déjà une approche hybride avec des phases claires (Discover, Prepare, Explore, Realize, Deploy, Run). Elle intègre des “Fit-to-Standard Workshops” qui jouent le rôle de sprint reviews. Essayer de plaquer un Scrum vanilla par-dessus génère des conflits entre les artefacts Activate (Accelerators, Templates) et les artefacts Scrum (Product Backlog, Sprint Backlog). Mieux vaut enrichir Activate d’éléments agiles que de repartir de zéro.
2. Négliger la gestion documentaire. Un backlog n’est pas une documentation de paramétrage. La décision de configurer un compte d’attente pour la TVA sur encaissements doit être tracée dans un document de configuration, pas seulement dans un commentaire de ticket Jira. Sans cette documentation, chaque prestataire qui touche au système après le go-live repart de zéro.
3. Oublier les tests de non-régression à chaque sprint. Quand le sprint 4 configure le module comptabilité, il peut modifier des paramètres qui affectent les modules achats et ventes configurés en sprints 1 et 2. Sans tests de non-régression systématiques, ces régressions ne sont découvertes qu’en recette globale, trop tard pour les traiter sereinement.
4. Sous-estimer la courbe d’apprentissage des key-users. Les key-users impliqués dans les sprint reviews doivent apprendre l’ERP en même temps qu’ils valident. Participer à une revue de sprint sur un module que l’on ne maîtrise pas encore est épuisant. Il faut prévoir des sessions de formation avant chaque cycle de sprints sur un nouveau module, pas uniquement une formation globale en fin de projet.
5. Confondre vélocité Scrum et avancement ERP. La vélocité Scrum mesure le volume de travail livré par sprint. En ERP, un sprint peut avoir une faible vélocité (peu de stories fermées) parce qu’une décision de gestion bloque la configuration, pas parce que l’équipe est inefficace. La communication d’avancement auprès des sponsors doit distinguer clairement les stories bloquées par des choix métier non arbitrés.
Outillage recommandé
Jira, Azure DevOps, Linear ou Notion pour le backlog ERP
Jira reste l’outil le plus répandu pour les backlogs ERP, notamment parce que de nombreux intégrateurs SAP et Microsoft l’utilisent nativement. Azure DevOps est souvent préféré dans les environnements Microsoft (Dynamics 365). Linear convient bien aux projets Odoo ou NetSuite portés par des équipes tech agiles. Notion est acceptable pour les petits projets (moins de 5 modules, une seule équipe) mais montre ses limites sur les backlogs complexes avec dépendances.
Quel que soit l’outil, le minimum syndical est le suivant : hiérarchie épics / stories / sous-tâches, traçabilité des dépendances entre stories, statuts configurables pour refléter le cycle de vie ERP (À paramétrer, En cours, En attente validation, Validé, Fermé), et un champ “module” pour filtrer le backlog par périmètre fonctionnel.
Template de sprint planning adapté
Un sprint planning ERP efficace commence par la liste des stories du sprint (issues du backlog priorisé), la désignation du consultant responsable de chaque story, l’identification des dépendances avec d’autres modules ou d’autres équipes, et la définition explicite du critère de validation côté key-user. Le plan de sprint doit être partagé avec les key-users au moins 48 heures avant le lancement, afin qu’ils puissent bloquer leur agenda pour la sprint review.
La donnée de paramétrage elle-même doit être versionnée. Les exports de configuration (XML Odoo, fichiers de transport SAP, packages de déploiement Dynamics) doivent être stockés dans un dépôt versionné (Git ou équivalent). Sans cette discipline, le projet accumule une dette de traçabilité qui explose lors des montées de version ou des correctifs post-go-live.
La méthode agile adaptée à l’ERP ne promet pas moins de complexité. Elle promet des retours utilisateurs plus fréquents, une capacité à détecter les écarts plus tôt, et une organisation qui force la collaboration régulière entre l’équipe projet et les métiers. Ces trois bénéfices valent largement l’effort d’adaptation méthodologique.
Pour aller plus loin, consultez notre guide sur les 5 phases d’un projet ERP réussi, qui détaille les livrables et jalons de chaque étape, et notre article sur l’équipe projet ERP : rôles clés et matrice RACI, qui précise les responsabilités du Product Owner côté client dans un contexte agile.
