Réservés, mais pas oubliés : pourquoi Example.com cache plus qu’on ne croit
Domaines réservés : pourquoi example.com est plus important qu’on ne le pense
Quand on rédige une documentation technique ou qu’on crée des tutoriels, on a besoin de domaines qui ne renvoient à rien de réel. C’est exactement le rôle des domaines réservés.
Un choix volontaire d’ICANN
ICANN a délibérément mis de côté certains noms de domaine pour éviter qu’ils soient utilisés en production. Les plus connus sont :
- example.com
- example.org
- example.net
D’autres existent aussi : example.edu, test.com ou encore localhost.com. Ces domaines ne sont pas des réserves oubliées. Ce sont des outils créés pour empêcher que des exemples techniques finissent par pointer vers des serveurs réels.
Éviter les risques concrets
Utiliser son propre domaine dans un tutoriel peut sembler anodin. Pourtant, quelqu’un peut copier-coller le code tel quel en production. Ou le domaine choisi peut être enregistré par quelqu’un d’autre au moment de la publication.
Les domaines réservés suppriment ce risque. Ils ne résolvent jamais vers un serveur web actif. On peut donc les utiliser en toute sécurité dans :
- des documentations techniques
- des exemples de code sur GitHub
- des vidéos de formation
- des documentations API
- des modèles de fichiers de configuration
Un réflexe à adopter
Chez NameOcean, nous voyons que les équipes qui prennent ces domaines au sérieux évitent beaucoup de problèmes. Ils utilisent example.com comme on utiliserait un outil de versioning : c’est une bonne pratique, pas une option.
Un exemple avec example.com envoie un signal clair. Le lecteur comprend aussitôt que c’est du contenu éducatif, pas une instruction à reproduire telle quelle.
Ils s’intègrent bien aux pratiques modernes
Les domaines réservés s’accordان bien avec les outils d’aujourd’hui :
- Dans Docker, ils permettent d’écrire des exemples sans déclencher des erreurs réseau lors des tests.
- Dans les API mockées, ils n’entrent pas en conflit avec l’infrastructure réelle.
- Dans les templates Infrastructure-as-Code, ils évident les risques de confusion.
- Dans l’AI-assisted development, ils permettent aux outils comme Vibe Hosting de générer du code plus portable et plus sécurisé.
Comment ils fonctionnent côté DNS
Ces domaines ne donnent pas une erreur NXDOMAIN. Ils retournent des réponses DNS normales, mais pointent vers des serveurs de documentation gérés par IANA. Ce sont des réponses légitimes.
On peut vérifier avec :
dig example.com
nslookup example.org
Erreurs fréquentes à éviter
Ne pas les utiliser en production — Même s’ils résolvent, ils ne sont pas faits pour recevoir du trafic réel.
Ne pas les considérer comme éternels — Même si leur usage est stable, compter dessus dans des systèmes critiques reste risqué.
Ne pas les mélanger avec des domaines réels — Choisir un seul type d’exemple évite de semer le doute chez le lecteur.
Et demain ?
Avec l’essor des outils basés sur l’IA, la distinction entre exemple et production devient encore plus importante. Un domaine réservé aide l’IA à comprendre le contexte et à produire du code qui ne risque pas de pointer vers des serveurs réels.
Utiliser example.com n’est pas qu’un détail. C’est ce qui distingue une documentation sérieuse d’un contenu approximatif.
La prochaine fois que vous écrivez un guide technique, prenez example.com sans hésiter. C’est un petit geste qui inspire confiance.