Parcourez n’importe quel programme EPM en difficulté et les symptômes pointent dans la même direction : le chargement a échoué cette nuit et personne ne sait pourquoi ; les réalisés ne se réconcilient pas avec l’ERP ; la hiérarchie a changé et quarante modules ont cassé. Aucun n’est un problème de modélisation. Ce sont des problèmes de data déguisés en planification, et ils étaient tous visibles avant le démarrage du projet.
L’anti-pattern : l’héroïsme point à point
L’architecture d’intégration par défaut d’un premier projet EPM est un tuyau direct depuis l’ERP (plus trois tableurs, plus un extrait CRM) vers la plateforme de planification, construit à la hâte pendant l’implémentation par qui était disponible. Ça marche le jour du go-live. Puis ça se dégrade, silencieusement, parce que chaque changement de source atterrit directement sur le modèle, et parce que plus personne ne possède le tuyau une fois l’intégrateur parti.
Ce qu’est réellement un hub de données de planification
Pas un programme d’entrepôt de données. Un hub de données de planification est une couche fine et possédée, typiquement une poignée de tables curées sur la plateforme que vous avez déjà (BigQuery, Snowflake, voire un PostgreSQL bien tenu), qui remplit quatre missions :
- Conformer les données de référence une seule fois : une hiérarchie produit, une hiérarchie client, un arbre de centres de coûts, versionnés, avec dates d’effet, consommés par chaque modèle de planification plutôt que reconstruits dans chacun.
- Mettre en staging les flux transactionnels à la maille de planification, avec des contrôles qualité qui échouent bruyamment avant que les données n’atteignent le modèle.
- Tenir le contrat d’intégration : schémas, fenêtres de rafraîchissement et SLA convenus par écrit entre la DSI et la finance, pour qu’un changement côté source soit une négociation plutôt qu’une panne.
- Récupérer les sorties de plan, pour que plans, prévisions et réalisés puissent être comparés dans le temps sans archéologie à l’intérieur de l’outil de planification.
Pourquoi cela change l’économie du projet
Avec un hub en place, la plateforme de planification cesse d’être l’endroit où l’on découvre et rafistole les problèmes de data. La logique du modèle se simplifie, plus de formules défensives autour d’entrées sales. Ajouter un deuxième modèle (les effectifs après la demande, par exemple) coûte des semaines, pas des mois, parce que les fondations sont déjà conformées. Et le jour où vous migrez ou ajoutez une plateforme, c’est le hub qui rend le mouvement survivable : la logique est portable parce que la couche de données n’a jamais appartenu à l’éditeur.
La propriété, c’est ce que les organisations ratent
Le hub échoue s’il appartient au « projet ». Il lui faut un propriétaire nommé, en pratique une petite capacité de data engineering avec un responsable à l’aise avec la finance, et une ligne budgétaire qui survit au go-live. C’est généralement une à deux personnes, pas un département. Le test est simple : quand l’équipe ERP annonce un changement de champ, est-ce que quelqu’un dont c’est le rôle reçoit l’information et évalue l’impact sur la planification ? Si la réponse est non, vous n’avez pas de fondation data ; vous avez un délai entre deux incidents.
Le séquencement d’un vrai programme
- La conformité des données de référence d’abord, c’est le travail à plus fort levier et le moins glamour du chemin critique.
- Mettre en staging les deux ou trois flux dont le premier modèle a réellement besoin ; résister à l’envie de tout traiter d’un coup.
- Rédiger les contrats d’intégration tant que la bonne volonté est haute, pas après la première panne.
- Alors seulement, laisser la construction du modèle consommer depuis le hub.
Sur les programmes structurés ainsi, nous voyons systématiquement les incidents d’intégration devenir des événements rares plutôt qu’un bruit hebdomadaire, et, plus important, des équipes de planification qui font confiance à leurs propres chiffres. Cette confiance, pas le modèle, est le livrable.
