Francais

Mode projet vs mode opération dans un ERP : pourquoi la transition est plus difficile que prévu

Alex at FitGap

07 Apr 2026 — 7 min read

Schéma illustrant la transition entre le mode projet et le mode opération dans un projet ERP, avec le go-live comme point de bascule

La plupart des équipes ERP savent piloter un projet. Très peu sont prêtes à piloter un système.

Il y a une différence entre construire un ERP et l'exploiter. Ça paraît évident. Ça ne l'est pas. La confusion entre ces deux états est l'une des sources les plus fiables de chaos post-go-live — dépassements de budget, files de support interminables, ruptures de processus, et une équipe finance qui peine encore à clôturer correctement six mois après le lancement.

Le mode projet a un chef de projet, un plan, un budget et une date de fin. Le mode opération n'a rien de tout ça par défaut. Il doit être construit — délibérément, avant que le projet ne se termine.

La plupart des organisations ne le font pas. Elles supposent que la structure opérationnelle va émerger naturellement une fois le système en production. Elle n'émerge pas.

Cet article décrit ce que chaque mode exige concrètement, où ils entrent en conflit, et ce qu'il faut mettre en place avant le go-live pour survivre à la transition.

1. Ce qu'est vraiment le mode projet

Le mode projet est temporaire par conception. Il existe pour livrer un ERP configuré, testé et déployé. Il se termine au go-live.

Il fonctionne selon une logique de projet. Il y a un périmètre défini. Il y a des flux de travail avec des responsables. Il y a un Comité de pilotage qui prend des décisions avec autorité. Il y a un partenaire d'implantation qui avance sur un plan de livraison. Toute la structure est conçue pour produire un résultat — un système en production — dans un délai défini.

L'équipe projet est optimisée pour livrer, pas pour durer.

Ce n'est pas une critique. C'est le bon design pour un projet. Mais ça crée un problème structurel : tout dans le mode projet est court-termiste. Les consultants sont sous contrat pour la durée. Les utilisateurs clés sont détachés de leur poste habituel. Les décisions se prennent vite parce que la vitesse est l'objectif. La dette technique est documentée comme « phase 2 ». Les choix de configuration sont verrouillés sans analyse complète des conséquences opérationnelles.

Le partenaire d'implantation part après le go-live. Le Comité de pilotage se dissout. Le chef de projet passe à la prochaine mission. Ce qui reste, c'est un système, des utilisateurs, et — si vous avez de la chance — de la documentation.

→ Voir aussi : Parcours d'implantation ERP : de la conception au go-live

→ Voir aussi : Vérités sur le partenaire d'implantation ERP

2. Ce qu'est vraiment le mode opération

Le mode opération est permanent. Il commence au go-live et n'a pas de date de fin.

Il fonctionne selon une logique de processus. Le système doit produire des données financières correctes chaque jour, chaque période, chaque année. La clôture mensuelle doit se faire. Les paiements fournisseurs doivent sortir. L'amortissement des immobilisations doit être validé. Les pistes d'audit doivent être complètes. Le reporting réglementaire doit être exact.

En mode opération, il n'y a pas de chef de projet à qui escalader. Il n'y a que le métier.

C'est le changement que la plupart des équipes sous-estiment. En mode projet, quand quelque chose casse, il y a une cellule de crise, une période d'hypercare et une équipe de consultants disponibles. En mode opération, quand quelque chose casse, il faut une structure de support interne — un service d'assistance, un administrateur ERP, un responsable fonctionnel qui gère la configuration, un processus pour enregistrer et traiter les incidents.

Cette structure ne se construit pas toute seule. Elle exige une conception délibérée avant que le projet ne se ferme.

L'équipe finance fonctionne aussi différemment dans ce mode. Pendant l'implantation, l'attention se porte sur les tests et la validation du système. En opération, l'attention se porte sur l'exécution de processus financiers exacts et reproductibles. Les utilisateurs clés deviennent les experts. Le partenaire d'implantation est parti, ou disponible uniquement à un coût supplémentaire.

→ Voir aussi : Ce que coûte vraiment l'exploitation d'un ERP après le go-live

→ Voir aussi : Clôture mensuelle dans D365 Finance

3. Les sept différences fondamentales

Ce ne sont pas des abstractions. Chacune a une conséquence opérationnelle concrète.

Dimension	Mode projet	Mode opération
Objectif	Livrer un système configuré	Exécuter des processus financiers exacts et conformes
Horizon temporel	Fixe — se termine au go-live	Indéfini — continu
Autorité de décision	Comité de pilotage	Responsables de processus métier, gouvernance IT
Résolution des incidents	Cellule de crise du partenaire d'implantation	Support interne + contrats de support éditeur
Modèle humain	Consultants + utilisateurs clés détachés	Équipe interne permanente
Gestion des changements	Modifications de configuration via le processus projet	Contrôle formel des changements (demandes, tests, approbations)
Mesure de succès	Dans les délais, dans le budget, dans le périmètre	Précision de la clôture, disponibilité du système, adoption

L'écart le plus dangereux concerne l'autorité de décision. Pendant l'implantation, le Comité de pilotage a un vrai pouvoir et se réunit régulièrement. Après le go-live, la gouvernance se dissout souvent. Personne n'est explicitement responsable de décider si une modification de configuration doit être faite, qui approuve les nouveaux rôles de sécurité, ou comment traiter un écart de processus qui n'a pas été identifié en UAT.

Ce vide ne reste pas vide. Il se remplit de contournements, de fichiers Excel et de modifications non autorisées qui dégradent le système au fil du temps.

💡 FitGap Toolkit : Si vous avez besoin d'une structure claire sur qui possède quoi après le go-live — et comment les décisions se prennent une fois que l'équipe projet est partie — le ERP Governance Health-Check couvre ce sujet directement avec 7 checklists de gouvernance prêtes à l'emploi → https://fitgapfinance.gumroad.com/l/erp-governance-toolkit

→ Voir aussi : La gouvernance ERP n'est pas négociable

4. La transition est une falaise, pas une rampe

Le go-live n'est pas un passage progressif. C'est un événement. Un jour, l'équipe d'implantation est responsable du système. Le lendemain, c'est l'entreprise.

La plupart des organisations traitent la période d'hypercare comme la transition. Ce n'est pas le cas. L'hypercare est un filet de sécurité pour les incidents techniques dans les premières semaines après le go-live. Ce n'est pas un programme de transfert de connaissances. Ce n'est pas un plan de préparation opérationnelle.

On ne peut pas compresser six mois de préparation opérationnelle dans deux semaines d'hypercare.

Ce que la préparation opérationnelle exige réellement :

Un responsable du support ERP nommé avant le go-live, pas après
Une documentation interne qui ne dépend pas du partenaire d'implantation pour être interprétée
Un processus testé pour soumettre, enregistrer et résoudre les tickets de support
Une propriété claire de la maintenance des données de référence — qui ajoute un nouveau fournisseur, qui modifie un segment du plan comptable, qui approuve une nouvelle valeur de dimension financière
Un processus formel de contrôle des changements de configuration post-go-live
Un plan de déploiement pour la formation continue des utilisateurs au fil du renouvellement des équipes

Tout ça n'est pas la responsabilité du partenaire d'implantation à concevoir après la fermeture du projet. C'est la responsabilité du sponsor de l'exiger avant.

→ Voir aussi : Go-live ERP : 5 questions que tout sponsor doit poser

→ Voir aussi : Signaux d'alerte ERP

5. Ce qui change pour l'équipe finance

La relation de l'équipe finance avec l'ERP change complètement au go-live.

Pendant l'implantation, les professionnels finance sont des évaluateurs et des validateurs. Ils testent des scénarios. Ils approuvent des configurations. Ils participent à des ateliers. Ils donnent leur avis sur les documents de conception fonctionnelle (FDD). Leur rôle est de s'assurer que le système est construit correctement.

Après le go-live, ils sont des opérateurs. Ils passent des écritures comptables. Ils pilotent la clôture mensuelle. Ils rapprochent les soldes des auxiliaires avec le Grand livre. Ils analysent les erreurs de validation. Ils traitent les factures fournisseurs dans le vrai workflow, pas dans un environnement de test.

Les compétences requises en mode opération sont différentes de celles requises en mode projet.

Le mode projet exige de savoir évaluer des options de configuration et anticiper les lacunes de processus. Le mode opération exige d'exécuter des transactions correctement, de diagnostiquer des problèmes de validation et de maintenir l'intégrité des données dans la durée.

Les utilisateurs clés sont le pivot. Pendant le projet, un utilisateur clé est un expert métier qui fait le lien entre le partenaire d'implantation et l'entreprise. Après le go-live, un utilisateur clé est un expert interne qui répond aux questions de ses collègues, maintient la documentation des processus et assure le premier niveau de support.

La plupart des utilisateurs clés ne se font pas dire ça explicitement. On leur dit qu'ils ont « terminé » quand le projet prend fin. Puis les appels commencent.

→ Voir aussi : Utilisateurs clés : les réalités d'un projet ERP

→ Voir aussi : Rôles et responsabilités dans un projet ERP

6. Ce que les sponsors comprennent mal

Les sponsors voient le go-live comme la ligne d'arrivée. Ce n'en est pas une. C'est le départ d'une autre course, avec des règles différentes.

L'erreur la plus courante : proclamer la victoire au go-live et se retirer. L'implantation était dans les délais, dans le budget, le système est en production. Le projet est fermé. La structure de gouvernance se dissout. Le Comité de pilotage arrête de se réunir.

Six mois plus tard, le système est dans un état critique. La charte de comptes (le plan comptable) a des segments non autorisés. Des rôles de sécurité ont été attribués de manière informelle parce qu'il n'y avait pas de processus d'approbation. La clôture mensuelle prend trois fois plus de temps que prévu parce que trois réconciliations manuelles n'ont jamais été supprimées. Personne ne sait qui appeler quand une écriture ne s'équilibre pas.

Le projet a livré un système. Personne n'a livré une opération.

Le rôle du sponsor ne s'arrête pas au go-live. Il se transforme. Le sponsor doit s'assurer qu'une gouvernance opérationnelle est en place — non pas comme livrable du projet, mais comme structure permanente. Cela signifie des responsables de processus nommés. Un processus de contrôle des changements. Un budget pour le support et l'optimisation continus.

→ Voir aussi : Gouvernance ERP : rôle du directeur financier

→ Voir aussi : Gouvernance vs gestion ERP

Conclusion

Le mode projet et le mode opération ne sont pas deux versions de la même chose. Ils sont structurellement différents, avec des personnes différentes, une logique de décision différente et des définitions du succès différentes.

L'écart entre les deux est là où les programmes ERP échouent — pas de façon spectaculaire, mais progressivement. La clôture devient plus difficile. Les contournements se multiplient. Les utilisateurs perdent confiance. Le système censé simplifier la finance la complique davantage.

C'est évitable. Mais ça demande de construire le mode opération délibérément, avant que le projet ne se termine — pas d'espérer qu'il s'assemble tout seul après le départ des consultants.

La question à poser à votre programme dès maintenant : qui est responsable de l'exploitation de ce système le lendemain du go-live ?

Si la réponse est floue, c'est votre risque projet le plus urgent.