API officielle : automatiser ne dispense pas de validation humaine

« C'est eux qui détiennent la vérité »

Une équipe technique qui branche une intégration automatique sur l'API d'un opérateur national part presque toujours du même réflexe : une fois la source « officielle » connectée, la donnée n'aura plus besoin d'être vérifiée. L'idée se défend : si un opérateur national gère le réseau électrique, il est nécessairement l'autorité de référence sur l'état de ce réseau. La conclusion qu'on en tire trop vite, en revanche, est que cette autorité s'étend à toutes les données que l'API renvoie, y compris les données administratives qui l'accompagnent.

Cette confusion n'est pas propre à l'énergie. Elle se retrouve dès qu'une équipe branche une source jugée « faisant autorité » : un registre national d'entreprises, une base cadastrale, un référentiel d'adresses postales. Dans chaque cas, l'autorité de la source porte sur un périmètre précis, et le réflexe consiste à l'étendre, sans le vérifier, à l'ensemble de ce qu'elle renvoie.

Ce réflexe n'est pas naïf, il est même logique en apparence. Automatiser une intégration a justement pour but de supprimer une saisie manuelle jugée coûteuse et sujette à erreur. Si la source qui remplace cette saisie porte le qualificatif « officielle », il paraît raisonnable de considérer le problème comme résolu. C'est précisément cette apparence de résolution complète qui pose problème : elle masque la partie du travail qui reste à faire, au lieu de la rendre visible dès la conception.

Une autorité technique n'est pas une autorité administrative

Un opérateur d'infrastructure est responsable, légalement et opérationnellement, de la fiabilité de ses données techniques. S'il se trompe sur l'état d'un point du réseau, les conséquences sont directes et mesurables pour lui. Sur ce périmètre, sa fiabilité n'est pas une hypothèse, elle est une contrainte de son propre métier.

Ce raisonnement, une fois posé clairement, se transpose facilement à n'importe quelle source jugée autoritaire dans un projet de modernisation SI ou d'intégration IA : un référentiel produit d'un fournisseur, une base de prix d'un partenaire, un système d'information d'un grand groupe auquel une filiale est rattachée. La question à poser reste la même : sur quel périmètre précis cette source engage-t-elle sa propre responsabilité, et où commence le périmètre qu'elle se contente de relayer sans le garantir.

Ce que l'API garantit, ce qu'elle ne garantit pas

Les données administratives associées, adresse, nom d'entreprise, référence d'un contrat tiers, suivent une chaîne de responsabilité totalement différente. Elles proviennent le plus souvent d'une saisie effectuée par des tiers, à des moments différents, sans processus de nettoyage a posteriori. L'opérateur les transporte, il ne les garantit pas. La confusion entre les deux périmètres, technique et administratif, est ce qui pousse une équipe à automatiser une validation qui n'a en réalité jamais existé du côté de la source.

Le signal à surveiller n'est pas la réputation générale de la source, il est la question suivante : qui, chez l'opérateur, a intérêt à corriger cette donnée précise si elle est fausse ? Sur une donnée technique, la réponse est claire, un réseau mal cartographié coûte cher à celui qui le gère. Sur une adresse administrative incohérente transmise par un tiers, personne, chez l'opérateur, n'a de raison de s'en soucier tant qu'elle ne bloque rien de son côté.

Initialiser, pas valider

Chez Leando, ce principe s'appelle initialiser, pas valider : on automatise la récupération et le pré-remplissage des données depuis une source externe, jamais leur validation finale sur les champs hors du cœur d'expertise de cette source. Le gain de temps ne vient pas de la suppression de toute vérification humaine, il vient de la suppression de la ressaisie. Une équipe qui devait auparavant chercher, recopier et vérifier chaque champ à la main n'a plus qu'à confirmer ce qui a déjà été pré-rempli. La charge de travail change de nature, elle ne disparaît pas.

Comment garder cette validation légère

La difficulté, en pratique, est de ne pas réintroduire par la petite porte la lourdeur qu'on cherchait à éliminer. La question à se poser n'est pas « faut-il valider », elle est « faut-il remplir à la main ou seulement valider ce qui est déjà rempli ».

« Est-ce qu'il n'y a pas nécessité de faire une sorte d'étape de prévalidation [...] valider les infos du prospect, est-ce qu'il y a besoin de les remplir à la main ou est-ce que le vrai besoin c'est de les valider et qu'elles soient déjà remplies ? »

Concrètement, cela signifie afficher les champs à risque déjà pré-remplis par l'automatisation, avec une action de confirmation explicite plutôt qu'un champ vide à compléter. L'utilisateur passe de « saisir » à « confirmer ou corriger », ce qui reste rapide même sur un volume important. Sur la manière de cartographier ce qui existe réellement avant de coder une intégration, les pièges classiques d'une intégration API en PME détaillent les questions à poser avant même d'écrire la première ligne de code.

Le cas où l'automatisation doit s'arrêter avant la validation

Il existe une deuxième option, moins confortable mais parfois plus honnête : ne pas automatiser du tout l'initialisation d'un champ tant que la fiabilité de la source sur ce champ précis n'a pas été mesurée. Une équipe pressée de livrer préfère souvent tout pré-remplir plutôt que d'admettre qu'un champ reste incertain. Cette impatience coûte cher plus tard : un champ pré-rempli inspire confiance par sa seule présence, même quand cette confiance n'est pas méritée. Mieux vaut un champ visiblement vide, qui appelle une vérification, qu'un champ rempli qui endort la vigilance.

Ce que ce principe exclut

Initialiser, pas valider, ne s'applique pas à l'ensemble des données renvoyées par une source externe, seulement à celles hors de son cœur d'expertise. Réintroduire une validation manuelle sur les données où la source est réellement autoritaire, la donnée technique elle-même, fait perdre le bénéfice entier de l'automatisation sans gagner de fiabilité supplémentaire. Le test à appliquer, champ par champ : si cette donnée est fausse, qui en porte la responsabilité, l'opérateur de l'API ou vous ? Si la réponse est l'opérateur, ce champ ne mérite pas de point de validation. Si la réponse est vous, il en mérite un.

Ce test s'applique aussi à l'envers : certaines équipes, échaudées par une première erreur sur un champ administratif, finissent par remettre en doute la source dans son ensemble et réintroduisent une vérification manuelle même sur les données techniques pourtant fiables. Cette réaction annule le bénéfice de l'automatisation sans améliorer la qualité de la donnée sur le périmètre qui posait réellement problème.

Des fiches de sites énergétiques fiables sur le réseau, pas sur l'administratif

Un fournisseur d'énergie ETI a automatisé la création de fiches de sites à partir de l'API d'Enedis, l'opérateur qui gère le réseau électrique français. Les données techniques, état du point de livraison, caractéristiques du réseau, se sont révélées fiables et jamais mises en cause. Les données administratives associées, adresses, noms d'entreprises, contenaient en revanche des incohérences fréquentes, héritées d'une saisie tierce jamais nettoyée. L'équipe a limité l'automatisation à l'initialisation complète des fiches, et conservé une étape de validation humaine ciblée uniquement sur les deux ou trois champs administratifs à risque, sans repasser par une saisie manuelle complète du reste. Sur la manière d'anticiper les cas qui ne suivent jamais le chemin nominal d'une intégration, cartographier les scénarios non nominaux avant qu'ils ne tuent un projet SI prolonge cette logique à l'ensemble d'un projet d'intégration.

Le point de validation ciblé a aussi changé la nature du travail des équipes administratives. Elles ne ressaisissaient plus des informations déjà disponibles ailleurs, elles confirmaient ou corrigeaient deux champs précis, avec le contexte affiché juste à côté. Le temps de traitement d'une fiche est passé de plusieurs minutes à quelques secondes, sans qu'aucune erreur de structure n'ait été constatée sur les mois suivants.

Cette semaine, listez les sources externes que votre système considère comme fiables par défaut. Pour chacune, distinguez ce qui relève réellement de son cœur d'expertise, et ce qu'elle ne fait que transporter sans garantie.