Le besoin
Un groupe industriel construit par acquisitions successives. Chaque entité a gardé son ERP, son plan de comptes et ses habitudes de reporting. Chaque mois, la direction financière produit un reporting consolidé pour la direction générale, et ce cycle reposait sur une chaîne entièrement manuelle : collecte de fichiers hétérogènes, reprise dans un classeur central, normalisation, recalcul, contrôles. Une à deux journées de travail par cycle.
Le sujet n'est pas venu de l'informatique. Il est sorti de nos sessions d'acculturation avec le comité de direction : la fonction finance l'a désigné comme son cas d'usage le plus coûteux en temps et le plus pauvre en valeur ajoutée. Le paradoxe : un entrepôt de données alimenté par les ERP existait déjà. La vraie question n'était donc pas « faut-il une plateforme data ? » mais « pourquoi le reporting reste-t-il manuel ? ».
Ce qu'on a fait
- Acculturer avant d'outiller. Des sessions pour les dirigeants et les fonctions support, puis des workshops par métier (qualité, RSE, DSI, AI Champions). Plus de 140 collaborateurs formés.
- Un hackathon de trois jours avec les directions financières. Sur leurs propres données : un entrepôt de travail, un serveur MCP branché sur Claude, et des équipes qui interrogent leurs propres chiffres en langage naturel avant la fin du hackathon.
- Un diagnostic data, source par source. Un entretien par direction financière et un référentiel qui croise chaque société avec chaque indicateur. Constat clé : le chiffre d'affaires vient des ERP, mais le budget, la trésorerie et les engagements vivent dans des fichiers.
- Une architecture sobre. Un serveur MCP comme point d'accès unique, en lecture seule garantie par la base, sans aucune copie des données de production. Les fichiers de gestion deviennent une source à part entière. Les agents lisent, calculent et signalent ; aucune action sortante sans validation humaine.
- La preuve par le publié. Les trois derniers arrêtés mensuels ont été regénérés de bout en bout en 17 jours, puis confrontés cellule par cellule aux chiffres reçus par la direction générale. Chaque écart affiche la valeur publiée et sa cause.
Schéma de la missionReporting financier consolidé
Le reporting financier d'un groupe, reconstruit depuis ses ERP, chiffre par chiffre.
- 01Acculturer avant d'outiller
- 02Un hackathon de trois jours avec les directions financières
- 03Un diagnostic data, source par source
- 04Une architecture sobre
- 05La preuve par le publié
Résultat
-97 %
d'effort de traitement sur la consolidation mensuelle
Le résultat
- La consolidation passe d'une à deux journées à quelques dizaines de minutes.
- Sur le dernier arrêté, le chiffre d'affaires groupe reconstruit est à 0,1 % du publié, la trésorerie corrigée est exacte à l'unité près, et plus de la moitié des sociétés tombent juste à la précision du reporting.
- Dix ans d'historique mensuel reconstitués, là où les tables décisionnelles n'en portaient que vingt et un mois.
- Pour la première fois, la direction financière dispose de l'explication écrite de chaque règle qui fabrique ses chiffres.
- Le groupe a retenu notre plateforme souveraine Obelyx pour la mise en production. Un deuxième chantier suit : le rapprochement bancaire multi-banques, avec 76 % des lignes vérifiées automatiquement sur une première filiale.
Ce qu'on en retient
Le goulot n'était ni l'ERP, ni l'entrepôt, ni les agents. C'était la date à laquelle les entités arrêtent leurs comptes. Automatiser le traitement fait apparaître le vrai sujet : un choix de gouvernance financière, que seul le client peut trancher.
