Par Pascal Chevallot, avec l’appui de son harnais d’IA

23 septembre 2026

Il suffit désormais de déposer un rapport, un tableur ou quelques fichiers de données, puis de demander en langage naturel un tableau de bord. Quelques minutes plus tard, les graphiques sont là. Cette facilité est utile. Elle crée aussi un risque : confondre la production instantanée d’une représentation avec la construction d’un véritable dispositif de pilotage.

Une courbe nette, une carte bien colorée ou un voyant qui passe à l’orange donnent rapidement le sentiment que la situation est maîtrisée. Mais que mesure-t-on exactement ? Qui produit la donnée ? Selon quelle définition métier ? À quelle fréquence est-elle mise à jour ? Quelle décision doit-elle éclairer ? Et que fera-t-on si elle évolue ?

Tant que ces questions restent ouvertes, le tableau de bord peut être exact, lisible et régulièrement actualisé sans rien changer au travail ni à la décision.

Certaines des idées développées dans cet article se sont précisées lors d’une formation organisée à la FNCCR, au fil d’échanges avec des DGS de syndicats mixtes et de collectivités concédantes de réseaux. La démonstration de tableaux de bord web dynamiques, générés à partir des mêmes données avec différentes versions de Claude, a naturellement conduit la discussion vers l’informatique décisionnelle et les mécanismes classiques du traitement des données. Parmi eux figurent les chaînes ETL — Extract, Transform, Load, c’est-à-dire extraire les données de leurs sources, les transformer pour les rendre cohérentes et exploitables, puis les charger dans un système destiné à leur analyse. Cette séquence a rappelé une évidence : la facilité nouvelle de produire une interface ne supprime ni le travail sur la donnée, ni la nécessité d’en organiser la gouvernance.

La génération à la volée ne produit pas la gouvernance qui lui manque

La fabrication d’un tableau de bord se banalise. Ce qui demandait auparavant la maîtrise d’un outil de visualisation, quelques développements ou l’intervention d’un prestataire peut désormais être obtenu, au moins sous forme de prototype, par une demande formulée en français courant.

Ce déplacement est important pour les collectivités. Il permet à une direction des finances d’explorer un rapport d’orientations budgétaires, à une direction des ressources humaines de représenter des évolutions d’effectifs, à un service déchets de comparer des tonnages, ou à une direction générale de rapprocher l’avancement de projets de leurs échéances.

Mais l’IA ne sait pas, à la place de la collectivité, si deux services emploient le même mot pour désigner deux réalités différentes. Elle ne décide pas si un taux d’exécution budgétaire faible traduit un retard, un calendrier normal de mandatement ou l’abandon d’une opération. Elle ne connaît pas spontanément la différence entre une donnée de gestion, une donnée comptable, une estimation et un objectif politique.

La commodisation du tableau de bord rend donc la gouvernance de la donnée plus nécessaire, pas moins. Plus il devient facile de produire une vue, plus il faut savoir sur quelles définitions, quelles responsabilités et quelles règles cette vue repose.

La gouvernance de la donnée commence par les métiers et la stratégie

La gouvernance de la donnée n’est pas un sujet réservé à la direction des systèmes d’information, au délégué à la protection des données ou à une équipe spécialisée. Elle organise la manière dont la collectivité définit, produit, documente, sécurise, partage, corrige et utilise ses données.

Elle doit partir des politiques publiques et du travail réel. Une donnée n’a pas la même portée selon qu’elle sert à suivre une obligation réglementaire, à répartir des moyens, à rendre compte à des élus, à organiser une intervention technique ou à mesurer l’accès effectif des usagers à un service.

Les métiers doivent donc définir le sens et les conditions d’usage. La direction relie l’information aux priorités de la collectivité. La politique du système d’information garantit que les sources, les applications, les droits d’accès, l’interopérabilité, la sécurité et la continuité restent cohérents. Le contrôle de gestion, les fonctions data, la DSI, le DPO et les responsables opérationnels apportent chacun une partie de la réponse ; aucun ne peut la porter seul.

Cette gouvernance de la donnée constitue une composante de la gouvernance de l’IA. Un système génératif peut accélérer l’exploration, proposer un calcul, produire du code ou composer une visualisation. Il ne répare pas une définition métier ambiguë, une donnée sans propriétaire, une rupture de série non documentée ou un indicateur déconnecté de la stratégie.

Un chiffre peut décrire l’activité sans éclairer la décision

Le rapport publié en février 2024 par la chambre régionale des comptes Pays de la Loire sur la commune de Saumur fournit un cas précis, qui ne doit pas être généralisé à toutes les collectivités. La chambre relève que les documents transmis étaient principalement des suivis budgétaires, de masse salariale et de recrutements, ainsi que des rapports d’activité annuels. Elle juge ces rapports utiles pour valoriser l’activité des services, mais indique qu’ils ne peuvent être assimilés à des outils d’aide à la décision, fonction principale d’un tableau de bord de pilotage.

La distinction est essentielle. Compter des dossiers traités, des kilomètres de voirie entretenus, des tonnes collectées ou des agents formés renseigne sur une activité. Cela n’établit ni l’effet obtenu pour les habitants, ni la cause d’un écart, ni l’arbitrage à rendre.

Une direction des ressources humaines peut ainsi suivre un taux moyen d’absentéisme sans voir qu’il recouvre des situations très différentes selon les métiers, les périodes ou les conditions de travail. Une carte des incidents sur un réseau peut localiser les événements sans montrer leur criticité, les populations concernées ou les contraintes d’intervention. Un taux d’abandon d’une démarche en ligne peut signaler une difficulté sans dire si elle vient du formulaire, de l’authentification, du public visé ou de la mesure elle-même.

Dans chacun de ces cas, le chiffre est nécessaire. Il ne parle pas seul.

Une datavisualisation doit raconter une histoire juste

Dire qu’une visualisation doit raconter une histoire ne signifie pas scénariser les données pour leur faire dire ce que l’on souhaite. Cela signifie rendre lisible un raisonnement utile : d’où part-on, que constate-t-on, à quoi compare-t-on la situation, que sait-on de ses causes, quelle incertitude subsiste et quelle décision devient possible ?

Une carte n’est utile que si son échelle, ses catégories et ses absences permettent de comprendre le territoire. Un indicateur n’est utile que si sa définition reste stable ou si ses changements sont documentés. Une courbe n’est utile que si la période de comparaison a un sens pour le métier. Une couleur d’alerte n’est utile que si quelqu’un sait ce qu’elle déclenche, et ce qu’elle ne doit surtout pas déclencher automatiquement.

La qualité d’une datavisualisation tient donc autant à ce qu’elle choisit de ne pas montrer qu’à ce qu’elle affiche. Une moyenne peut masquer une inégalité territoriale. Une évolution annuelle peut dissimuler une saisonnalité. Une carte détaillée peut exposer des données personnelles ou donner une précision trompeuse. Un classement peut transformer une convention de calcul en jugement sur un service.

Le récit utile n’est pas celui qui simplifie jusqu’à supprimer le doute. C’est celui qui permet au décideur, au métier et au lecteur de comprendre ensemble ce qui est établi, ce qui reste à vérifier et ce qui peut être décidé.

Écrire le contrat de l’indicateur avant de fabriquer la vue

DesignGouv recommande de définir le problème, les objectifs et les indicateurs de réussite dès l’exploration d’un service numérique, puis de suivre les retours des usagers et ces indicateurs pendant la mise à l’épreuve et l’amélioration continue. Le même principe vaut pour un tableau de bord : la représentation doit arriver après le problème de décision, pas le remplacer.

Avant d’ajouter un indicateur, nous proposons d’écrire son contrat d’usage. Cette fiche ne remplace ni le dialogue de gestion ni l’évaluation d’une politique publique. Elle oblige simplement à relier la donnée au métier et à la décision.

1. Intention : quelle question stratégique ou opérationnelle cherche-t-on à instruire ?
2. Définition métier : que mesure précisément l’indicateur, et quelles réalités laisse-t-il de côté ?
3. Source et qualité : qui produit la donnée, dans quel système, selon quelle règle de calcul, avec quelle fréquence et quelles limites ?
4. Représentation : quelle comparaison, quelle maille, quelle carte ou quelle visualisation rend l’information compréhensible sans la déformer ?
5. Référence : quel état initial, objectif, intervalle ou seuil appelle une vérification plutôt qu’une réaction automatique ?
6. Responsabilité et action : qui analyse l’écart, qui arbitre et quelles options sont réellement ouvertes, y compris maintenir, corriger, approfondir, suspendre ou arrêter ?
7. Réexamen : quand vérifiera-t-on l’effet de la décision et l’utilité persistante de l’indicateur ?

La sortie attendue n’est pas une couleur. C’est une décision datée, son motif, son responsable et la prochaine vérification.

Moins d’indicateurs peut produire davantage de maîtrise

Le programme beta.gouv.fr publie des indicateurs d’usage et d’impact afin d’évaluer la pertinence des services et la valeur apportée à leurs utilisateurs. Il distingue également des standards de qualité, par exemple l’accessibilité ou la sécurité. Cette séparation est utile : un service très utilisé peut rester inaccessible, fragile ou coûteux ; un bon résultat moyen peut masquer un public exclu.

Un tableau de bord de décision a besoin de plusieurs regards, mais pas d’une collecte illimitée. Activité, résultat pour l’usager, qualité du service, coût complet, conditions de travail et risques peuvent se contredire. Ces contradictions sont précisément ce que l’arbitrage doit rendre visible.

Lorsque les données sont personnelles, le principe de minimisation rappelé par la CNIL s’applique : elles doivent être adéquates, pertinentes et limitées à ce qui est nécessaire au regard de la finalité. Ajouter un détail parce qu’il est disponible augmente le coût de collecte, les risques d’accès et la charge d’interprétation. La possibilité technique de croiser ou de cartographier une information ne suffit pas à justifier son usage.

Une alerte, une courte liste d’exceptions ou une revue mensuelle d’un fichier existant peut être plus robuste qu’un nouveau tableau de bord. Certains arbitrages rares, politiques ou fortement contextuels résistent à un seuil automatique. Dans ces cas, le bon instrument prépare la discussion ; il ne prétend pas la trancher.

Commencer par retirer ce qui ne conduit nulle part

Avant de générer une nouvelle vue, on peut ouvrir le tableau de bord actuel et poser une question simple à chaque indicateur : quelle décision récente a-t-il éclairée ?

Si personne ne peut répondre, plusieurs explications sont possibles. L’indicateur est mal relié au travail, sa définition n’est pas partagée, la décision n’est attribuée à personne, la donnée n’est pas assez fiable ou l’information n’est plus utile.

Le premier geste de gouvernance n’est alors pas toujours de construire. Il peut consister à supprimer une métrique, désigner un propriétaire métier, documenter une source, réconcilier deux définitions, modifier une habilitation dans le système d’information ou organiser une revue d’écart.

La génération en langage naturel permet de créer rapidement des tableaux de bord. Elle devrait aussi nous donner la liberté de les considérer comme jetables : les éprouver, conserver ceux qui aident réellement à comprendre et à décider, puis supprimer les autres avant qu’ils ne deviennent une nouvelle couche de reporting.

Un véritable instrument d’arbitrage ne se reconnaît pas au nombre de ses graphiques ni à la vitesse avec laquelle il a été produit. Il se reconnaît à la qualité de la donnée qu’il mobilise, à l’histoire juste qu’il rend lisible et aux décisions qu’il permet d’expliquer, de revoir et, lorsque les faits l’exigent, de renverser.

Sources

• Direction interministérielle du numérique, « Data et Territoires » : recommandations pour renforcer l’exploitation des données par les collectivités.
• data.gouv.fr, « Bien documenter un jeu de données », guide sur la description, la compréhension et la réutilisation des données.
• Chambre régionale des comptes Pays de la Loire, « Commune de Saumur (Maine-et-Loire) », rapport publié le 8 février 2024.
• Direction interministérielle du numérique, DesignGouv, « Concevoir un service public numérique de qualité ».
• Direction interministérielle du numérique, beta.gouv.fr, « Indicateurs d’impact ».
• CNIL, « Minimisation ».
• Comptoir des Signaux, « Une charte IA ne tranche aucune décision à elle seule », 21 août 2026.