Claude dans le secteur public : le cadre avant l’usage

Les collectivités et les administrations posent souvent les mêmes questions que les entreprises sur l’IA générative : quels usages, quel gain de temps, quel risque. Mais elles n’ont pas le même point de départ. Trois différences ne sont pas des nuances de prudence, ce sont des règles de droit : un organisme public ne peut pas fonder un traitement de données sur les mêmes bases légales qu’une entreprise, il porte des obligations spécifiques au titre du règlement européen sur l’IA, et il ne peut pas acheter une prestation d’accompagnement sans passer par la commande publique.

Ces trois contraintes ne bloquent rien. Elles déterminent l’ordre dans lequel un projet doit être instruit — et un projet instruit dans le mauvais ordre se fait arrêter en fin de parcours, quand la DPO ou le service des marchés découvre le dossier.

Trois règles que le secteur privé n’a pas

La première est la base légale. Le RGPD écarte explicitement l’intérêt légitime comme base légale pour les autorités publiques agissant dans le cadre de leurs missions (article 6, paragraphe 1). Une administration doit donc rattacher l’usage de l’IA à sa mission d’intérêt public ou à une obligation légale — ce qui suppose de nommer le traitement, pas de couvrir « l’IA » en général par une charte d’usage.

La deuxième est propre au règlement européen sur l’IA (AI Act). Son annexe III classe à haut risque plusieurs domaines massivement publics : l’accès aux services publics essentiels et aux prestations sociales, l’éducation, l’emploi, la sécurité, la migration et la justice. Et son article 27 ajoute une obligation que le privé n’a pas dans le cas général : un organisme public qui déploie un système à haut risque doit réaliser une analyse d’impact sur les droits fondamentaux avant la mise en service. Le régime applicable aux systèmes à haut risque de l’annexe III a été reporté au 2 décembre 2027 par le « Digital Omnibus » de juillet 2026 — et au 2 août 2028 pour les systèmes intégrés à des produits déjà réglementés (annexe I).

La troisième est l’achat : une prestation de conseil, d’architecture ou de formation sur Claude est un marché public de services, avec un objet et des critères à définir.

• Base légale : mission d’intérêt public ou obligation légale, traitement par traitement — l’intérêt légitime n’est pas mobilisable.
• Analyse d’impact : AIPD au titre du RGPD lorsque les critères sont réunis, et analyse d’impact sur les droits fondamentaux (AI Act, article 27) pour les usages relevant de l’annexe III.
• Achat : marché public de services, dont l’objet doit décrire une prestation cadrée et livrable, pas « de l’intelligence artificielle ».

L’obligation de formation, elle, est déjà en vigueur

C’est le point le plus souvent manqué. Toutes les obligations de l’AI Act ne sont pas différées à 2026 : son article 4, qui impose aux fournisseurs comme aux déployeurs — y compris publics — de prendre des mesures pour soutenir la maîtrise de l’IA chez les personnes qui l’utilisent pour leur compte, s’applique depuis le 2 février 2025. Le « Digital Omnibus » l’a réécrit — règlement (UE) 2026/1744, en vigueur le 27 juillet 2026 — sans le supprimer : l’obligation est devenue une obligation de moyens, ce qui ne dispense pas d’un dispositif mais change ce qu’il faut démontrer.

Autrement dit, une collectivité dont les agents utilisent déjà un assistant d’IA générative est concernée aujourd’hui, indépendamment du calendrier des systèmes à haut risque. Cette obligation se satisfait par un dispositif traçable — qui a été formé, à quoi, avec quelles consignes d’usage documentées — et non par une note de service. C’est exactement le périmètre d’un dispositif de formation à Claude adossé à des cas d’usage réels du service.

Où passe la ligne sur les données

La doctrine « cloud au centre » de l’État impose que les données les plus sensibles soient hébergées sur une offre qualifiée SecNumCloud par l’ANSSI. Claude n’est à ce jour proposé dans aucune offre qualifiée SecNumCloud : les traitements portant sur ces données-là ne relèvent donc pas de cet outil, et ce constat doit être posé au début du projet, pas découvert au moment de l’homologation.

Pour tout le reste, deux leviers permettent de cadrer réellement le périmètre. D’abord la localisation : Claude est accessible via AWS Bedrock et Google Cloud Vertex AI dans des régions européennes, ce qui permet de contenir le traitement dans l’Union. Ensuite le cantonnement par processus : le protocole MCP (Model Context Protocol) permet d’ouvrir à un assistant une source précise — recueil des délibérations, procédures internes, documentation d’un service — sans lui donner accès aux applications métier qui portent les données nominatives des administrés.

À noter aussi que l’État produit ses propres outils : la DINUM développe Albert, une suite d’IA publique déjà utilisée dans des services d’accueil du public. Pour une administration, l’arbitrage n’est donc pas seulement « acheter ou ne rien faire », mais aussi « quel usage relève d’un outil mutualisé de l’État, et quel usage justifie un déploiement propre ».

Acheter une prestation Claude en tant qu’acheteur public

Le code de la commande publique prévoit un seuil de 40 000 € HT en dessous duquel un marché de services peut être passé sans publicité ni mise en concurrence préalables. Beaucoup de premiers cadrages — audit d’opportunité, architecture d’un périmètre pilote, formation d’une première équipe — tiennent sous ce seuil, ce qui permet de démarrer vite et de documenter la valeur avant d’engager un marché plus large.

Deux précautions rendent la suite plus simple. Décrire l’objet en livrables vérifiables (cartographie des usages, architecture cible, sessions de formation, dispositif de mesure) plutôt qu’en technologie : cela évite un marché attaché à un fournisseur de modèle et facilite la réversibilité. Et séparer ce qui est prestation intellectuelle de ce qui est licence logicielle, dont l’achat peut relever d’un support différent — accord-cadre existant ou centrale d’achat.

Par quoi commencer sans entrer dans le haut risque

Les premiers usages qui passent l’instruction sans difficulté ont un point commun : ils portent sur des documents internes et n’interviennent pas dans une décision individuelle relative à un administré. Cela exclut d’emblée l’instruction automatisée d’une demande de prestation sociale ou le tri de candidatures, qui relèvent de l’annexe III.

• Recherche et synthèse dans un corpus interne volumineux : délibérations, règlements, procédures, marchés passés — avec passages sourcés plutôt qu’un résumé libre.
• Comptes rendus de réunions et de séances à partir de notes ou de documents préparatoires, relus avant diffusion.
• Premiers jets de courriers et de réponses type, systématiquement validés par un agent habilité avant envoi.
• Aide à la rédaction de documents de la commande publique (cahiers des charges, rapports d’analyse) côté acheteur, la décision restant entièrement humaine.

L’ordre d’instruction qui fonctionne

Dans le secteur public, le bon premier projet est celui qui permet à la DPO, au RSSI et au service des marchés de voir sur un périmètre restreint que le dispositif tient : traitement nommé et rattaché à une mission, données cantonnées à une source identifiée, agents formés de façon traçable, contrôle humain là où une décision engage l’administration. Une fois ce socle établi et documenté, l’extension à d’autres services se discute sur des critères d’opportunité, plus sur des questions de conformité déjà tranchées.

C’est l’ordre inverse de celui que suit spontanément un projet d’IA : l’usage d’abord, la conformité ensuite. C’est aussi la raison pour laquelle tant de pilotes s’arrêtent au stade du pilote.