IA dans les collectivités : comment maîtriser le shadow AI ?

Une agente du service urbanisme prépare la réponse à un recours. Pour gagner du temps, elle copie le courrier d’un administré dans un assistant d’IA ouvert sur son téléphone, demande une reformulation, puis colle le résultat dans sa messagerie professionnelle. L’opération prend deux minutes. Personne, ni la direction des systèmes d’information (DSI) ni le délégué à la protection des données (DPO), n’en a connaissance.

Ce scénario illustratif n’a rien d’exceptionnel. Il pose une question simple : quand l’intelligence artificielle s’invite dans les services, comment garder la maîtrise de ce qui y circule ?

Pourquoi les collectivités sont particulièrement exposées

Les administrations territoriales manipulent des informations qui n’ont rien d’anodin : état civil, situation familiale, aides sociales, dossiers d’urbanisme, pièces de marchés publics. Leurs équipes sont aussi soumises à une forte charge rédactionnelle : courriers, comptes rendus, notes aux élus, réponses aux usagers. L’IA générative répond exactement à ce besoin, ce qui explique son adoption rapide.

À cela s’ajoute une contrainte propre au secteur public : la confiance. Une fuite de données ou une réponse erronée adressée à un habitant engage la crédibilité de l’institution, et pas seulement sa conformité.

Shadow AI : de quoi parle-t-on ?

Le shadow ai désigne les usages d’outils d’intelligence artificielle qui échappent à la visibilité de l’organisation. Il prend plusieurs formes : compte personnel utilisé pour un besoin professionnel, abonnement souscrit par un service sans validation, extension de navigateur installée sans contrôle, ou petit développement connecté à un modèle externe en dehors du périmètre suivi par la DSI.

Il prolonge le shadow IT, mais avec une nuance de taille. Un logiciel non validé pose un problème d’outil. Avec l’IA, ce sont des contenus entiers, parfois nominatifs, qui quittent le système d’information pour être traités par un service tiers.

Dans une collectivité, ce phénomène est rarement un acte de défiance. Il apparaît lorsque la réponse officielle est absente, lente ou trop restrictive. Le constater permet d’éviter une erreur fréquente : traiter le sujet comme une question de discipline plutôt que d’organisation.

Cartographier avant de décider : trois niveaux de sensibilité

Avant d’écrire une politique d’usage, il faut savoir ce qui se fait réellement. Une approche pragmatique consiste à classer les usages selon la nature des informations concernées.

Niveau 1 : contenus publics ou génériques. Reformuler un texte déjà publié, proposer un plan de présentation, traduire une information destinée au site internet. Le risque est limité, sous réserve de relecture.

Niveau 2 : contenus internes non nominatifs. Notes de service, comptes rendus de réunion, éléments de préparation budgétaire. Ils appellent un outil fourni par la collectivité, avec des règles claires.

Niveau 3 : données personnelles et dossiers individuels. Courriers d’administrés, dossiers sociaux, contentieux, ressources humaines. Ils exigent un cadre explicite, validé avec le DPO, et des protections techniques avant tout traitement par un modèle.

Un questionnaire court et non punitif, adressé aux services, suffit pour démarrer : quels outils, pour quelles tâches, avec quels types de documents ? Les notes de frais, les demandes adressées au support informatique et, lorsqu’ils existent, les journaux réseau complètent utilement la photographie.

Qui décide de quoi ? Répartir les responsabilités

Un cadre d’usage échoue souvent faute de pilote identifié. Une répartition simple peut servir de base :

• Les directions métiers expriment les besoins, valident les cas d’usage et assument la relecture des productions.
• La DSI choisit et opère les outils, gère les accès et assure la traçabilité.
• Le DPO évalue les traitements de données personnelles et conseille sur les garanties à prévoir.
• La direction générale ou les élus référents arbitrent les orientations et les budgets.

Les règles de fond relèvent du RGPD : une collectivité doit pouvoir dire quelles données personnelles sont traitées, par qui, sur quelle base et avec quels sous-traitants. Un usage invisible rend cette démonstration impossible. La CNIL publie des ressources sur l’IA et la protection des données, à consulter pour construire ce cadre.

Reprendre le contrôle : à quoi ressemble une solution sécurisée ?

Une fois les usages cartographiés, la question devient opérationnelle : par quel moyen offrir aux agents un accès à l’IA qui soit simple, tracé et protégé ? Quatre fonctions permettent d’évaluer une solution.

Un point de passage unique. Tous les usages (agents, applications, services connectés) transitent par une même couche de contrôle. Les accès sont structurés, les modèles autorisés sont définis, et la collectivité ne dépend pas des réglages propres à chaque fournisseur.

L’accès à plusieurs modèles. Un outil limité à un seul modèle pousse les agents à chercher ailleurs. Proposer plusieurs modèles dans une même interface réduit cette tentation.

La protection des données avant l’envoi. Les données personnelles sont détectées et remplacées avant leur transmission au modèle. Le critère à examiner est le comportement en cas de défaillance : le message doit pouvoir être bloqué plutôt qu’envoyé sans protection. Retirer un seul nom ne suffit d’ailleurs pas toujours, car un faisceau d’indices (lieu, date, situation) peut permettre de reconnaître une personne. Aucun dispositif ne dispense la collectivité de décider quelles catégories de données peuvent être transmises : cette responsabilité reste la sienne.

La traçabilité et le pilotage. Journaliser les interactions permet de reconstituer les usages, d’analyser un incident et de disposer d’éléments en cas d’audit. Le suivi des consommations permet de piloter les budgets.

Les conditions contractuelles complètent cette grille : localisation des traitements, sous-traitants, durée de conservation, et engagement de non-réutilisation des contenus pour entraîner des modèles. Ces points doivent être vérifiés dans le contrat, et non supposés.

Enfin, aucune réponse générée ne devrait partir vers un habitant sans relecture par un agent responsable : une production d’IA peut être inexacte ou mal adaptée.

Mutualiser à l’échelle de l’agglomération

Dans une intercommunalité, les communes membres n’ont pas toutes les mêmes moyens techniques ni les mêmes compétences en protection des données. Une charte d’usage commune, des formations partagées, un point de contact pour la conformité et, éventuellement, un outil unique mis à disposition des agents réduisent cette inégalité.

Plusieurs approches existent : solutions hébergées en interne, plateformes multi-modèles, passerelles de contrôle des flux. Crosstensor, qui développe une infrastructure de gouvernance de l’IA, répond à ces critères : sa plateforme donne accès à des modèles de plusieurs fournisseurs , anonymise les données personnelles détectées avant leur envoi au modèle (le message n’est pas envoyé si l’anonymisation est indisponible) , trace et journalise les interactions D8 et applique cette protection à tous les flux, quel que soit le fournisseur . Ses conditions contractuelles prévoient que les contenus ne sont pas utilisés pour entraîner des modèles . Comme pour toute solution, une collectivité devra l’évaluer au regard de ses exigences : hébergement, contractualisation, règles de la commande publique.

Côté formation, le CNFPT propose une offre nationale destinée aux collectivités et à leurs agents pour développer les compétences et maîtriser les enjeux éthiques de l’IA.

Conclusion : organiser plutôt qu’ignorer

Le shadow AI révèle un besoin que l’organisation n’a pas encore formalisé. Pour une collectivité, la démarche la plus solide tient en quatre gestes : cartographier les usages par niveau de sensibilité, répartir les responsabilités entre métiers, DSI et DPO, équiper les agents d’outils protégés, et maintenir la relecture humaine. Les habitants y gagnent la garantie que leurs informations sont traitées avec rigueur, et les services conservent les gains de temps de l’IA.