Pourquoi traiter les projets comme des centres de coûts casse le module projets dans Dynamics 365 Finance
Voici ce qui casse le module Gestion de projets et comptabilité (PMA) dans Microsoft Dynamics 365 Finance plus vite que n’importe quelle erreur de paramétrage :
Traiter les projets comme des centres de coûts permanents.
Lorsque la finance conçoit les projets PMA comme des centres de coûts qui ne se ferment jamais, les budgets perdent leur portée, les responsabilités se diluent et les rapprochements deviennent un travail d’archéologie.
Pire encore, cela crée des risques de conformité liés à la capitalisation que beaucoup de directions financières ne découvrent qu’au moment de l’audit.
Ce schéma est omniprésent.
Et ce n’est pas un problème technologique — c’est un réflexe.
Le réflexe du centre de coûts (et pourquoi il est compréhensible)
Dans de nombreuses organisations, les projets PMA sont créés :
- un projet par département,
- un projet miroir d’un centre de coûts existant,
- ou un projet « administratif » unique, réutilisé indéfiniment.
La justification initiale est généralement rationnelle :
- standardiser les processus,
- centraliser le reporting,
- éviter la multiplication des structures.
Du point de vue finance, cela paraît propre et maîtrisé.
Le problème est que les projets et les centres de coûts ne répondent pas aux mêmes besoins.
Les projets et les centres de coûts ne sont pas interchangeables
Un centre de coûts est :
- permanent,
- organisationnel,
- conçu pour l’allocation et le reporting,
- rarement clôturé.
Un projet est :
- temporaire ou structuré par phases,
- orienté vers un objectif précis,
- régi par des règles et jalons spécifiques,
- destiné à évoluer à travers des étapes avec des traitements financiers distincts.
Lorsque les projets sont conçus comme des centres de coûts, PMA cesse d’être un outil de pilotage du cycle de vie.
Il devient une couche de reporting secondaire, avec toute la lourdeur de la comptabilité de projet — et aucun de ses bénéfices.
👉 Lecture connexe :
https://www.fitgapfinance.com/grand-livre-vs-auxiliaire-d365-finance/
Ce qui se passe réellement (et pourquoi ça finit mal)
Les conséquences ne sont pas immédiates.
Elles s’accumulent silencieusement — puis explosent.
1. La capitalisation devient un risque de conformité
Lorsque les projets sont traités comme des centres de coûts, il devient impossible de distinguer correctement les charges et les immobilisations au niveau transactionnel.
Dans une conception PMA saine :
- les projets de coûts capturent les charges,
- les projets d’investissement capturent les immobilisations,
- les catégories de projet déterminent le traitement comptable au fil de l’eau.
Dans le modèle « centre de coûts » :
- toutes les dépenses passent par le même projet départemental,
- la finance reclasse manuellement en fin de mois ou de trimestre,
- la traçabilité transactionnelle disparaît,
- la capitalisation devient un exercice de rapprochement — pas un contrôle.
Exemple réel :
Un industriel avait créé un projet PMA unique « Département TI ». En trois ans, ce projet a accumulé 52 M$ de coûts liés à des infrastructures, du support et une implémentation ERP.
Lors de l’audit, l’entreprise n’a pas été en mesure de distinguer charges et immobilisations sans reconstituer l’historique manuellement.
L’ajustement de capitalisation s’est élevé à 9 M$ et a été qualifié de faiblesse significative du contrôle interne par les auditeurs externes.
Ce n’est pas une question d’efficacité.
C’est un risque d’audit avéré.
2. Maintenance lourde et processus rigides
Les projets « permanents » nécessitent :
- des ajustements constants,
- un nettoyage régulier,
- une discipline manuelle pour rester exploitables.
Ce qui devait simplifier finit par alourdir les opérations.
L’historique s’accumule indéfiniment et chaque clôture exige de comprendre ce qui relève du passé lointain ou de l’activité courante.
3. Un reporting centralisé… mais vidé de sens
Oui, les coûts sont centralisés.
Mais avec le temps :
- les données historiques se polluent,
- les comparaisons perdent leur pertinence (est-ce un écart réel ou un bruit hérité de 2021 ?),
- le reporting ne reflète plus les initiatives réelles.
On gagne en homogénéité — au prix de la compréhension.
👉 Article associé :
https://www.fitgapfinance.com/ecarts-reporting-d365-finance/
4. Une gouvernance floue
Lorsqu’un projet ne se termine jamais, une question simple devient inconfortable :
Qui est responsable ?
- Le département ?
- Le chef de projet ?
- La finance ?
Les centres de coûts ont une responsabilité structurelle.
Les projets ont une responsabilité définie par la gouvernance — quelqu’un est comptable du périmètre, du budget et des résultats dans le temps.
Mélanger les deux affaiblit la responsabilité et les droits de décision. Les budgets deviennent des enveloppes. Les écarts sont justifiés vaguement. La responsabilité se dissout.
👉 À lire également :
https://www.fitgapfinance.com/gouvernance-erp-modele-roles-decisions/
https://www.fitgapfinance.com/matrice-raci-projet-erp/
5. Les travaux en cours (WIP) et les estimations deviennent fictifs
Dans un PMA correctement conçu :
- les travaux en cours (WIP),
- les estimés à terminaison,
- les écarts à terminaison
alimentent le pilotage financier et l’apprentissage.
Lorsque les projets ne se ferment jamais et n’ont pas de phases claires :
- les WIP n’ont plus de sens ou sont forcés manuellement,
- les estimations ne sont jamais confrontées aux réalisés,
- la boucle d’amélioration disparaît.
Le système enregistre des coûts, mais ne pilote plus les projets.
Le piège du « projet administratif »
Certaines équipes financières objectent :
« Nous avons besoin de projets long terme pour les salaires, les services partagés ou les refacturations internes. »
Voici la vérité inconfortable :
Si votre conception PMA repose sur des projets d’allocation administrative, votre structure de dimensions financières est probablement défaillante.
Les salaires, services partagés et refacturations internes devraient passer par :
- des journaux d’allocation avec une logique de dimensions robuste,
- des mécanismes intercompagnies ou inter-entités,
- le module de comptabilité analytique si des clés de répartition sont nécessaires,
- des pools de frais indirects avec des taux clairement définis.
Les projets utilisés uniquement pour déplacer des montants sont le symptôme d’un échec de conception de la structure financière.
Il existe une exception étroite : des projets explicitement conçus comme des mécanismes, avec un périmètre, des règles et des revues strictes.
Mais dès que cette logique est généralisée, le problème des centres de coûts réapparaît sous un autre nom.
Quand PMA n’est pas le bon outil
Si l’objectif est uniquement :
- un reporting standardisé,
- un suivi cohérent des coûts,
- une visibilité transverse,
alors PMA est excessif.
Les dimensions financières et les structures de reporting permettent d’obtenir le même résultat :
- avec moins de gouvernance,
- moins de maintenance,
- moins de risques de rapprochement.
Utiliser PMA doit être un choix de conception délibéré, pas un réflexe.
Quand la logique centre de coûts est pertinente
Utilisez des centres de coûts et des dimensions lorsque :
- le reporting est organisationnel et permanent,
- les coûts ne nécessitent pas de traitement par phase,
- la distinction charge / immobilisation n’est pas transactionnelle,
- la responsabilité est structurelle.
Utilisez des mécanismes d’allocation lorsque :
- la répartition est basée sur des inducteurs,
- les règles sont stables et répétables,
- la transparence des frais indirects est essentielle.
Utilisez PMA lorsque :
- le traitement financier varie selon le cycle de vie,
- des règles de capitalisation s’appliquent à certaines activités,
- la reconnaissance du revenu dépend de jalons ou de l’avancement,
- les estimations et WIP sont critiques,
- la responsabilité est gouvernée, pas simplement hiérarchique.
Le système permet tout.
La vraie question est : quel problème cherchez-vous à résoudre ?
Un cadre de décision avant de créer un projet
Avant de créer un projet dans PMA, la finance devrait pouvoir répondre « oui » à la majorité des questions suivantes :
- Le traitement financier évolue-t-il selon les phases ?
- L’initiative a-t-elle un objectif clair à atteindre ou à abandonner ?
- Existe-t-il des phases, jalons ou points de revue définis ?
- Le traitement comptable diffère-t-il réellement des règles corporate ?
- La responsabilité est-elle définie par la gouvernance, et non l’organigramme ?
Si la plupart des réponses sont « non », le besoin est probablement un meilleur reporting — pas de la comptabilité de projet.
Le principe fondamental
Un projet vise un objectif précis dans un horizon donné — et sa comptabilité doit refléter la gouvernance du projet, pas l’organigramme.
C’est la ligne que PMA impose.
La franchir rend PMA lourd, politique et fragile.
La respecter en fait l’un des outils de contrôle financier les plus puissants de Dynamics 365 Finance.
Ce que cela implique pour la conception
Le paramétrage technique de PMA est relativement simple.
La vraie difficulté est de convaincre les directions financières que la discipline projet est une fonctionnalité, pas une contrainte.
Cela ouvre naturellement sur la suite :
- pourquoi les types de projets sont des décisions comptables,
- comment la capitalisation révèle les défauts de conception,
- pourquoi certains budgets PMA donnent une illusion de contrôle.
Cet article fait partie de la série FitGap Finance – Project Management & Accounting, dédiée à une approche finance-first de la gouvernance ERP, de la conception et de la prise de décision au-delà du go-live.
🇬🇧 Version anglaise disponible ici : https://www.fitgapfinance.com/why-projects-like-cost-centers-break-pma-d365-finance/
