Le forfait rassure : un périmètre, un prix, une date et un prestataire qui s’engage. Mais dans un projet ERP, cette apparente certitude peut masquer le principal risque : l’entreprise découvre ses véritables besoins pendant le déploiement, alors que le contrat suppose qu’ils étaient déjà connus.
Le sujet n’est donc pas de choisir entre forfait et régie. Il est de construire une gouvernance qui permette de décider rapidement, de traiter les écarts sans conflit permanent et de garder la maîtrise du résultat métier.
La promesse qu’on entend partout
La promesse du projet ERP au forfait est simple : vous décrivez le résultat attendu, l’intégrateur chiffre le travail et assume les efforts nécessaires pour livrer. Votre budget serait ainsi sécurisé, tandis que la responsabilité opérationnelle serait transférée au fournisseur.
Ce discours n’est pas absurde. Un forfait bien préparé peut apporter :
- un engagement contractuel sur des livrables identifiés ;
- un calendrier de référence partagé ;
- une procédure de validation ;
- une visibilité budgétaire supérieure à une intervention entièrement facturée au temps passé.
Pour un dirigeant, la proposition est séduisante. Il n’a pas à arbitrer chaque journée de paramétrage et peut comparer plusieurs offres sur une base commune. Un cahier des charges construit selon la bonne méthode facilite effectivement cette comparaison.
Le problème commence lorsque le mot « forfait » est compris comme « risque supprimé ». Il signifie seulement que certaines responsabilités ont été réparties dans un contrat. Il ne garantit ni la qualité des données, ni la disponibilité des équipes internes, ni la pertinence des processus retenus.
Ce qui est vrai
Dans un périmètre stable, vérifiable et suffisamment documenté, le forfait oblige utilement le fournisseur à formaliser ses hypothèses. Il doit préciser ce qu’il configure, ce qu’il développe, ce qu’il migre et ce qu’il exclut.
Cette discipline peut empêcher un projet de dériver par accumulation de demandes informelles. Elle donne également au comité de pilotage une référence pour distinguer une anomalie — le logiciel ne respecte pas ce qui était prévu — d’une évolution — l’entreprise souhaite désormais autre chose.
Le forfait est particulièrement pertinent pour des livrables observables : installation d’un environnement, configuration d’un flux défini, reprise d’un jeu de données identifié, production d’une interface ou remise d’un dossier d’exploitation. Il fonctionne moins bien lorsque le résultat dépend encore de décisions métier non prises.
La méthode européenne PM² illustre cette distinction en séparant notamment la charte du projet, le plan de travail, le plan d’acceptation des livrables, la gestion des exigences, le plan de changement et les journaux de risques et de décisions. Ces documents sont disponibles dans les modèles officiels PM² de la Commission européenne.
Autrement dit, un prix fixe ne remplace pas le pilotage. Il fonctionne parce qu’un dispositif de pilotage permet de maintenir ou de modifier consciemment la référence contractuelle.
Ce qui est faux, ou seulement vrai sous conditions
La première idée fausse consiste à croire que l’intégrateur porte seul le risque. Il ne contrôle pourtant pas la disponibilité de votre responsable comptable, la qualité de votre référentiel articles ou la capacité des responsables de service à choisir entre deux procédures contradictoires.
La deuxième consiste à penser que les besoins sont figés après la signature. Les ateliers révèlent souvent des exceptions, des fichiers parallèles, des validations orales ou des règles différentes selon les établissements. Ce ne sont pas nécessairement des erreurs du cahier des charges : certaines réalités ne deviennent visibles qu’en confrontant le futur ERP au travail quotidien.
La troisième consiste à confondre « inclus au périmètre » et « adapté à l’usage ». Une fonction peut être livrée conformément au contrat tout en imposant trop de manipulations, en produisant des données difficiles à exploiter ou en déplaçant la charge vers un autre service. La conformité contractuelle ne suffit donc pas à établir la valeur opérationnelle.
Enfin, un forfait ne protège que si ses hypothèses sont lisibles. Une phrase comme « reprise des données clients » ne dit pas :
- qui dédoublonne les fiches ;
- quel historique doit être conservé ;
- comment sont traitées les données incomplètes ;
- qui valide les règles de rapprochement ;
- ce qui se passe lorsque la source ne respecte pas le format annoncé.
Sans réponse, le risque n’a pas disparu. Il a été repoussé vers une discussion ultérieure sur ce qui était « implicitement compris ».
C’est aussi pourquoi le choix du dispositif de direction reste distinct du choix de l’intégrateur. Notre comparaison entre DSI partagée, freelance et intégrateur pour piloter un projet IT détaille ces responsabilités différentes.
Ce que ça coûte quand on y va sans préparation
Le premier coût est le temps de décision. Lorsque personne n’a reçu le pouvoir d’arbitrer une règle de gestion, l’intégrateur attend, avance sur une hypothèse ou configure plusieurs variantes. Dans les trois cas, l’entreprise consomme du budget sans réduire l’incertitude.
Le deuxième coût est la multiplication des avenants. Chaque découverte devient une négociation commerciale, y compris lorsqu’elle aurait pu être identifiée pendant le cadrage. Le comité de pilotage finit alors par discuter davantage de la qualification contractuelle des demandes que du résultat métier.
Le troisième coût est la dette technique. Pour tenir la date annoncée, les équipes peuvent empiler des développements spécifiques, des imports manuels ou des interfaces provisoires. Ces solutions doivent ensuite être maintenues, testées lors des mises à jour et expliquées aux nouveaux collaborateurs.
Le quatrième coût est une dépendance accrue envers le fournisseur. Si les décisions, les paramétrages et les règles de reprise ne sont pas documentés côté client, changer d’intégrateur devient difficile. L’entreprise possède juridiquement son projet, mais ne sait plus expliquer précisément comment il fonctionne.
Prenons un scénario type, à titre d’illustration : une direction commerciale demande pendant le paramétrage que les remises soient contrôlées différemment selon le canal de vente. Sans responsable métier désigné, registre de décision et analyse d’impact, l’intégrateur peut soit bloquer le sujet, soit appliquer une règle partielle, soit proposer un développement supplémentaire. Le problème n’est pas uniquement technique : il vient de l’absence de mécanisme pour décider.
Une recette fonctionnelle préparée avant la signature du procès-verbal permet de détecter une partie de ces écarts. Elle intervient néanmoins trop tard si les arbitrages structurants n’ont jamais été rendus.
La façon raisonnable d’y aller
Cadrer avant de demander un prix ferme
Le dirigeant sponsorise une phase de découverte menée par le responsable de projet avec les propriétaires des processus concernés. Le Service Manual de GOV.UK indique qu’une découverte dure typiquement de quatre à huit semaines, en adaptant sa longueur au problème étudié.
Le livrable attendu n’est pas une présentation générale. Il comprend la version approuvée du périmètre, les exclusions, les processus concernés, les interfaces, les sources de données, les hypothèses du chiffrage et la liste des décisions encore ouvertes. Le prix ferme ne doit porter que sur ce qui est suffisamment déterminé.
Attribuer chaque décision à une personne nommée
Le sponsor désigne un responsable pour chaque domaine : finance, ventes, achats, stocks, données et infrastructure selon le périmètre. Ces responsables ne donnent pas seulement un avis. Ils valident les règles, acceptent les compromis et rendent leurs décisions traçables pendant toute la construction.
Le chef de projet tient un registre indiquant la question, les options examinées, l’impact, le décideur et la décision retenue. PM² prévoit précisément des journaux de changement, de décision, de risque et de problème parmi ses outils de gouvernance de projet.
Lundi matin, demandez donc la liste des décisions ouvertes et le nom de la personne habilitée à trancher chacune d’elles. Si une ligne n’a pas de propriétaire, elle constitue déjà un risque projet.
Organiser les changements plutôt que les interdire
Pendant toute la réalisation, chaque demande nouvelle doit être décrite dans une fiche courte : besoin d’origine, raison du changement, utilisateurs concernés, impact sur les données, coût, calendrier, risques et options de contournement.
Le comité de pilotage peut alors accepter, refuser, différer ou regrouper la demande dans une version ultérieure. Ce mécanisme ne vise pas à ralentir le projet. Il évite qu’une conversation d’atelier devienne silencieusement un engagement de livraison.
La Commission européenne décrit la gestion du changement comme un processus d’identification, de documentation, d’évaluation, d’approbation, de planification et de contrôle dans son guide PM² consacré au pilotage des changements.
Piloter les données comme un chantier autonome
Le responsable métier des données, et non l’intégrateur seul, valide les correspondances entre ancien et nouveau système. Il arbitre les doublons, les valeurs manquantes, l’historique utile et les règles d’archivage.
Le projet doit produire un dictionnaire de données, un fichier de correspondance, un rapport de rejets, une procédure de rapprochement et un résultat de migration à blanc. Ce chantier s’étend de la conception jusqu’à la stabilisation suivant la mise en service.
Reporter le nettoyage à la migration finale revient à découvrir la qualité réelle du carburant au moment de démarrer le moteur.
Conditionner les paiements à des preuves acceptées
Le sponsor et le chef de projet associent les échéances contractuelles à des livrables vérifiables : dossier de conception validé, processus configuré et testé, reprise rapprochée avec la source, scénarios de recette exécutés, anomalies critiques traitées, documentation d’exploitation transmise.
Un avancement déclaré ne vaut pas une acceptation. Le paiement doit refléter la disponibilité d’un résultat contrôlable par l’entreprise, conformément à un plan d’acceptation défini avant la réalisation.
Si votre entreprise ne dispose pas de DSI, notre article sur le pilotage d’un projet IT sans direction informatique interne précise les responsabilités qui doivent malgré tout rester côté client.
Notre position chez D1 Consulting
Le forfait est un outil contractuel utile, mais une mauvaise stratégie de transfert du risque. Plus un projet ERP touche aux règles de gestion, aux données et aux habitudes de travail, moins il peut être piloté par le seul contrat.
Notre position est donc de séparer clairement le périmètre stabilisé, qui peut être forfaitisé, des décisions encore ouvertes, qui doivent être instruites et arbitrées. Nous intervenons en représentation du client pour cadrer le projet, organiser la gouvernance, challenger les estimations, piloter les changements, préparer la recette et sécuriser le passage en exploitation grâce à notre offre de Direction de projet IT et DSI partagée.
👉 Réservez un diagnostic gratuit de 30 minutes pour identifier les zones de risque de votre projet ERP avant de figer le périmètre, le budget ou le contrat.
