Dynamics 365 – Gestion de projets et comptabilité : à quoi sert réellement ce module
En résumé
Le module Gestion de projets et comptabilité (Project management and accounting – PMA) de Dynamics 365 Finance est avant tout un moteur de comptabilité de projet, et non un outil de gestion de projet.
La plupart des difficultés rencontrées ne viennent pas de l’outil, mais de choix de conception et de gouvernance mal définis.
Pourquoi ce module est si souvent mal compris
Le module Gestion de projets et comptabilité (PMA) de Dynamics 365 Finance fait partie des modules les moins documentés sous l’angle métier et gouvernance.
La documentation Microsoft explique très bien :
- les fonctionnalités,
- les options de paramétrage,
- les capacités fonctionnelles.
En revanche, elle explique beaucoup moins :
- dans quels cas utiliser PMA,
- quel problème métier il est censé résoudre,
- ce qu’il ne faut surtout pas en attendre.
Après avoir participé à plusieurs implémentations de Dynamics 365 Finance de taille moyenne à grande, dans différents secteurs, un constat revient systématiquement :
Les organisations abordent PMA avec une logique de gestion de projet, et découvrent – souvent trop tard – qu’il impose avant tout une logique comptable.
Cet article vise précisément à corriger ce malentendu.
PMA n’est pas une extension du grand livre
Une idée très répandue chez les parties prenantes métier consiste à considérer PMA comme :
« Une version plus détaillée du grand livre. »
Cette hypothèse est fausse – et coûteuse.
Le grand livre sert à répondre à des questions de niveau corporate :
- Qu’a-t-on dépensé ?
- Où cela impacte-t-il le compte de résultat ou le bilan ?
- Comment ces montants se consolident-ils dans les états financiers ?
PMA, lui, répond à des questions financières propres aux projets :
- Comment les coûts évoluent-ils sur le cycle de vie d’un projet ?
- Quels coûts sont facturables, capitalisables ou à passer en charges, et selon quelles règles ?
- À quel moment les coûts passent-ils du suivi opérationnel à la réalité comptable ?
- En quoi les budgets, contrôles et validations diffèrent-ils de la finance corporative ?
PMA introduit une comptabilité auxiliaire de projet, dont les écritures sont transférées vers le grand livre selon des règles comptables explicitement définies au niveau projet.
👉 Pour approfondir :
- https://www.fitgapfinance.com/grand-livre-vs-auxiliaire-d365-finance/
- https://www.fitgapfinance.com/cloture-mensuelle-d365-finance/
Traiter PMA comme une simple extension du GL conduit généralement à :
- des décisions de conception prises trop tard,
- une gouvernance floue,
- des problèmes de rapprochement qui apparaissent plusieurs mois après le go-live.
Pourquoi les organisations disent vouloir PMA… et pourquoi elles en ont réellement besoin
Les raisons officiellement invoquées pour déployer PMA sont en général légitimes :
- meilleure visibilité des coûts par projet,
- facturation (externe ou intercompagnies),
- suivi budgétaire.
La raison réelle est plus profonde :
Les organisations veulent piloter leurs projets de bout en bout d’un point de vue financier et comptable, et pas uniquement analyser les coûts a posteriori.
PMA permet notamment :
- des budgets et validations spécifiques aux projets,
- une comptabilité auxiliaire pilotée par des règles projet (puis intégrée au GL),
- une logique de cycle de vie (démarrage, exécution, clôture),
- des mécanismes optionnels de capitalisation et de facturation.
Ce n’est pas du reporting.
C’est de la conception financière appliquée au niveau projet.
L’erreur la plus dommageable : utiliser PMA comme un outil de gestion de projet
PMA est très souvent détourné pour des usages pour lesquels il n’a pas été conçu :
- suivi des jalons,
- gestion des livrables,
- pilotage opérationnel de l’exécution.
C’est là que les problèmes les plus sérieux apparaissent.
PMA est très solide en comptabilité de projet :
- contrôle des coûts,
- classification comptable,
- fiabilité de la facturation,
- logique de capitalisation.
En revanche, ce n’est pas un outil de gestion de projet au sens opérationnel.
Oui, PMA propose des structures de planification (WBS, activités, feuilles de temps).
Mais celles-ci existent avant tout pour servir les besoins de contrôle financier et de comptabilisation, pas pour remplacer un véritable outil de pilotage de projet.
Lorsqu’une organisation tente d’utiliser PMA comme substitut à un outil de gestion de projet dédié, on observe généralement :
- des structures de projet inutilement complexes,
- une mauvaise utilisation des catégories et activités,
- une frustration croissante des chefs de projet,
- une visibilité très limitée sur l’avancement réel.
Paradoxalement, cette mauvaise utilisation dégrade à la fois la gestion de projet et la qualité comptable.
Réalité de la gouvernance : PMA met en lumière ce que l’organisation évite de trancher
PMA ne crée pas les problèmes de gouvernance.
Il les révèle.
Dans la majorité des implémentations :
- la Finance pilote les décisions de conception PMA,
- le bureau de projet est partiellement impliqué,
- les TI exécute la configuration.
Le point de rupture le plus fréquent concerne les approbations :
- Qui approuve les demandes d’achat et les bons de commande ?
- Le gestionnaire hiérarchique ?
- Le chef de projet ?
- La finance corporative ?
Sans réponse claire, PMA devient le terrain de confrontation entre :
- le contrôle corporatif,
- l’autonomie des projets.
👉 À lire également :
- https://www.fitgapfinance.com/gouvernance-erp-modele-roles-decisions/
- https://www.fitgapfinance.com/matrice-raci-projet-erp/
Un autre point de tension récurrent concerne la structure des projets :
- les contrôleurs recherchent stabilité et facilité de rapprochement,
- les chefs de projet recherchent flexibilité et alignement opérationnel.
PMA force ces arbitrages. Les éviter garantit des frictions futures.
👉 Article connexe :
Capitalisation : là où PMA devient discrètement à risque
PMA est souvent choisi pour gérer :
- la capitalisation R&D,
- des projets d’investissement intégrés aux immobilisations.
L’hypothèse la plus dangereuse est la suivante :
« On définira les règles de capitalisation plus tard. »
Les règles de capitalisation ont un impact direct sur :
- la structure des projets,
- les profils de comptabilisation,
- les catégories de coûts,
- l’intégration avec les immobilisations.
Lorsque ces règles sont incomplètes ou floues, les conséquences sont prévisibles :
- soldes d’ouverture erronés,
- rapprochements fragiles,
- corrections manuelles non pérennes.
Même sans intervention immédiate des auditeurs, ces faiblesses ressortent généralement lors des clôtures ou des revues financières.
👉 Article associé :
Quand utiliser PMA… et quand l’éviter
PMA n’est pas systématiquement la bonne solution.
Si l’objectif est uniquement :
- un suivi plus fin des coûts,
- un reporting enrichi,
des mécanismes plus simples sont souvent préférables :
- dimensions financières,
- attributs ou balises,
- structures de reporting.
👉 Voir :
PMA est en revanche pertinent lorsque :
- l’organisation gère de nombreux projets avec un début et une fin clairement définis,
- les projets nécessitent des budgets et validations spécifiques,
- la comptabilité projet diffère de la comptabilité corporate,
- une facturation (notamment basée sur les coûts) est requise,
- des mécanismes de capitalisation ou d’intercompany sont en jeu.
Utiliser PMA « au cas où » est généralement une faiblesse de conception.
La décision de conception que les équipes regrettent toujours d’avoir repoussée
Une décision est presque toujours reportée, car elle n’apparaît pas dans les états financiers :
L’introduction d’une dimension projet.
Même lorsqu’elle n’est pas requise pour le reporting statutaire, elle facilite considérablement :
- les rapprochements,
- les analyses transverses,
- la résolution des problèmes en clôture.
Les équipes qui font l’impasse compensent ensuite par des analyses manuelles lourdes et peu fiables.
Le changement de perspective qui fait toute la différence
Après avoir vu PMA bien – et mal – implémenté, une conclusion s’impose :
PMA est un outil de comptabilité de projet, pas un outil de gestion de projet.
Les pires implémentations ont un point commun :
des responsabilités mal définies entre chefs de projet, contrôleurs et finance corporative.
Si un projet Dynamics 365 Finance devait répondre à une seule question dès le départ, ce serait celle-ci :
Qu’est-ce qu’un “projet” dans notre organisation, et comment PMA doit-il nous aider à atteindre nos objectifs métier ?
Sans réponse claire, les choix de paramétrage restent des paris.
À qui s’adresse cet article
Cet article s’adresse en priorité :
- aux directeurs financiers,
- aux contrôleurs,
- aux sponsors ERP.
Il parlera également :
- aux consultants seniors,
- aux chefs de projet évoluant vers des environnements ERP.
Si PMA vous paraît plus lourd que prévu, plus politique qu’anticipé ou plus difficile à rapprocher que promis, le problème est rarement l’outil.
C’est un problème de conception et de gouvernance.
La suite de la série
Les prochains articles aborderont :
- pourquoi traiter les projets comme des centres de coûts casse PMA,
- les types de projets comme décisions comptables,
- les erreurs classiques de conception en matière de capitalisation,
- l’illusion du contrôle budgétaire,
- quand il vaut mieux ne pas utiliser PMA.
Cet article fait partie de la série FitGap Finance — une approche métier de la gouvernance ERP, de la prise de décision et du contrôle au-delà du go-live.
🇬🇧 Version anglaise disponible ici : https://www.fitgapfinance.com/d365-pma-what-its-really-for/
