Moderniser le core ERP et la donnée financière : le playbook du CFO

Le problème n'est pas que les anciens ERP "ne fonctionnent plus". SAP ECC, Oracle E-Business Suite ou Sage X3 délivrent encore leurs transactions. Le problème est que la direction générale et les investisseurs attendent désormais des clôtures en deux jours, des prévisions glissantes actualisées chaque semaine, et des analyses de rentabilité par segment à la demande. Ces attentes sont incompatibles avec une architecture où la donnée financière vit dans des tables propriétaires, extraite par des scripts écrits par un consultant parti depuis trois ans, nettoyée dans Excel par une équipe de contrôle de gestion qui ne dort pas lors des clôtures.

En 2026, la migration vers des plateformes cloud comme SAP S/4HANA Cloud, Oracle Fusion Cloud Financials ou Workday Financial Management n'est plus une option réservée aux grandes multinationales. Des ETI de 500 millions d'euros de chiffre d'affaires effectuent ces transitions en dix-huit mois. Ce qui change, c'est moins le logiciel que la discipline de programme imposée en amont.

Le playbook : une séquence en six étapes

Étape 1 : cartographier la dette de données avant de toucher au code

Avant de sélectionner un éditeur ou de lancer un RFP, l'équipe finance doit produire un inventaire de ses flux de données actuels : quelles sources alimentent le grand livre, combien de réconciliations manuelles existent entre le subledger et le GL, où se trouvent les "patches" Excel intercalés dans des processus supposément automatisés. Ce travail prend quatre à six semaines avec un analyste dédié et un outil de data lineagedata lineageData lineage maps how data moves and transforms across systems, from origin to consumption, showing where it came from, what changed it, and where it goes.Voir la définition complète → comme Alation ou Collibra. Sans cet état des lieux, le projet ERP héritera des mêmes défauts dans une interface plus récente.

Étape 2 : définir les cas d'usage métier qui pilotent les choix techniques

La question n'est pas "quel ERP choisir" mais "quelles décisions financières devons-nous prendre plus vite et avec quelle granularité de données". Si la priorité est la consolidation multi-entités avec des exigences IFRS 17 (assurance) ou IFRS 16 (leasing), cela oriente vers des modules spécifiques. Si c'est le FP&A en temps réel, cela implique d'évaluer comment l'ERP s'intègre avec Anaplan, OneStream ou SAC (SAP Analytics Cloud). Définir trois à cinq cas d'usage quantifiés, avec un gain de temps ou un gain de qualité mesuré, donne un filtre objectif pour comparer les offres.

Étape 3 : choisir une architecture de données, pas seulement un logiciel

Un ERP cloud seul ne résout pas le problème de fragmentation des données. La plupart des directions financières ont besoin d'une couche intermédiaire : un entrepôt de données analytiques (Snowflake, Google BigQuery, Azure Synapse) qui consolide les flux ERP, CRMCRMCustomer Relationship Management: software and strategy to manage and analyse customer interactions throughout their lifecycle.Voir la définition complète →, chaîne d'approvisionnement et données externes. Cette séparation entre le système transactionnel et le système analytique permet de faire évoluer l'un sans perturber l'autre. Le CFO doit arbitrer ce choix avec la DSI, pas le subir.

Étape 4 : structurer la gouvernance des données financières dès le départ

Un projet ERP qui n'adresse pas la gouvernance reproduit le problème dans douze mois. Concrètement : nommer un data owner par domaine comptable (trésorerie, immobilisations, comptes clients), définir un dictionnaire de données partagé avec les équipes opérationnelles, et établir des règles de qualité vérifiables automatiquement. Des outils comme dbt (data build tool) permettent de documenter et tester les transformations de données directement dans le pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Voir la définition complète →, ce qui réduit la dépendance aux connaissances tacites de quelques personnes.

Étape 5 : piloter par les processus, pas par les fonctionnalités

La plus grande erreur des projets ERP est de cartographier les fonctionnalités du nouveau système sur les processus existants. C'est l'occasion de revoir le processus Order-to-Cash, le Procure-to-Pay, la clôture mensuelle. Une règle pratique utilisée par plusieurs grandes directions financières européennes : si un processus actuel nécessite plus de trois systèmes ou plus de deux interventions manuelles pour aboutir, il doit être revu avant la migration, pas après.

Étape 6 : planifier la coexistence et la sortie des systèmes legacy

Peu de migrations se font en big bang. La plupart des CFO gèrent une période de dix-huit à trente-six mois où l'ancien et le nouveau système coexistent. Il faut prévoir explicitement les interfaces de synchronisation, les règles de réconciliation entre les deux environnements, et surtout une date de décommissionnement ferme pour l'ancien système. Sans cette date, le legacy survit indéfiniment et l'organisation paie deux systèmes pour les mêmes données.

Les écueils qui font dérailler ces projets

Le premier écueil est de confier la définition des besoins à la seule équipe IT ou au seul intégrateur. Les intégrateurs comme Capgemini, Accenture ou Deloitte ont des compétences réelles, mais leur modèle économique valorise la complexité. Le CFO doit maintenir un interlocuteur interne avec suffisamment de temps et d'autorité pour contester les choix de configuration.

Le deuxième écueil est de sous-estimer la qualité des données de référence (chartof accounts, centres de coût, entités juridiques). Une migration qui transporte des données mal structurées produit un système neuf avec des résultats incohérents dès le premier mois. Un nettoyage préalable des référentiels prend du temps, mais il ne se récupère pas après le go-live.

Le troisième écueil est d'acheter des modules analytiques IA proposés par l'éditeur ERP sans vérifier la qualité des données qui les alimentent. SAP, Oracle et Workday intègrent tous des fonctions de prédiction et de détection d'anomalies. Ces fonctions sont utiles quand les données sont propres et cohérentes. Sur des données fragmentées ou incomplètes, elles produisent des alertes fausses qui dégradent rapidement la confiance des utilisateurs.

Pour démarrer cette semaine

• Demander à l'équipe contrôle de gestion de lister les cinq rapports mensuels qui mobilisent le plus de préparation manuelle, avec une estimation du temps passé.
• Identifier les deux ou trois sources de données externes au GL qui ne sont pas réconciliées automatiquement avec la comptabilité.
• Vérifier si votre contrat de maintenance avec l'ERP actuel inclut une date de fin de support (SAP ECC atteint sa fin de maintenance standard en 2027).
• Obtenir un benchmark de clôture mensuelle dans votre secteur, disponible auprès de cabinets comme APQC ou Hackett Group, pour mesurer l'écart avec votre performance actuelle.

La modernisation du core ERP n'est pas un projet informatique avec un sponsor finance