Sources et références

Par La rédaction de Mon-Adresse-IP.net·Publié le 21 août 2026·

Voici la bibliographie sur laquelle repose l'ensemble du site : les spécifications de l'IETF, les registres de l'IANA et des registres régionaux, les textes juridiques européens et français, et les fournisseurs de données que nous interrogeons. Chaque entrée précise ce que le document établit et à quel endroit du site nous nous en servons.

Comment nous hiérarchisons nos sources

Toutes les sources ne se valent pas, et l'ordre dans lequel nous les consultons n'est pas arbitraire. Nous appliquons systématiquement la hiérarchie suivante :

1. La spécification Le document qui définit le protocole, généralement une RFC publiée par l'IETF. C'est la seule source qui puisse trancher une question de format, de comportement attendu ou de plage réservée.
2. Le registre Quand un chiffre doit être attribué (un numéro de port, un bloc d'adresses, un numéro d'AS), c'est un registre qui fait foi : l'IANA au niveau mondial, les registres régionaux pour les adresses, l'AFNIC pour le .fr.
3. La documentation officielle d'un acteur Pour un comportement propre à un opérateur, à un éditeur de système d'exploitation ou à une autorité publique, nous nous appuyons sur sa propre documentation : assistance d'un fournisseur d'accès, publications de l'ANSSI, doctrine de la CNIL.
4. La presse spécialisée et les travaux de recherche Utiles pour le contexte, l'historique ou l'ordre de grandeur, jamais pour établir seuls un fait technique. Nous ne reprenons pas un chiffre lu ailleurs sans remonter à sa source d'origine.

Une conséquence pratique : lorsqu'une source de rang inférieur contredit une source de rang supérieur, c'est la seconde qui l'emporte, et nous le signalons dans le texte. Il arrive par exemple que la documentation d'un constructeur de routeur emploie « NAT » dans un sens plus restreint que celui de la RFC 2663 ; nous conservons alors la définition de la RFC et expliquons l'écart dans notre guide sur le NAT.

Fondamentaux d'Internet

Six documents suffisent à couvrir la mécanique de base d'une connexion. Ils sont anciens pour la plupart, et toujours en vigueur.

Adressage et plages spéciales

C'est le domaine où les approximations circulent le plus. Chaque plage « spéciale » que nous listons est rattachée au document qui la réserve, sans exception.

Traduction d'adresses et attribution

Ces six documents expliquent pourquoi votre ordinateur porte une adresse différente de celle que voient les sites, et comment il l'a obtenue.

Noms de domaine et authentification du courrier

Le DNS est le point de passage de presque toute activité en ligne, et le socle des mécanismes qui authentifient un expéditeur de courriel.

Web, HTTP et messagerie

Ce que votre navigateur transmet à chaque page consultée, et ce qu'un en-tête de courriel permet de reconstituer, sont décrits dans ces cinq documents.

Registres et bases publiques

Une spécification dit ce qu'est un numéro de port ou un bloc d'adresses ; un registre dit à qui il a été attribué. Les deux sont nécessaires, et ce sont les registres qui alimentent nos tables de référence.

Sécurité et bonnes pratiques

Pour les recommandations de sécurité, nous nous appuyons sur les publications de l'ANSSI, autorité nationale créée en 2009, plutôt que sur des listes de conseils sans auteur identifiable. L'intérêt de ces documents est qu'ils justifient chaque mesure au lieu de l'énoncer.

Protection des données et droit

La question « une adresse IP est-elle une donnée personnelle ? » revient constamment, et la réponse ne se trouve pas dans une RFC. Elle repose sur un texte européen, une jurisprudence et une doctrine nationale. Nous décrivons ce que ces documents établissent, sans en tirer de conseil applicable à une situation particulière.

Fournisseurs de données utilisés par le site

Les pages ci-dessus décrivent nos sources documentaires. Les données affichées en temps réel, elles, proviennent de prestataires que nous nommons systématiquement, licence et attribution comprises.

Comment lire une RFC

Les RFC ont mauvaise réputation : texte brut, ton austère, absence d'illustrations. Elles sont pourtant lisibles dès qu'on connaît trois conventions, et il est utile de savoir les consulter soi-même plutôt que de dépendre de la vulgarisation d'autrui.

Le statut compte plus que le numéro. Une RFC n'est pas nécessairement une norme. L'en-tête de chaque document annonce sa catégorie : Standards Track (une norme en cours ou aboutie), Best Current Practice (une pratique recommandée), Informational (un document explicatif ou la description d'une technologie propriétaire), Experimental ou Historic. Une RFC informationnelle décrit ; elle n'impose rien. Depuis la révision du processus de normalisation par la RFC 6410, la voie des normes ne comporte plus que deux niveaux de maturité, Proposed Standard et Internet Standard ; l'ancien niveau intermédiaire n'est plus attribué, ce qui explique que beaucoup de protocoles universellement déployés portent encore la mention Proposed Standard.

Une RFC publiée n'est jamais modifiée. C'est le point qui déroute le plus. Le texte est figé définitivement ; l'évolution passe par de nouveaux documents. L'en-tête indique alors Obsoletes (ce document remplace intégralement un précédent) ou Updates (il en modifie une partie). Réciproquement, une RFC dépassée affiche Obsoleted by. C'est ainsi que la RFC 793 renvoie vers la RFC 9293, et la RFC 2460 vers la RFC 8200. Les coquilles et erreurs relevées après publication sont consignées séparément dans un système d'errata, à consulter avant de s'appuyer sur un passage litigieux. Les numéros STD et BCP offrent une alternative commode : ils désignent une fonction plutôt qu'un texte et pointent toujours vers la version en vigueur. STD 13 renverra toujours à la spécification du DNS, quel que soit le document qui l'incarne.

Les mots en majuscules ont un sens juridique interne. Lorsqu'une RFC écrit MUST, SHOULD ou MAY en capitales, elle emploie le vocabulaire normalisé par les RFC 2119 et 8174, réunies sous le numéro BCP 14. MUST signifie une obligation absolue, SHOULD une recommandation forte dont on ne s'écarte qu'en connaissance de cause, MAY une simple faculté. Cette nuance explique quantité de différences de comportement entre équipements : deux implémentations peuvent être conformes tout en traitant différemment un cas marqué SHOULD.

Où les consulter. Le site du RFC Editor héberge la collection complète depuis la RFC 1 de 1969, en texte, en HTML et en PDF. Le Datatracker de l'IETF y ajoute l'historique : brouillons successifs, groupe de travail responsable, documents liés, statut à jour. Le processus qui mène un brouillon au rang de norme est lui-même décrit dans une RFC, la RFC 2026 (BCP 9). En pratique, la lecture rentable commence rarement au début : la table des matières, la section de terminologie et les considérations de sécurité en fin de document livrent l'essentiel en quelques minutes. Notre glossaire reprend d'ailleurs les définitions de ces sections de terminologie chaque fois qu'elles existent.

Questions fréquentes