SI finance : cadrage, MOA et recette fonctionnelle
Un projet SI finance ne se joue pas dans l'outil : il se joue dans le cadrage, dans les arbitrages, et dans la recette. Nous tenons le rôle du métier face aux éditeurs et aux intégrateurs — du cahier des charges jusqu'au go/no-go de mise en production.
Changer d'ERP, déployer une solution de dématérialisation, se raccorder à une plateforme agréée de facturation électronique : ces projets engagent la direction financière pour plusieurs années, sur des budgets qui se chiffrent vite. Ils sont pourtant menés, le plus souvent, avec un déséquilibre structurel : l'intégrateur y consacre une équipe entière, le métier y consacre le temps qui reste. Notre rôle est de rétablir cet équilibre.
Pourquoi les projets SI finance dérapent
Les projets SI finance qui déraillent se ressemblent. Trois causes reviennent, mission après mission — et aucune n'est technique.
- Le métier est sous-représenté face à l'intégrateur. D'un côté, une équipe projet dédiée, rompue à l'exercice, qui déploie la même solution pour la dixième fois. De l'autre, une direction financière qui doit suivre le projet en plus de la clôture, du budget et du quotidien. Les arbitrages se prennent alors par défaut, dans le sens de la solution standard — et les écarts se découvrent après la mise en production, quand ils coûtent le plus cher.
- La recette est bâclée en fin de projet. Prévue trop courte, préparée trop tard, elle sert de variable d'ajustement quand le planning glisse. On teste ce qui passe, on valide sous pression, et les cas de gestion réels — avoirs, litiges, flux intercompagnies, cas particuliers de TVA — arrivent en production sans avoir été éprouvés.
- La qualité des données est découverte trop tard. Référentiels fournisseurs incomplets, doublons de tiers, imputations hétérogènes : tout projet SI finance finit par se heurter à l'état réel des données. Quand le sujet émerge au moment de la migration, il est trop tard pour le traiter sereinement.
Ces trois causes ont un point commun : elles relèvent de la maîtrise d'ouvrage, pas de la maîtrise d'œuvre. C'est précisément le rôle que nous tenons. Et parce qu'un SI ne corrige jamais un processus défaillant, ce travail s'articule avec l'optimisation des processus finance — les processus d'abord, l'outil ensuite.
Notre offre, en quatre temps
Nous intervenons sur tout ou partie de la trajectoire, selon l'endroit où vous en êtes.
La recette fonctionnelle, notre différenciant
La recette est souvent traitée comme une formalité de fin de projet. Nous en faisons une discipline à part entière, avec des livrables précis :
- Une stratégie de recette définie en amont : périmètre, niveaux de tests, responsabilités, environnements, calendrier — établie pendant le paramétrage, pas au moment d'exécuter.
- Des cahiers de tests construits à partir des exigences du cahier des charges et des cas de gestion réels de vos équipes, y compris les cas dégradés que les scénarios de démonstration ignorent.
- Des jeux d'essai issus de vos données, représentatifs de vos volumes et de vos particularités : c'est sur vos factures, vos tiers et vos schémas comptables que l'outil doit faire ses preuves.
- Un pilotage des anomalies tenu : qualification, priorisation, suivi des corrections et des non-régressions, arbitrage entre ce qui bloque et ce qui peut attendre.
- Des critères de go/no-go explicites, définis avant la campagne de tests, pour que la décision de mise en production soit un constat partagé — pas une négociation de fin de planning.
Ce travail ne s'arrête pas au constat : une recette n'a de valeur que si les anomalies relevées sont corrigées, re-testées et soldées avant le démarrage. C'est pourquoi nous restons jusqu'au go/no-go — et, quand la décision est de différer, nous documentons ce qui manque pour que le report soit un choix éclairé, pas un aveu.
La réforme de la facturation électronique en offre un cas d'école : le raccordement à une plateforme agréée est un projet à échéance réglementaire, où la recette fait la différence entre « c'est branché » et « ça fonctionne » — flux de réception, statuts de cycle de vie, cas de rejet compris.
Notre parti pris
Nous nous plaçons du côté du métier, et nous y restons. Indépendants des éditeurs et des intégrateurs, nous ne vendons ni licence ni journées de développement : notre seul livrable est un SI finance qui fonctionne pour ceux qui s'en servent. Cette indépendance se paie d'une exigence — dire ce qui ne va pas, y compris quand ce n'est pas ce qu'on veut entendre.
Questions fréquentes
MOA, AMOA, MOE : qui fait quoi ?
La maîtrise d'ouvrage (MOA) représente le métier : elle définit le besoin, arbitre les priorités et valide que le résultat livré est conforme. La maîtrise d'œuvre (MOE) réalise : c'est l'intégrateur ou l'équipe technique qui paramètre, développe et livre. L'assistance à maîtrise d'ouvrage (AMOA) vient renforcer la MOA quand le métier n'a ni le temps ni l'expérience projet pour tenir ce rôle au quotidien — c'est là que nous intervenons. Concrètement, nous parlons le langage de la direction financière et celui de l'intégrateur, nous traduisons les besoins en exigences testables et nous défendons les intérêts du métier à chaque arbitrage. La décision reste chez vous : nous l'instruisons, nous ne la confisquons pas.
Pourquoi confier la recette à un tiers plutôt qu'à l'intégrateur ?
Parce qu'un intégrateur qui recette son propre travail est juge et partie. Son intérêt est de faire prononcer la conformité au plus tôt ; le vôtre est de vérifier que l'outil fonctionne dans vos cas de gestion réels, y compris les moins fréquents. Une recette menée côté métier, avec des jeux d'essai issus de vos données et des critères de go/no-go définis à l'avance, déplace la charge de la preuve : ce n'est plus au métier de démontrer qu'un défaut existe, c'est à la solution de démontrer qu'elle fonctionne. C'est aussi le dernier moment où un défaut coûte peu à corriger. Après la mise en production, le même défaut se paie en litiges, en ressaisies et en clôtures retardées.
Êtes-vous liés à des éditeurs de logiciels ?
Non. Nous ne percevons aucune commission d'apport, ne revendons aucune licence et n'avons aucun accord commercial avec des éditeurs ou des intégrateurs. Nous connaissons les solutions du marché — SAP S/4HANA, Esker, Ivalua, Coupa, Generix ou Sage X3, entre autres — parce que nous les rencontrons en mission, pas parce que nous les distribuons. Ce positionnement a une conséquence simple : quand nous recommandons une solution à l'issue d'un benchmark, cette recommandation ne rémunère personne. Elle n'engage que notre analyse, et nous restons à vos côtés pour en répondre pendant le déploiement.
À quel moment nous faire intervenir ?
Le plus tôt est le mieux : au cadrage, avant que le cahier des charges ne soit rédigé et l'intégrateur choisi. C'est là que se prennent les décisions les plus structurantes, et les moins coûteuses à corriger. Cela dit, nous intervenons à toutes les étapes : en cours de déploiement pour renforcer une maîtrise d'ouvrage débordée, en fin de projet pour construire et piloter la recette fonctionnelle, ou après la mise en production quand les anomalies remontent. Chaque point d'entrée est utile ; simplement, plus il est tardif, plus la marge de manœuvre se réduit.
Notre projet est déjà en dérive : que peut-on faire ?
D'abord, poser un diagnostic factuel : ce qui est réellement livré, testé et validé — pas ce que dit le planning, ce que disent les livrables. Ensuite, resserrer le périmètre sur ce qui conditionne le démarrage et geler le reste. Puis réinstaller une gouvernance : des décisions tracées, des critères de validation explicites, un pilotage des anomalies tenu semaine après semaine. Nous avons repris des maîtrises d'ouvrage en cours de route : la situation est rarement aussi bloquée qu'elle en a l'air, mais elle exige de dire des choses désagréables à l'intégrateur, et parfois au comité de pilotage. C'est plus facile pour un tiers qui n'a ni l'historique du projet à défendre, ni de contrat de réalisation à protéger.
Combien de temps prévoir pour une recette fonctionnelle ?
Cela dépend du périmètre, du nombre de cas de gestion et de la qualité de ce qui est livré en entrée — une durée standard ne voudrait rien dire, et nous n'en donnons pas. Ce qui est certain : la recette se prépare bien avant la phase de tests elle-même. La stratégie de recette, les cahiers de tests et les jeux d'essai doivent être construits pendant le paramétrage, pas improvisés au moment d'exécuter. Une recette comprimée en fin de projet pour tenir une date est le signal le plus fiable d'une mise en production douloureuse. Si le planning ne laisse pas la place de recetter sérieusement, c'est le planning qu'il faut revoir, pas la recette.
Où nous intervenons
Nos missions sur le sujet, anonymisées :
- Recette fonctionnelle d'une plateforme agréée de facturation électronique, pour un groupe d'ingénierie : stratégie de recette, cahiers de tests, pilotage des anomalies.
- Reprise de la maîtrise d'ouvrage d'un déploiement Esker dans le secteur de l'assurance : continuité de service et montée en charge maîtrisée.
- Cadrage du SI finance d'une filiale d'un groupe environnement : cahier des charges, benchmark de solutions, trajectoire de déploiement.
- Direction de projet d'un programme SAP S/4HANA : douze chantiers coordonnés, du cadrage au démarrage.
- Intégration et paramétrage de Sage X3 pour une PME industrielle.
D'autres missions et notre approche sont présentées sur la page d'accueil.
Parlons de votre projet SI finance
Trente minutes pour situer où en est votre projet — cadrage, choix de solution, déploiement ou recette — et identifier ce qui mérite d'être renforcé. Sans engagement, avec un associé.
Prendre rendez-vous