Un chiffre figurant dans un rapport de durabilité a presque toujours parcouru un chemin. Il commence comme une ligne dans une facture d'énergie, un compteur dans un système de production, un champ de saisie dans un outil RH. Au moment où le chiffre apparaît dans le rapport, il a été compté, converti, agrégé et parfois corrigé. Ces étapes intermédiaires sont rarement visibles dans le résultat final. Celui qui ne regarde que le rapport voit un chiffre. Celui qui regarde le chemin parcouru voit une série de choix.
Entre la source et le rapport se trouve généralement un ordre fixe de traitements, même si personne ne l'a jamais consigné par écrit.
D'abord, les données sont collectées : exportées d'un système, retranscrites à partir d'une facture, copiées depuis une feuille de calcul. Ensuite, elles sont normalisées : les litres deviennent des mètres cubes, les kilowattheures deviennent des gigajoules, une devise locale devient une unité de calcul fixe. Puis elles sont attribuées à une catégorie ou à un scope, ce qui relève d'un choix et non d'un automatisme. Vient ensuite l'agrégation : les chiffres des sites, des mois ou des services sont réunis en un total annuel. En chemin, des corrections ont lieu, pour des doubles comptages, pour des mois manquants, pour une unité erronée qu'une personne a repérée un an plus tôt et corrigée manuellement.
Chaque étape est un endroit où une hypothèse est posée. Un facteur d'émission est choisi. Une estimation remplace une mesure manquante. Un arrondi est appliqué. En soi, rien de tout cela n'est problématique. Le problème apparaît lorsque plus personne ne sait quelle hypothèse a été posée, par qui, et pourquoi.
Un chiffre de rapport qu'on ne peut pas retracer jusqu'à sa source est un chiffre affirmé. Dès qu'un contrôleur, un auditeur ou une autorité de contrôle demande comment un chiffre a été construit, la réponse doit être davantage que « c'est dans le système ». La réponse doit pouvoir montrer le trajet : cette source, cette conversion, cette agrégation, cette correction.
Consigner ce trajet a trois conséquences directes. Premièrement, la détection d'erreurs devient une affaire de minutes plutôt que de jours, car il est clair où une conversion a été appliquée et où elle ne l'a pas été. Deuxièmement, la transmission devient possible : si la personne qui gère la feuille de calcul quitte l'entreprise, la connaissance des traitements ne part pas avec elle. Troisièmement, une base de vérification se crée, car une partie externe peut suivre les étapes sans devoir d'abord les reconstruire.
Sans cette consignation, chaque cycle de reporting est une répétition d'un travail de recherche. Quelqu'un appelle l'ancien gestionnaire, fouille de vieux e-mails, devine la raison derrière un arrondi. Ce travail est invisible dans le rapport lui-même, mais il déterminera la confiance que ce rapport mérite.
Tous les traitements n'exigent pas la même approche. L'agrégation, où des chiffres provenant de plusieurs sources sont réunis en un seul total, demande une consignation différente de la normalisation, où les unités et définitions sont harmonisées. Ceux qui veulent savoir comment documenter précisément l'agrégation trouveront cela dans une explication sur la consignation des étapes d'agrégation, et ceux qui se demandent comment traiter la normalisation le liront dans une description de la consignation de la normalisation. Les deux font partie de la même chaîne, mais les questions qu'elles soulèvent sont différentes : l'agrégation soulève des questions d'exhaustivité, la normalisation des questions de cohérence.
La situation change aussi lorsque la source elle-même n'est pas un système mais une feuille de calcul. Il n'y a alors pas d'export automatique, pas de journal système, pas de structure fixe, et la consignation doit être construite différemment. Ceux qui sont confrontés à cette situation trouveront des points d'appui dans une explication du source-to-report mapping lorsque la source est une feuille de calcul et dans un aperçu des traitements entre la source et le rapport spécifiquement pour les sources de type feuille de calcul. Pour ceux qui n'ont pas de budget pour un outil et doivent construire la lignée avec les moyens déjà disponibles, il existe une méthode pour créer une lignée sans logiciel spécialisé.
La consignation des traitements est souvent confondue avec un journal : une liste de qui a modifié quoi et quand. C'est une partie de l'histoire, mais pas l'ensemble. Une piste d'audit qui n'enregistre que les modifications ne dit pas pourquoi un choix a été fait ni quelle règle a été appliquée. La différence entre un journal et une véritable structure de responsabilisation est développée dans un exposé sur les raisons pour lesquelles une piste d'audit doit être plus qu'un journal.
Le Data Readiness Scan cartographie ce trajet : quelle source alimente quel point de données, quels traitements se trouvent entre les deux, qui est propriétaire de chaque étape et quelle règle de qualité s'y rattache. Ce n'est ni un rapport ni un questionnaire, mais la structure sous-jacente qui rend les deux fiables.
Dès que les traitements entre la source et le rapport sont décrits, il devient visible quelles étapes constituent un travail manuel fixe : la retranscription d'une facture, l'application d'un facteur de conversion fixe, l'agrégation de chiffres mensuels selon une règle fixe. C'est précisément le type de travail dont on peut calculer la part reprenable par l'IA, sans que la consignation de la source au rapport ne perde sa fonction. FTE TO AI calcule par tâche quelle part de celle-ci est transférable, sur la base du scan de travail qui rend cette différence visible tâche par tâche.
Le Data Readiness Scan est en cours de développement. Ceux qui souhaitent faire consigner les traitements entre la source et le rapport dès que le scan sera disponible peuvent s'inscrire sur la liste d'attente.
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.