Un arrêt américain qui rouvre la faille transatlantique
Le 29 juin 2026, la Cour suprême des États-Unis a jugé, dans l'affaire Trump v. Slaughter, que les protections garantissant l'indépendance de la Federal Trade Commission étaient inconstitutionnelles. Un détail technique en apparence, un séisme dans les faits : la FTC est l'un des organes de contrôle sur lesquels repose le Data Privacy Framework, l'accord qui autorise depuis 2023 le transfert de données personnelles entre l'Union européenne et les États-Unis. Le droit européen exige pourtant que ce contrôle soit assuré par une autorité indépendante.
Dans la foulée de cette décision, l'ONG noyb de Max Schrems a demandé à la Commission européenne de retirer sa décision d'adéquation. C'est le troisième acte d'une histoire connue des juristes du numérique : le Safe Harbor est tombé en 2015 (Schrems I), le Privacy Shield en 2020 (Schrems II). Le Data Privacy Framework avait, lui, survécu en septembre 2025 à un premier recours porté par le député français Philippe Latombe, également membre de la CNIL. Ce recours est aujourd'hui en appel devant la Cour de justice de l'Union européenne, et Microsoft a été admis à y intervenir.
Rien n'est tombé formellement : la décision d'adéquation reste en vigueur tant que la Commission ne l'abroge pas ou que la Cour de justice ne l'annule pas, ce qui peut prendre des années. Mais bâtir aujourd'hui sa gouvernance de données sensibles sur un socle aussi contesté relève, selon l'analyse de Laurence Fernando, fondatrice de l'agence rennaise Malibellule, d'un pari plutôt que d'une stratégie.
Hébergement européen : une garantie qui ne dit pas tout
L'illusion la plus répandue, écrit Laurence Fernando dans sa chronique publiée sur le Journal du Net, consiste à croire qu'un service « hébergé en Europe » est de ce fait à l'abri. Le CLOUD Act américain permet aux autorités des États-Unis de contraindre un fournisseur soumis à leur juridiction à livrer des données, quel que soit le pays où se trouvent les serveurs. Un modèle d'IA consommé via une API hébergée sur une infrastructure américaine reste dans le champ de cette extraterritorialité, même si l'éditeur du modèle est français.
L'exemple donné est celui de Mistral AI. L'éditeur français propose des déploiements self-hosted et on-premises qui constituent de véritables réponses de souveraineté. Mais le partenariat d'infrastructure noué avec Microsoft à l'été 2026 amène aussi ses modèles sur Azure et dans Copilot, c'est-à-dire, pour ces usages précis, sur une infrastructure américaine. Le bon critère n'est donc ni « modèle américain ou français », ni « ouvert ou fermé », mais : qui contrôle, de bout en bout, le modèle, l'infrastructure de calcul et les données ? Un modèle en open weights opéré sur une infrastructure européenne maîtrisée ne relève pas de la même logique qu'un modèle propriétaire appelé à distance sur un cloud tiers.
Pour les professions au secret, la confidentialité change de statut
Un système de RAG (Retrieval-Augmented Generation) permet à une IA de répondre en s'appuyant sur une base documentaire propre à l'organisation. Pour les cabinets d'avocats, de notaires, d'experts-comptables ou pour les professionnels de santé, cette base a précisément vocation à indexer ce qui est le plus sensible : dossiers clients, contrats, pièces de procédure, données patients.
Pour ces métiers, la confidentialité n'est pas un argument de confort. C'est une obligation déontologique et une exigence du RGPD. Faire transiter le cœur d'un dossier par une brique dont on ne maîtrise ni la juridiction ni la chaîne d'accès déplace un risque juridique sur une décision d'architecture technique, souvent sans que le dirigeant en ait pleinement conscience. La question centrale n'est alors plus « quel est le modèle le plus performant », mais où vivent les données à chaque étape du traitement, et qui peut y accéder en cas de réquisition étrangère.
Ce que l'AI Act ajoute à l'équation RGPD
Le règlement européen sur l'intelligence artificielle impose, à son article 55, aux fournisseurs de modèles à usage général présentant un risque systémique au sens de l'article 51, de tester, documenter et signaler sans délai les incidents graves affectant leurs systèmes. Pour une organisation utilisatrice, la conséquence opérationnelle est que la gouvernance se déplace du modèle vers ce qui l'entoure : les habilitations accordées, les systèmes qu'un agent connecté peut modifier, et la journalisation de ses actions. Un agent d'IA disposant d'un accès à un système métier doit être traité comme un compte à privilèges.
La CNIL a de son côté publié le 26 août 2026 une nouvelle version de Genmod, un outil qui explore la généalogie des modèles d'IA publiés en source ouverte : de quels modèles un système dérive, et quels modèles il a lui-même contribué à produire. L'intérêt pour un cabinet qui affine en interne un modèle open source afin de bâtir son RAG est direct : consigner l'ascendance du modèle utilisé permet d'instruire une demande d'effacement au titre de l'article 17 du RGPD, ou une demande d'accès au titre de l'article 15, sans avoir à reconstituer la chaîne après coup. La souveraineté technique et la traçabilité documentaire deviennent ainsi deux faces d'une même exigence de conformité.
Trier par sensibilité plutôt que choisir un camp
Traiter la souveraineté comme un absolu serait une erreur symétrique. Toutes les données d'un cabinet ne se valent pas. La méthode consiste à trier les données selon leur sensibilité et à adapter la protection à chaque niveau. Pour les données couvertes par le secret ou stratégiques, la souveraineté, entendue comme un modèle ouvert hébergeable soi-même sur une infrastructure européenne maîtrisée, est un prérequis. Pour les usages non sensibles, reformuler une note interne ou générer un brouillon anodin, elle redevient un critère parmi d'autres, à mettre en balance avec la performance et le coût.
Cette hybridation suppose une gouvernance claire et un minimum de pédagogie interne. Sans règle explicite, les équipes retournent toujours vers l'outil le plus simple, y compris pour des données qui ne devraient jamais y transiter.
| Architecture de déploiement | Contrôle du modèle et de l'infrastructure | Exposition au CLOUD Act | Adapté aux données couvertes par le secret professionnel |
|---|---|---|---|
| Modèle propriétaire américain via API directe | Fournisseur américain, de bout en bout | Oui | Non, sans mesure complémentaire |
| Modèle français ou européen sur cloud américain (ex. Azure, Copilot) | Éditeur européen pour le modèle, fournisseur américain pour l'infrastructure de calcul | Oui, pour ces usages précis | Non pour les données sensibles |
| Modèle open weights self-hosted sur infrastructure européenne maîtrisée | L'organisation ou son prestataire européen, de bout en bout | Non, si le prestataire est hors juridiction américaine | Oui, c'est le prérequis décrit par Laurence Fernando |
| Application française hébergée en France, appelant des modèles tiers après pseudonymisation | Application et stockage en France, requêtes finales traitées par les fournisseurs des modèles interrogés | Réduite pour les métadonnées applicatives, non nulle pour la requête elle-même | Utile pour des usages courants, insuffisant seul pour le cœur d'un dossier couvert par le secret |
Cette dernière ligne mérite un exemple concret. Des plateformes françaises comme Moon AI, éditée par Stellarr Studio SAS, hébergent l'application et le stockage chez OVHcloud, à Strasbourg et à Roubaix, et proposent un mécanisme nommé Moon Blur qui remplace les données personnelles par des jetons avant l'envoi aux modèles tiers, puis les rétablit au retour. Ce procédé étant réversible, il s'agit d'une pseudonymisation au sens de l'article 4-5 du RGPD, pas d'une anonymisation : les requêtes finissent par partir chez les fournisseurs des modèles interrogés, après pseudonymisation. Pour un usage non sensible, ce filtre réduit le risque. Pour un dossier couvert par le secret professionnel, il ne répond pas seul à la question posée par Laurence Fernando : qui peut accéder à la donnée en cas de réquisition, même pseudonymisée ?
Questions fréquentes
Le RGPD interdit-il d'utiliser des modèles d'IA américains ?
Non, le RGPD n'interdit pas en soi le recours à un fournisseur américain. Il exige que le transfert de données personnelles vers un pays tiers repose sur une base juridique solide, comme une décision d'adéquation. C'est précisément cette base qui est aujourd'hui contestée pour les États-Unis, à travers la remise en cause du Data Privacy Framework et son recours en appel devant la Cour de justice de l'Union européenne.
Un hébergement en Europe met-il à l'abri du CLOUD Act ?
Non. Le CLOUD Act s'applique à tout fournisseur soumis à la juridiction américaine, quel que soit le pays où se trouvent physiquement ses serveurs. Un modèle français consommé via une infrastructure de calcul américaine reste exposé, pour cet usage précis, à cette extraterritorialité.
Un modèle open source garantit-il automatiquement la conformité ?
Non. L'ouverture du modèle est une condition nécessaire mais pas suffisante. Elle ne devient une réponse de souveraineté que si le modèle est effectivement hébergé sur une infrastructure de calcul que l'organisation ou son prestataire maîtrise, hors de portée d'une juridiction étrangère.
Le Data Privacy Framework est-il toujours valide aujourd'hui ?
Formellement oui. La décision d'adéquation reste en vigueur tant que la Commission européenne ne l'abroge pas ou que la Cour de justice de l'Union européenne ne l'annule pas, une procédure qui peut prendre des années. Mais sa base juridique aux États-Unis, l'indépendance de la FTC, a été fragilisée par la Cour suprême américaine, et l'ONG noyb a demandé son retrait à la Commission.