AMOA fonctionnelle : quand faire appel à un support alors que le projet est déjà lancé ?

Une AMOA fonctionnelle n'est pas réservée au cadrage : elle est souvent la plus utile quand le projet EPM est déjà lancé et que les premiers signaux faibles apparaissent.

Le projet est lancé, les premiers signes de freinage

Vous avez choisi votre solution, retenu un intégrateur, tenu le kick-off. Quelques semaines plus tard, le planning n'existe pas ou glisse. Les réunions se succèdent sans compte rendu. Les ateliers tournent au récit d'activité plutôt qu'à la spécification. Et l'intégrateur attend des réponses que personne n'a formalisées.

Ce n'est ni une fatalité, ni, le plus souvent, un problème de compétence. C'est un problème d'interface entre le métier, qui sait ce qu'il fait mais pas comment le dire à un outil, et la technique, qui sait construire mais attend qu'on lui dise quoi.

Cet article parcourt les grandes phases d'un projet EPM : démarrage, conception, modélisation, build, recette, déploiement, puis vie de l'application. Pour chacune, il décrit les situations concrètes où une AMOA fonctionnelle change la trajectoire d'un projet déjà engagé. Il s'appuie sur nos missions, notamment sur un projet de planification mené dans un groupe international que nous avons rejoint un mois après son démarrage, avec une mise en service fixée quatre mois plus tard.

L'AMOA fonctionnelle : le chaînon entre le métier et l'intégrateur

Dans un projet, l'assistant à maîtrise d'ouvrage est le prestataire que le client mandate pour l'assister à différents stades : formaliser ses besoins, piloter, dialoguer avec le réalisateur, vérifier que les besoins sont bien pris en compte et alerter sur les risques. Dans un projet EPM, le maître d'ouvrage est la direction financière et ses utilisateurs ; le maître d'œuvre est l'intégrateur de la solution.

Ce partage des rôles explique la plupart des blocages. Un intégrateur construit ce qu'on lui spécifie : il attend des dimensions, des métriques et des règles de gestion. Il ne lui revient pas de traduire un discours métier en spécifications. Et les utilisateurs, eux, racontent leur activité avec précision, mais rarement dans la forme dont un modèle a besoin.

Notre conception de l'AMOA tient en trois engagements :

1. Identifier les besoins liés à chaque cas d'usage, y compris les aides à la production et à la décision. Un système de budget ne doit pas être un réceptacle vide : il doit proposer une projection pertinente, à partir de l'historique ou de calculs.
2. Les traduire dans le vocabulaire de l'intégrateur : dimensions, métriques, règles de gestion, formules, référentiels, visualisation.
3. Mettre les arbitrages techniques sur la table, pour que le système soit robuste aujourd'hui et maintenable demain.

Cette AMOA ne reste pas au niveau purement fonctionnel. Elle intègre une part technique (référentiels, données, architecture), parce que c'est là que se jouent la fiabilité et la flexibilité du modèle. C'est aussi pour cela que nos consultants sont des profils de la finance d'entreprise, avec 10 à 15 ans d'expérience, qui ont piloté des projets en interne avant de devenir consultants.

Au démarrage : reprendre la main sur le cap

Quand un projet démarre sans planning ni comité, une AMOA fonctionnelle le remet sur des rails en quelques semaines, en commençant par arbitrer ce qui sera réellement livré à la date prévue.

C'est la situation dans laquelle nous sommes arrivés sur une mission de planification multi-pays : 3 semaines après le lancement, aucun planning, deux ou trois réunions tenues sur les dimensions existantes, aucun compte rendu, aucun fichier d'exemple. La mise en service était pourtant fixée quatre mois plus tard.

Ce que vous constatez

• Pas de découpage du projet en lots fonctionnels précis
• Pas de planning détaillé, partagé, ni de date de mise en service déclinée en jalons.
• Des réunions sans compte rendu : les décisions ne sont pas tracées.
• Une cible que l'on cherche à définir en reproduisant l'existant à l'identique, alors que les dimensions actuelles ne suffisent pas à déterminer le modèle cible.

Ce que change l'AMOA

• Elle met en place la comitologie et construit un planning à rebours jusqu'à la date de mise en service.
• Elle fait arbitrer un MVP (minimum viable product) à une date précise : quand le temps est court, la cible complète n'est pas tenable, et mieux vaut le décider en septembre que le constater en novembre.
• Elle provoque très tôt la réunion technique sur l'intégration des données financières réelles, les sources de référentiels, qui conditionne tout le reste.
• Elle lance le kick-off et démarre le prototypage à partir des documents du client (processus budgétaire, note de cadrage, présentation du budget).

Résultat : chacun sait ce qui sera livré, quand, et qui arbitre.

En conception fonctionnelle : transformer le discours métier en spécifications & décrire une cible fonctionnelle augmentée

En atelier, le métier raconte son activité ; l'intégrateur attend des dimensions, des métriques et des règles de calcul. L'AMOA fait en sorte d'accroître la valeur du modèle (pas seulement ce que l'on fait, comme on le fait actuellement, mais tirer le bénéfice d'une solution qui est une aide à la projection - décision). Elle s'assure que les ateliers produisent ces trois éléments, et pas seulement des comptes rendus.

Ce que vous constatez

• Les ateliers s'étirent : le client décrit son quotidien avec richesse, mais peine à se concentrer sur l'attendu, c'est-à-dire les axes d'analyse et leur granularité.
• Les métiers ne peuvent se projeter sur un processus et des fonctionnalités cibles, ils décrivent le présent (ce qu'ils ont, ce qu'ils font)
• Les équipes techniques ont du mal à suivre le discours métier. Elles ne posent pas de questions : elles attendent que le client leur fournisse exactement les éléments de build.
• Chaque pays ou entité décrit sa propre pratique, sans vue d'ensemble sur ce qui est local et ce qui est central.

Ce que change l'AMOA

1. Elle prototype avant de modéliser. Nous montons les maquettes des futurs « écrans » de l'EPM, à partir du processus budgétaire, de la note de cadrage et de la présentation du budget. Les propositions, maquettes intègrent les fonctionnalités cibles même si elles n'existent pas dans le processus actuel (initialisation du budget, bridges automatiques par exemple).  Elles fixent les dimensions, les axes d'analyse (par client, par activité, par entité), le niveau d'agrégation et de détail, et l'enchaînement chargement des données, initialisation de la saisie, restitution.
2. Elle réunit les sachants, maquettes en main. Les utilisateurs finaux réagissent à une première proposition : ils nous disent ce qu'ils font réellement et comment ils construisent leur projection. Nous détaillons avec eux les calculs d'initialisation et les règles de gestion, avec des exemples chiffrés, jusqu'au paramétrage induit (par exemple le calcul des jours ouvrés).
3. Elle interroge l'intégrateur en séance. C'est l'AMOA qui lui demande ce qui est possible, ce qui ne l'est pas et ce qu'il recommande, pour éviter une conception qui s'avérerait intenable techniquement.
4. Elle restitue sous forme exploitable. Dans notre mission, un atelier de quatre heures avec les utilisateurs a pu être restitué clairement à l'intégrateur en 45 minutes, formules à l'appui.

À l'issue de ces ateliers, un seul processus harmonisé et un modèle par thématique servent de base de démarrage à l'intégrateur. Les échanges entre pays, et entre les pays et le siège, sont un bénéfice en soi : ils font émerger les écarts de pratiques et permettent d'arriver à un consensus ou sont arbitrés,  avant qu'ils ne se figent dans l'outil.

En modélisation : sécuriser les référentiels et la robustesse du modèle

Les failles les plus coûteuses d'un projet EPM se logent dans les référentiels et les niveaux de saisie, et elles se découvrent rarement d'elles-mêmes avant la recette. Une AMOA qui connaît les points de vigilance les fait remonter pendant la conception.

Le sujet n'a rien d'anecdotique. Dans l'enquête 2025 de l'AFP auprès de 362 professionnels de la finance, 61 % citent le manque de fiabilité des données comme un obstacle, et 60 % le manque d'accessibilité (AFP, janvier 2025).

Une hiérarchie qui ne tient pas d'un pays à l'autre

Sur notre projet multi-pays, la saisie du forecast était prévue au niveau "usine" dans tous les pays. L'analyse des référentiels a montré que ce niveau ne se situait pas au même endroit de la hiérarchie selon le pays :

Le problème n'avait pas été identifié côté intégrateur. Nous l'avons mis en évidence, convoqué un point dédié, puis proposé un attribut permettant, application par application, de déterminer ce qui remonte en filtre.

Un modèle stable dans le temps et performant

• Historisation. Pour suivre l'évolution de la prévision d'un mois sur l'autre, il faut conserver la construction et le résultat de chaque forecast.
• Versioning. Les sources et les hypothèses doivent être versionnées, pour que les résultats et les reportings ne « bougent » pas après coup. Exemple type : modifier le taux d'augmentation générale ne doit pas changer les budgets des exercices précédents.
• Paramétrage plutôt que formules en dur. Les mappings doivent rester accessibles à l'administrateur fonctionnel, qui doit pouvoir les faire évoluer sans repasser par l'intégrateur.

Cette flexibilité est également discutée avec l'intégrateur pour s'assurer d'une performance du système : temps de réponse

Pendant le build : arbitrer entre le besoin et la contrainte technique

Pendant le build, des questions techniques surgissent sur une conception pourtant validée. L'AMOA est l'interlocuteur qui sait y répondre sans trahir le besoin métier ni dégrader l'architecture.

Ce que vous constatez

• L'intégrateur bute sur un point de conception et réalise un contournement éventuellement sans en informer le métier, ou dont personne côté métier ne mesure la portée.
• Les décisions techniques se prennent entre techniciens, sans que leurs conséquences fonctionnelles soient présentées.
• Les premiers écrans fonctionnent, mais le même chiffre n'est pas identique d'un écran à l'autre.

Ce que change l'AMOA

• Elle répond aux questions de l'intégrateur sur le design défini.
• Elle consulte les métiers et peut les conduire à accepter de revenir sur la conception quand c'est nécessaire, pour qu'elle reste pertinente et maintenable.
• Elle exige que les arbitrages soient soumis : l'intégrateur explique ce qu'il propose pour répondre au besoin, et ce que cela implique pour la robustesse et la maintenance.
• Elle vérifie les points de cohérence qui font la crédibilité d'un outil, par exemple que le compte de résultat affiche une information alignée dans tous les écrans, et que les référentiels sont gérés de façon optimale par l'administrateur fonctionnel.
• Elle fait le lien permanent entre besoin fonctionnel et conception technique, avec un principe simple : un maximum de paramétrage, un minimum de règles codées en dur.
• Elle réalise des tests en amont pour s'assurer que le build est conforme aux attentes.

C'est ce que nous appelons l'application lifetime value : mesurer, à chaque décision, l'impact qu'elle aura non seulement à la livraison, mais dans trois ans.

En recette : guider les utilisateurs et industrialiser le traitement des anomalies

Une recette réussie se prépare des semaines avant son démarrage : qui teste, sur quels scénarios, et comment les anomalies sont suivies jusqu'à leur résolution.

Ce que vous constatez

• Les utilisateurs sont invités à « tester » sans savoir quoi vérifier ni quels résultats attendre.
• Les anomalies remontent par mails et par messages, sans priorisation ni suivi.
• Les erreurs les plus visibles sont découvertes en phase de recette formelle, quand le temps manque pour les corriger sereinement.

Ce que change l'AMOA

• Elle identifie dès les comités de projet les opérationnels à mobiliser et prépare avec eux les cahiers de test : des scénarios construits sur des cas réels, avec des résultats attendus chiffrés.
• Elle organise et réalise des tests anticipés pour éliminer les erreurs et anomalies les plus criantes avant l'arrivée des utilisateurs.
• Elle définit le circuit de suivi des anomalies (un fichier partagé ou un outil de type Jira) et le processus de priorisation et de résolution.
• Elle guide les utilisateurs pendant les tests, pour qu'ils jugent l'outil sur ce qu'il doit faire et pas sur ce qu'ils imaginaient.
• Elle s'assure de la priorisation de traitement des tickets : améliorations fonctionnelles, anomalies, pour mener au go live

Au déploiement : préparer les utilisateurs, pas seulement l'outil

Un roll out se prépare deux à trois mois avant sa date. Les comités de projet sont le lieu où l'AMOA met ces échéances à l'ordre du jour avant qu'elles ne deviennent des urgences.

L'enjeu est aussi celui de l'usage. Parmi les raisons qui poussent les équipes finance à multiplier les outils, l'enquête AFP citée plus haut mentionne un nombre insuffisant de décideurs prêts à utiliser les solutions en place (AFP, janvier 2025). Un outil conforme à la spécification mais mal déployé finit contourné.

Ce que vous constatez

• La date de déploiement approche, mais personne n'a défini comment chaque périmètre (pays, département, usine...) sera embarqué.
• Les formations, les accès et la communication restent à organiser.
• Les entités découvrent l'outil au moment de s'en servir, avec des écarts de pratiques que la conception n'avait pas anticipés.

Ce que change l'AMOA

• La stratégie de déploiement est envisagée dés la planification détaillée du projet et validée par le Sponsor.
• Elle fait inscrire le roll out à l'ordre du jour des comités deux ou trois mois à l'avance, pour en définir la stratégie.
• Elle pose les questions qui conditionnent le déploiement : faut-il une gap analysis ? Quel niveau d'ajustement local accepte-t-on ? Dans quel ordre déploie-t-on les pays ? Quelle communication, quelles formations ? Qui a accès à quoi ?
• Elle restitue en comité ce qui a été fait, fait ressortir les questions et arbitrages qui en découlent, et prépare les phases suivantes.

Après la mise en production : protéger la valeur de l'application dans la durée

La valeur d'une application EPM se juge sur sa capacité à absorber une nouvelle entité, un nouveau compte ou une nouvelle règle sans refonte. Cette capacité se décide pendant la conception, mais elle se vérifie après la mise en service.

Le risque est connu : dans la même enquête AFP, 96 % des répondants utilisent des tableurs pour la planification, alors que 71 % utilisent un EPM pour planifier au moins une fois par trimestre. Un modèle rigide ou opaque nourrit ce retour à Excel.

Ce que vous constatez

• Chaque évolution, même mineure, exige de rappeler l'intégrateur.
• Les administrateurs fonctionnels ne savent pas où se trouvent les règles et les mappings.
• Des chiffres anciens bougent quand on modifie une hypothèse.

Ce que change l'AMOA

• Elle revient sur les choix d'architecture (niveaux de saisie, mappings, versioning) à l'aune des évolutions prévisibles de l'organisation.
• Elle s'assure que le paramétrage reste accessible à l'administrateur fonctionnel, pour qu'il pilote l'outil au quotidien.
• Elle structure la gouvernance des évolutions : les demandes sont arbitrées en comité, priorisées et suivies, plutôt que traitées au fil de l'eau.

C'est le sens de notre engagement : faire en sorte que l'application garde sa valeur bien après le départ de l'équipe projet.

Si l'AMOA est présente en amont, sur l'ensemble du projet, elle anticipe ce run :

• process de gestion en interne des anomalies, des améliorations fonctionnelles
• identification de l'organisation interne adhoc, personnes clefs
• mise en place de la co-construction en cours de projet permettant aux équipes en interne de se former sur l'outil et de participer à la construction de l'architecture des modèles

Les signaux qui doivent vous alerter

Si vous cochez trois cases ou plus, votre projet gagnerait à être regardé par un tiers.

• Il n'existe pas de planning à jour, jalonné jusqu'au déploiement.
• Les réunions n'aboutissent pas à des comptes rendus ni à des décisions tracées.
• La date de mise en service n'a pas été confrontée à ce qu'il est réaliste de livrer : aucun MVP n'a été arbitré.
• Les ateliers produisent des récits d'activité, pas des dimensions, des métriques et des règles de calcul.
• L'intégrateur n'a pas de questions : il attend que vous lui fournissiez les réponses.
• Les hiérarchies et les référentiels n'ont pas été comparés entre pays ou entités.
• Personne ne sait dire comment l'historique des prévisions sera conservé et versionné.
• Les arbitrages techniques sont pris sans que leurs conséquences vous soient expliquées.
• Il n'y a ni cahiers de test, ni circuit de suivi des anomalies.
• Le déploiement dans les entités n'est ni planifié ni préparé, à moins de trois mois de l'échéance.

Un projet lancé n'est pas un projet perdu

À chaque phase, les mêmes symptômes ont la même origine : un besoin métier qui n'a pas été traduit en éléments exploitables, et des arbitrages techniques dont personne ne mesure l'effet à long terme. L'AMOA fonctionnelle intervient précisément sur cette interface, et elle peut le faire à tout moment, y compris quand le projet est déjà engagé.

Si plusieurs signaux de la liste ci-dessus vous parlent, échangeons. Notre expertise permet de poser rapidement un regard extérieur sur votre projet, avec des consultants qui ont piloté des projets de transformation de la fonction finance de l'intérieur avant de devenir conseil.

Sources

• Enquête 2025 AFP FP&A Benchmarking Survey, communiqué du 14 janvier 2025
• Retours d'expérience EPO Conseil issus de multiples projets réalisés de bout en bout ou pour lesquels EPO Conseil est sollicité sur une phase critique

‍