Architecture data de la finance

L’architecture data de la finance organise le parcours d’une donnée depuis son système d’origine jusqu’au chiffre utilisé pour décider, en précisant les transformations et les responsabilités. Elle relie les besoins financiers aux choix techniques pour que le même montant conserve une signification explicite lorsqu’il passe de la comptabilité à l’analyse ou à la préparation des prévisions.

• Des sources identifiées et des flux maîtrisés. Un flux de données est un transfert organisé d’informations entre systèmes. Pour chaque flux, la finance doit connaître l’origine, le contenu, la fréquence, les contrôles et le responsable. Une extraction n’est pas fiable simplement parce qu’elle est automatisée : il faut vérifier qu’elle couvre la bonne période, toutes les entités attendues et les écritures retenues pour l’usage concerné. Les données rejetées doivent être visibles et traitées, plutôt que disparaître silencieusement du résultat.
• Un langage financier commun. Un référentiel est une liste partagée de codes, de libellés et de règles de classement. Comptes, entités, produits et activités doivent être interprétés de manière cohérente. Cela ne signifie pas imposer la même organisation partout : les particularités locales peuvent être conservées si leur correspondance avec la lecture commune est documentée. Le périmètre est l’ensemble des entités, activités ou opérations retenues pour un calcul. Le chiffre devient comparable parce que son périmètre et sa définition sont connus, pas parce que tous les fichiers ont la même présentation.
• Une chaîne explicable jusqu’à la décision. La traçabilité des données est la capacité à retrouver leur origine et les transformations appliquées. Un total publié doit pouvoir être rapproché de sa source, avec ses règles de calcul et son statut de validation. Les outils de restitution ne remplacent pas cette discipline. Une architecture utile permet aussi de corriger une anomalie à l’endroit approprié, de republier une donnée approuvée et de comprendre quels usages sont concernés par la correction.

Sans architecture explicite, la direction financière peut disposer de nombreux outils tout en restant dépendante d’un assemblage fragile de fichiers. Les mêmes données sont extraites plusieurs fois, les corrections circulent par courriel et chaque équipe conserve sa propre interprétation des comptes ou des activités. Le travail consiste alors davantage à expliquer les différences entre documents qu’à analyser la performance.

Des chiffres identiques en apparence, différents en réalité

Deux états portant le même intitulé peuvent différer parce que l’un exclut une entité, que l’autre intègre des écritures tardives ou que leurs dates d’extraction ne sont pas les mêmes. Sans description du périmètre et de la date de référence, la comparaison devient trompeuse. Une correction locale peut ensuite résoudre un écart dans un fichier tout en créant une divergence ailleurs.

Des responsabilités difficiles à établir

Lorsqu’un code produit manque ou qu’un montant semble incohérent, personne ne sait nécessairement qui doit intervenir : l’équipe qui saisit l’opération, celle qui transporte les données ou celle qui produit le tableau. L’architecture rend cette répartition explicite. Elle distingue un problème de donnée source, une erreur de transformation et une mauvaise définition financière, qui appellent des actions différentes.

Des analyses qui ne résistent pas aux changements

Une nouvelle entité, une réorganisation ou un changement de logiciel peut casser des traitements construits autour de codes implicites. L’historique devient difficile à comparer si les anciennes données sont reclassées sans conserver leur lecture d’origine. Les prévisions risquent aussi d’utiliser une organisation différente de celle des données réalisées.

Le problème résolu n’est donc pas seulement technique. Il concerne la confiance dans les chiffres, la capacité à reproduire une analyse et la continuité du pilotage. L’objectif est de réduire les ambiguïtés et les manipulations sans contrôle, sans prétendre supprimer tout jugement financier ni toute intervention humaine.

1. Identifier les sources faisant autorité. Un ERP, ou progiciel de gestion intégré, enregistre notamment les opérations comptables et commerciales. D’autres applications portent les effectifs, les commandes ou les encaissements. Pour chaque donnée, désigner la source retenue et préciser son statut : enregistrée, provisoire ou validée. Une information commerciale ne devient pas automatiquement une donnée comptable.

2. Collecter avec des contrôles de transport. L’ETL, extraction, transformation et chargement, prépare les données avant leur insertion dans une destination ; l’ELT, extraction, chargement et transformation, les prépare après leur chargement. Le choix dépend des outils, des volumes et des contraintes. Dans les deux cas, conserver les dates, les volumes reçus, les erreurs et l’identifiant de chaque transfert.

3. Conserver et structurer les données. Un entrepôt de données, ou Data Warehouse, est un espace de stockage structuré destiné à l’analyse. Un Data Lake conserve des données dans des formats variés ; un Data Lakehouse associe ce stockage à des fonctions de gestion structurée. Ces options ne sont pas des étapes obligatoires. La priorité est de préserver les données reçues et de produire une couche contrôlée adaptée aux usages.

4. Appliquer les règles financières. Le mapping comptable est la correspondance entre des comptes sources et des comptes ou rubriques cibles. Les règles précisent aussi les signes, les unités, les périodes et les regroupements. Une dimension est un axe d’analyse, par exemple l’entité ou le produit. La granularité est le niveau de détail d’une donnée : une écriture et un total mensuel ne permettent pas les mêmes analyses.

5. Valider, publier et tracer. La BI, informatique décisionnelle, regroupe les outils d’analyse et de restitution. L’EPM, gestion de la performance d’entreprise, organise notamment la planification, les calculs et les validations financières. Leur alimentation doit reposer sur des données contrôlées dont le statut est explicite. Des données provisoires peuvent être chargées pour analyse ou validation ; leur publication comme données approuvées doit respecter les contrôles et validations prévus. Le lineage, ou filiation des données, décrit le parcours technique et fonctionnel du chiffre ; il complète les contrôles de rapprochement, comparaison de deux ensembles de données afin d’identifier et d’expliquer leurs différences.

Cet exemple est fictif : une entreprise de taille intermédiaire regroupe les données mensuelles de deux entités, Nord et Sud, pour comparer leur activité réalisée au budget. Le budget est la référence financière approuvée pour une période ; le réel correspond ici aux montants enregistrés et validés pour cette même période. Toutes les valeurs sont en euros, sans conversion de devise ni opération entre les entités.

Le chiffre d’affaires (CA) est le montant des ventes retenues sur la période. Les coûts variables évoluent avec le niveau d’activité selon la convention retenue. La marge sur coûts variables est égale au CA moins les coûts variables. Ces définitions sont communes aux deux entités.

| Entité | CA réel | Coûts variables réels | Marge réelle | CA budget | Coûts variables budget | Marge budget | |---|---:|---:|---:|---:|---:|---:| | Nord | 120 000 | 72 000 | 48 000 | 110 000 | 66 000 | 44 000 | | Sud | 80 000 | 52 000 | 28 000 | 90 000 | 54 000 | 36 000 | | Total | 200 000 | 124 000 | 76 000 | 200 000 | 120 000 | 80 000 |

Les calculs sont explicites : marge réelle Nord = 120 000 − 72 000 = 48 000 ; marge réelle Sud = 80 000 − 52 000 = 28 000. Au total, CA réel = 120 000 + 80 000 = 200 000 ; coûts variables réels = 72 000 + 52 000 = 124 000 ; marge réelle = 200 000 − 124 000 = 76 000.

L’écart budgétaire est égal au réel moins le budget. L’écart de marge est donc 76 000 − 80 000 = −4 000 euros, défavorable. L’écart de coûts variables est 124 000 − 120 000 = +4 000 euros, défavorable ici. Le taux de marge sur coûts variables est la marge sur coûts variables divisée par le CA : 76 000 / 200 000 × 100 = 38 % au réel, contre 80 000 / 200 000 × 100 = 40 % au budget.

L’architecture conserve les extractions d’origine, applique les correspondances de comptes et rapproche les totaux avec les sources. Le CA total respecte le budget, mais cela masque deux écarts opposés : +10 000 euros au Nord et −10 000 euros au Sud. Le détail par entité reste donc nécessaire pour expliquer la baisse de marge.

1. Partir d’une décision à éclairer. Décrire les questions auxquelles la finance doit répondre, les utilisateurs, les échéances et le détail nécessaire. Éviter de commencer par un catalogue de technologies. Livrable : une fiche d’usage précisant les données attendues, leur définition et les critères d’acceptation.

2. Cartographier l’existant. Recenser les applications, fichiers, extractions, règles et corrections manuelles. Identifier la source faisant autorité pour chaque donnée ainsi que les dépendances entre traitements. Livrable : une carte des flux avec responsables, fréquence, contrôles et difficultés connues.

3. Définir le modèle cible. Le modèle de données décrit les informations stockées et leurs relations. Choisir les dimensions, la granularité, les périodes et les unités. Distinguer les données communes des besoins propres à chaque usage. Livrables : dictionnaire des données et tables de correspondance approuvées, notamment pour le mapping comptable.

4. Concevoir les règles de contrôle et d’accès. Prévoir les rapprochements, les traitements de rejet, les droits de consultation et les droits de modification. Définir ce qui bloque une publication et ce qui déclenche seulement une alerte. Livrables : catalogue des contrôles, matrice des droits et procédure de correction.

5. Construire un périmètre pilote complet. Choisir un usage limité mais représentatif, incluant une difficulté réelle : changement de code, correction tardive ou donnée manquante. Tester toute la chaîne, de l’extraction au tableau validé. Livrables : flux opérationnel, journal d’exécution et résultats des tests financiers.

6. Faire accepter puis mettre en service. La recette utilisateur est la vérification, par les utilisateurs métier, que la solution répond aux besoins convenus. Comparer les résultats aux sources, vérifier les accès et tester la reprise après incident. Livrables : procès-verbal d’acceptation, documentation et consignes d’exploitation.

7. Étendre sans perdre la maîtrise. Ajouter les usages après stabilisation des règles communes. Chaque extension doit préciser son impact sur les données existantes. Livrables : plan d’évolution, responsables de maintenance et suivi des anomalies. La finance valide le sens des chiffres ; l’équipe technique sécurise leur transport et leur disponibilité.

Écrire les définitions avant de construire les calculs

Un dictionnaire partagé doit préciser le sens de chaque donnée, son unité, sa source et ses conditions d’utilisation. Pour une marge, documenter les charges incluses ; pour un effectif, préciser la population et la date d’observation. Cette discipline évite qu’un même intitulé recouvre plusieurs calculs. Le référentiel doit être entretenu comme un actif de gestion, pas comme un fichier annexe.

Conserver l’origine et séparer les corrections

Préserver les données reçues permet de rejouer les traitements et d’expliquer un changement. Une correction financière doit avoir un motif, un auteur et une validation. Elle ne doit pas effacer silencieusement la donnée d’origine. Corriger dans la source lorsque c’est approprié ; sinon, enregistrer séparément l’ajustement et son impact.

Rapprocher à plusieurs endroits

Contrôler le passage entre source et stockage, puis entre données transformées et restitution. Les contrôles doivent combiner montants, présence des données et cohérence des périodes : un total correct peut masquer des omissions compensées par des doublons.

Adapter le détail et la fréquence à l’usage

Un tableau mensuel n’exige pas nécessairement une alimentation continue. À l’inverse, une analyse d’encaissements peut nécessiter des données plus fréquentes. Conserver le détail utile à l’explication sans charger chaque outil avec toutes les écritures disponibles. La disponibilité technique d’une donnée ne signifie pas qu’elle soit déjà validée financièrement.

Prévoir les changements et les incidents

Le versionnement est la conservation de plusieurs états identifiés d’une donnée ou d’une règle. Dater les correspondances et conserver les états publiés protège la comparaison historique. Tester aussi le retraitement d’une période et la restauration des données. Enfin, appliquer le principe du moindre privilège, qui limite les accès aux seuls droits nécessaires : les informations salariales ou individuelles ne doivent pas circuler simplement parce qu’elles sont présentes dans une source commune.

Choisir une plateforme avant de définir les usages

Une technologie ne résout pas une ambiguïté de définition. Collecter toutes les données sans objectif produit souvent un stockage difficile à exploiter. Pour éviter ce piège, partir des décisions à prendre, puis déterminer le détail, la fréquence et les contrôles nécessaires. Le choix technique vient ensuite, avec des critères explicites.

Confondre données chargées et données utilisables

Un transfert réussi confirme que des données sont arrivées, pas qu’elles sont complètes ou correctes. Des codes inconnus, une période erronée ou une extraction partielle peuvent traverser un traitement sans erreur technique. Prévoir une validation financière distincte et afficher clairement le statut des données dans les restitutions.

Écraser l’historique lors d’une réorganisation

Remplacer une ancienne affectation par la nouvelle rend parfois impossible la reproduction d’un tableau déjà diffusé. Conserver les règles datées et préciser si une analyse utilise l’organisation d’origine ou une organisation retraitée. Une comparaison peut être reconstruite, mais cette reconstruction doit rester identifiable.

Additionner des mesures qui ne s’additionnent pas

Une mesure additive est sommable sur tous les axes pertinents. Une mesure semi-additive est sommable sur certains axes seulement : un solde de trésorerie peut être additionné entre comptes ou entités sous conditions de périmètre et de devise, mais pas entre dates. Une mesure non additive, comme un taux, ne se somme pas. Le taux de marge global se recalcule en divisant la somme des marges par la somme des chiffres d’affaires, puis en multipliant par 100 pour l’exprimer en pourcentage. Documenter la règle d’agrégation de chaque mesure et tester les totaux affichés.

Multiplier les règles dans les outils de restitution

Si chaque tableau recalcule les mêmes rubriques à sa façon, les divergences réapparaissent malgré une source commune. Centraliser les définitions partagées et laisser aux rapports les calculs réellement propres à leur usage. Toute exception doit être nommée et expliquée.

Automatiser sans organiser la reprise

Un flux qui fonctionne en situation normale peut créer des doublons lorsqu’il est relancé. L’idempotence est la propriété d’un traitement dont la répétition ne modifie pas davantage le résultat attendu. Tester les relances, les interruptions et les corrections tardives. Définir qui décide de republier les données et comment les utilisateurs sont informés d’une modification.

Un KPI, indicateur clé de performance, mesure un résultat important pour un objectif donné. Pour l’architecture data, il doit éclairer la fiabilité ou la disponibilité des données, et non seulement l’activité technique. Chaque formule doit préciser son périmètre, sa période et les exclusions éventuelles ; un dénominateur nul conduit à un résultat non calculable, pas à un succès automatique.

• Taux de flux livrés à l’heure = nombre de flux attendus disponibles et validés avant l’échéance / nombre de flux attendus × 100. Mesurer une disponibilité métier : une livraison technique non validée ne compte pas comme prête à l’emploi.
• Taux de rejet = nombre d’enregistrements rejetés / nombre d’enregistrements reçus × 100. Compléter ce taux par les montants concernés et les motifs, car une anomalie peu fréquente peut avoir un impact financier important.
• Taux de couverture des correspondances = nombre de codes sources utilisés disposant d’une correspondance valide / nombre de codes sources utilisés × 100. Vérifier aussi que la correspondance est correcte et applicable à la période.
• Écart de rapprochement = montant chargé après transformation − montant source attendu après application des règles documentées. L’objectif est de détecter les écarts inexpliqués ; les exclusions autorisées doivent être explicites.
• Délai de disponibilité validée = date et heure de validation − date et heure de disponibilité de la source. Choisir une unité commune et observer les étapes qui composent ce délai.
• Taux de corrections après publication = nombre de publications ayant nécessité une correction de données / nombre de publications × 100. Définir ce qui constitue une publication et distinguer une erreur d’une mise à jour prévue.

Les livrables associés rendent ces mesures actionnables : carte des flux, dictionnaire, tables de correspondance datées, catalogue des contrôles, journal des rejets, preuves de rapprochement et état des validations. S’y ajoutent la matrice des droits et la procédure de reprise.

Le tableau de suivi doit identifier un responsable et une action pour chaque anomalie significative. Aucun seuil universel ne convient à tous les flux : la criticité dépend de l’usage, de l’échéance financière et de la sensibilité des données.

Un EPM apporte une couche de gestion financière au-dessus des données sources ou de la plateforme de données. Il ne remplace pas automatiquement l’ERP ni l’entrepôt. Sa valeur dépend de la qualité des données reçues, des règles configurées et de l’adéquation entre son modèle et les processus financiers.

Des données reliées aux processus

Selon la solution et les modules retenus, un EPM peut organiser les imports, les correspondances, les contrôles, les calculs et les validations. Un workflow est un enchaînement de tâches et d’approbations attribuées à des responsables. Il permet de distinguer une donnée reçue, contrôlée, approuvée et publiée. Un scénario est un ensemble cohérent d’hypothèses ; une version est un état identifié des données ou hypothèses. Leur gestion facilite la séparation entre réel, budget et prévisions.

Une frontière à définir avec la plateforme de données

La plateforme peut conserver le détail des opérations et préparer les données communes. L’EPM peut porter les hypothèses, les ajustements financiers et les calculs propres à la planification ou à la consolidation. La consolidation est le processus de présentation des comptes de plusieurs entités comme ceux d’un ensemble économique. Sa mise en œuvre demande des fonctions dédiées, qui ne sont pas présentes de manière équivalente dans tous les outils.

Il faut décider où chaque règle s’exécute et comment les résultats repartent vers les outils d’analyse. Dupliquer une formule dans plusieurs systèmes crée une nouvelle source de divergence. Les frontières entre BI et EPM doivent donc être explicites.

Des éditeurs à examiner selon les besoins

OneStream, CCH Tagetik et Oracle EPM proposent des solutions pour plusieurs processus financiers. SAP Analytics Cloud, Anaplan, Pigment, Board et Workday Adaptive Planning sont également à examiner selon les besoins de planification, de modélisation et d’analyse.

La comparaison doit porter sur le périmètre fonctionnel effectivement proposé, les connexions aux sources, les droits, la traçabilité et la maintenance des modèles. Demander une démonstration sur ses propres cas : code inconnu, période corrigée, validation bloquée et restitution rapprochée.

Débutant : des chiffres dépendants des personnes

Les sources existent, mais les extractions et les règles sont surtout connues de quelques collaborateurs. Les fichiers servent à la fois de stockage, de correction et de restitution. Les définitions varient selon les équipes ; les validations sont informelles. Une absence ou une réorganisation peut empêcher de reproduire un résultat.

Le signe distinctif n’est pas l’usage d’un tableur, mais l’absence de règles partagées et de preuves de contrôle. La priorité consiste à documenter les sources, les définitions et les rapprochements essentiels. Un registre des corrections et un responsable par donnée constituent déjà un progrès, même sans nouvelle plateforme.

Intermédiaire : une chaîne structurée et contrôlée

Les flux importants sont organisés, les référentiels communs et les contrôles documentés. La finance distingue les données reçues des données validées. Les anomalies ont un responsable, les droits sont revus et les tableaux s’appuient sur des calculs partagés. Le détail des opérations reste accessible lorsque l’analyse l’exige.

Des fragilités peuvent subsister : correspondances modifiées manuellement, historique incomplet ou dépendance à un spécialiste technique. La priorité est alors de dater les règles, de tester les reprises et de maîtriser les changements. L’architecture doit rester compréhensible au-delà de l’équipe qui l’a construite.

Avancé : une architecture gouvernée et évolutive

La gouvernance des données est l’organisation des responsabilités, des décisions et des règles relatives aux données. À ce niveau, les définitions, les accès, les validations et les évolutions sont suivis dans la durée. Les impacts d’un changement de source ou de règle peuvent être identifiés avant publication. Les états déjà diffusés restent reproductibles.

L’intelligence artificielle (IA) désigne des méthodes informatiques produisant notamment des prédictions ou des classifications à partir de données. Son utilisation repose sur des historiques qualifiés, des droits adaptés et une évaluation distincte de celle des flux financiers. Une architecture avancée ne rend pas une prédiction exacte par nature.

La maturité se juge sur la capacité à expliquer, corriger et faire évoluer les chiffres sans perdre leur contrôle. Elle ne se mesure ni au nombre d’outils ni à la quantité de données stockées.

• [ ] Les décisions et analyses à servir sont-elles décrites, avec leurs utilisateurs, leurs échéances et le détail nécessaire ?
• [ ] Pour chaque donnée importante, une source faisant autorité est-elle désignée, sans ambiguïté entre donnée commerciale, comptable et prévisionnelle ?
• [ ] Les définitions financières précisent-elles les comptes inclus, les signes, les unités et les règles de calcul ?
• [ ] Le périmètre des entités et activités est-il explicite, y compris lorsqu’il change au cours de l’historique ?
• [ ] Les dimensions communes disposent-elles de codes stables, de responsables et de règles de création ou de modification ?
• [ ] Les correspondances sont-elles approuvées et datées, avec un traitement visible des codes inconnus ?
• [ ] La granularité permet-elle d’expliquer les totaux sans imposer un détail inutile à chaque outil ?
• [ ] Les données reçues sont-elles conservées de façon à pouvoir reproduire les transformations et examiner une anomalie ?
• [ ] Les contrôles couvrent-ils les montants, les doublons, les données manquantes, les périodes et la présence des entités attendues ?
• [ ] Les écarts de rapprochement sont-ils expliqués avant publication, avec des exclusions autorisées clairement documentées ?
• [ ] Une correction distingue-t-elle la valeur d’origine, le motif, l’auteur, l’approbateur et la date de republication ?
• [ ] Les règles partagées sont-elles placées dans un système identifié plutôt que recopiées dans plusieurs rapports ?
• [ ] Les accès limitent-ils effectivement la consultation et la modification des données sensibles ?
• [ ] La relance d’un flux après interruption évite-t-elle les doublons et permet-elle de retrouver un état cohérent ?
• [ ] Les états déjà publiés peuvent-ils être reproduits malgré une réorganisation ou une modification des règles ?
• [ ] Les responsabilités de la finance et de l’équipe technique sont-elles distinctes, avec une procédure de traitement des incidents ?
• [ ] Le périmètre pilote teste-t-il des cas difficiles représentatifs, et pas seulement une alimentation sans anomalie ?
• [ ] Les utilisateurs savent-ils reconnaître une donnée provisoire, validée ou corrigée dans les restitutions ?
• [ ] Les évolutions prévues sont-elles examinées pour leur impact sur les contrôles, les accès et les usages existants ?

À retenir. Une architecture data financière fiable associe sources identifiées, définitions communes, contrôles, traçabilité et responsabilités. Les outils rendent cette organisation opérante, mais ne remplacent ni les conventions de calcul ni la validation financière. Commencer par un usage complet et maîtrisé vaut mieux qu’accumuler des données sans règle d’exploitation.

Faut-il obligatoirement un entrepôt de données ?

Non. Une organisation limitée peut utiliser des flux contrôlés directement entre ses sources et ses outils financiers. Un entrepôt devient pertinent lorsque plusieurs usages doivent partager des données structurées, un historique ou un détail important. Le choix dépend des besoins, des contraintes et de la capacité à maintenir la solution, pas d’une obligation technologique.

L’EPM doit-il contenir toutes les écritures comptables ?

Pas nécessairement. Il doit contenir le détail requis par les processus qu’il sert et permettre l’explication des montants. Les écritures peuvent rester dans l’ERP ou la plateforme de données, à condition de conserver un lien fiable avec les agrégats utilisés dans l’EPM. Certaines analyses ou fonctions de contrôle peuvent toutefois justifier un chargement plus détaillé.

Qui est responsable de la qualité des données ?

La responsabilité est partagée, mais elle doit être précise. Le responsable de la source garantit la qualité de la saisie ; l’équipe technique garantit le transport et l’exécution des transformations ; la finance approuve les définitions, les contrôles et l’usage des chiffres. Chaque anomalie doit avoir un responsable de résolution identifié. Une responsabilité collective sans attribution concrète laisse les problèmes ouverts.

Une alimentation plus fréquente améliore-t-elle toujours le pilotage ?

Non. Elle peut être utile pour certains usages opérationnels, mais aussi diffuser davantage de données provisoires. La fréquence doit correspondre au rythme de décision et au délai nécessaire à la validation. Il faut distinguer fraîcheur technique et fiabilité financière, puis informer l’utilisateur du statut de l’information.

Peut-on utiliser l’IA avant d’avoir une architecture mature ?

Un essai limité est possible sur un jeu de données contrôlé. En revanche, intégrer ses résultats au pilotage exige de connaître la qualité de l’historique, les droits d’utilisation et les limites du modèle. Une suggestion ou une prévision produite par l’IA ne doit pas être confondue avec un montant comptable validé.