IA dans les services publics: au Data Day d’adesso, la promesse d’efficacité bute sur la gouvernance

Francfort, Data Day, même message répété dans les couloirs: l’intelligence artificielle est déjà entrée dans les usages, mais elle n’a pas reçu les clés du système. Lors de l’événement organisé par adesso et relayé par le site spécialisé energie. blog, le contraste a dominé les échanges: d’un côté, un marché saturé de discours sur les agents et l’automatisation généralisée, de l’autre, des exploitants qui demandent d’abord des garde-fous, des tests et des responsabilités clairement attribuées. Pour les entreprises de services publics, notamment les stadtwerke (régies municipales) et les gestionnaires de réseaux, l’objectif affiché est simple: intégrer l’IA dans les processus sans perdre le contrôle.

Cette prudence n’a rien d’un frein culturel. Elle vient d’une réalité opérationnelle: dans l’énergie, l’eau, les transports ou la gestion de réseaux, une erreur n’est pas un simple bug de service client. Elle peut déclencher une mauvaise décision de maintenance, une communication erronée à des usagers, voire une chaîne de décisions coûteuses. Les retours d’expérience partagés pendant la journée convergent vers une idée: l’IA apporte déjà du gain mesurable quand elle est cadrée, mais elle devient une source de risque quand elle est déployée comme une promesse technologique sans architecture, sans données fiables, et sans gouvernance.

Le débat s’inscrit aussi dans un calendrier réglementaire européen. L’AI Act de l’Union européenne, adopté en 2024 et mis en uvre progressivement, pousse les organisations à documenter les usages, à évaluer les risques et à encadrer les systèmes selon leur niveau de criticité. Même quand un cas d’usage n’entre pas dans la catégorie haut risque, la dynamique est la même: prouver la maîtrise. Dans ce contexte, l’IA au quotidien n’est pas une IA en pilotage automatique. C’est une IA instrumentée, auditée, et maintenue comme un actif industriel.

Le hype des agents face aux contraintes des stadtwerke et des gestionnaires de réseaux

La tension la plus visible au Data Day tient en deux mots: agents et réalité. Les agents, au sens des systèmes capables d’enchaîner des tâches, d’appeler des outils, de planifier et d’agir avec une certaine autonomie, occupent aujourd’hui le centre du marketing IA. La réalité, elle, se mesure en tickets d’incident, en délais de raccordement, en stocks de pièces, en conformité, et en contraintes de cybersécurité. Les opérateurs présents décrivent un terrain où l’autonomie totale reste l’exception, parce que les processus sont imbriqués dans des obligations de traçabilité et des systèmes d’information hétérogènes.

Dans les services publics, l’IA est souvent d’abord attendue sur des tâches de soutien: recherche documentaire, synthèse de dossiers, classification de demandes, assistance à la rédaction de réponses, ou extraction d’informations dans des bases internes. Ces usages modestes ont un avantage: ils permettent de démontrer un ROI sans exposer le cur opérationnel. Le bénéfice est immédiat si la base documentaire est propre et si l’outil est correctement intégré. Mais l’écart entre un assistant et un agent autonome reste considérable, parce qu’un agent doit interagir avec des systèmes de production, déclencher des actions et gérer des exceptions, ce qui impose des contrôles.

Les participants insistent sur un point: l’automatisation ne peut pas être décrétée. Elle se construit par étapes, avec des seuils de confiance explicitement définis. Une approche fréquente consiste à commencer par un mode suggestion où l’IA propose, puis un mode exécution contrôlée où l’humain valide, avant d’envisager une exécution partielle sur des périmètres limités. Ce schéma répond à une contrainte majeure: la responsabilité finale reste humaine, et doit rester attribuable. Dans un environnement où la continuité de service est une obligation, la question n’est pas seulement est-ce que ça marche?, mais est-ce que l’on peut prouver pourquoi ça a marché, et détecter quand ça ne marche plus?

Cette prudence reflète aussi une maturité: les organisations ont déjà vécu des vagues technologiques présentées comme autoportantes. Elles savent que l’IA générative peut produire des réponses convaincantes mais fausses, et que l’IA prédictive peut dériver si les données changent. Le message entendu à Francfort est net: l’agent autonome n’est pas un produit standard, c’est un système à gouverner. Dans l’énergie, la promesse d’efficacité doit passer après la maîtrise du risque opérationnel et du risque de conformité.

Gouvernance IA: rôles, validation et traçabilité avant l’automatisation

Le mot qui revient le plus souvent quand on sort des démonstrations, c’est gouvernance. La gouvernance IA ne se limite pas à un comité éthique ou à une charte. Elle recouvre des décisions concrètes: qui a le droit de déployer un modèle, qui valide un cas d’usage, qui surveille la performance, qui gère les incidents, et qui tranche quand l’IA se trompe. Dans les organisations de services publics, cette clarification est un préalable, parce que l’IA touche rapidement des données sensibles et des processus réglementés.

Un cadre de gouvernance robuste inclut, dans la pratique, un inventaire des cas d’usage, une classification des risques, des règles de gestion des données, et une politique d’outillage. Il impose aussi des exigences de traçabilité: conserver les versions de modèles, les prompts ou paramètres clés, les sources de données, et les journaux d’exécution. Sans ces éléments, un incident devient difficile à diagnostiquer, et une amélioration devient impossible à mesurer. La traçabilité n’est pas un luxe technique, c’est un outil de pilotage et un mécanisme de défense en cas de contestation.

La gouvernance se matérialise également par la séparation des responsabilités. Les équipes métiers définissent le besoin et les critères d’acceptation, les équipes data garantissent la qualité et la disponibilité des données, les équipes sécurité valident les flux et les contrôles, et les équipes juridiques encadrent les usages au regard des obligations. Ce découpage peut sembler lourd, mais il répond à une réalité: une IA utile en production est un système socio-technique, pas un simple abonnement à un service en ligne.

Le sujet devient plus sensible quand l’IA est connectée à des outils d’action: création d’ordres de travail, modification d’un planning, déclenchement d’une communication client. Dans ce cas, la gouvernance doit définir des garde-corps: plafonds d’autorité, listes d’actions autorisées, validation humaine obligatoire au-delà d’un certain seuil, et mécanismes d’arrêt. Les échanges du Data Day rappellent un principe industriel: l’automatisation ne vaut que si l’on sait la désactiver proprement et revenir à un mode manuel sans chaos.

Ce travail de gouvernance est aussi une réponse aux exigences européennes. L’AI Act pousse à formaliser des processus de gestion des risques, de documentation et de contrôle. Même en dehors des cas haut risque, l’esprit du texte incite à structurer la chaîne de responsabilité. Pour les opérateurs présents, l’enjeu est moins d’anticiper une sanction que de sécuriser l’exploitation: une IA non gouvernée transforme un gain de productivité potentiel en dette opérationnelle.

Tests, monitoring et red teaming: l’IA utile se mesure, l’IA fragile se surveille

Le Data Day met en avant un autre pivot: la culture du test. Les organisations qui tirent déjà de la valeur de l’IA ne se contentent pas d’une démonstration réussie. Elles mettent en place des batteries d’évaluation avant mise en production, puis un suivi continu. Dans le cas de l’IA générative, cela passe par des jeux de questions représentatives, des scénarios d’erreur, des tests de robustesse, et des critères de qualité explicites: exactitude, complétude, conformité, et absence de fuite de données.

Le défi, souvent sous-estimé, est que l’IA n’est pas un logiciel déterministe. Deux réponses différentes peuvent être acceptables ou inacceptables selon le contexte. Les équipes doivent donc définir des métriques adaptées: taux de réponses exploitables, taux d’hallucinations détectées, respect des consignes, temps gagné, satisfaction interne, et coût par requête. Le suivi en production devient une discipline à part entière. Dans des environnements critiques, la question n’est pas seulement la performance moyenne, mais la gestion des cas extrêmes.

Le monitoring est présenté comme un impératif: surveiller la dérive des performances, la qualité des données d’entrée, l’apparition de nouveaux types de demandes, et les signaux de comportements indésirables. Cette surveillance est d’autant plus importante que les organisations connectent l’IA à des bases internes via des mécanismes de recherche augmentée (RAG). Une base documentaire qui se dégrade, des documents obsolètes, ou des droits d’accès mal gérés peuvent produire des réponses trompeuses mais plausibles. Le problème n’est plus le modèle, mais l’écosystème.

Les pratiques de red teaming, consistant à tester volontairement les limites, les contournements et les scénarios d’abus, gagnent du terrain. Elles permettent de vérifier la résistance aux prompts malveillants, aux tentatives d’exfiltration, ou aux demandes ambiguës. Dans un contexte de services publics, ces tests ne relèvent pas seulement de la cybersécurité: ils protègent aussi la réputation et la relation usager. Une réponse erronée sur un délai de raccordement ou une procédure réglementaire peut générer un conflit et une perte de confiance.

La mesure du bénéfice est, elle aussi, un point d’insistance. Les retours d’expérience valorisent les projets qui partent d’un indicateur opérationnel: réduction du temps de traitement, baisse des appels répétés, amélioration du taux de résolution au premier contact, ou accélération de la préparation de dossiers techniques. L’IA gadget est identifiée rapidement, parce qu’elle n’a pas de métrique, pas de propriétaire, et pas de plan de maintien en condition opérationnelle. Là où l’IA devient utile, elle est traitée comme un produit interne, avec une feuille de route et des arbitrages.

Données et architecture: pourquoi la qualité des référentiels décide du résultat

Les discussions de Francfort rappellent un fait souvent relégué derrière la fascination pour les modèles: l’IA dépend d’abord des données et de l’architecture. Dans les stadtwerke et chez les gestionnaires de réseaux, les systèmes d’information sont fréquemment construits par strates, avec des ERP, des outils métiers, des bases documentaires et des historiques d’intervention. L’IA ne corrige pas cette complexité. Elle l’expose. Une réponse fiable exige des référentiels propres, des définitions partagées, et des flux maîtrisés.

Le premier écueil est la fragmentation: des informations identiques existent sous plusieurs formes, dans plusieurs applications, avec des mises à jour non synchronisées. Une IA qui interroge ces sources peut produire des contradictions. Le second écueil est la qualité: documents non versionnés, métadonnées absentes, champs mal renseignés, ou historiques incomplets. Avant même de parler de modèle, les organisations doivent décider ce qui fait foi, où se trouve la source de vérité, et comment les mises à jour sont gouvernées.

Sur le plan architectural, les choix se cristallisent autour de la localisation des données et des modèles: solutions cloud, déploiements hybrides, ou environnements plus isolés pour des données sensibles. Chaque option a des implications en sécurité, en coûts et en capacité d’évolution. Les échanges mettent en avant une approche pragmatique: commencer par des périmètres où les données sont déjà structurées, puis élargir. Cette progression évite de transformer un projet IA en chantier de refonte globale, souvent trop long pour produire de la valeur rapidement.

La question des données ne se limite pas à la technique. Elle touche aux droits d’accès, à la conformité et aux habitudes internes. Un assistant IA qui sait tout sur le papier peut devenir un risque si les permissions ne sont pas strictement alignées sur les règles existantes. Les organisations doivent donc intégrer l’IA dans leur modèle de sécurité: authentification, contrôle d’accès, journalisation, et segmentation des informations. Sans cela, l’IA devient un raccourci involontaire vers des données qui n’auraient jamais dû être accessibles dans un même espace.

Enfin, l’architecture doit permettre l’évolution. Les modèles changent vite, les fournisseurs aussi, et les coûts peuvent varier selon l’usage. Les opérateurs cherchent donc à éviter l’enfermement: interfaces standardisées, séparation entre la couche applicative et la couche modèle, et capacité à remplacer un composant sans réécrire toute la chaîne. Au Data Day, cette exigence apparaît comme une condition de souveraineté opérationnelle: l’IA doit s’insérer dans le système d’information, pas le dicter.

Le facteur humain: formation, responsabilité et limites assumées de l’IA en production

Dernier point, souvent décisif: l’IA ne remplace pas l’organisation, elle la met à l’épreuve. Les retours relayés par energie. blog insistent sur le rôle des équipes et des processus. Une IA déployée sans formation génère des usages incohérents, des attentes irréalistes et des contournements. À l’inverse, une IA accompagnée devient un outil de standardisation: mêmes sources, mêmes formulations, mêmes contrôles, avec un gain en qualité et en rapidité.

La formation ne se limite pas à savoir prompter. Elle porte sur la compréhension des limites: ce que l’outil sait faire, ce qu’il ne sait pas faire, et comment vérifier. Dans les métiers techniques, l’IA peut accélérer la préparation d’une intervention ou la synthèse d’un dossier, mais elle ne doit pas faire disparaître la validation métier. Dans les métiers de la relation usager, elle peut proposer une réponse, mais la politique de communication et la conformité restent des sujets humains.

Le facteur humain se joue aussi dans l’attribution de la responsabilité. Quand une IA produit une recommandation, qui la signe? Qui assume le risque si la recommandation est erronée? Les organisations qui avancent définissent des règles explicites: l’IA conseille, l’humain décide, sauf périmètres strictement encadrés. Cette règle n’empêche pas l’automatisation, mais elle l’organise. Elle oblige aussi à documenter les cas où l’automatisation est permise, et ceux où elle est interdite.

Un autre enseignement est la nécessité d’un retour terrain structuré. Les utilisateurs détectent les erreurs, les ambiguïtés et les angles morts. Encore faut-il que ces remontées soient captées, triées et transformées en améliorations. Cela suppose un canal de feedback, des cycles de mise à jour, et un propriétaire produit. Sans ce dispositif, l’IA se dégrade: les utilisateurs perdent confiance, reviennent à des méthodes manuelles, et le projet devient un coût sans adoption.

Au Data Day, la ligne de crête est assumée: l’IA s’impose dans le quotidien, mais le pilotage automatique reste une promesse conditionnelle. Les organisations qui veulent franchir le pas doivent accepter une discipline: gouverner, tester, surveiller, former. Dans les services publics, la question n’est pas de savoir si l’IA sera utilisée, mais à quel rythme et sous quel contrôle, parce que la continuité de service et la confiance des usagers ne se délèguent pas à un modèle.