Introduction
Le 22 octobre 2026, la fondation suisse Quad9 annonce son retrait de France, effectif au 24 novembre. La cause : un jugement du tribunal judiciaire de Paris ordonnant à ce résolveur DNS de bloquer une cinquantaine de domaines associés à des diffusions illicites de matchs de tennis, à la demande de beIN Sports. La fondation refuse — non par posture, mais pour une raison qui tient à sa propre architecture de données. Elle ne dispose tout simplement pas des informations nécessaires pour s'y conformer de manière géographiquement ciblée.
Un blocage géographique qui suppose une base que Quad9 n'a pas
Quad9 opère un résolveur DNS public accessible via l'adresse 9.9.9.9, gratuit et sans inscription. C'est précisément cette conception qui rend l'injonction inapplicable. Identifier les utilisateurs français pour leur bloquer sélectivement certains domaines suppose, a minima, un mécanisme de géolocalisation des requêtes et une base de correspondance IP/territoire. Or, Quad9 a construit son modèle sur l'absence totale de cette donnée : pas de journaux d'adresses IP, pas de profils utilisateurs, pas de traçabilité des requêtes. C'est une décision d'architecture délibérée, revendiquée comme garantie de confidentialité et conforme au RGPD.
L'alternative — bloquer les domaines incriminés pour l'ensemble de sa base mondiale — a été écartée comme disproportionnée. Plutôt que de créer ex nihilo une base de données qu'il a toujours refusé de constituer, ou d'appliquer un blocage planétaire sur injonction d'une juridiction nationale, Quad9 a préféré cesser de servir le territoire français. La pénalité initiale réclamée par beIN Sports atteignait 580 000 € par jour ; le tribunal l'a réduite à 1 000 € par jour. Cela n'a pas modifié la décision de la fondation, qui fait par ailleurs face à une vingtaine d'autres procédures françaises en cours.
Ce que la couche DNS dit de votre gouvernance data
L'affaire n'est pas qu'un épisode judiciaire isolé. Elle met en lumière une catégorie de décisions que de nombreuses équipes IT ne formalisent jamais : le choix du résolveur DNS.
DNS est la première couche de toute connexion réseau. Chaque pipeline de données, chaque appel vers une API tierce, chaque synchronisation SaaS passe d'abord par une résolution de nom. Qui opère cette résolution, quelles données il conserve, sous quelle loi il est soumis — ces questions ont des implications directes sur la souveraineté des données opérationnelles de l'organisation.
Quad9 était utilisé par certains réseaux institutionnels — santé, éducation, collectivités, énergie — pour deux propriétés simultanées : un filtrage actif des domaines malveillants alimenté par plus de vingt-cinq fournisseurs de renseignements sur les menaces, et une absence totale de logs utilisateurs. Son retrait de France crée un vide fonctionnel pour ces structures, qui devront migrer vers un autre résolveur ou en déployer un en propre.
Trois questions à poser à votre stack DNS
Votre résolveur actuel collecte-t-il des données ? Beaucoup d'équipes ignorent si leur résolveur consigne les requêtes, les stocke localement ou les transfère à un tiers. C'est pourtant de la donnée opérationnelle sur l'ensemble des flux applicatifs — une donnée rarement incluse dans les cartographies de traitement.
Quelle est votre dépendance effective à un service tiers ? Si un résolveur public disparaît ou modifie sa politique, combien de systèmes basculent silencieusement vers un fallback non documenté ?
Comment votre DNS s'articule-t-il avec votre stratégie de souveraineté ? L'Union européenne a lancé DNS4EU en 2025, résolveur conforme aux exigences réglementaires européennes. Des solutions on-premise permettent de garder la maîtrise complète des logs et des règles de filtrage, au prix d'une gestion opérationnelle internalisée.
Le cas Quad9 illustre une tension désormais récurrente dans la gouvernance data : les architectures conçues pour minimiser la collecte sont efficaces sur le plan de la vie privée, mais peuvent buter sur des obligations légales qui supposent précisément l'existence de cette donnée. C'est un arbitrage que les DSI et responsables data doivent documenter explicitement — et non laisser figé par défaut dans une configuration réseau héritée.