Le débat sur la souveraineté numérique tourne autour du cloud, des modèles d’IA, des datacenters. On y parle d’hébergeurs et de juridictions. On n’y parle presque jamais des deux protocoles sans lesquels rien de tout cela ne fonctionne. Pas un dirigeant ne les surveille. Pourtant, le jour où l’un des deux flanche, le reste tombe avec lui. Posons-les, sans dramatiser.
Ce que fait le DNS, et où sont les points de contrôle
Le DNS, c’est le carnet d’adresses d’Internet. Tu tapes un nom, ton ordinateur a besoin d’un numéro, l’adresse IP, pour joindre la machine en face. Le DNS traduit l’un en l’autre. Sans cette traduction, les noms ne mènent nulle part. Tout ce que tu fais en ligne commence par une requête DNS que tu ne vois jamais.
Le système est hiérarchique, et c’est là que se trouvent les points de contrôle. Tout en haut, la racine. Treize ensembles de serveurs racine, coordonnés sous l’égide de l’ICANN, une structure de droit américain. Sous la racine, les registres : celui qui gère le .com, celui qui gère le .fr, l’Afnic en l’occurrence. Sous les registres, les bureaux d’enregistrement qui te vendent ton nom de domaine. Et à l’autre bout de la chaîne, les résolveurs : les serveurs qui font le travail de traduction pour ton réseau.
Trois zones de fragilité se dégagent. La racine et son rattachement juridique, qui concentrent la coordination mondiale. Le registre de ton extension, qui peut suspendre un nom. Et surtout le résolveur que tu utilises au quotidien. Beaucoup d’organisations laissent leurs machines interroger les résolveurs publics de Google ou de Cloudflare, par défaut, sans décision consciente. Ce résolveur voit passer chaque nom que tu demandes. C’est un journal de navigation complet, confié à un tiers que personne n’a choisi.
Ce que fait le NTP, et pourquoi le temps est critique
Le NTP synchronise les horloges des machines. Chaque serveur, chaque poste, chaque équipement réseau ajuste en permanence son heure sur une source de référence, par couches successives qu’on appelle des strates, depuis une horloge atomique ou un signal satellite jusqu’à ta machine. On le prend pour un détail technique. C’est une dépendance fondamentale.
Sans temps précis, la cryptographie se dérègle. Un certificat TLS a une date de début et une date de fin. Si l’horloge dérive, le certificat est jugé expiré ou pas encore valide, et la connexion sécurisée échoue. Les jetons d’authentification, les codes à usage unique, les protocoles d’horodatage reposent tous sur une heure commune. Décale les horloges, et la sécurité s’effondre en silence.
Sans temps cohérent, les journaux deviennent illisibles. Corréler un incident entre dix serveurs suppose que les dix datent leurs événements sur la même échelle. Un écart de quelques secondes et la chronologie d’une attaque devient impossible à reconstituer. Sans temps fiable, les transactions financières perdent leur ordre. Les marchés réglementés imposent une synchronisation à la microseconde précisément pour cette raison. Le temps n’est pas une commodité. C’est l’infrastructure sous l’infrastructure.
Et la source par défaut est souvent unique : un pool public, ou les serveurs du fabricant du système d’exploitation. Dépendance silencieuse, là encore.
Pourquoi le débat politique tourne mal
Dès qu’on porte ces protocoles sur le terrain politique, la discussion déraille, et toujours de la même façon. Un camp veut reprendre le contrôle, ce qui se traduit vite par recentraliser : un résolveur national, une racine régionale, un temps de référence souverain. L’autre rappelle que la robustesse de ces protocoles vient précisément de leur distribution, et que les fragmenter par frontière les rendrait plus fragiles, pas moins.
Les deux ont une part de raison, et c’est pour ça que le débat n’avance pas. La racine DNS est bien rattachée à un droit étranger, c’est un fait. Mais bâtir une racine alternative reviendrait à scinder l’espace de nommage, donc à casser l’universalité qui fait l’intérêt d’Internet. De même, un résolveur unique imposé à l’échelle d’un pays crée un point de contrôle là où il n’y en avait pas.
Le piège est toujours le même : on veut réglementer un objet sans dire lequel. Réglementer la racine ? Personne n’en a le pouvoir seul. Le résolveur ? Là, oui, une organisation décide. La synchronisation du temps ? Une organisation décide aussi. La souveraineté utile ne se joue pas au sommet de la hiérarchie, hors de portée. Elle se joue à l’endroit où tu as réellement la main.
Ce qu’une organisation peut faire maintenant
Pas besoin d’attendre un standard européen dans vingt ans. Quatre mesures sont à portée dès aujourd’hui.
Reprends la main sur la résolution DNS. Héberge ton propre résolveur, ou choisis-en un dont tu connais l’opérateur et le droit applicable, au lieu de laisser tes machines pointer par défaut vers un résolveur public dont tu ignores tout. Tu reprends ainsi le journal de tes propres requêtes.
Diversifie tes sources de temps. Configure plusieurs serveurs NTP d’origines différentes, et pas tous chez le même fournisseur. Une organisation exposée gagne à disposer d’une référence interne, par exemple un récepteur de signal satellite, pour ne pas dépendre d’une seule source externe.
Active DNSSEC. Cette extension signe cryptographiquement les réponses DNS et garantit qu’un nom n’a pas été détourné en chemin. Elle se met en place côté domaine comme côté résolveur, et elle ferme une classe entière d’attaques.
Surveille les deux. Un tableau de bord qui suit la dérive de tes horloges et la santé de ta résolution DNS coûte peu et révèle les pannes silencieuses avant qu’elles ne deviennent des incidents. Ce qu’on ne mesure pas, on ne le voit pas tomber.
Le DNS et le NTP ne feront jamais la une. Ils n’ont ni logo ni drapeau à brandir. Mais ce sont des dépendances vérifiables, avec des points de contrôle connus et des parades concrètes. La souveraineté commence là où tu arrêtes de subir des réglages par défaut que personne n’a décidés.
Sources
- ICANN, fonctionnement du système des serveurs racine, icann.org
- Afnic, gestion du registre
.fr, afnic.fr - RFC 1035 (DNS) et RFC 5905 (NTPv4), IETF
- ANSSI, recommandations sur la sécurisation du DNS et DNSSEC, cyber.gouv.fr
- ESMA / MiFID II, exigences de synchronisation horloge pour les marchés réglementés