Le paradoxe de la souveraineté à moitié

Tu paies un VPN sérieux. Tu as migré vers Proton Mail. Tu as monté un mesh Tailscale entre tes Macs. Tu as activé la Protection Avancée des Données iCloud, désactivé la moitié des analytics, basculé Safari en mode privacy max.

Et ton FAI sait pourtant que hier soir, petit coquinou, tu as ouvert un onglet sur un site de rencontres à 23h47.

Pas parce que le VPN a fui. Pas parce qu’Apple a craqué. Parce que la couche la plus banale d’internet, celle dont tout le monde a entendu le nom sans jamais s’en occuper, fonctionne en clair par défaut. Cette couche s’appelle le DNS, et c’est le maillon faible que personne ne regarde, y compris dans des stacks privacy par ailleurs solides.

Cet article explique pourquoi ce maillon est cassé, pourquoi les réponses faciles, ces fameux Cloudflare 1.1.1.1 et iCloud Private Relay, ne sont pas vraiment des réponses, et comment reprendre le contrôle en trois niveaux gradués.

Le DNS, c’est quoi

L’annuaire qui rend internet utilisable

Les humains retiennent des noms : proton.me, apple.com, macsouverain.fr. Les machines, elles, ne savent parler qu’avec des adresses IP : 185.70.43.10, 17.253.144.10, 83.228.215.109. Entre les deux, il faut un traducteur en temps réel. C’est le DNS, Domain Name System.

Imagine un téléphone fixe sans répertoire. Tu connais le nom de ton plombier mais pas son numéro. Tu appelles donc d’abord les renseignements téléphoniques, qui te donnent le numéro, puis tu rappelles ton plombier. Le DNS, c’est exactement ça : un service de renseignements automatique, interrogé des dizaines de fois par minute, sans que tu t’en rendes compte.

Le flux complet d’une résolution

Quand tu tapes signal.org dans Safari, voilà ce qui se passe en quelques dizaines de millisecondes :

1. Ton Mac regarde dans son cache local. A-t-il déjà demandé cette adresse récemment ? Si oui, il la réutilise et c’est terminé.
2. Sinon, il interroge le resolver configuré sur la machine. Par défaut, c’est celui que ta box t’a poussé en DHCP, donc celui de ton FAI.
3. Ce resolver, s’il n’a pas la réponse en cache, attaque la hiérarchie DNS. Il interroge d’abord un root server, l’une des treize adresses de référence de l’annuaire global (déployées sur des centaines d’instances physiques en anycast), qui lui dit « pour .org, demande à ces serveurs-là ».
4. Il interroge ensuite le serveur TLD du .org, qui lui dit « pour signal.org, demande à ces serveurs-là ».
5. Il interroge enfin le serveur authoritative de signal.org, qui détient la vérité officielle et lui renvoie l’adresse IP.
6. Le resolver te transmet la réponse, ton Mac peut établir la connexion HTTPS.

Cette descente de la hiérarchie, c’est ce qu’on appelle une résolution récursive. Le resolver fait le travail de remontée à ta place.

Et c’est précisément sur ce premier maillon, entre ton Mac et le resolver, que tout se joue.

Pourquoi c’est le talon d’Achille

Par défaut, tout passe en clair

Le DNS classique tourne sur le port 53, en UDP, sans chiffrement. Quand ton Mac demande proton.me à ton FAI, la question et la réponse circulent en clair sur le réseau, lisibles par n’importe quel équipement entre les deux : ta box, le DSLAM du quartier, le routeur de l’opérateur, et bien sûr le serveur DNS du FAI lui-même qui fait le travail.

Le HTTPS ne change rien à ça. HTTPS chiffre le contenu des pages, pas la question DNS qui les a précédées. Tu peux avoir le plus beau cadenas du monde sur Safari, ton FAI a déjà noté la destination avant que la connexion chiffrée ne commence.

Ton FAI voit chaque domaine, avec horodatage

C’est l’équivalent de connaître la liste de tous les magasins que tu visites dans une journée, sans savoir ce que tu y achètes. Pour un profilage commercial ou un examen judiciaire, c’est largement suffisant.

Un appel au site web d’un avocat spécialisé en droit du divorce en dit long sur toi. Une visite à 3h du matin sur une plateforme de pari en ligne renseigne ton FAI tout aussi bien. Idem pour une consultation matinale et systématique d’un site médical spécialisé. Tes données de navigation, c’est une manne de données gratis, à revendre ou à exploiter.

En France, les FAI sont légalement tenus de conserver ces métadonnées pendant un an (décret 2006-358, contesté mais maintenu malgré les arrêts de la CJUE). Aux États-Unis, des FAI ont vendu des historiques de navigation à des courtiers en données, légalement, faute de protection fédérale comparable. Le risque n’est pas l’espionnage ciblé du quotidien, c’est l’exposition structurelle : des données collectées automatiquement, stockées des mois, accessibles sur réquisition ou via une fuite.

Chiffré côté FAI ≠ chiffré bout en bout

Beaucoup d’utilisateurs croient que parce que leur box affiche un cadenas dans l’interface admin ou parce que leur abonnement mentionne « DNS sécurisé », ils sont protégés. Erreur. Le FAI peut très bien chiffrer la liaison entre ses propres serveurs et un upstream, ça ne change rien : c’est lui qui résout, c’est lui qui voit, c’est lui qui logue.

La seule manière de soustraire ta question DNS au regard de ton FAI, c’est qu’elle ne passe jamais par ses serveurs. Pas par lui, pas par sa box, pas par son resolver « amélioré ».

Et même avec un VPN, ça peut fuir

Tu as un VPN qui tourne. Tout ton trafic est chiffré dans un tunnel WireGuard. Et pourtant, tes requêtes DNS peuvent contourner le tunnel et aller directement chez ton FAI. C’est ce qu’on appelle une fuite DNS, et c’est l’un des défauts les plus silencieux des VPN mal configurés ou trop bon marché.

Le mécanisme est simple : ton appareil garde en mémoire le resolver DHCP de la box, le VPN ne pousse pas son propre resolver assez fort, et certaines requêtes système partent en parallèle du tunnel. Ton trafic web est protégé, ton DNS est exposé.

Test en trente secondes : dnsleaktest.com ou dnscheck.tools. Si ton FAI apparaît dans la liste alors que ton VPN est connecté, tu fuis.

À lire : Pourquoi tu as besoin d’un VPN, et ce qu’il fait vraiment

Le piège DoH, DoT et Private Relay

Chiffrer, oui, mais chez qui

Pour répondre au DNS en clair, l’industrie a poussé deux protocoles : DoH (DNS-over-HTTPS, port 443) et DoT (DNS-over-TLS, port 853). Sur le fond, ils font la même chose : encapsuler la requête DNS dans un tunnel chiffré entre ton Mac et un resolver. Sur la forme, le DoH se fond dans le trafic HTTPS normal et est plus discret, le DoT est plus facile à identifier et à bloquer côté admin réseau.

Activer DoH ou DoT sort enfin tes requêtes DNS du regard de ton FAI. C’est un vrai progrès. Sauf qu’on n’a pas vraiment résolu le problème, on l’a juste déplacé.

Parce que la vraie question n’est pas « est-ce que c’est chiffré sur le câble ? » Elle est « qui est en face ? ».

La centralisation, c’est l’autre nom du fouineur

Quand tu actives DoH par défaut sur Chrome, Firefox, ou via un profil macOS générique, tu te retrouves typiquement chez Cloudflare, Google, ou NextDNS. Cloudflare gère une part énorme du DNS public mondial. Google aussi. Tous les deux sont des entreprises américaines, soumises au CLOUD Act, donc contraignables par la justice US à remettre les données qu’elles stockent, indépendamment de la nationalité de l’utilisateur.

Tu as remplacé un fouineur, ton FAI réquisitionnable par la justice française, par un autre fouineur, un cloud américain réquisitionnable par les Etats-Unis, sans mandat au besoin, merci au Cloud Act 2018. La conversation n’est plus en clair sur le câble, elle est juste enregistrée chez quelqu’un d’autre.

C’est ici que la plupart des comparatifs DNS détournent le regard. « Cloudflare 1.1.1.1, c’est gratuit et c’est rapide ». C’est vrai. « C’est privé » est une affirmation qui peut se révéler trompeuse et qui demande à être contextualisée par la juridiction et le modèle économique de l’opérateur.

Apple Private Relay, l’illusion premium

iCloud Private Relay, inclus dans iCloud+, est une variante intéressante du même piège. Le mécanisme : Apple chiffre tes requêtes DNS et ton trafic Safari, les fait sortir d’abord par un serveur Apple, puis par un partenaire (Cloudflare ou Fastly dans la plupart des régions). L’idée, c’est qu’aucun acteur seul ne voit à la fois qui tu es et où tu vas.

Sur le papier, c’est élégant. Dans les faits, deux problèmes massifs.

D’abord, Private Relay ferme le DNS au niveau OS, pour Safari et certaines app système, en court-circuitant ce que tu aurais configuré. Tu pensais utiliser ton resolver Quad9 ? Apple repasse par Cloudflare ou Fastly pour Safari, sans te demander.

Ensuite, ça ne couvre que Safari et une fraction du trafic iCloud. Ton Chrome, ton Firefox, ton Mail, ton Slack, ton Discord, ton client SSH, ton terminal, ton client torrent, tes apps tierces : Private Relay ne touche pas à leurs requêtes DNS.

Tu paies un service « premium » pour une couverture partielle qui déporte la confiance sur un tandem Apple+Cloudflare que tu ne peux ni configurer ni remplacer. Apple voit que tu navigues, Cloudflare voit où tu vas, séparément par design, mais toujours deux acteurs CLOUD Act sur lesquels tu n’as aucune prise. Pour la moitié du trafic, tu n’as rien gagné.

À lire : Privacy macOS, les paramètres à changer immédiatement

Ce que ça change concrètement

Ce que ton FAI voit, et ne voit pas

Sans DNS chiffré, ton FAI dispose d’un journal complet : domaine, horodatage, fréquence, durée approximative de session. Il peut établir que tu visites un site bancaire chaque jour à 8h, que tu consultes un site médical spécifique tous les mardis soir, que tu passes un certain temps sur des sites de presse alternative, que tu te connectes à signal.org à des horaires précis. Il ne lit pas tes messages, il n’a pas besoin.

Avec un DNS chiffré et un resolver de confiance, ton FAI ne voit plus que des connexions TLS vers des adresses IP. Il sait que tu utilises internet, pas vers qui tu te connectes en premier lieu. Une partie de l’IP reste révélatrice, mais c’est un saut qualitatif énorme par rapport au défaut.

Ce qui peut quand même être corrélé

Soyons clairs sur ce qui reste exposé même avec un DNS souverain.

Le SNI (Server Name Indication) : pendant la poignée de main TLS, ton navigateur annonce encore en clair quel domaine il veut joindre, pour que le serveur présente le bon certificat. Cette information est lisible par les acteurs réseau, indépendamment du DNS. La parade s’appelle ECH (Encrypted Client Hello). Les navigateurs majeurs supportent ECH côté client, c’est le déploiement serveur qui traîne. Pour les sites sans ECH côté serveur, le SNI reste lisible par les acteurs réseau.

L’adresse IP de destination : même si personne ne lit ton DNS et ton SNI, la connexion à un serveur révèle son IP. Pour un service utilisant un grand CDN partagé (Cloudflare, AWS), l’IP toute seule ne dit pas grand chose. Pour un petit site auto-hébergé, l’IP suffit à l’identifier.

Le fingerprinting navigateur : c’est là que ça devient plus concret. Ton navigateur divulgue passivement, au moment de charger n’importe quelle page, une combinaison de signaux : rendu canvas, GPU, polices installées, résolution d’écran, timezone, plugins actifs. Pris ensemble, ils forment une empreinte suffisamment unique pour t’identifier à travers les sites, sans cookie, sans identifiant visible.

C’est la technique de tracking post-cookie des réseaux adtech et des data brokers, Meta Pixel, Google Analytics, et des dizaines d’acteurs moins visibles. Elle fonctionne en navigation privée. Elle survit à la suppression des cookies. Et elle n’a rien à voir avec ton resolver DNS : tu peux passer par Quad9 chiffré, ton empreinte navigateur reste aussi lisible.

Le DNS souverain n’est donc pas une baguette magique. C’est une couche de protection parmi d’autres. Elle bouche le trou le plus visible, le plus systématique, et celui que personne ne regarde.

Idées reçues à démonter

« J’ai un VPN, donc le DNS est couvert »

Pas nécessairement. Un VPN sérieux pousse son propre resolver DNS et force toutes les requêtes dans le tunnel. Un VPN gratuit ou bon marché ne le fait pas, ou le fait mal. Et même avec un VPN sérieux, certaines configurations macOS, des apps qui résolvent par leur propre stack, des fallbacks DHCP, peuvent contourner. Test obligatoire à dnscheck.tools.

« DoH égale privacy »

DoH chiffre le tuyau. Il ne change pas la nature de l’opérateur en face. Activer DoH par défaut dans Chrome, c’est typiquement balancer son DNS chez Cloudflare ou Google. Centralisation et juridiction US sont des questions distinctes du chiffrement, et elles ne disparaissent pas avec un cadenas en plus.

« Je n’ai rien à cacher »

L’argument classique repose sur une hypothèse fausse : que le problème serait ce que toi tu fais. Le vrai problème, c’est ce que d’autres peuvent faire avec tes données. Un historique DNS de plusieurs mois, croisé avec des bases tierces, dessine un profil comportemental dont tu ne contrôles ni l’usage, ni la durée de rétention, ni les destinataires futurs. « Rien à cacher » suppose que tu connais d’avance toutes les manières dont ces données peuvent être réutilisées contre toi. Personne ne le sait.

« Apple Private Relay, c’est top »

Sur un sous-ensemble du trafic Safari, Private Relay améliore le statu quo. Sur le reste, il ne fait rien. Et il déporte la confiance vers Apple + Cloudflare/Fastly sans alternative configurable. Pour quelqu’un qui n’a aucune envie de toucher aux réglages, c’est mieux que rien. Pour quelqu’un qui essaie d’avoir une stack souveraine cohérente, c’est un placebo qui peut donner un faux sentiment de sécurité.

« Cloudflare 1.1.1.1, c’est rapide et gratuit »

C’est vrai. C’est aussi un cloud américain dont le modèle économique repose sur la collecte agrégée de données réseau, et qui est soumis au CLOUD Act. Pour un utilisateur ordinaire, c’est mieux que le DNS de la box. Pour quelqu’un qui veut sortir des juridictions Five Eyes sur sa stack privacy, c’est un point de départ, pas un point d’arrivée.

Reprendre le contrôle, en trois niveaux

Trois niveaux d’engagement, du plus simple au plus souverain. Chacun est une vraie amélioration. Choisis celui qui correspond à ton temps disponible et à ton seuil de tolérance technique.

Niveau 1, gain immédiat, deux minutes

Tu changes le resolver système macOS pour un opérateur respectueux, en DoH ou DoT, via un profil de configuration. Pas d’app à installer, pas de service à lancer.

Concrètement, les étapes :

1. Choisis un resolver. Deux candidats sérieux, accessibles sans connaissances techniques particulières : Quad9 (fondation à but non lucratif, Suisse, juridiction nLPD) et Mullvad DNS (Suède, no-logs déclaré, infrastructure auditée Cure53, opérateur transparent). Les deux : un fichier .mobileconfig, deux clics, c’est plié.
2. Récupère le profil de configuration .mobileconfig officiel sur quad9.net ou mullvad.net selon ton choix.
3. Double-clique le fichier sur ton Mac, va dans Réglages Système > Confidentialité et sécurité > Profils, valide l’installation.
4. Vérifie le résultat sur dnscheck.tools : tu devrais voir le resolver choisi, plus ton FAI.

Avantage : deux minutes, zéro maintenance, gain immédiat. Tes requêtes ne sont plus visibles par ton FAI.

Limite : tu confies quand même tes requêtes à un opérateur externe. Quad9 et Mullvad ont des politiques no-log vérifiées et des audits indépendants et c’est autrement plus sérieux que ton FAI. Mais c’est une fondation ou une entreprise, pas toi. Pour ceux qui veulent moins déléguer, on monte d’un cran.

Niveau 2, local-first avec dnscrypt-proxy

Tu installes dnscrypt-proxy sur ton Mac. C’est un petit service local qui devient ton resolver. Il gère DoH, DoT, le protocole DNSCrypt, le cache local, le filtrage de domaines, et surtout l’anti-leak : il intercepte toutes les requêtes système et les force dans son tunnel chiffré, peu importe ce que macOS aurait fait par défaut.

Comment ça marche concrètement : ton Mac demande proton.me. La requête part en 127.0.0.1:53, vers dnscrypt-proxy qui tourne en local. Le proxy chiffre la requête et l’envoie à un ou plusieurs resolvers en anycast (Quad9, Mullvad, des serveurs DNSCrypt communautaires). Les réponses reviennent, sont mises en cache local, et servent ton Mac. Le tout sans que ton FAI voie quoi que ce soit, et avec la possibilité de réveiller plusieurs upstreams pour ne pas mettre tous tes œufs dans le même panier.

Concrètement, les étapes :

1. Installation : brew install dnscrypt-proxy.
2. Configuration : éditer /opt/homebrew/etc/dnscrypt-proxy.toml pour activer DoH, désactiver le DNS clair, choisir une liste de resolvers (Quad9, Mullvad, communautaires non-loggés).
3. Démarrage : sudo brew services start dnscrypt-proxy. Le service s’enregistre et démarre au boot.
4. Configurer macOS pour utiliser 127.0.0.1 comme seul resolver (Réglages Système > Réseau > avancé > DNS).
5. Vérifier sur dnscheck.tools : tu vois plusieurs upstreams qui tournent, jamais ton FAI, jamais Cloudflare ou Google.

Avantage : souverain à 80%. Ton Mac ne fait plus confiance à un opérateur unique. Tu peux distribuer la charge sur plusieurs resolvers no-logs européens. Anti-leak natif. Cache local rapide.

Limite : un cran de plus en config initiale, environ trente minutes la première fois. Maintenance ensuite minimale, mises à jour via brew. Tu fais toujours confiance à des resolvers tiers, simplement à plusieurs au lieu d’un seul, et en pouvant en changer en deux lignes de config.

Niveau 3, plein contrôle, Unbound récursif sur VPS perso

Tu montes ton propre resolver récursif. Pas de tiers du tout. Ton Mac interroge ta machine, qui descend la hiérarchie root → TLD → authoritative toute seule, comme une grande. Personne en face ne voit l’agrégat de tes requêtes : chaque serveur autoritaire ne voit que la requête qui le concerne, sans rien savoir du reste.

Comment ça marche concrètement : tu as un VPS chez un hébergeur souverain (Infomaniak en Suisse, Hetzner en Allemagne, etc…). Sur ce VPS tourne Unbound, un serveur DNS récursif open source réputé pour la propreté de son code. Tu connectes ton Mac à ce VPS via Tailscale, donc en tunnel WireGuard chiffré sur réseau privé. Tu configures ton Mac pour utiliser l’IP Tailscale du VPS comme resolver. Les requêtes sont chiffrées dans Tailscale, atterrissent chez Unbound qui fait la résolution récursive, et reviennent. Et parce que tout ton trafic transite dans le tunnel WireGuard Tailscale, ton FAI ne voit même plus le SNI de tes connexions HTTPS : uniquement des paquets chiffrés vers les endpoints Tailscale.

Aucun opérateur commercial ne logue l’ensemble de tes requêtes. Les serveurs autoritaires voient une IP de datacenter européen, pas ton IP résidentielle. Le seul maillon résiduel dans la config de base : les requêtes récursives d’Unbound sortent du VPS en UDP non chiffré. L’éliminer est simple : configurer Unbound en mode forward-tls-upstream vers Quad9 ou Mullvad en DoT (port 853), et tout le chemin devient chiffré, ton hébergeur ne voit plus rien non plus.

Concrètement, les étapes :

1. Provisionner un petit VPS (1 vCPU, 1 Go RAM, suffit largement) chez un hébergeur souverain.
2. Installer Unbound + DNSSEC validation activée.
3. Joindre le VPS au mesh Tailscale.
4. Restreindre Unbound à n’écouter que sur l’interface Tailscale, jamais sur l’interface publique.
5. Configurer macOS pour utiliser l’IP Tailscale du VPS comme seul resolver.

Avantage : souveraineté maximale sur le DNS. Aucun opérateur tiers. Validation DNSSEC bout à bout. Tu peux ajouter tes propres listes de filtrage (publicité, trackers, télémétrie Apple, télémétrie Microsoft) sans dépendre d’un service externe. Le résolveur t’appartient.

Limite : le frein, c’est l’installation. Compter une demi-journée la première fois si tu n’as jamais touché à Unbound. Une fois en place, la maintenance est minimale, mise à jour mensuelle du paquet et logs occasionnels. Tu paies un VPS, quelques euros par mois.

C’est excessif pour la plupart des particuliers, mais cohérent quand le reste de la stack est déjà souverain (mail, drive, password manager, mesh) et que le DNS resterait sinon le seul maillon centralisé.

À lire : Souveraineté digitale en pratique

Ce qui reste exposé, et comment le fermer

Le DNS souverain ferme le trou le plus systématique. Trois autres existent.

Le SNI (Server Name Indication) : pendant la poignée de main TLS, ton navigateur annonce en clair le domaine de destination. Même avec un DNS parfait, cette info reste lisible par les acteurs réseau, tant qu’ECH n’est pas déployé côté serveur.

L’adresse IP de destination reste visible. Pour les services derrière un grand CDN partagé, l’IP seule ne dit pas grand chose. Pour un site auto-hébergé sur un VPS dédié, elle suffit à l’identifier.

Le fingerprinting navigateur : rendu canvas, GPU, polices, timezone forment une empreinte cross-site que les adtech utilisent indépendamment du DNS, et qui survit à la navigation privée. Ni le DNS souverain, ni Tailscale n’y changent quoi que ce soit : c’est une couche applicative, dans le navigateur. La réponse est ailleurs, Firefox avec arkenfox, Brave avec sa randomisation native, ou des extensions comme CanvasBlocker. Sujet à part entière, article à venir.

La parade pour le SNI et l’IP : Tailscale avec exit node. Tout ton trafic transite dans un tunnel WireGuard chiffré. Ton FAI ne voit plus ni les requêtes DNS, ni le SNI, ni la destination. DNS souverain + Tailscale exit node, c’est le combo qui ferme ces deux portes d’un coup.

DNS souverain seul, c’est la première brique. DNS souverain + Tailscale exit node, c’est la stack réseau réellement blindée. L’architecture Tailscale, c’est donc la suite et, promis, on t’explique tout ça en détail, dans un nouvel article à venir bientôt.

En résumé

Le DNS, c’est l’annuaire d’internet. Par défaut sur la plupart des connexions, il fonctionne en clair, et ton FAI voit chaque domaine que tu visites avec horodatage. Le HTTPS ne change rien à ça : il chiffre le contenu, pas la destination. Et un VPN mal configuré peut laisser fuir le DNS hors du tunnel sans que tu t’en rendes compte.

Les solutions faciles sont en réalité des déplacements de problème. Activer DoH par défaut, c’est typiquement basculer chez Cloudflare ou Google, des clouds américains soumis au CLOUD Act. iCloud Private Relay couvre Safari et oublie le reste, en redonnant les clés à Apple et Cloudflare sur la partie qu’il couvre. Tu n’as pas supprimé le fouineur, tu en as juste changé.

Reprendre le contrôle se fait en trois niveaux gradués : gain immédiat avec Quad9 ou Mullvad DNS en DoH, deux minutes via profil de configuration. Local-first avec dnscrypt-proxy sur ton Mac, anti-leak natif et multi-resolvers, en trente minutes. Plein contrôle avec Unbound récursif sur un VPS perso joint à ton mesh Tailscale, exit node activé, demi-journée d’install, DNS et SNI réglés d’un coup.

Concrètement, les actions :

1. Teste maintenant tes fuites DNS sur dnscheck.tools. Si ton FAI ou Cloudflare apparaissent et que ce n’était pas un choix conscient, tu sais ce que tu as à faire.
2. Choisis un niveau d’engagement honnête avec ton temps. Niveau 1 immédiat, c’est mieux que niveau 3 jamais.
3. Si tu as déjà une stack privacy ailleurs (VPN, Proton, Tailscale), assure-toi que le DNS n’est pas le maillon faible qui révèle ce que le reste protège.

Le DNS, c’est la première brique d’une souveraineté réseau cohérente. Sans elle, le reste est en partie du théâtre. Avec elle et Tailscale en exit node, c’est une stack réellement blindée.

Voir aussi

• Pourquoi tu as besoin d’un VPN, et ce qu’il fait vraiment
• Souveraineté digitale en pratique
• Le cloud, c’est l’ordinateur de quelqu’un d’autre
• Privacy macOS, les paramètres à changer immédiatement

Des termes techniques ? Consulte le glossaire.