Source de vérité des données métier : pourquoi un service de calcul ne doit pas stocker ses résultats

Le moment où un calcul devient un service

Tant qu'un calcul vit dans un tableur, la question de son stockage ne se pose pas. Le prix d'un contrat, le score d'un dossier ou la date de livraison estimée sont calculés dans la même feuille que celle où ils sont conservés, par la même personne, au même moment. La question apparaît le jour où ce calcul sort du tableur pour devenir une brique logicielle à part entière : un service de tarification appelé par le back-office, un moteur de planification interrogé par l'outil de production, un modèle d'IA qui classe les demandes entrantes. Le calcul est désormais un composant que d'autres systèmes appellent, et il faut décider qui garde la trace de ce qu'il répond.

Ce moment arrive dans presque toute modernisation de SI, parce que sortir la logique de calcul d'un fichier Excel ou d'un vieux progiciel est précisément ce qui la rend maintenable, testable et réutilisable. C'est une bonne décision. Le piège est ailleurs : dans la réponse que l'équipe technique donne, souvent sans en débattre, à la question du stockage.

Pourquoi la proposition « le service stocke lui-même » paraît raisonnable

La proposition revient avec une régularité remarquable : puisque le service calcule, qu'il enregistre aussi ses résultats dans son propre schéma de base de données. L'argument se tient en apparence. Le service connaît le mieux ce qu'il produit, il a toutes les variables sous la main, et le développeur qui le construit n'a pas besoin de coordonner quoi que ce soit avec l'équipe du back-office. C'est plus rapide à livrer, plus simple à tester isolément, et personne ne se sent bloqué par personne. Tous ces avantages sont réels. Ils sont aussi tous du côté de ceux qui construisent le système, aucun du côté de ceux qui l'utiliseront pour prendre des décisions.

Deux garants pour une même donnée, c'est zéro garant

Une donnée métier ne peut avoir qu'une seule source de vérité, et ce doit être le système qui porte la responsabilité fonctionnelle de cette donnée. Quand le service de calcul stocke ses résultats et que le back-office métier les reprend pour facturer, suivre ou produire des statistiques, deux systèmes deviennent garants de la même information. Tant qu'ils concordent, personne ne remarque rien. Le jour où ils divergent, et ils divergent toujours, personne ne sait lequel croire, et la réunion qui devait servir à décider sert à réconcilier des chiffres.

Les divergences ne viennent pas d'erreurs spectaculaires. Elles viennent d'un prix recalculé après la modification d'une grille tarifaire, d'un score retouché à la main par un commercial dans le back-office sans que le service en soit informé, d'un résultat corrigé d'un côté et pas de l'autre. Chaque écart est anodin. Leur accumulation produit exactement le symptôme que la modernisation devait supprimer : des chiffres différents selon la personne qui les sort, un signal déjà décrit dans notre article sur les six signes d'un SI fragmenté.

Les appels qui ne sont pas des décisions

Un second problème est moins visible et tout aussi coûteux. Un service de calcul est appelé bien plus souvent que ses résultats ne deviennent des décisions. Un commercial simule trois variantes de prix avant d'en proposer une. Un testeur lance cinquante calculs pour valider une nouvelle règle. Un écran rafraîchit une estimation à chaque modification d'un champ. Si le service stocke chaque réponse, la base se remplit de résultats qui n'ont jamais engagé l'entreprise, mélangés à ceux qui l'ont engagée, sans aucun moyen fiable de distinguer les uns des autres. Le service ne peut pas savoir lequel de ses calculs a été retenu. Seul le système métier le sait, parce que c'est lui qui a enregistré le devis envoyé, le contrat signé, la priorité validée.

Ce débat s'est posé tel quel chez un fournisseur d'énergie ETI, filiale d'un groupe suisse, au moment de brancher un service de tarification algorithmique sur son back-office. La proposition initiale était de laisser le service écrire ses résultats dans son propre schéma. Elle a été écartée au motif que le back-office porte la logique métier, donc la garde de la donnée, et que deux garants pour un même prix créeraient une confusion durable. Le choix a été fait avant la première ligne de code du flux, ce qui en a rendu le coût à peu près nul.

« [...] il faut vraiment réfléchir à la conception et à la compréhension de tout avant de se dire, c'est bon, on a déjà ça en base de données, du coup, on va le faire comme ça. »

Calculer, pas stocker : le principe et ce qu'il exclut

Le principe qu'on peut nommer calculer, pas stocker tient en une phrase : un service de calcul reçoit des données, renvoie un résultat, et ne conserve rien qui ait valeur de vérité métier. C'est le système appelant, celui qui porte la responsabilité fonctionnelle, qui décide quoi enregistrer, à quel moment et avec quel contexte. Le service reste sans état du point de vue du métier : on peut le remplacer, le réécrire ou le faire tourner deux fois sur les mêmes entrées sans que la moindre donnée officielle ne change.

Ce découpage a une conséquence pratique immédiate : le système métier doit stocker non seulement le résultat retenu, mais aussi ce qui permet de l'expliquer plus tard. La version de la grille appliquée, les principaux paramètres d'entrée, la date du calcul, et le fait que la valeur a été ajustée manuellement le cas échéant. C'est ce contexte, et non la seule valeur, qui permet de répondre dans six mois à un client qui conteste un prix. Un service de calcul qui stocke ses propres résultats donne l'illusion de cette traçabilité, sans jamais savoir lequel de ses résultats a réellement été utilisé.

Ce que le principe exclut, et ce qu'il n'exclut pas

Le principe n'interdit pas au service de calcul d'avoir sa propre mémoire technique. Un cache pour accélérer des calculs répétitifs, des tables de paramètres qu'il lit, un journal des appels pour diagnostiquer une lenteur restent parfaitement légitimes. Le critère de distinction est simple : si l'on vidait entièrement ce stockage demain matin, l'entreprise perdrait-elle une information qu'elle ne peut pas reconstituer ? Si la réponse est non, c'est de la mémoire technique. Si la réponse est oui, une donnée métier s'est glissée au mauvais endroit.

Il exclut en revanche un raisonnement très répandu dans les équipes techniques : choisir l'emplacement d'une donnée selon ce qui arrange celui qui code, et non selon qui en répond devant le métier. Ce n'est pas un procès d'intention. Le développeur du service optimise son périmètre, ce qui est son travail. C'est au moment de la conception, et à la personne qui porte la vision du SI dans son ensemble, de trancher la question de la garde avant que la commodité ne la tranche à sa place. Ce rôle d'arbitre est précisément celui que nous décrivons dans notre article sur l'architecte comme garde-fou d'un projet SI en PME.

La même règle s'applique à un modèle d'IA

Un modèle d'IA intégré à un SI est un service de calcul comme un autre. Il reçoit une demande, un document ou une série de données, et il renvoie une catégorie, une extraction, un score ou une proposition de réponse. Tout ce qui précède s'applique donc, avec une circonstance aggravante : un modèle d'IA est encore plus souvent appelé pour rien qu'un moteur de tarification. Les tests de prompt, les reformulations, les propositions rejetées par un opérateur se comptent par centaines pour une réponse finalement retenue.

L'erreur la plus fréquente en intégrant une IA dans un outil métier est de laisser la chaîne IA, ou l'outil qui l'orchestre, écrire directement ses réponses dans les tables métier. La catégorisation proposée par le modèle devient la catégorie officielle sans que personne ne sache si un humain l'a validée, corrigée ou simplement ignorée. Le bon découpage est le même que pour n'importe quel service : le modèle propose, le système métier enregistre la valeur retenue, avec la mention de son origine. C'est aussi la logique qui fonde notre recommandation de faire passer l'IA par des fonctions codées plutôt que par un accès libre aux données, développée dans notre article sur le function calling comme garde-fou entre l'IA et votre base de données.

Tracer sans donner le statut de vérité

Garder une trace des réponses d'un modèle reste utile pour mesurer sa fiabilité dans le temps, comparer deux versions ou comprendre une erreur. Cette trace a sa place dans un journal technique séparé, pas dans les tables que le reste de l'entreprise consulte pour décider. La distinction paraît bureaucratique jusqu'au jour où quelqu'un construit un tableau de bord sur la mauvaise table et présente au comité de direction un taux de réclamations calculé à partir de propositions que personne n'a jamais retenues.

La question à poser avant votre prochain atelier d'architecture

Pour chaque service de calcul ou modèle d'IA que votre SI appelle, ou s'apprête à appeler, demandez à l'équipe de répondre par écrit à une seule question : si ce service disparaissait demain avec tout ce qu'il a stocké, quelle information métier perdrions-nous ? Si la réponse est « aucune », le découpage est sain. Si la réponse cite un prix, un score, une priorité ou une date qui a engagé l'entreprise, vous avez identifié une donnée qui a changé de garant sans que personne ne l'ait décidé. Déplacer cette donnée vers le système métier coûte quelques jours avant la mise en production. Après deux ans de fonctionnement, avec des rapports et des calculs construits de part et d'autre, cela devient un chantier de migration à part entière.