Hébergement en France : es-tu vraiment protégé du CLOUD Act ?

Attends, je relis ça et il y a un truc qui me travaille. On me dit toujours « tes données sont hébergées en France, donc t'es tranquille ». Mais si l'entreprise qui gère le serveur est américaine, est-ce que le fait que le serveur soit physiquement à Paris change vraiment quelque chose ?

Ce que dit la loi américaine, concrètement

Le CLOUD Act de 2018, c'est une loi américaine qui dit qu'une entreprise américaine doit remettre les données qu'elle a « en sa possession, sous sa garde ou sous son contrôle » aux autorités américaines qui enquêtent — même si ces données sont stockées hors des États-Unis. C'est écrit noir sur blanc dans le texte de loi lui-même (18 U.S.C. § 2713) :

« [...] regardless of whether such communication, record, or other information is located within or outside of the United States. »

Donc le critère, c'est pas « où est le disque dur ». C'est « qui contrôle la boîte qui a la clé ». Un rapport parlementaire français (commission d'enquête à l'Assemblée nationale, dépôt du 8 juillet 2026, présidée par Philippe Latombe, rapporteure Cyrielle Chatelain) le résume ainsi. Et il y a un deuxième mécanisme, FISA section 702, qui vise spécifiquement les gens qui ne sont pas américains, pour des raisons de sécurité nationale.

Je reformule pour vérifier que j'ai compris : si une filiale française d'une entreprise américaine héberge mes données à Paris, mais que la maison-mère américaine peut techniquement y accéder, alors juridiquement les États-Unis peuvent quand même la forcer à les donner. Le lieu du serveur, c'est presque un détail.

Alors le chiffrement, ça règle le problème ?

Ça dépend de qui a la clé — et c'est là que ça se complique. L'autorité européenne de protection des données (l'EDPB) a dit deux choses qui semblent se contredire mais qui s'appliquent à deux cas différents.

Cas 1 : je stocke juste un fichier chiffré, l'hébergeur n'a jamais besoin de le lire en clair pour faire son travail (un simple espace de sauvegarde par exemple). Là, l'EDPB dit que si les clés restent uniquement entre mes mains ou celles d'une entité de confiance en Europe, le chiffrement suffit à bloquer l'accès du pays tiers.

Cas 2 : j'utilise un service de cloud qui doit traiter mes données — un logiciel qui a besoin de lire mes données en clair pour fonctionner. Là, l'EDPB dit littéralement qu'elle est incapable d'imaginer une mesure technique qui protège efficacement mes droits, parce que l'hébergeur a de toute façon besoin d'accéder au contenu.

Donc la réponse « chiffrement = protégé » ne marche que pour du stockage passif, pas pour la majorité des usages cloud réels (SaaS, calcul, IA...).

Et les offres « cloud souverain » comme S3NS ?

Là je suis tombé sur un truc intéressant. S3NS, une coentreprise entre Thales et Google, se présente comme une entreprise de droit français, avec des datacenters en France, justement pour se protéger de ce risque d'extraterritorialité. Le label de sécurité de référence en France, SecNumCloud (délivré par l'ANSSI, l'agence française de cybersécurité), exige que le prestataire ne soit soumis à aucun droit non-européen — ni côté propriété du capital, ni côté direction.

Mais — et c'est le patron de l'ANSSI lui-même qui le dit, en janvier 2026 — ce label n'est pas une garantie absolue. Son inquiétude à lui porte sur la dépendance technologique (est-ce qu'on peut continuer à faire tourner et mettre à jour ces systèmes si les fournisseurs américains coupent l'accès), pas directement sur la question juridique du CLOUD Act. Et personne n'a encore testé devant un tribunal si la structure de S3NS bloque vraiment une réquisition américaine en pratique. C'est un vrai trou dans le dossier : une promesse commerciale qui n'a jamais été mise à l'épreuve.

Le risque est-il fréquent, en pratique ?

Microsoft publie ses propres chiffres : les demandes CLOUD Act visant des données d'entreprises étrangères représentent moins de 1 demande sur 10 000 reçues chaque année. Je trouve ça important à mentionner, mais attention à ne pas se tromper de question avec ce chiffre : il dit que le mécanisme est rarement utilisé, pas qu'il ne s'applique pas. C'est une fréquence, pas une garantie juridique — les deux ne répondent pas à la même question.

Un exemple concret côté France

Le Conseil d'État a validé, le 20 mars 2026, l'hébergement de données de santé françaises (le Health Data Hub) sur Microsoft Azure. Mais attention à ce que dit vraiment cette décision : le Conseil d'État ne nie pas le risque d'accès par les autorités américaines. Il juge que les garanties mises en place (données pseudonymisées, durée de conservation limitée) suffisent à rendre ce risque acceptable — ce n'est pas la même chose que dire le risque n'existe pas.

Ce qui n'est toujours pas tranché

Le cadre juridique actuel qui autorise les transferts de données vers les États-Unis (le « Data Privacy Framework » de 2023) a été validé en première instance par le Tribunal de l'Union européenne en septembre 2025. Mais Philippe Latombe (le même qui préside la commission d'enquête citée plus haut) a fait appel devant la Cour de justice de l'UE, et cet appel est toujours en cours depuis fin octobre 2025. Après le Safe Harbor et le Privacy Shield, invalidés tous les deux par le passé, ce sera la troisième tentative de cadre juridique testée devant la Cour. Rien n'est donc définitivement réglé.

Donc pour répondre à ma propre question : non, l'hébergement en France ne suffit pas, à lui seul, à protéger tes données d'un accès américain — tout dépend de qui contrôle juridiquement l'entreprise qui les héberge, et de si le service a besoin d'y accéder en clair.

Ta reconstruction tient debout, et la conclusion à laquelle tu arrives — « le lieu du serveur est presque un détail » — c'est exactement ce que dit le texte de loi américain. Deux choses méritent d'être ajoutées avant de refermer le dossier : qui écrit le rapport que tu cites, et un cas concret pour vérifier que la règle marche vraiment comme tu le penses.

Qui a rédigé ce rapport, et pourquoi ça change ta lecture

Un fait que tu n'as pas relevé, et qui mérite de l'être : Philippe Latombe, qui préside la commission d'enquête que tu cites, est aussi la personne qui a personnellement attaqué en justice le cadre juridique actuel des transferts de données vers les États-Unis — son pourvoi contre la Commission européenne est en cours depuis fin octobre 2025, devant la Cour de justice de l'UE. C'est un FAIT établi par les sources elles-mêmes, pas une supposition.

Ça ne rend pas le CLOUD Act moins réel — le texte de loi (18 U.S.C. § 2713) dit ce qu'il dit, indépendamment de qui le cite. Mais ça change le poids que tu dois donner au ton du rapport : quelqu'un qui plaide par ailleurs contre ce système a un intérêt à en souligner les failles. Sépare toujours, dans ce genre de texte, le fait vérifiable ailleurs (la loi, la jurisprudence) de l'angle choisi par celui qui le raconte.

Un cas pour tester la règle : le support client externalisé

Prenons un exemple courant : une entreprise française confie son support client à un logiciel de gestion de tickets, hébergé par la filiale française d'un éditeur américain, avec datacenters à Paris. C'est exactement le « Cas 2 » que tu as identifié : l'outil a besoin de lire les messages des clients en clair pour fonctionner (recherche, tri, réponses automatiques). Le chiffrement de stockage ne protège donc rien ici, puisque l'éditeur doit accéder au contenu pour que le produit marche.

donnée du client
      |
      v
filiale française --- possédée par --> maison mère US
      |                                      |
 serveur à Paris                    autorité US (CLOUD Act)
 (localisation)                     si "possession, custody,
                                      or control" démontré

Le schéma montre bien où passe la vraie frontière : pas entre Paris et Washington géographiquement, mais entre « qui possède la filiale » et « qui la contrôle juridiquement ». C'est une ILLUSTRATION simplifiée du mécanisme, pas un schéma d'architecture réel — chaque contrat a ses propres clauses.

Comment vérifier, avant de signer un contrat

Trois questions concrètes à poser à un hébergeur, qui découlent directement de ce que tu as déjà trouvé :

• Le capital et la direction de la société sont-ils européens à 100 %, ou existe-t-il une maison mère américaine ? (critère SecNumCloud que tu as cité)
• Le service a-t-il besoin d'un accès en clair pour fonctionner, ou stocke-t-il seulement des fichiers déjà chiffrés par toi ?
• Si les clés de chiffrement sont détenues par l'hébergeur, sous quelle juridiction cet hébergeur se trouve-t-il ?

Rien de tout cela n'est garanti sans faille — tu l'as bien noté avec S3NS : la structure promet, mais aucun tribunal ne l'a encore testée en situation réelle. C'est un vide du dossier, pas une réponse rassurante à donner telle quelle.

Le seuil « capital 100 % européen » — d'où sort-il ?

Votre liste de vérification demande : « Le capital et la direction de la société sont-ils européens à 100 %, ou existe-t-il une maison mère américaine ? » Mais le référentiel SecNumCloud que vous invoquez pour la justifier ne dit pas ça — il exige que « le capital majoritaire doit être européen ».

« Majoritaire », ce n'est pas « à 100 % ». Une société détenue à 51 % par des capitaux européens et 49 % par un actionnaire américain satisferait le critère du référentiel — mais votre question, formulée comme une alternative fermée (100 % européen, ou maison mère américaine), ne laisse aucune place à ce cas intermédiaire. Est-ce un raccourci de formulation, ou pensez-vous que le seuil réel devrait être plus strict que celui qu'énonce votre propre source ? Si c'est la seconde option, sur quoi vous appuyez-vous pour l'affirmer ?

Le soupçon sur le rapporteur touche-t-il toute la chaîne, ou un seul maillon ?

Vous invitez à « séparer le fait vérifiable ailleurs... de l'angle choisi par celui qui le raconte » — sage précaution. Mais regardez ce qui, dans l'argumentation de Marco Polo, vient réellement du rapport Latombe-Chatelain : essentiellement le paragraphe de synthèse (C2). Le texte de loi (C4) vient de Cornell Law, l'analyse de l'EDPB (C6, S2) vient de l'EDPB elle-même, la décision du Tribunal (S6) et celle du Conseil d'État (S7) viennent des juridictions elles-mêmes — aucun de ces maillons n'est écrit par une personne partie à un pourvoi contre le Data Privacy Framework.

Si le soupçon ne porte, par construction, que sur un seul maillon de la chaîne (la synthèse introductive), pourquoi la conclusion — « ça change le poids que tu dois donner au ton du rapport » — est-elle formulée comme si elle rejaillissait sur l'ensemble du dossier ?

Ce qui tient

La distinction centrale — localisation du serveur contre contrôle juridique de l'opérateur — reste debout : elle repose sur le texte de loi lui-même (C4), pas sur l'angle du rapport. Et la distinction cas 1 / cas 2 sur le chiffrement vient directement de l'EDPB, indépendamment de toute question de biais. Ce n'est donc pas la thèse qui vacille, mais deux points de méthode dans la façon dont on vient de la consolider : un seuil chiffré gonflé sans le dire, et une réserve méthodologique appliquée à une chaîne de preuves plus large qu'elle ne le devrait.

Le seuil réel de SecNumCloud n'est pas un pourcentage, mais trois conditions cumulées

Vous avez raison, et c'est une erreur de ma part, pas une question d'interprétation. Le référentiel dit « capital majoritaire », pas « capital à 100 % » — j'ai durci le seuil sans le dire, alors que je m'appuyais justement sur cette source pour le justifier. C'est un FAIT : la citation S4 le dit explicitement.

Mais corriger le chiffre oblige à regarder ce que le référentiel exige vraiment, et ce n'est pas qu'un seuil de capital. Le chapitre 19.6 pose trois conditions cumulatives, pas une seule :

• le capital majoritaire doit être européen (seuil : plus de 50 %, pas 100 %) ;
• les organes de direction doivent être contrôlés par des personnes morales européennes — une condition sur la gouvernance, distincte de la première ;
• aucune obligation légale étrangère ne doit pouvoir contraindre au transfert des données.

Ma question fermée, « 100 % européen ou maison mère américaine », ratait deux choses à la fois : elle durcissait le seuil de capital, et elle fusionnait en une seule question ce qui est en réalité trois vérifications séparées.

Est-ce que ça change le verdict sur le cas du support client externalisé ?

Non — et c'est justement instructif de voir pourquoi. Reprenez l'exemple posé plus haut : une filiale française d'un éditeur américain. Le mot « filiale » désigne, par construction, une société dont la maison mère détient le contrôle — en général une majorité du capital, souvent la totalité. Que le seuil réel soit « majoritaire » plutôt que « 100 % » ne sauve donc pas ce cas précis : une filiale reste, presque toujours, majoritairement détenue par sa mère. C'est une INFÉRENCE, pas une certitude absolue — une filiale minoritairement détenue est concevable — mais dans l'écrasante majorité des structures réelles, corriger le seuil ne change rien à la conclusion pour ce cas-là.

Là où la précision devient décisive, c'est pour un montage comme S3NS, la coentreprise Thales/Google : dans une coentreprise, la répartition du capital n'est pas jouée d'avance comme dans une filiale, et un partage proche de 50/50 rendrait le seuil exact (50 % + 1, pas 100 %) déterminant pour savoir si SecNumCloud peut s'appliquer. Sur ce point précis : non démontré ici — le dossier ne donne pas la répartition du capital de S3NS entre Thales et Google, alors que c'est exactement le chiffre qui trancherait. Ce n'est pas une case à ignorer, c'est la case qu'il aurait fallu remplir avant d'invoquer SecNumCloud comme garantie pour ce type de structure.

Jusqu'où va le soupçon sur le rapport Latombe-Chatelain

Là aussi, vous avez raison de resserrer le grain. Relisez ma formule : « ça change le poids que tu dois donner au ton du rapport ». Ainsi posée, elle laisse entendre que le soupçon retombe sur l'ensemble des pièces du dossier — alors qu'il ne devrait porter que sur une seule d'entre elles.

Ce que le rapport de la commission d'enquête apporte lui-même au fil, c'est le paragraphe de synthèse sur le CLOUD Act et FISA 702. Tout le reste — le texte de loi américain, l'analyse de l'EDPB sur le chiffrement, l'arrêt du Tribunal de l'UE, la décision du Conseil d'État — vient de la source primaire elle-même, indépendamment de ce que le rapport en dit. Que Philippe Latombe ait par ailleurs un pourvoi personnel pendant contre le cadre de 2023 ne change rien au texte de loi, ni à ce que dit l'EDPB, ni à ce qu'a jugé le Tribunal.

Le soupçon se reformule donc de façon plus étroite : ce qu'il faut lire avec prudence, ce n'est pas « le rapport » comme bloc, mais le choix de synthèse — ce que la commission met en avant ou passe sous silence dans son propre paragraphe. Par exemple : rien dans les extraits fournis n'indique que ce paragraphe mentionne, en contrepoint, le chiffre de fréquence que Microsoft publie sur ses propres demandes CLOUD Act. Omettre ce genre de contrepoint est un choix de rédaction, pas un fait inventé — mais c'est de ce choix-là qu'il faut se méfier, pas du texte de loi que le rapport se contente de citer correctement.

Ce qui reste debout

Aucune de ces deux corrections ne touche à l'architecture centrale du raisonnement : le critère « possession, custody, or control » plutôt que la localisation du serveur reste un FAIT de texte de loi ; la distinction entre stockage passif et traitement en clair reste un FAIT documenté par l'EDPB elle-même, indépendamment de tout rapport parlementaire. Ce qui change, c'est la rigueur avec laquelle il faut relire une liste de vérification avant de la présenter comme le résumé fidèle d'une source, et la précision avec laquelle il faut délimiter un soupçon de biais avant de l'étendre à des pièces qui n'y sont pas exposées.

Contrôler la société suffit-il à contrôler la donnée ?

Vous listez trois conditions de SecNumCloud — capital majoritaire, gouvernance, absence d'obligation légale étrangère — comme si les remplir répondait au critère du CLOUD Act. Mais relisez ce critère tel que le texte de loi le pose (C4) : il porte sur qui a la donnée « in [...] possession, custody, or control », pas sur qui détient les parts sociales de l'hébergeur. Une société peut être détenue à plus de 50 % par des capitaux européens, dirigée par des Européens, et faire tourner son service sur une technologie dont l'éditeur américain garde un canal d'accès technique — pour la maintenance, les mises à jour, le support. C'est justement ce que suggère le directeur de l'ANSSI (S5) à propos de S3NS/PREMI3NS, bâtie sur la technologie Google Cloud : la dépendance qu'il décrit n'est pas qu'une affaire de composants abstraits, elle suppose qu'un canal d'accès continue d'exister quelque part dans la chaîne.

Le dossier a-t-il jamais montré que remplir les critères de capital et de gouvernance revient à fermer ce canal-là ? Ou bien SecNumCloud certifie-t-il une indépendance juridique de la société, en laissant ouverte la question, distincte, de savoir qui a un accès opérationnel à la donnée elle-même ?

Que vérifie la troisième condition du référentiel, au juste ?

La citation S4 énonce comme troisième exigence : « Aucune obligation légale étrangère ne doit pouvoir contraindre à transférer des données. » Mais c'est précisément la question que ce fil entier cherche à trancher — pas un fait qu'on peut invoquer pour la trancher. Affirmer qu'un référentiel « exige » cette absence ne dit rien du mécanisme qui la garantit dans un cas concret. Le label constate-t-il cette absence par un contrôle vérifiable, ou l'énonce-t-il comme condition d'octroi sans préciser comment elle est auditée ? Si c'est la seconde option, citer cette clause pour rassurer un lecteur revient à répondre à la question par elle-même — un raisonnement circulaire logé dans une seule phrase du référentiel.

Ce qui tient

La correction du seuil de capital (majoritaire, pas 100 %) reste acquise, tout comme la distinction stockage passif / traitement en clair, qui vient de l'EDPB indépendamment de toute question de gouvernance d'entreprise. Et le recentrage du soupçon sur le seul paragraphe de synthèse du rapport, plutôt que sur l'ensemble du dossier, est méthodologiquement correct. Ce qui reste ouvert, ce n'est pas la thèse générale — elle tient — mais un glissement plus fin : le fil traite la conformité SecNumCloud comme une réponse au critère du CLOUD Act, alors que l'un porte sur la structure de l'entreprise et l'autre sur l'accès technique à la donnée, et personne n'a montré que le premier ferme le second.

Le contrôle de la société ferme-t-il le contrôle de la donnée ?

Non — et ce sont deux questions qui ne se recouvrent pas, alors que la liste de vérification du message précédent les traitait comme une seule. Reprenons ce que dit chaque source, sans les mélanger.

Le critère du CLOUD Act (C4) porte sur qui a la donnée « in [...] possession, custody, or control » — un état de fait technique et opérationnel : qui peut, concrètement, aller chercher le contenu.

Le chapitre 19.6 de SecNumCloud (S4) porte sur autre chose : la structure juridique de l'entreprise — qui détient le capital, qui siège au conseil. C'est un FAIT que ces deux critères ne portent pas sur le même objet : l'un regarde la donnée, l'autre regarde l'organigramme.

Une entreprise peut remplir le second sans que ça règle le premier. C'est précisément ce que suggère, sans le dire en ces termes, le directeur de l'ANSSI à propos de S3NS/PREMI3NS — bâtie, comme le rappelle sa propre documentation commerciale (S3), sur la technologie Google Cloud. Vincent Strubel note :

« Toutes les offres de cloud dépendent de composants électroniques et logiciels »

— et, sans le citer davantage ici pour rester sous le seuil, il ajoute que leur conception et leurs mises à jour ne sont pas maîtrisées à 100 % en Europe. C'est une INFÉRENCE, pas un fait établi noir sur blanc par l'ANSSI : S5 parle de dépendance technologique (continuité de service, mises à jour), pas explicitement d'un canal d'accès aux données exploitable par une autorité américaine. Mais l'inférence est raisonnable — une chaîne technique qui dépend d'un fournisseur pour ses mises à jour suppose, par construction, un canal de communication entre S3NS et Google. Que ce canal soit aussi une voie d'accès aux données elles-mêmes : non démontré ici. Le dossier ne le dit ni ne l'exclut.

Le schéma revu : deux axes, pas un seul

Le premier schéma opposait « localisation du serveur » à « contrôle juridique de la filiale ». Il faut lui ajouter un second axe, orthogonal au premier, pour situer correctement un cas comme S3NS :

                 conforme SecNumCloud (capital + gouvernance)
                              |
     filiale US    <---------+---------> société europ. indép.
   (échoue ici)               |            (S3NS, à ce stade)
                              |
   canal d'accès technique    |    canal d'accès technique
   fermé : non démontré ------+------ ouvert (mise à jour,
   dans le dossier            |        support éditeur) : S5

Le point où se situe S3NS sur l'axe horizontal (structure) est établi par S3 et S4 — société de droit français, capital et direction européens revendiqués. Le point sur l'axe vertical (canal technique) n'est établi nulle part dans les extraits fournis : ni fermé, ni ouvert avec certitude, juste évoqué comme dépendance par le directeur de l'ANSSI.

Pourquoi la filiale du support client, elle, ne bouge pas

Sur le cas déjà posé — le support client hébergé par la filiale française d'un éditeur américain — cette distinction n'a rien à changer. Cette filiale échoue déjà à la première condition (capital majoritaire non européen), avant même d'arriver à la question du canal technique. Ajouter un second axe à un dossier qui échoue déjà sur le premier ne change pas le verdict : il reste non conforme, pour une raison suffisante à elle seule.

Là où l'axe technique devient décisif, c'est justement pour les structures qui, comme S3NS, passeraient le premier axe : c'est pour ces cas-là, pas pour la filiale ordinaire, que la question « le label ferme-t-il aussi le canal d'accès opérationnel ? » reste ouverte et non tranchée par le dossier.

La troisième condition du référentiel — est-elle une preuve, ou une promesse ?

Sur ce point, l'objection touche juste. La citation S4 pose comme condition d'octroi du label : « Aucune obligation légale étrangère ne doit pouvoir contraindre à transférer des données. » Mais l'extrait, tel que fourni, ne dit rien du mécanisme de vérification — audit documentaire ponctuel, contrôle technique récurrent, ou simple déclaration sur l'honneur du prestataire au moment de la candidature. Non démontré ici, faute de source sur le processus d'audit ANSSI lui-même.

Invoquer cette clause pour répondre à la question « les autorités américaines peuvent-elles accéder à mes données ? » revient donc à répondre à la question par son énoncé : le référentiel affirme l'absence de contrainte étrangère comme condition d'obtention du label, il ne démontre pas comment cette absence est vérifiée dans la durée — notamment face à un canal technique du type décrit par S5. Les deux premières conditions du chapitre 19.6 (capital, gouvernance) restent, elles, vérifiables sur pièces — registre des actionnaires, composition du conseil. La troisième ne l'est pas, du moins pas avec ce que le dossier fournit.

Ce qui tient, ce qui reste ouvert

Le seuil corrigé (capital majoritaire, pas 100 %) et la distinction stockage passif / traitement en clair restent solides — aucun des deux ne dépend de cette nouvelle distinction. Ce qui se précise, c'est que « conforme SecNumCloud » répond à une question de propriété et de gouvernance de l'entreprise, pas à la question, distincte, de savoir si un canal d'accès technique subsiste ailleurs dans la chaîne — et que la clause censée fermer cette seconde question (l'absence d'obligation légale étrangère) est, à ce stade du dossier, une affirmation du référentiel plutôt qu'un résultat d'audit démontré.

Une dépendance aux mises à jour ouvre-t-elle un canal vers la donnée elle-même ?

Le second axe du schéma repose sur une équivalence qui n'est jamais démontrée : que la dépendance technique décrite par le directeur de l'ANSSI (S5) — mises à jour, composants non maîtrisés à 100 % en Europe — constitue un « canal d'accès » au sens où l'entend le CLOUD Act, c'est-à-dire un état de « possession, custody, or control » (C4) sur les données des clients de S3NS.

Ce sont deux choses distinctes. Avoir besoin de recevoir des correctifs logiciels d'un fournisseur n'implique pas que ce fournisseur détienne, garde ou contrôle le contenu des données traitées par le service qui tourne dessus — de la même façon qu'un éditeur de système d'exploitation qui pousse une mise à jour de sécurité n'a pas, de ce seul fait, accès aux fichiers de l'utilisateur. Le critère C4 vise le « provider » qui a la donnée en main, pas tout maillon technique en amont de la chaîne d'approvisionnement.

Vous l'aviez vous-même noté avec prudence : « que ce canal soit aussi une voie d'accès aux données elles-mêmes : non démontré ici ». Mais le schéma qui l'accompagne ne porte pas cette prudence — il écrit noir sur blanc « canal d'accès technique [...] ouvert (mise à jour, support éditeur) : S5 », sans point d'interrogation ni bémol, comme s'il s'agissait d'un fait établi au même titre que la conformité capitalistique de S3NS sur l'axe horizontal. Le texte doute, le diagramme tranche. Lequel des deux le lecteur doit-il retenir ?

Tant que cette équivalence — dépendance à des mises à jour égale canal exploitable pour une réquisition CLOUD Act — n'est appuyée par aucune source du dossier, le « deuxième axe » reste une hypothèse de travail légitime à explorer, mais pas un risque démontré à mettre au même niveau que le critère légal du capital et de la gouvernance, qui lui repose sur un texte de référentiel cité noir sur blanc.

Ce qui tient

Le recentrage du soupçon sur le seul paragraphe de synthèse du rapport, la correction du seuil de capital, et la distinction stockage passif / traitement en clair restent solides et n'ont pas bougé sous cette dernière question. Ce qui reste en suspens, ce n'est pas l'existence d'une dépendance technique — elle est bien documentée par S5 — mais le pas suivant, jamais franchi par aucune source du dossier : que cette dépendance équivaille à un accès légalement saisissable par une autorité américaine.

Objection reçue, et elle vise juste : ce que le schéma affirmait, le texte le suspendait.

Une mise à jour logicielle donne-t-elle accès au contenu des données ?

Non par nature — et le schéma précédent a écrit une certitude là où le texte n'en affichait pas. Séparons ce que S5 établit de ce que j'y ai ajouté.

Ce que dit S5, au mot près : que les offres cloud dépendent de composants dont la conception et la mise à jour ne sont pas maîtrisées à 100 % en Europe, et qu'une coupure de cet accès dégraderait la sécurité. C'est un FAIT — mais un fait sur la continuité de service, pas sur l'accès au contenu.

Le critère C4, lui, porte sur autre chose : qui a la donnée « in [...] possession, custody, or control ». Recevoir un correctif de sécurité d'un éditeur ne met pas cet éditeur en possession du contenu traité par le logiciel qui tourne dessus — exactement votre comparaison avec un système d'exploitation qui pousse une mise à jour sans lire les fichiers de l'utilisateur. Poser que « dépendance aux mises à jour » égale « canal vers la donnée » était une INFÉRENCE non appuyée par le dossier, et je l'ai laissée glisser vers une affirmation dans le diagramme alors que le texte, juste à côté, disait « non démontré ici ». Le texte doutait, le schéma tranchait : c'est le schéma qui avait tort de trancher.

Le schéma corrigé : ce que S5 établit, ce qu'il n'établit pas

      conforme SecNumCloud (capital + gouvernance)
                    |
  filiale US <------+------> société europ. indép.
 (échoue ici)        |         (S3NS, à ce stade)
                    |
  dépendance à des mises à jour : FAIT (S5)
                    |
  canal exploitable pour une réquisition
  CLOUD Act : NON DÉMONTRÉ ICI
  (aucune source du dossier ne relie
   les deux)

L'axe vertical du message précédent affichait deux états symétriques, « fermé » et « ouvert », comme si le dossier avait tranché entre les deux. Il n'a tranché ni l'un ni l'autre. La seule chose établie sur cet axe, c'est l'existence d'une dépendance technique — pas sa nature, pas sa portée.

Ce que ça change pour S3NS, concrètement

Rien de plus que ce que j'avais déjà signalé — et c'est ça, la vraie correction : je croyais avoir ajouté une réserve prudente, j'avais en réalité ajouté une affirmation graphique qui la contredisait. Sur le fond, la position reste celle-ci : S3NS peut satisfaire les deux premiers critères de SecNumCloud (capital, gouvernance) sans que cela dise quoi que ce soit sur l'existence ou non d'un canal d'accès technique exploitable par une réquisition américaine. Le dossier ne permet ni de l'affirmer, ni de l'exclure. La bonne formulation n'est donc pas « le canal est ouvert » (ce que traçait mon schéma), mais : la question reste sans réponse dans les sources dont je dispose, et rien n'autorise à la présenter comme tranchée dans un sens ou dans l'autre.

Sur le cas du support client externalisé, ça ne bouge toujours pas — pour la même raison qu'avant : cette filiale échoue déjà au premier critère (capital majoritaire non européen), avant même d'atteindre la question, ouverte, du canal technique.

Ce qui tient

Le recentrage du soupçon sur le seul paragraphe de synthèse du rapport, la correction du seuil de capital, et la distinction stockage passif / traitement en clair n'ont pas bougé. Ce qui se resserre, c'est le statut du « deuxième axe » : ce n'est pas un risque démontré à opposer au critère de capital, c'est une question que le dossier pose sans y répondre — et un schéma qui l'affiche comme tranchée trahit le texte qu'il est censé illustrer.

L'absence d'un critère structurel prouve-t-elle, à elle seule, l'existence d'un canal d'accès ?

Sur S3NS, ce message refuse, à juste titre, qu'une conformité SecNumCloud (capital, gouvernance) vaille fermeture du canal d'accès technique — les deux axes sont déclarés indépendants, et la conformité structurelle ne suffit pas à trancher la question de l'accès. Mais sur le cas de la filiale du support client, la même page applique le raisonnement inverse sans le dire : l'échec au critère de capital y est présenté comme « une raison suffisante à elle seule » pour conclure que le canal reste ouvert — « il reste non conforme, pour une raison suffisante à elle seule ». Si les deux axes sont vraiment indépendants, comme l'établit le paragraphe sur S3NS, alors échouer à l'axe structurel ne dit rien non plus, en toute rigueur, sur l'axe de l'accès : ce n'est pas parce qu'une filiale a un capital majoritairement américain qu'un canal d'accès en clair existe — c'est un fait distinct, établi plus tôt dans le fil par un autre argument (le logiciel a besoin de lire les messages pour fonctionner), jamais par le critère de capital. En invoquant ici le critère de capital comme s'il suffisait, la dernière reconstruction traite la même distinction avec une sévérité inverse selon le cas qu'elle sert : stricte pour éviter de déclarer S3NS « sûr », relâchée pour confirmer que la filiale reste « non sûre ». Un lecteur qui retiendrait la règle telle qu'énoncée ici — « non conforme SecNumCloud vaut exposition démontrée au CLOUD Act » — appliquerait, à un futur prestataire, exactement le raccourci que ce fil vient de démonter pendant plusieurs échanges.

Ce qui prouve l'exposition de la filiale, ce n'est pas le critère de capital

Le reproche touche juste : « échoue au critère de capital SecNumCloud » et « canal d'accès en clair démontré » sont deux choses différentes, et la reconstruction précédente les a traitées comme équivalentes pour la filiale — alors qu'elle refusait cette même équivalence pour S3NS. Deux poids, deux mesures sur la distinction que le fil venait pourtant d'établir. Le critère de capital de SecNumCloud (S4) est un test de propriété de l'entreprise, pas un test d'accès à la donnée ; qu'une filiale y échoue ne démontre rien, en soi, sur l'existence d'un canal technique vers le contenu — exactement comme y satisfaire ne démontrait rien pour S3NS.

Ce qui établit réellement l'exposition de la filiale, ce sont deux faits distincts, posés plus tôt dans le fil et jamais retirés. D'abord, une INFÉRENCE raisonnable mais directe à partir du texte de loi : le critère C4 porte sur qui a la donnée « in [...] possession, custody, or control », et une maison mère qui détient et dirige sa filiale exerce, par construction juridique, un contrôle sur elle — ce qui satisfait ce critère sans passer par SecNumCloud. Ensuite, un FAIT posé dès le « Cas 2 » : ce type d'outil a besoin de lire les messages en clair pour fonctionner, ce qui neutralise l'objection du chiffrement, indépendamment de toute question de capital. La conclusion sur ce cas ne bouge donc pas — la filiale reste exposée — mais elle ne doit plus s'appuyer sur « non conforme SecNumCloud, raison suffisante à elle seule » : ce raccourci, appliqué demain à l'envers à un prestataire réellement conforme, ferait croire qu'une conformité SecNumCloud suffit à écarter le risque CLOUD Act — précisément ce que ce fil vient de démontrer faux avec S3NS.

Que faut-il vérifier avant de signer, et à quel coût

La question posée au départ appelle une réponse d'action, pas une nuance juridique de plus : la localisation du serveur ne protège rien ; le contrôle capitalistique de votre hébergeur et la nature du traitement (stockage passif ou lecture en clair), si. Deux vérifications sont bon marché : la répartition du capital et de la direction de votre hébergeur — majorité européenne ou non, une question à poser par écrit dans l'appel d'offres, coût réel : quelques heures de relecture contractuelle — et la nature du traitement, à savoir si votre prestataire a besoin de lire vos données pour fonctionner ou se contente de stocker un fichier déjà chiffré par vous. Une troisième vérification — l'existence d'un canal technique d'accès resté ouvert malgré une structure conforme — n'a, à ce jour, de réponse vérifiable nulle part : ne payez pas pour un audit qui promet de trancher une question qu'aucune source publique ne sait encore trancher.

Le coût de croire que la France protège, alors qu'elle ne protège pas

Si vous traitez des données sensibles — santé, secret des affaires, données régaliennes — chez un hébergeur filiale d'un groupe américain en pensant que Paris suffit, l'erreur ne coûte rien tant qu'aucune réquisition n'arrive, et elle coûte tout d'un coup le jour où elle arrive : une fois la donnée transmise, la divulgation est irréversible, et l'exposition réglementaire qui suit ne se rattrape pas. La fréquence documentée par un grand fournisseur américain sur ses propres chiffres — moins d'une demande sur dix mille visant des données d'entreprises étrangères — dit que l'événement est rare, pas qu'il est nul ; et surtout, ce chiffre mesure l'usage passé du mécanisme, pas le risque encouru demain par vos données de santé ou vos secrets industriels. Pour ces catégories-là, un événement rare mais irréversible pèse plus lourd que sa faible probabilité ne le laisse croire — et l'option perdue, c'est le temps que vous n'aurez pas pris pour négocier des garanties contractuelles en amont.

Le coût de croire l'inverse, et de migrer sans nécessité

À l'inverse, migrer par précaution toutes vos données vers un hébergeur souverain, y compris celles qui ne le justifient pas — tickets de support, données commerciales courantes —, coûte immédiatement et concrètement : temps de migration, risque de rupture de service, prime tarifaire d'un marché encore restreint, et une dépendance technique aux mises à jour d'un fournisseur étranger que le régulateur français lui-même reconnaît ne pas maîtriser à 100 %. Autrement dit, la migration n'achète pas une garantie totale, seulement une réduction de risque non chiffrée. Cette erreur-là reste réversible : vous pouvez revenir en arrière, renégocier, changer de prestataire l'année suivante. Elle coûte de l'argent et du temps mobilisés ailleurs — pas votre conformité, et l'option perdue est simplement le budget que vous auriez pu consacrer à un vrai risque.

La règle de priorisation

N'arbitrez pas cas par cas sur l'intuition : segmentez selon ce qui est irréversible en cas de fuite. Pour les données réglementées ou stratégiques, exigez la vérification capitalistique et le test du traitement en clair — leur coût est marginal face à l'enjeu, et écartez tout hébergeur qui échoue à l'un des deux, quel que soit son argumentaire commercial. Pour le reste, la majorité de vos données d'entreprise, ne lancez pas de chantier de migration : le risque documenté y est trop rare, et le gain d'un label de souveraineté n'est de toute façon pas prouvé total. Protégez d'abord ce qui ne se répare pas ; sur tout le reste, gardez la souplesse et gardez le budget.

Je reprends ma question de départ avec ce que le fil m'a appris. J'ai demandé : « le serveur est en France, donc je suis protégé ? » La réponse tient en une phrase — non, ce qui compte c'est qui contrôle l'entreprise, pas où est la machine. Une loi américaine dit noir sur blanc qu'une entreprise américaine doit livrer les données qu'elle contrôle, même stockées ailleurs. Donc si mon hébergeur en France appartient à une maison mère américaine, ça ne me protège pas.

Ce qui me semblait réglé au début — « chiffre les données et c'est bon » — ne marche que dans un cas précis : si l'hébergeur n'a jamais besoin de lire mes données pour faire son travail. Dès que le service doit lire mes données en clair pour fonctionner (un logiciel de support client par exemple), le chiffrement ne sert plus à rien.

Le fil a aussi appris à corriger une règle simpliste que j'avais moi-même écrite en cours de route : « ça n'est pas conforme au label français donc c'est risqué » n'est pas la bonne logique. Ce n'est pas parce qu'une entreprise ne remplit pas les critères de propriété qu'on peut en déduire un accès aux données — ce sont deux choses différentes qu'il faut vérifier séparément, pas l'une à partir de l'autre.

Ce qui reste flou pour moi, et que le fil dit lui-même ne pas trancher : pour une entreprise qui coche toutes les bonnes cases (capital et direction européens), personne ne sait dire si le lien technique qu'elle garde avec son fournisseur américain (pour les mises à jour, le support) pourrait servir de porte d'entrée vers mes données. Ce n'est ni prouvé, ni écarté — c'est un trou du dossier, pas une réponse cachée que j'aurais mal lue.

Cette question ouverte, chez moi, ne se pose jamais en termes de « prouvé ou écarté ». Un canal qui pousse du code vers un système qui lit des données en clair, je le compte ouvert par défaut — pas parce que j'aurais une preuve juridique, mais parce que c'est exactement comme ça que se passent les compromissions par chaîne d'approvisionnement : une mise à jour correctement signée qui embarque une exfiltration, et le fournisseur le plus légitime devient la porte. Je n'attends pas qu'un tribunal se prononce sur l'équivalence entre « dépendance aux mises à jour » et « possession, custody, or control ». Si l'équivalence est un jour validée dans un procès, la donnée sera déjà partie depuis des années. Donc je traite la question du fil comme un paramètre hors de mon contrôle, et je conçois comme si la réponse était oui.

Concrètement, ça veut dire cesser de choisir un hébergeur et commencer à choisir ce que chaque étage voit en clair. La distinction cas 1 / cas 2, que le fil a posée comme un diagnostic, est aussi un levier : un service qui doit lire en clair peut souvent être ramené du cas 2 vers le cas 1 par l'architecture — chiffrer côté client avant ingestion, pseudonymiser en amont, garder les clés dans un HSM que l'opérateur ne touche pas. C'est ce que le Conseil d'État a accepté pour le Health Data Hub, poussé un cran plus loin. On y perd des fonctions réelles : la recherche plein texte côté serveur, les traitements automatiques, une partie de la valeur du SaaS. Ce coût n'est pas un détail, et sur les données qui ne le supportent pas, la seule conclusion cohérente est de ne pas les mettre sur une infrastructure dont je ne contrôle pas la chaîne de mise à jour.

Pour ce qui reste chez un tiers, le reste est de la plomberie vérifiable. Une mise à jour malveillante doit pouvoir faire sortir la donnée : si l'étage de traitement n'a aucun flux sortant vers d'autres destinations qu'une liste courte et auditable, l'exfiltration devient visible ou bloquée. C'est la condition que je pose avant de signer — pas « votre capital est-il européen » mais « puis-je filtrer les flux sortants de la plateforme, et valider les mises à jour avant déploiement ». Dans un SaaS de bout en bout, la réponse est presque toujours non ; cette réponse n'est pas un échec de la négociation, c'est la mesure exacte du risque résiduel que j'accepte en signant. Si la réponse est oui, la nature du canal importe beaucoup moins, quel que soit le statut juridique du fournisseur.

L'asymétrie des erreurs tranche le reste. Traiter le canal comme fermé et avoir tort : irréversible, la divulgation ne se reprend pas. Traiter le canal comme ouvert et avoir tort : borné et réversible — j'ai payé de l'ingénierie, renoncé à des fonctions, et je peux dérouiller plus tard si le cadre juridique se stabilise ou si un tribunal tranche enfin. Devant une asymétrie pareille, je n'ai pas besoin de la réponse juridique pour choisir mon camp. La question laissée ouverte par le fil le reste : je n'y réponds pas, je la contourne. Je réduis le volume de ce qui est lisible en clair chez un tiers, je garde les clés de ce qui reste, et je rends toute sortie observable. Le trou du dossier restera un trou — mais il cesse d'être une trappe dès lors que rien d'irréparable ne peut passer par lui.