Notre méthodologie

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

Cette page décrit exactement comment chaque résultat affiché sur ce site est obtenu : quelles sources sont interrogées, quels traitements sont appliqués, et quelles erreurs ces traitements peuvent produire. Elle est écrite à partir du code réellement déployé, pas d'une description idéalisée.

Comment nous déterminons votre adresse IP

Un serveur web ne « voit » pas directement l'appareil qui le contacte : il voit l'adresse source du dernier équipement qui lui a parlé, plus, éventuellement, ce que des intermédiaires ont bien voulu écrire dans les en-têtes de la requête. Notre fonction de détection construit donc une liste de candidats dans un ordre fixe, puis choisit.

1. CF-Connecting-IP   # 1 candidat, en-tête posé par Cloudflare
2. X-Forwarded-For    # n candidats, découpés sur les virgules, de gauche à droite
3. REMOTE_ADDR        # 1 candidat, adresse réelle de la connexion TCP

La liste est parcourue en deux passes. La première retient la première adresse syntaxiquement valide et publique : la validation rejette les plages privées (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, fc00::/7) et réservées (127.0.0.0/8, 169.254.0.0/16, 0.0.0.0/8…), si bien qu'un 192.168.1.10 laissé en tête de X-Forwarded-For par des proxys internes est ignoré d'office. Si aucune adresse publique ne ressort, une seconde passe accepte la première adresse valide quelle qu'elle soit : c'est ce qui permet d'afficher 127.0.0.1 en test local. Si rien n'est exploitable, la fonction renvoie une chaîne vide et la page l'annonce plutôt que d'inventer une valeur. Ces plages sont détaillées dans notre inventaire des adresses IP réservées.

Pourquoi ces en-têtes ne sont jamais pris pour argent comptant

X-Forwarded-For et CF-Connecting-IP sont de simples lignes de texte dans la requête. N'importe quel client peut en fabriquer une et y écrire ce qu'il veut, y compris du code HTML. Deux garde-fous s'appliquent en conséquence : une valeur n'est retenue que si elle passe la validation d'adresse IP, ce qui élimine mécaniquement toute chaîne exotique ; et toute donnée affichée traverse notre fonction d'échappement HTML avant d'atteindre la page. C'est une règle absolue sur l'ensemble du site, y compris pour les champs renvoyés par l'API de géolocalisation.

Ces garde-fous protègent la page, pas la véracité de l'information : si vous fabriquez vous-même un X-Forwarded-For valide, nous afficherons l'adresse que vous y avez mise. Notre page d'analyse des en-têtes HTTP, qui montre la requête brute reçue par le serveur, permet de l'observer directement.

Les conséquences concrètes

• Derrière un proxy d'entreprise, l'adresse affichée est celle de la passerelle de sortie de l'organisation : deux collègues verront la même.
• Derrière un CDN ou un service anti-DDoS, l'adresse d'origine n'est connue que si l'intermédiaire la transmet dans un en-tête ; sinon, c'est celle du relais qui s'affiche.
• Sur mobile ou en CGNAT, l'adresse publique est partagée entre de nombreux abonnés : elle ne vous désigne pas individuellement.
• En IPv6, l'adresse affichée est celle employée pour joindre ce site précisément ; elle peut différer de celle vue ailleurs si votre système utilise des adresses temporaires, comme l'explique notre comparatif IPv4 contre IPv6.

D'où viennent les données de géolocalisation

Une fois l'adresse déterminée, nous interrogeons l'API de ipinfo.io en HTTPS, avec vérification du certificat, un délai maximal de 4 secondes et un agent utilisateur identifiant clairement notre site. Un seul appel est effectué, et il ne transmet rien d'autre que l'adresse IP à résoudre : ni identifiant de visiteur, ni en-tête de votre navigateur, ni page consultée. L'adresse étant elle-même une donnée à caractère personnel, nous la réduisons au strict nécessaire plutôt que de prétendre qu'aucune donnée ne circule.

Ces bases sont déclaratives. Elles agrègent les allocations enregistrées auprès des registres Internet régionaux, le RIPE NCC pour l'Europe, les objets WHOIS et RDAP publiés par les opérateurs, les annonces de routage BGP, les fichiers de localisation auto-publiés, et des inférences tirées de mesures de latence entre sondes. Aucune de ces sources n'est une mesure physique de votre position : ni GPS, ni triangulation, ni accès à votre appareil. Le mécanisme est détaillé dans notre guide sur la géolocalisation par adresse IP.

La mise en cache de 24 heures

Chaque réponse est enregistrée dans un fichier local, nommé d'après une empreinte de l'adresse interrogée, et réutilisée pendant 24 heures. Deux raisons : préserver le quota d'appels de l'API, et remplacer un aller-retour réseau de plusieurs centaines de millisecondes, jusqu'à 4 secondes en cas de lenteur, par une lecture de fichier. La contrepartie : si la base est corrigée en amont, notre affichage peut accuser jusqu'à 24 heures de retard supplémentaire.

Si l'appel échoue ou expire, la fonction ne produit rien : les champs affichent « Non disponible » et le verdict bascule en statut indéterminé (bouclier gris). Nous ne substituons jamais une valeur approchée à une donnée manquante.

Quelle précision attendre

La question n'est pas de savoir si la géolocalisation par IP est fiable, mais à quelle échelle elle l'est. Voici ce que l'on peut raisonnablement attendre, niveau par niveau.

Le point le plus mal compris concerne le champ loc. Quand une base ignore la ville exacte, elle renvoie un point par défaut : centre de l'agglomération, voire centre du pays. Ce mécanisme a produit des situations bien documentées, où des propriétés rurales désignées comme point par défaut d'un pays entier sont devenues l'adresse apparente de millions de connexions, avec les visites et les plaintes qui vont avec. Un point sur une carte n'est pas une position : c'est un repère de repli.

Comment nous détectons Tor

La détection du réseau Tor est le seul point de notre analyse qui repose sur une source d'autorité plutôt que sur une heuristique. Nous téléchargeons la liste officielle des nœuds de sortie publiée par le projet Tor sur check.torproject.org, et nous la conservons en cache pendant 12 heures.

Le traitement est délibérément strict. Le fichier est découpé ligne par ligne, chaque ligne est nettoyée, puis conservée uniquement si elle constitue une adresse IP valide : les commentaires et lignes vides sont donc écartés d'office. Les adresses retenues sont stockées comme clés d'un tableau associatif, ce qui permet une vérification en temps constant, mais impose une comparaison exacte : nous ne testons ni préfixe, ni plage, ni voisinage.

Quatre limites en découlent, et il faut les connaître :

• Un relais qui vient de rejoindre le réseau, ou de changer d'adresse de sortie, peut ne pas encore figurer dans la liste : le délai de publication en amont s'additionne à nos 12 heures de cache.
• À l'inverse, une adresse qui a cessé d'être un nœud de sortie reste signalée comme telle jusqu'au prochain rafraîchissement.
• La comparaison est textuelle : une adresse IPv6 écrite sous une forme équivalente mais différente de celle publiée ne serait pas reconnue.
• Seuls les nœuds de sortie sont listés. Si le téléchargement échoue, la liste revient vide et aucune détection Tor n'a lieu : l'adresse passe aux étapes suivantes, qui la classeront le plus souvent comme adresse d'hébergeur, les relais de sortie étant généralement installés en datacenter.

Le fonctionnement du réseau lui-même, et ce qu'il protège réellement, sont décrits dans notre guide sur Tor.

Comment nous classons une adresse en « protégée » ou « exposée »

Le bouclier affiché en page d'accueil et sur l'outil de recherche d'adresse IP résulte d'une cascade de tests exécutés dans un ordre strict. Le premier test qui répond arrête l'analyse.

1. Données absentes Si aucune adresse n'a pu être déterminée ou si l'API n'a rien renvoyé, le statut est indéterminé (bouclier gris). Aucun autre test n'est tenté.
2. Nœud de sortie Tor Comparaison exacte avec la liste officielle. Verdict : protégée.
3. Fournisseur de VPN identifié Recherche de mots-clés dans la concaténation du champ org et du nom d'hôte, tout en minuscules. Verdict : protégée.
4. Hébergeur ou datacenter Recherche d'une cinquantaine de termes caractéristiques des infrastructures d'hébergement. Verdict : protégée, avec le libellé « adresse non résidentielle ».
5. Cas par défaut Toute adresse qui n'a déclenché aucun des tests précédents est considérée comme résidentielle. Verdict : exposée (bouclier jaune).

Deux détails d'implémentation changent le résultat. D'abord, le mot « vpn » employé seul n'est recherché que dans le nom d'hôte, jamais dans le nom d'organisation : ce mot apparaît dans quantité de dénominations qui ne désignent pas un service grand public, alors qu'un nom inverse contenant vpn est un signal nettement plus fiable. Les fournisseurs explicitement listés, eux, sont recherchés dans les deux champs. Ensuite, la classification résidentielle est un cas par défaut, pas une détection : le code contient une liste de fournisseurs d'accès grand public, mais elle sert de référence documentaire et n'intervient pas dans la décision. Une adresse est donc déclarée « exposée » parce que rien ne l'a fait sortir du lot, pas parce que nous avons reconnu votre opérateur.

Les deux types d'erreurs possibles

Le faux positif survient quand un abonné ordinaire est classé « protégé ». La recherche s'effectuant par sous-chaîne, il suffit qu'un terme générique comme cloud, server ou hosting figure dans le nom de l'organisation où la plage est enregistrée : c'est fréquent pour les accès professionnels livrés par la filiale d'hébergement d'un groupe télécom, ou pour les petits opérateurs dont l'objet RIPE porte le nom d'une entité d'infrastructure.

Le faux négatif est symétrique : une connexion réellement protégée est présentée comme exposée. C'est le cas d'un VPN modeste ou auto-hébergé, dont la plage n'appartient à aucun fournisseur listé, dont le champ org reste neutre et dont le nom inverse n'existe pas. Votre adresse réelle est bien masquée ; notre heuristique, elle, n'a rien vu.

Aucune liste de mots-clés ne résout parfaitement ces deux cas : c'est une limite structurelle de la méthode, que seule une base commerciale spécialisée dans la détection de proxys réduirait, sans l'éliminer. Croisez donc le verdict avec deux vérifications indépendantes : notre test de fuite WebRTC, qui révèle les adresses divulguées par votre navigateur en dehors du tunnel, et notre page mon navigateur, qui montre ce que votre configuration expose au-delà de l'adresse IP. Pour masquer durablement votre adresse, notre guide comment masquer son adresse IP compare les approches.

Ce que nous ne faisons pas

La transparence sur les traitements absents vaut celle sur les traitements réalisés. Voici ce que ce site ne fait pas, par conception :

• Aucune journalisation applicative des adresses consultées. Notre code n'écrit aucune ligne de journal contenant votre adresse ou celle que vous recherchez.
• Aucune base d'historique. Il n'existe aucune base de données sur ce site : rien ne permettrait techniquement de relier deux visites.
• Aucune revente, aucun partage. Ni enrichissement de profil, ni cession à des courtiers en données.
• Aucun scan de ports, aucun test intrusif. Nous n'envoyons jamais le moindre paquet vers l'adresse analysée, nous lisons seulement ce qu'une base publique en dit : l'analyser ne déclenche rien chez son détenteur.
• Aucune empreinte de navigateur à des fins de suivi. Les caractéristiques affichées par nos outils sont calculées et présentées, jamais stockées ni corrélées.

Le fichier de cache ne contient que la réponse de l'API pour une adresse donnée : pays, région, ville, code postal, fuseau, opérateur, nom d'hôte et coordonnées approximatives. L'adresse interrogée elle-même en est retirée avant écriture : elle serait redondante, puisque le nom du fichier en dérive, et sa présence en clair ferait du cache un fichier nominatif. Ni identifiant de visiteur, ni horodatage de visite, ni page consultée, ni association entre plusieurs adresses. Les fichiers dont la durée de vie est dépassée ne sont plus jamais lus, et une purge automatique déclenchée au plus une fois par heure les efface du disque : un résultat périmé ne survit donc jamais plus d'une heure au-delà de ses 24 heures.

Deux réserves d'honnêteté : comme tout site hébergé, le serveur web tient des journaux d'accès techniques standard, indépendants de notre code ; et une adresse recherchée via notre outil transite par l'URL, donc par ces journaux. Le détail des traitements et de vos droits figure dans notre politique de confidentialité et, sur le plan juridique, dans notre analyse de l'adresse IP au regard du RGPD.

Les outils entièrement côté navigateur

Plusieurs de nos outils ne communiquent rien au serveur. Ce n'est pas une promesse : c'est vérifiable en quelques secondes.

• Le calculateur de sous-réseau et le convertisseur d'adresses IP sont écrits intégralement en JavaScript exécuté chez vous : le formulaire n'est jamais soumis, aucune requête n'est émise, et le code serveur ne lit aucun paramètre.
• Le test WebRTC s'exécute dans votre navigateur et interroge un serveur STUN public pour forcer l'énumération des candidats de connexion. Les adresses découvertes sont affichées localement et ne nous sont jamais transmises.
• La page mon navigateur se contente de mettre en forme les propriétés que votre navigateur expose spontanément à tout site visité.

Pour le vérifier : ouvrez les outils de développement avec la touche F12, placez-vous sur l'onglet Réseau, videz la liste, puis lancez un calcul. Aucune nouvelle requête n'apparaît. Le test WebRTC fait exception : l'échange STUN passe en UDP et n'apparaît pas dans cet onglet ; il s'observe dans about:webrtc ou chrome://webrtc-internals.

À l'inverse, notre analyseur d'en-têtes HTTP est par nature un outil serveur : il affiche les en-têtes que votre navigateur a envoyés, et qu'un serveur doit forcément recevoir pour répondre. Ils sont lus, affichés, puis oubliés.

Comment nous vérifions les contenus rédactionnels

Les pages de ce site sont rédigées à partir de sources primaires : les RFC de l'IETF pour les protocoles, les registres de l'IANA pour les numéros et les plages réservées, la documentation du RIPE NCC pour l'allocation des adresses en Europe, les publications de l'ANSSI, de la CNIL et de l'ARCEP pour la sécurité, la vie privée et la réglementation. Quand une affirmation ne repose pas sur une source primaire, elle est formulée comme une observation, pas comme un fait établi.

Conséquence directe sur l'écriture : nous ne citons aucun chiffre que nous ne pouvons pas sourcer. Là où d'autres pages avancent des pourcentages sans référence, nous préférons un ordre de grandeur exprimé en toutes lettres. Les procédures décrites (commandes réseau, réglages de box, tests de fuite) sont exécutées sur nos propres accès fixes et mobiles avant publication, et corrigées quand l'interface d'un opérateur change.

Chaque page affiche sous son titre sa date de publication et, si elle diffère, sa date de mise à jour. Ces dates proviennent d'un registre central unique : elles bougent quand le contenu bouge, jamais pour simuler de la fraîcheur. Une erreur factuelle signalée via notre page de contact est vérifiée, corrigée dans les meilleurs délais, et la date de révision mise à jour ; une correction substantielle est signalée dans la page concernée. Nos engagements figurent dans notre charte éditoriale, les références utilisées dans notre page sources.

Enfin, l'indépendance éditoriale est une contrainte assumée : aucun lien affilié, aucun classement commercial, aucun « meilleur fournisseur ». Les marques ne sont citées que comme exemples techniques neutres. Le site n'affiche aucune publicité et ne perçoit aucun revenu : il n'existe donc aucun intérêt commercial susceptible d'influencer le contenu des pages.

Signaler une erreur de localisation

C'est la demande la plus fréquente sur ce type de site, et la réponse est nette : nous ne pouvons pas corriger la donnée nous-mêmes. Nous affichons la réponse du fournisseur telle qu'elle nous parvient ; la retoucher localement produirait un site en contradiction avec tous les autres services, sans rien changer à la source du problème. Voici la marche à suivre réellement efficace.

1. Vérifiez que l'adresse analysée est bien la vôtre Comparez avec l'analyseur d'en-têtes : une localisation portant sur l'adresse d'un proxy d'entreprise n'est pas une erreur de base.
2. Croisez avec d'autres services Chacun s'appuie sur une base différente. Si tous affichent la même ville erronée, l'erreur vient de l'enregistrement d'origine.
3. Demandez la correction au propriétaire de la base Les principaux éditeurs, dont ipinfo et MaxMind, publient un formulaire de correction. Préparez le préfixe concerné, la localisation correcte et un justificatif : objet RIPE, attestation de l'opérateur, ou tout document rattachant la plage à un lieu.
4. Simple abonné : sollicitez votre opérateur Vous n'agissez que sur une adresse, lui peut corriger toute la plage. Le support grand public connaît rarement le sujet : mentionnez « données de géolocalisation IP » et « objet inetnum ».
5. Comptez plusieurs semaines Les bases sont reconstruites périodiquement, les corrections validées manuellement, et notre cache ajoute jusqu'à 24 heures.

Le cas des opérateurs : publier un geofeed

Les opérateurs et les entreprises disposant de leurs propres plages ont une solution nettement plus efficace que les demandes au cas par cas : publier un geofeed. Il s'agit d'un fichier CSV auto-publié, normalisé par la RFC 8805, qui associe chaque préfixe à un pays, une subdivision, une ville et un code postal. Un champ laissé vide signifie explicitement « information non fournie », ce qui vaut mieux qu'une valeur par défaut erronée.

192.0.2.0/24,FR,FR-33,Bordeaux,33000
198.51.100.0/24,FR,FR-75,Paris,
2001:db8:1::/48,FR,FR-35,Rennes,
# préfixe,pays,subdivision ISO 3166-2,ville,code postal

Encore faut-il que les éditeurs trouvent ce fichier : c'est l'objet de la RFC 9632 (2024), qui a remplacé la RFC 9092. Le geofeed est déclaré dans l'objet de registre correspondant à la plage (sur le RIPE, un attribut geofeed: dans l'objet inetnum ou inet6num) et servi en HTTPS. Les principaux éditeurs exploitent ces déclarations, ce qui en fait le moyen le plus fiable pour un opérateur de reprendre la main sur la localisation apparente de ses abonnés. Le rôle des registres est expliqué dans notre page sur les fournisseurs d'accès français.

Questions fréquentes