L’IA générative dans les collectivités : quelles précautions juridiques prendre en compte ?

Inscrit au barreau de Paris et de Montpellier, Alexandre Diehl accompagne depuis plus de 25 ans les collectivités, les entités publiques et les entreprises sur des sujets comme la conformité (RGPD, NIS2, ...), la négociation de contrats informatiques et, plus globalement, autour des usages de nouvelles technologies et des réglementations associées. 

L’IA, surtout pour ce qui concerne les LLM libres, est de plus en plus utilisée par les fonctionnaires et contractuels des collectivités. Or, l’expérience démontre que la fiabilité de ces outils laisse à désirer quant à certains cas d’usage, entraînant ainsi des erreurs et des responsabilités qui auraient pu être évitées. Pourtant, des précautions simples permettent de limiter le risque, tout en respectant la loi. Parmi ces recommandations, certaines ont été mises en exergue par un récent rapport sénatorial du 13 mars 2025 ...

Organiser les équipes de sa collectivité

Au titre de l’article L.313-1 du code général de la fonction publique (« CGFP »), l’organe délibérant d’une collectivité est en charge de la définition et de l’encadrement de chaque emploi créé au sein de ladite collectivité. L’aspect structurel des ressources humaines relève donc de sa responsabilité.

L’importance d’un CDO

Le rapport sénatorial propose en outre qu’un CDO (« Chief Data Officer ») soit nommé dans les collectivités de certaine taille. Cette fonction permettrait, aux côtés du DPO (Data Protection Officer), d'harmoniser et valider en interne les besoins, cas d’usage et fonctionnalités pour la collectivité, de participer aux choix et achats d’IA ou à la conception, réalisation et/ou supervision d’IA « maison » et de suivre et de faire respecter la réglementation relative à la data (le RGPD, le règlement du 13 juin 2024 sur l’intelligence artificielle dit « AIAct », le règlement du 13 décembre 2023 portant sur les données notamment publiques dit « Data Act », etc…) et à la sécurité de la data (NIS2, RGS, CRA, etc…). Même si une telle fonction n’est pas encore obligatoire, elle est structurellement recommandée par l’ensemble de ces réglementations.

L’obligation de sensibilisation et de formation

De manière générale, un nouvel outil / une nouvelle technologie ne peut être introduite dans un milieu professionnel que moyennant une acceptation par les utilisateurs et une formation suivie de mises à jour. Ce principe est d’autant plus important que l’enjeu est fort compte tenu de l’hétérogénéité des utilisateurs, entre les usagers citoyens, les fonctionnaires, les contractuels, les fournisseurs et les élus. Cette obligation de formation, y compris continue, est d’ailleurs très clairement visée par l’article L.422-21 du CGFP qui couvre, à notre sens, l’obligation pour la collectivité de former ses agents et fonctionnaires aux nouveaux enjeux de l’IA. C’est au DPO que revient cette mission de sensibilisation et formation du personnel pour ce qui concerne la data, ainsi que le rappelle l’article 39 du RGPD.

La nécessité d’encadrer conventionnellement les usages et utilisations de l’IA

En l’état, la jurisprudence administrative précise que les mesures d’interdiction ou de limitation de l’usage des ressources informatiques dans les collectivités doivent être justifiées soit par les nécessités du service, soit la sécurité des systèmes d’information, soit par la protection des données personnelles. Elles ne doivent pas porter atteinte de manière disproportionnée aux droits des agents.

Une limitation se fera notamment par un acte réglementaire à l’instar d’une charte informatique d’une société. Cet acte administratif réglementaire limitera l’usage des IA afin que certains usages soient interdits ou limités, de manière proportionnée et justifiée. A ce titre, l’acte réglementaire devra respecter notamment le référentiel relatif à la gestion des ressources humaines de la CNIL (délibération n° 2019-160 du 21 novembre 2019).

Choix et achat des IA

La définition des besoins, la rédaction d’un cahier des charges, la sélection des fonctionnalités envisagées puis des outils possibles, le choix entre le développement en interne et/ou l’acquisition auprès d’un tiers, la détermination des intervenants pour chaque tâche et les coûts induits, sont les étapes naturelles d’un projet IA qui doivent respecter la réglementation.

La nécessaire définition des cas d’usage et des besoins avant d’introduire une nouvelle IA

Les cas d’usage et les fonctionnalités recherchées doivent respecter un ensemble de règles qui sont propres aux collectivités publiques, et notamment :

• l’empreinte environnementale de chaque cas d’usage. Même si cette détermination n’est pas obligatoire, elle est induite par un ensemble de textes dont le code de l’énergie, et rappelée à juste titre par le rapport sénatorial ;
• le respect de la vie privée des agents, des élus et des citoyens, qui reste un principe constitutionnel ;
• les droits acquis des fonctionnaires, les accords collectifs déjà conclus et en vigueur, les règlements intérieurs des collectivités, etc…

Il est donc nécessaire que les cas d’usage envisagés soient conformes à la réglementation en vigueur, l’IA ne pouvant jamais être un prétexte pour s’écarter d’une règle en vigueur.

L’AI Act prévoit, de plus, que certaines catégories sont soit interdites (article 5), soit encadrées ou limitées (article 6). Que ces IA soient in fine achetées ou développées « en interne » :

• sont notamment interdits : la notation sociale des personnes par les collectivités, la surveillance biométrique en temps réel dans les lieux publics (sauf exceptions limitées) ou encore les systèmes d’identification biométrique à distance a posteriori non autorisés ;
• sont très encadrées car à « haut risque » : les IA dont l’utilisation peut avoir des effets significatifs sur la sécurité ou les droits fondamentaux et notamment les produits soumis à une réglementation sectorielle (machines, dispositifs médicaux, véhicules, ascenseurs, etc.) intégrant de l’IA, et les systèmes utilisés dans des domaines sensibles comme l’éducation, l’emploi, la justice, le crédit, la gestion des infrastructures critiques ou l’accès aux services publics.

 

Pour ce qui concerne plus spécifiquement les collectivités :

• l’évaluation à l'éligibilité des personnes physiques aux prestations et services d'aide sociale essentiels, y compris les services de soins de santé, ainsi que pour octroyer, réduire, révoquer ou récupérer ces prestations et services;
• l’évaluation de la solvabilité des personnes physiques ou pour établir leur note de crédit ;

 

Ces systèmes doivent respecter des exigences strictes : gestion des risques, qualité des données d’entraînement, traçabilité, documentation technique, transparence, surveillance humaine et cybersécurité.

Les fournisseurs doivent procéder à une évaluation de conformité avant mise sur le marché et maintenir un suivi post-commercialisation.

L’importance des données d’entraînement en cas de création / développement d’une IA « maison »

Pour ce qui concerne les projets de création / développement d’IA, le rapport sénatorial souligne l’importance que les collectivités communiquent et partagent leurs expériences entre elles, par exemple en créant des comités territoriaux de la donnée, un réseau des acteurs territoriaux de l’ingénierie IA, des chefs de file sur certains thèmes spécifiques ou encore, la création d’une bibliothèque nationale des projets IA développées par les collectivités. Il revient aux acteurs politiques de se positionner sur ces propositions.

Par ailleurs, tant le RGPD que l'AI Act ou les réglementations de sécurité (RGS, NIS2, etc…) imposent que les données utilisées pour créer et entrainer une IA « maison » répondent à des critères et notamment de consentement préalable des personnes concernées pour cette finalité, de minimisation d’utilisation de la donnée et de qualité de la donnée, les couches logicielles utilisées soient sécurisées et auditables, qu’un minimum de documentation soit associée à chaque étape de création de l’IA et qu’une supervision soit assurée par des agents qualifiés.

Cet ensemble d’obligations sera contrôlé par la CNIL et les autorités compétentes en cas de création d’un projet IA.

L’exigence de la rédaction et négociation d’un contrat en cas d’achat d’une IA

Si la collectivité voulait « acheter » une IA (ou plus exactement souscrire à un abonnement IA en SaaS), l’appel d’offres devrait obligatoirement tenir compte des contraintes habituelles, mais également imposer :

• une documentation technique (même pour les IA qui ne sont pas à haut risque)
• des garanties de respect de la réglementation, notamment en termes sociaux et environnementaux ;
• une description des phases d’entraînement, de maintenance et de surveillance.

 

Le contrat final devra intégrer, au minimum :

• un SLA (Service-Level Agreement) ;
• un DPA (Data Processing Agreement - annexe « données personnelles ») ;
• une garantie générale que l’IA respecte les principes de la réglementation, que les données d’entrainement respectaient bien le RGPD, que le fournisseur procède bien à la surveillance et que les ressources informatiques induites (MegaWatts notamment) respectent la charte de la collectivité ;
• une répartition parfaitement claire sur la responsabilité : qui est responsable des résultats / rendus de l’IA.

 

Ces contrats se négocient, il est donc naturel que la collectivité et le fournisseur ne tombent pas d’accord dès la première version du document. En revanche, si la collectivité ne négocie pas, elle aura toutes les responsabilités, n’aura aucune garantie et, en cas de problème, c’est le fonctionnaire ou l’élu qui en sera tenu responsable.