Quelque part dans le processus figure un chiffre que plus personne ne peut expliquer. La consommation scope 2 d'un site, le nombre d'ETP dans une filiale, la quantité de déchets par ligne de production. Le chiffre figure dans le rapport de l'année dernière, mais personne ne sait plus de quel système il provient, qui l'a saisi, s'il est le résultat d'une addition ou d'une estimation. Ce n'est pas une exception. C'est l'une des constatations les plus fréquentes dès qu'une organisation examine ses données de durabilité de manière systématique pour la première fois.
La question n'est pas rhétorique. Une donnée sans source n'est pas forcément erronée, mais elle n'est pas prouvée. Et une donnée non prouvée qui se retrouve tout de même dans un rapport constitue un risque qui ne se révèle qu'au moment où quelqu'un — un prestataire d'assurance, une autorité de contrôle, un client avec ses propres obligations de chaîne — pose des questions plus poussées.
Un registre des données n'est ni un outil de reporting ni un tableau de bord. C'est une liste : chaque donnée qui aboutit dans un rapport de durabilité, accompagnée d'un certain nombre de champs fixes. D'où vient-elle. Qui en est le propriétaire. Quels traitements se situent entre la source et le rapport. Selon quelle règle sa qualité est-elle évaluée. Quand a-t-elle été contrôlée pour la dernière fois.
Sans ces champs, une donnée n'est qu'un chiffre qui se trouve là par hasard. Avec ces champs, elle devient une information dont l'origine est consignée, et donc vérifiable de manière reproductible. Cette distinction est précisément ce sur quoi les organisations s'enlisent : le rapport existe, la structure sous-jacente non.
Dans la plupart des cas, il y a bien eu une source à l'origine. Quelqu'un a un jour extrait un chiffre d'un système ERP, l'a placé dans un tableur, et un collègue l'a repris l'année suivante sans copier son origine. Ou le chiffre est le résultat d'un calcul — une estimation basée sur une moyenne, une conversion de litres en kilogrammes de CO2 — dont la règle de calcul n'a jamais été notée. C'est précisément ce parcours, quels traitements se situent entre la source et le rapport, qui fait disparaître le plus d'informations. Un chiffre qui a été traité trois fois avant d'atteindre le rapport a eu trois occasions de perdre son origine.
Dans les organisations comptant plusieurs sites ou unités opérationnelles, une seconde cause s'ajoute : la même donnée existe à plusieurs endroits, sous une forme légèrement différente, et personne n'a jamais établi quelle version constitue la donnée source. C'est une question différente de celle de la source manquante, mais elles se recoupent : si vous voulez savoir où une donnée existe déjà dans plusieurs unités opérationnelles, vous vous heurtez souvent exactement au même angle mort.
Une donnée sans source reçoit dans le registre un statut : non confirmée. Ni supprimée, ni tacitement présumée correcte, mais marquée. À partir de ce moment, un choix s'impose, et ce choix dépend de ce qui est en jeu. S'il s'agit d'une donnée évaluée comme mineure dans une analyse de matérialité, sa source peut être retrouvée ultérieurement sans que le rapport n'en dépende. S'il s'agit d'une donnée soumise à une mission d'assurance, la source est une condition, pas un simple plus.
La recherche elle-même suit un parcours fixe : retour au document ou au système source, en passant par chaque étape de traitement, jusqu'au propriétaire capable de confirmer l'exactitude du chiffre. C'est exactement ce que le mapping source-to-report recouvre : non pas vérifier le chiffre, mais reconstituer le chemin qui y mène. Il arrive que ce chemin ne puisse plus être reconstitué. La conclusion n'est alors pas que le chiffre est erroné, mais qu'il ne peut être prouvé — un résultat différent, et tout aussi important pour un rapport.
Un registre n'est pas achevé dès que chaque donnée possède une source. Il est achevé dès que chaque donnée dispose d'un propriétaire identifiable, d'une règle de qualité selon laquelle elle est évaluée, et d'un historique de traitement consigné qui peut être parcouru à nouveau sans que quiconque doive s'en souvenir par cœur. Ce que cela recouvre précisément, et le moment où vous pouvez cesser de chercher davantage de détails, est développé sur quand un registre est-il achevé. Pour la plupart des organisations, la réponse est concrète, mais peu satisfaisante : il est achevé lorsqu'un nouveau collègue peut reconstituer le rapport sans aide.
Repérer et corriger une donnée sans source est un travail qui se décompose en étapes : parcourir les documents source, retracer les traitements, contacter les propriétaires, consigner les réponses. Une partie de ce travail — parcourir les systèmes à la recherche d'un chiffre manquant, regrouper les confirmations obtenues — est suffisamment répétitive pour qu'on calcule ce que l'IA peut en prendre en charge. Le scan de travail de FTE TO AI fait cela tâche par tâche : non pas par des affirmations générales sur l'automatisation, mais par une estimation concrète de la part de ce type de travail de recherche pouvant être confiée à un système, et de la part qui continue d'exiger appropriation et jugement humain.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.