IA publique en Suède ⚠️ ChatGPT & Claude bloqués

Ce que la Suède a décidé

Les services du gouvernement suédois, qui assistent le premier ministre et le cabinet, bloqueront ChatGPT et Claude sur les ordinateurs de leurs employés. Microsoft Copilot restera le seul outil d'IA approuvé dans cette administration. L'annonce, relayée par la radio publique nationale Sveriges Radio, s'appuie sur les propos de Mikael Wettercrantz, directeur de la numérisation des services du gouvernement.

Dans l'explication fournie, la sécurité de l'information est au centre du sujet. Dans un message publié sur l'intranet du personnel, le responsable indique que l'usage de services d'IA sans contrat formel peut exposer l'organisation. Il évoque aussi des situations où la sensibilité des informations saisies a posé problème, et où la façon dont les réponses ont ensuite été utilisées a aggravé le risque.

La mesure ne revient donc pas à dire que « l'IA » est interdite partout dans l'administration suédoise. Elle trace plutôt une limite : certains services sont autorisés dans un cadre précis, d'autres non. D'après les informations publiées, certains employés pourraient continuer à utiliser ChatGPT ou Claude via une plateforme d'IA interne, construite par les services du gouvernement. Le nombre de personnes concernées et les restrictions exactes ne sont pas indiqués.

Cette décision s'inscrit dans un contexte plus large au sein du secteur public suédois. L'administration fiscale et le Conseil national des soins institutionnels ont déjà pris des mesures similaires à l'encontre d'outils d'IA grand public. L'Autorité d'exécution, notamment chargée du recouvrement des dettes et de l'application de décisions judiciaires, prépare aussi sa propre décision. De son côté, un audit interne de l'Administration des transports a relevé l'usage d'une dizaine de services d'IA dans des conditions jugées trop largement appliquées et risquées.

En clair : des usages peuvent s'installer avant que les règles ne suivent. Quand plusieurs équipes testent chacune des outils différents, la visibilité se dégrade vite : quelles données sont envoyées, quels comptes sont utilisés, et comment les réponses sont réinjectées dans des documents ou des décisions. Bloquer certains services est une réaction rapide à cette perte de contrôle. Mais ça ne remplace pas une politique d'utilisation de l'IA, pensée sur la durée.

Pourquoi un outil d'IA peut exposer des informations

Le problème ne tient pas uniquement à la qualité des réponses. Il vient aussi du trajet d'une requête. Quand un agent copie un extrait de dossier dans un service en ligne, l'information quitte son environnement de travail pour être transmise à l'infrastructure du fournisseur. Ensuite, les règles de traitement varient selon le produit, le type de compte, les paramètres activés et les engagements contractuels applicables.

Un compte grand public et une offre destinée aux organisations ne sont donc pas interchangeables. Un contrat peut encadrer les usages, la conservation des données, les modalités de traitement, et les obligations du fournisseur. Il peut aussi prévoir des contrôles d'administration ou des garanties particulières. Mais le contrat, même existant, ne suffit pas à lui seul : une organisation doit vérifier ce qui est réellement couvert, comment le service est configuré, et quels risques existent avec ses propres informations.

Dans le cas suédois, le message des autorités vise l'usage de services « sans accord formel ». Une requête peut contenir beaucoup plus qu'une question générale : données personnelles, éléments d'un dossier administratif, informations commerciales ou documents internes. Même si l'utilisateur n'envoie pas un document entier, des extraits peuvent, une fois recoupés, révéler des informations sensibles. Côté terrain, le risque opérationnel est souvent banal : l'agent cherche à gagner du temps, copie un contenu « pour le résumer », et la réponse est ensuite transmise sans vérification suffisante.

Il faut aussi trier les questions que les discussions sur l'IA mélangent souvent :

• Où les données sont-elles traitées ? L'organisation doit examiner les engagements et les paramètres, plutôt que se baser sur le simple nom du service.
• Combien de temps sont-elles conservées ? Les durées et les usages possibles dépendent des conditions attachées au compte utilisé.
• Qui peut y accéder ? Le fournisseur peut être soumis à des obligations dans les pays où il opère. La portée d'une demande dépend du cadre juridique et des circonstances.
• Que fait-on de la réponse ? Une réponse plausible n'est pas forcément exacte, complète ou adaptée à une décision administrative.
• Qui porte la responsabilité du contrôle ? L'outil ne remplace ni les règles internes de confidentialité, ni le jugement du professionnel.

Pour une administration française, ces questions se recoupent avec le RGPD, mais ne s'y limitent pas. La conformité juridique est un socle ; la maîtrise concrète des usages passe aussi par des règles internes, des choix techniques et de la formation. La CNIL présente ses recommandations sur l'IA et les données personnelles, ce qui aide à cadrer les points à regarder.

L'erreur serait de réduire la précaution à une formule magique du type : « ne saisissez rien de sensible ». Oui, c'est utile. Mais encore faut-il que les employés sachent ce qui est considéré comme sensible, qu'ils aient une alternative approuvée, et que l'IA s'intègre réellement dans leurs habitudes sans les pousser à contourner les règles. Une politique efficace décrit des cas d'usage autorisés, des catégories de données à exclure, et une procédure en cas de doute.

Copilot autorisé : une distinction moins simple qu'elle n'y paraît

Les services du gouvernement suédois indiquent que Copilot a fait l'objet d'un examen de sécurité, et que ses paramètres ont été renforcés après cet examen. ChatGPT et Claude n'auraient pas suivi le même processus dans ce cadre. La logique, en pratique, ressemble donc à ceci : l'administration n'approuve pas un assistant « par nature » plus sûr, mais une configuration précise et un mode d'utilisation défini.

C'est important. Un produit peut proposer plusieurs versions, fonctionnalités et niveaux de contrôle. Le risque dépend alors de la configuration retenue, des connecteurs activés, des droits accordés et des données accessibles. Autrement dit : si une administration autorise un service, elle doit pouvoir dire ce qu'elle a évalué. « Copilot est approuvé » est une règle opérationnelle ; ce n'est pas, à elle seule, une explication suffisante de la sécurité du système.

Il existe aussi une zone grise intéressante. Selon une source, Microsoft aurait intégré des modèles Claude dans Copilot au début de 2026. Dans l'Union européenne, les modèles d'Anthropic seraient désactivés par défaut et nécessiteraient une activation explicite par les administrateurs. Les services du gouvernement suédois n'ont pas confirmé si leur instance de Copilot utilise cette option.

On ne peut pas en tirer que la décision serait incohérente, ni que Claude « doit » forcément être là. Le point, c'est surtout que le nom commercial d'un assistant ne suffit pas à décrire sa chaîne technique. Selon les paramètres, un même produit peut s'appuyer sur des modèles et des fournisseurs différents. La gouvernance doit donc porter sur l'instance réellement déployée, pas uniquement sur ce qui s'affiche à l'écran.

Pour les responsables informatiques, la bonne question n'est pas uniquement « quel assistant utilise-t-on ? », mais aussi :

1. Quels modèles et services sont activés ?
2. Les administrateurs peuvent-ils consulter et contrôler ces paramètres ?
3. Quelles données peuvent être accessibles via les connecteurs ?
4. Un changement dans le service déclenche-t-il une nouvelle évaluation ?
5. Les agents savent-ils quel outil et quel environnement ils utilisent ?

Tout ça a un coût : inventaire initial, configuration, suivi. Mais une autorisation prise sans cadre précis peut créer un faux sentiment de sécurité : « si c'est approuvé, alors tout est permis ». En pratique, une autorisation devrait préciser les tâches et les données concernées, ainsi que les limites applicables.

Ce que les organisations peuvent en retenir

La Suède n'est pas la seule à restreindre les assistants conversationnels dans le secteur public européen. En février, le Parlement européen a désactivé des fonctionnalités d'IA sur ses appareils de travail, y compris celles liées à ChatGPT, Claude et Copilot. Sa position était plus large : il jugeait ne pas pouvoir garantir la sécurité des données traitées via ces outils. La décision suédoise suit une logique différente : autoriser un environnement après examen, et bloquer deux autres.

Ces décisions ne donnent pas un modèle universel à copier. Elles illustrent plutôt deux façons de gérer l'incertitude : réduire fortement l'exposition, ou autoriser un environnement que l'organisation estime suffisamment contrôlé. Le choix dépend des données manipulées, des usages visés, et de la capacité à administrer le service. Une mairie qui traite des informations publiques n'a pas nécessairement le même profil de risque qu'un service qui gère des dossiers sociaux, des enquêtes ou des décisions sensibles.

Pour une entreprise française, une collectivité ou un organisme public, le point de départ pragmatique reste l'inventaire des usages réels. Les interdictions générales apportent une réponse immédiate, mais elles peuvent aussi pousser vers des comptes personnels ou des outils non déclarés si aucun remplacement approuvé n'est proposé. À l'inverse, un déploiement trop large sans contrôle rend difficile la détection des usages à risque. Dans les deux cas, le problème central devient l'écart entre la règle affichée et les pratiques sur le terrain.

Une démarche proportionnée peut se construire en six étapes :

1. Recenser les usages. Demandez aux équipes quels outils ils utilisent et pour quelles tâches. Un atelier court ou un questionnaire ciblé marche souvent mieux qu'une politique rédigée « pour tout le monde ».
2. Classer les informations. Définissez des catégories claires : données publiques, internes, personnelles, ou particulièrement sensibles. Appuyez-vous sur des exemples concrets du quotidien.
3. Évaluer les services et leurs configurations. Regardez les contrats, les paramètres, les fonctions activées et les accès aux données. L'outil approuvé doit correspondre à un environnement précis.
4. Autoriser des tâches, pas seulement des marques. Résumer un texte public n'expose pas au même risque que produire une réponse à partir d'un dossier nominatif. La règle doit tenir compte de ce décalage.
5. Former et fournir une option vraiment utilisable. Si l'outil autorisé est trop limité ou trop pénible à obtenir, les contournements deviennent prévisibles. Une règle réaliste doit inclure un chemin de travail acceptable.
6. Réexaminer régulièrement. Les fonctionnalités, les modèles et les contrats changent. Une évaluation valable au lancement doit être revue quand un changement touche aux données ou au traitement.

Tout cela ne supprime pas le risque. Mais ça le rend visible, et donc traitable selon sa gravité. C'est particulièrement important quand l'IA s'insère dans des outils déjà utilisés : messagerie, stockage documentaire, gestion des dossiers, logiciels métiers. Plus l'assistant peut accéder à des contenus internes, plus l'évaluation doit porter sur les permissions et les flux de données, pas seulement sur la « qualité » des réponses.

Les équipes dirigeantes doivent aussi clarifier ce qu'elles attendent de l'IA. Si l'objectif est de réduire le temps passé sur des tâches répétitives, il faut mesurer le gain réel, les erreurs introduites, et le temps de relecture. Un outil peut accélérer la rédaction tout en déplaçant la charge vers la vérification. Le bilan dépend alors du processus complet, pas du nombre de textes générés.