Cryptographie post-quantique on Arpokrat

Data Act vs CLOUD Act : qui contrôle vraiment vos données dans le cloud ?

Fri, 19 Jun 2026 00:00:00 +0000

Pendant des années, le monde a fonctionné sur une hypothèse simple : les données ont un lieu de résidence physique. Si elles se trouvaient sur un serveur à Dublin, elles relevaient du droit irlandais et européen. Cette hypothèse s’est effondrée en 2018, lorsque les États Unis ont adopté le CLOUD Act, une loi qui donne aux autorités américaines un accès aux données contrôlées par des entreprises américaines, peu importe où ces données sont physiquement stockées dans le monde. Plusieurs années plus tard, Bruxelles a répondu avec son propre dispositif de protection : le Data Act, désormais pleinement applicable, qui tente de limiter l’accès extraterritorial des autorités de pays tiers aux données détenues dans l’Union européenne.

Voici ce que prévoient réellement ces deux textes, où ils entrent en collision, et pourquoi la seule protection véritablement robuste face à ce conflit reste l’impossibilité technique d’accès.

Le CLOUD Act américain : un accès fondé sur le contrôle, pas sur la localisation

Le CLOUD Act (Clarifying Lawful Overseas Use of Data Act), adopté en mars 2018, a modifié le droit américain en y ajoutant l’article 18 U.S. Code § 2713. Ce texte impose à tout fournisseur de service de communication électronique ou de traitement informatique à distance de préserver, sauvegarder ou divulguer le contenu d’une communication ou tout enregistrement s’y rapportant, dès lors que ces données sont en sa possession, sous sa garde ou sous son contrôle, indépendamment du fait que ces données se trouvent à l’intérieur ou à l’extérieur des États Unis.

C’est précisément cette dernière clause qui change tout. Le critère retenu n’est plus la localisation physique du serveur, mais le contrôle exercé par la société mère sur ses filiales. Une entreprise américaine opérant des centres de données en Europe reste donc soumise aux réquisitions américaines, même pour des données stockées intégralement sur le sol européen.

Le Data Act européen : une barrière juridique à l’accès extraterritorial

Le Règlement (UE) 2023/2854, dit Data Act, est entré en vigueur le 11 janvier 2024 et s’applique pleinement depuis le 12 septembre 2025, certaines dispositions étant échelonnées jusqu’en 2026 et 2027. Son article 32 encadre directement la question de l’accès gouvernemental international aux données.

Le texte établit une règle claire : toute décision ou tout jugement d’une juridiction ou d’une autorité administrative d’un pays tiers exigeant d’un fournisseur de services de traitement de données qu’il transfère ou donne accès à des données non personnelles détenues dans l’Union européenne n’est reconnu et exécutoire que s’il repose sur un accord international, tel qu’un traité d’entraide judiciaire (MLA), en vigueur entre le pays demandeur et l’Union, ou entre ce pays et l’État membre concerné.

En l’absence d’un tel accord, l’article 32 prévoit une seconde voie, mais strictement encadrée : la décision étrangère ne peut être exécutée que si le système juridique du pays tiers exige que la demande soit motivée, proportionnée, et suffisamment spécifique, par exemple en établissant un lien clair avec des personnes ou des infractions précises, et si l’objection motivée du destinataire peut être soumise au contrôle d’une juridiction compétente de ce pays tiers.

Une collision juridique directe

Le problème est immédiat : le CLOUD Act exige une divulgation fondée sur le contrôle exercé par l’entreprise mère, sans condition de proportionnalité comparable à celle exigée par le droit européen. Le Data Act, à l’inverse, subordonne la reconnaissance d’une telle demande à l’existence d’un accord international ou à des garanties procédurales précises. Une entreprise américaine opérant en Europe, sommée par une autorité américaine de transmettre des données hébergées dans l’Union, se retrouve donc prise entre deux obligations légales contradictoires : se conformer au mandat américain en violant le droit de l’Union, ou respecter le Data Act en s’exposant aux conséquences d’un refus aux États Unis.

Cette tension n’est pas théorique. Elle a déjà été documentée par la Cour de justice de l’Union européenne (CJUE) dans deux décisions majeures, Schrems I (2015) et Schrems II (2020). Dans l’arrêt Schrems II, la CJUE a jugé que la surveillance américaine menée au titre de la Section 702 du FISA (Foreign Intelligence Surveillance Act) et de l’Executive Order 12333 ne respecte pas les garanties minimales exigées par le droit de l’Union au titre du principe de proportionnalité, et ne peut donc pas être considérée comme limitée à ce qui est strictement nécessaire. La Cour a également relevé l’absence de voie de recours juridictionnel effective pour les personnes concernées de l’Union, en violation de l’article 47 de la Charte des droits fondamentaux. Cette décision a invalidé le cadre du Privacy Shield, qui organisait jusque là les transferts de données entre l’UE et les États Unis.

Le risque structurel : Harvest Now, Decrypt Later

Au delà du conflit de juridictions, une menace plus insidieuse pèse sur les données hébergées dans des infrastructures soumises au droit américain : la stratégie dite Harvest Now, Decrypt Later (HNDL). Le principe consiste, pour un service de renseignement ou un acteur étatique hostile, à intercepter et stocker dès aujourd’hui des données chiffrées, dans l’attente de capacités de calcul quantique suffisantes pour les déchiffrer dans le futur.

Cette stratégie transforme toute dépendance prolongée envers une infrastructure cloud américaine en une dette de sécurité différée : ce qui est confidentiel aujourd’hui peut devenir lisible dans dix ou quinze ans, sans qu’aucune action supplémentaire ne soit nécessaire de la part de l’attaquant, seulement le temps et la patience.

Pourquoi seule l’impossibilité technique constitue une vraie garantie

L’analyse juridique converge vers un constat partagé par de nombreux experts en conformité : aussi solide soit le cadre légal du Data Act, il reste un texte que les rapports de force géopolitiques et les pressions diplomatiques peuvent contourner, retarder ou réinterpréter. La seule protection qui ne dépend d’aucune négociation future est l’impossibilité technique d’exécution.

Une architecture zero knowledge, où le prestataire ne détient ni la possession ni la garde des clés de déchiffrement, rend une réquisition matériellement inopérante. On ne peut pas être contraint de remettre ce que l’on ne possède jamais.

C’est la logique qui structure des écosystèmes comme Arpokrat :

Neutralisation juridictionnelle : l’infrastructure est hébergée en Suisse, sous le régime de la loi fédérale sur la protection des données (LPD/FADP), hors du champ d’application directe de l’extraterritorialité du CLOUD Act
Absence de garde : l’architecture zero knowledge prive le prestataire de toute capacité à remettre des clés ou des contenus qu’il ne détient jamais
Réduction de l’empreinte identitaire : en supprimant l’obligation d’inscription par numéro de téléphone ou adresse e-mail, des identifiants que la surveillance fondée sur la Section 702 du FISA peut suivre aisément, l’utilisateur cesse d’être un abonné identifiable pour devenir une clé cryptographique anonyme

La chaîne de garde ne s’arrête pas au chiffrement des messages

Un point souvent sous-estimé dans les analyses de conformité : il ne suffit pas de chiffrer le contenu d’une communication si le système d’exploitation sous jacent, qu’il s’agisse d’Android ou d’iOS, continue de capturer des métadonnées ou de la télémétrie au niveau du noyau, à destination de serveurs relevant de la juridiction américaine. La protection du secret exige une fermeture complète de la chaîne de garde, du contenu jusqu’à l’infrastructure matérielle elle même.

C’est pour cette raison que la souveraineté numérique implique aussi une réflexion sur le système d’exploitation utilisé, pas seulement sur les applications de messagerie. Des systèmes dégooglisés, où des modules comme le Bluetooth ou la géolocalisation GNSS peuvent être désactivés directement au niveau du noyau, éliminent des vecteurs d’attaque physiques qu’aucun chiffrement applicatif ne peut compenser.

La cryptographie post quantique, un horizon déjà engagé

Face à la menace que représente la stratégie HNDL, l’adoption de standards de cryptographie post quantique (PQC) devient une nécessité pour quiconque souhaite garantir la confidentialité de données sensibles sur le long terme, qu’il s’agisse de secrets d’affaires, de correspondances professionnelles ou de données de santé. Un chiffrement jugé robuste aujourd’hui selon les standards classiques ne garantit pas qu’il résistera aux capacités de calcul quantique attendues dans les quinze prochaines années.

Le conflit entre le Data Act et le CLOUD Act illustre une réalité plus large : la souveraineté numérique ne peut plus se construire uniquement sur des textes de loi, aussi solides soient ils. Elle exige une fermeture de la chaîne de garde à chaque niveau, du protocole de chiffrement jusqu’à la juridiction d’hébergement, en passant par le système d’exploitation lui même. C’est cette approche par couches, plutôt qu’une confiance reposant sur un seul cadre réglementaire, qui définit aujourd’hui une véritable souveraineté numérique par conception.

Mot de passe et Entropie : La science derrière votre sécurité

Wed, 03 Jun 2026 00:00:00 +0000

« Votre mot de passe doit contenir 8 caractères, une majuscule, une minuscule, un chiffre et un caractère spécial. »

Nous connaissons tous cette règle. Et pourtant, en cybersécurité, c’est ce que l’on appelle du “théâtre de sécurité”. Un mot de passe comme P@ssw0rd1! respecte toutes ces règles. Mais c’est un mot courant avec des substitutions prévisibles, exactement ce que les outils de cassage essaient en premier.

La véritable sécurité ne repose pas sur des règles visuelles arbitraires, mais sur une réalité mathématique implacable : l’entropie.

L’Entropie selon Claude Shannon

Pour comprendre la force d’un mot de passe, il faut se tourner vers Claude Shannon, le père de la théorie de l’information. L’entropie mesure le degré d’incertitude ou d’imprévisibilité d’une information.

Appliquée aux mots de passe, l’entropie se calcule en bits. Plus le nombre de bits est élevé, plus le mot de passe est imprévisible pour un ordinateur. La formule simplifiée de l’entropie (E) d’un mot de passe généré aléatoirement est :

E = L × log2(R)

L est la longueur du mot de passe.
R est la taille du répertoire (26 pour les minuscules, 62 avec les majuscules et chiffres, 94 avec tous les symboles imprimables). Les quatre jeux de caractères de notre générateur en donnent 91, car son jeu de symboles compte 29 caractères.

Augmenter la taille du répertoire (ajouter des symboles) augmente l’entropie, mais augmenter la longueur (ajouter des caractères) l’augmente de façon beaucoup plus drastique. Cependant, la longueur ne bat la complexité qu’à une seule condition : que le mot de passe soit généré aléatoirement.

Force brute vs Attaque par dictionnaire

Si vous utilisez des mots ou des structures prévisibles, la règle de la longueur pure s’effondre.

Les logiciels de piratage n’essaient pas toutes les combinaisons de lettres une par une (ce qu’on appelle la Force Brute). Ils utilisent de vastes listes de mots de passe réels issus de fuites de données passées, ainsi que des mots et phrases courants. C’est l’Attaque par Dictionnaire.

Si votre mot de passe est long, mais composé de mots du dictionnaire ou de substitutions prévisibles, son entropie réelle est dramatiquement plus faible que son entropie mathématique théorique.

Le tableau ci-dessous suit une seule règle : 100 milliards d’essais par seconde, le rythme que la page de notre générateur suppose pour une attaque hors ligne contre un hachage rapide. Les durées sont des moyennes (la moitié de toutes les possibilités), arrondies vers le bas avec la même formule que cette page. Le chemin le plus rapide pour chaque mot de passe est en gras :

Mot de passe	Entropie si chaque caractère était aléatoire	Force brute (moyenne)	Attaque par dictionnaire (notre estimation)
`password123`	56 bits (11 caractères, minuscules et chiffres)	7 jours	Moins d’une seconde
`S3cr3t!99`	58 bits (9 caractères, les quatre jeux)	24 jours	Moins d’une seconde
`correct horse battery staple`	133 bits (28 caractères, minuscules et espace)	Plus de 1 billion d’années	1 minute
`gL7!pQ9z#vX2`	78 bits (12 caractères, les quatre jeux)	51 mille ans	Aucun raccourci

La colonne dictionnaire est une estimation. Elle suppose que les essais de l’attaquant suivent la structure de chaque mot de passe, et que chaque mot de base fait partie des 1 000 mots les plus courants :

password123 : un mot courant et trois chiffres. Cela fait 1 000 × 1 000, soit environ un million d’essais.
S3cr3t!99 : un mot courant, avec ou sans majuscule, chaque “e” remplacé ou non par “3”, puis n’importe quel suffixe de trois caractères. Cela fait environ 7 milliards d’essais.
correct horse battery staple : quatre mots courants. La bande dessinée xkcd qui a rendu cette phrase célèbre compte 44 bits pour quatre mots tirés d’une liste de 2 048. Au même rythme, cela fait 88 secondes en moyenne, arrondies vers le bas à 1 minute.
gL7!pQ9z#vX2 : aucun mot et aucun motif, donc la force brute est le chemin le plus rapide.

Ces estimations traitent chaque mot de passe comme inconnu de l’attaquant. Tous les mots de passe de cet article sont désormais publics, donc chacun a sa place dans un dictionnaire. Un mot de passe publié est un mot de passe grillé.

L’illusion du Leetspeak et les règles de mutation

Prenons l’exemple de S3cr3t!99. Visuellement, il semble complexe et robuste. Pourtant, il s’agit simplement du mot du dictionnaire “secret”, où les ’e’ ont été remplacés par des ‘3’, auquel on a ajouté un suffixe très courant (!99). C’est ce qu’on appelle le leetspeak.

Face à une attaque par dictionnaire, ce mot de passe tient moins d’une seconde, et non les 24 jours que sa longueur laisserait croire. Les logiciels de craquage modernes (comme Hashcat) ne se contentent pas de tester des listes de mots figées ; ils appliquent automatiquement des règles de mutation. Ils vont prendre chaque mot de leur dictionnaire, tester toutes les combinaisons de leetspeak possibles, inverser les majuscules, et y accoler des années ou des symboles. Le leetspeak offre un faux sentiment de sécurité.

L’astuce du changement de clavier (Keyboard Shift)

Pour complexifier une phrase mémorisable, certains utilisent l’astuce du décalage de disposition de clavier. Par exemple, vous mémorisez une phrase comme mon-chat. Mais au moment de la taper, vous posez vos doigts sur un clavier physique AZERTY (français) tout en ayant configuré votre système d’exploitation en QWERTY (anglais).

Le mot pensé : mon-chat
Le résultat tapé : ;on-chqt (La touche ’m’ devient ‘;’ et le ‘a’ devient ‘q’).

Est-ce une bonne idée en OPSEC ? Non, cette méthode n’est pas suffisante si elle est utilisée seule. Tout comme le leetspeak, un changement de disposition est une substitution fixe : un attaquant qui la soupçonne applique la même correspondance à chaque essai. En OPSEC, c’est de la sécurité par l’obscurité : cela retarde un attaquant amateur, mais ne l’arrête pas face à une attaque ciblée et équipée.

Couplée à un mot de passe déjà fort (comme une longue phrase secrète aléatoire), elle apporte peu. Même si un attaquant essaie mille paires de dispositions, cela ajoute moins de 10 bits, puisque log2(1 000) ≈ 9,97. La force vient toujours de la phrase secrète en dessous.

Construire un mot de passe maître (~250 bits)

Si les listes de mots, le leetspeak et les astuces de frappe ont leurs limites, comment construire un mot de passe maître qui dure ? Notre générateur classe déjà 80 bits “Fort” et 100 bits “Très Fort”. Pour un mot de passe maître censé tenir des décennies, cet article vise bien plus haut : environ 250 bits d’entropie. La section quantique ci-dessous explique pourquoi, et ce que cette marge n’apporte pas.

Il existe deux manières d’y parvenir selon vos besoins :

1. Des caractères aléatoires (pour un gestionnaire de mots de passe)

Une chaîne de caractères générée entièrement au hasard, sans motif qu’une machine puisse exploiter : 8}8,_$-p)M&n,XvUCT0o+.5hDE6P^w6b@U-evS0 39 caractères tirés au hasard parmi les 91 de notre générateur : ≈ 253 bits. Elle a été tirée pour cet article, elle est donc désormais publique. Ne l’utilisez jamais.

2. Une phrase secrète aléatoire (pour un mot de passe que vous retenez)

Des mots aléatoires sont plus faciles à retenir que des caractères aléatoires. Chaque mot tiré de la liste EFF de 7 776 mots ajoute environ 12,9 bits : c’est donc le nombre de mots qui donne l’entropie. Douze mots donnent ≈ 155 bits, bien au-delà du seuil “Très Fort” de notre générateur. Des mots seuls ne dépassent 250 bits qu’à partir de 20 mots.

Notre générateur s’arrête à 12 mots. Pour dépasser 250 bits avec moins de mots, cochez “Chiffre aléatoire après chaque mot” et choisissez “Chiffre + Symbole” comme séparateur. Onze mots donnent alors ≈ 260 bits : depletion78$sporting14~overlap11>macaw86>paced95,paramedic41}blot41$flagstone07;uncanny92/broadways77#say2 Tirée au hasard pour cet article, avec exactement ces réglages. Un mot de passe publié est un mot de passe grillé : n’utilisez jamais celle-ci, ni aucun exemple que vous lisez. Seul ce qui est tiré au hasard compte. Mettre une majuscule à chaque mot n’ajoute rien, et des mots que vous choisissez vous-même sont bien plus faibles que des mots aléatoires.

La menace quantique : L’algorithme de Grover

Pourquoi viser 250 bits alors que 128 bits bloquent déjà les supercalculateurs d’aujourd’hui ? La réponse réside dans la perspective de grands ordinateurs quantiques.

En cryptographie, l’algorithme de Grover permet à un ordinateur quantique de chercher dans une base de données non triée de manière beaucoup plus rapide qu’un ordinateur classique. Concrètement, Grover réduit de moitié le niveau de sécurité effectif d’une clé symétrique ou d’un mot de passe.

Face à un ordinateur quantique exécutant l’algorithme de Grover, un mot de passe avec une entropie de 128 bits n’offrirait, en théorie, qu’une résistance équivalente à 64 bits. C’est une marge bien plus mince.

Doubler l’entropie préserve la marge : environ 256 bits laisseraient encore environ 128 bits face à Grover. C’est de là que vient l’objectif de 250 bits de cet article. C’est une précaution que cet article choisit, pas un chiffre tiré d’une norme.

Cette marge a ses limites. L’accélération de Grover est quadratique, pas illimitée. Chacune de ses étapes doit encore calculer le hachage du mot de passe stocké par le site, sur un ordinateur quantique assez grand pour l’exécuter. À titre de comparaison, aux 100 milliards d’essais par seconde que suppose la page de notre générateur, une recherche moyenne sur 100 bits prend déjà au moins 200 milliards d’années.

La logique rappelle Harvest Now, Decrypt Later (HNDL) : une base de hachages de mots de passe volée peut être conservée aujourd’hui et attaquée plus tard, avec de meilleures machines. Une marge plus large relève le niveau d’exigence face à ce risque. Ce n’est pas une garantie permanente.

Arpokrat Password Generator : Créez le vôtre

Ne laissez pas la sécurité de vos accès au hasard. Notre générateur gratuit crée des mots de passe et des phrases secrètes aléatoires. Pour chacun, il affiche l’entropie en bits et le temps moyen que prendrait une recherche.

Il se contente de générer : il n’évalue pas un mot de passe que vous utilisez déjà. Pour l’objectif de 250 bits ci-dessus, choisissez un mot de passe de 39 caractères avec les quatre jeux de caractères. Le générateur l’affiche à “≈ 253 bits”.

👉 Arpokrat Password Generator

Il fonctionne dans votre navigateur. Ce qu’il génère n’est jamais envoyé ni enregistré.

Le maillon faible final : Recyclage et gestion des accès

L’entropie mathématique ne protège pas contre l’erreur humaine. Un mot de passe de 250 bits perd toute sa valeur dès qu’il fuite, s’il est réutilisé sur plusieurs sites (une attaque appelée Credential Stuffing) ou s’il n’est pas protégé par un second facteur d’authentification (2FA).

La règle d’or de l’hygiène numérique est de n’avoir à retenir qu’un seul mot de passe : votre mot de passe maître de 250 bits (une phrase secrète aléatoire, comme ci-dessus). Tous vos autres accès (banque, réseaux sociaux, serveurs) doivent utiliser des mots de passe aléatoires uniques, générés spécifiquement pour eux.

Pour stocker tous ces mots de passe que vous ne pouvez pas retenir, utilisez un gestionnaire de mots de passe. Choisissez-en un qui chiffre votre coffre-fort sur votre appareil avant de le synchroniser (ce qu’on appelle souvent zero-knowledge), idéalement open source et audité de manière indépendante.

La Bombe à Retardement : Collecter maintenant, déchiffrer plus tard et l'Impératif Zero-Knowledge

Tue, 26 May 2026 00:00:00 +0000

La dépendance des gouvernements européens aux infrastructures cloud américaines ne pose pas seulement un problème d’interception immédiate. La grande révélation, la menace la plus dévastatrice pour les décennies à venir, est ce que les spécialistes du renseignement appellent la stratégie HNDL : « Harvest Now, Decrypt Later » (Collecter maintenant, déchiffrer plus tard).

Il ne s’agit pas d’une intrusion frontale, mais d’un vol silencieux. Les agences de renseignement et les adversaires étatiques interceptent et stockent aujourd’hui d’immenses quantités de données chiffrées, simplement parce que le coût du stockage est devenu dérisoire.

Ils attendent patiemment le moment où les bonds technologiques et l’évolution imprévisible de la puissance de calcul rendront les clés cryptographiques actuelles obsolètes. Ce qui constitue un secret d’État protégé en 2026 pourrait devenir un livre ouvert dans quinze ou vingt ans.

La Responsabilité Rétroactive et le Risque Temporel

Le modèle HNDL introduit une notion inédite : le préjudice juridique différé. Traditionnellement, une violation du secret est un événement statique. Avec la collecte massive de données en vue d’un déchiffrement futur, la confidentialité devient une variable dépendante du temps.

Pour quantifier ce risque, le modèle scientifique HNDL définit que la confidentialité échoue inévitablement lorsque la durée de vie nécessaire du secret dépasse l’horizon de déchiffrement de l’adversaire. Les secteurs d’exposition critique — comme le renseignement d’État, le secret industriel et les dossiers médicaux dont la conservation dépasse souvent 30 ans — se trouvent aujourd’hui dans un état de vulnérabilité latente.

Si un État ou une organisation ne garantit pas la souveraineté absolue de son infrastructure matérielle, il est, en pratique, en train de signer une renonciation à la confidentialité à long terme de ses citoyens et de ses institutions.

L’interception d’aujourd’hui est la compromission de demain. Transformer la dépendance au cloud en une dette de sécurité nationale est un pari impossible à rembourser.

L’Antithèse Arpokrat : L’Impossibilité Juridique par le Code

Face à cette vulnérabilité, l’industrie répond par la création d’écosystèmes de souveraineté numérique radicaux. Le modèle Arpokrat apparaît comme l’antithèse parfaite des messageries centralisées : au lieu de « maquiller » la sécurité sur des serveurs étrangers soumis au CLOUD Act, cette architecture fonctionne sur un réseau décentralisé, protégé par la très stricte Loi fédérale sur la protection des données (nLPD / FADP) en Suisse.

La logique centrale est celle d’une Privacy by Design absolue. En supprimant la nécessité de fournir un numéro de téléphone ou un e-mail, l’utilisateur devient une simple clé cryptographique, dénuée d’identité physique.

Sur le plan juridique, cela modifie drastiquement les règles du jeu. Un tribunal américain peut ordonner la remise de données à une entreprise relevant de sa juridiction, mais si l’architecture est fondamentalement Zero-Knowledge et non-custodiale, l’entreprise se retrouve face à une impossibilité technique d’exécution.

Il ne s’agit pas de désobéissance civile face aux lois extraterritoriales, mais d’une sauvegarde mathématique et juridique imparable : ce que l’on ne détient pas ne peut pas être divulgué.

Au-delà du Chiffrement : Dévaluer la Donnée Cible

Face à l’imprévisibilité des avancées technologiques des prochaines décennies, prétendre au “risque zéro” est une illusion. La véritable réponse, intégrée nativement dans l’application de messagerie Arpokrat, ne consiste pas à parier sur des mathématiques éternelles, mais à dévaluer la donnée elle-même.

Si un adversaire parvient un jour à briser les algorithmes grâce à une puissance de calcul inédite, notre architecture garantit qu’il ne trouvera qu’un réseau de communications anonymes. Sans métadonnées centrales, sans numéros de téléphone et sans historiques d’adresses IP pour relier un message à un individu physique, le contenu chiffré perd sa valeur stratégique car il devient inattribuable.

Cependant, le logiciel seul ne peut rien si le matériel le trahit en amont.

En dernière analyse, la sécurité au XXIᵉ siècle exige l’indépendance de la machine elle-même. L’utilisation de systèmes d’exploitation dégooglisés — avec une protection blindée au niveau du noyau (kernel) et l’élimination totale de la télémétrie étrangère — ne relève plus du militantisme de niche. Déployer un OS souverain est devenu une exigence de survie absolue pour quiconque manipule des secrets professionnels, industriels ou étatiques.