Pourquoi l'IPv4 arrive au bout : le contexte que tout dirigeant devrait connaître
Il y a des sujets techniques qui restent confinés dans les salles serveurs, et puis il y a ceux qui finissent, un beau matin, par atterrir sur le bureau d'un dirigeant. La fin des adresses IPv4 appartient à la seconde catégorie. Pendant des années, on en a parlé comme d'une échéance lointaine, un peu abstraite. Sauf que l'échéance est passée. Et que ses effets, eux, sont bien concrets : une facture d'hébergement qui grimpe sans explication claire, des emails qui n'arrivent plus, un accès distant qui cesse brusquement de fonctionner un lundi matin.
Ce guide part d'un constat simple. La plupart des entreprises subissent cette transition au lieu de la piloter. Non par négligence, mais parce que personne ne leur a expliqué où se situaient les vrais points de friction.
4,3 milliards d'adresses pour une planète connectée : le calcul qui ne tient plus
L'IPv4 repose sur un format de 32 bits. Traduction : environ 4,3 milliards d'adresses uniques possibles. En 1981, quand le protocole a été normalisé, ce chiffre semblait vertigineux. Presque absurde de générosité.
Puis le monde a changé. Chaque smartphone consomme une adresse. Chaque box internet, chaque objet connecté, chaque serveur, chaque caméra de surveillance, chaque terminal de paiement. Une PME de quinze personnes peut aujourd'hui mobiliser une cinquantaine d'adresses sans même s'en rendre compte : postes fixes, portables, téléphones, imprimantes réseau, NAS, borne wifi, alarme connectée, thermostat du local. Multipliez par le nombre d'entreprises sur Terre, ajoutez huit milliards d'humains dont une bonne partie possède plusieurs terminaux, et le compte est vite plié.
Le calcul ne tient plus depuis longtemps. Ce qui a changé récemment, c'est que les rustines qui masquaient le problème commencent, elles aussi, à montrer leurs limites.
Chronologie de l'épuisement : ce qui s'est réellement passé depuis 2011 en Europe
Février 2011. L'IANA, l'autorité mondiale qui distribue les blocs d'adresses aux registres régionaux, alloue ses derniers blocs disponibles. Le réservoir central est vide.
Septembre 2012. Le RIPE NCC, qui gère l'Europe, le Moyen-Orient et une partie de l'Asie centrale, entre dans sa phase dite d'épuisement. À partir de ce moment, une entreprise ne peut plus obtenir qu'un tout petit bloc, et seulement à condition de déployer aussi de l'IPv6.
Novembre 2019. Le RIPE annonce qu'il n'a plus la moindre adresse IPv4 à distribuer. Depuis, il existe une liste d'attente. Les adresses qui y circulent proviennent uniquement de restitutions ou de faillites d'organisations. L'attente se compte en années, pour des volumes dérisoires.
Voilà où nous en sommes. Ce n'est pas une prévision, c'est un état de fait vieux de plus de cinq ans. La différence, c'est que jusqu'ici les opérateurs absorbaient le choc en interne. Ils ont de moins en moins les moyens de le faire.
Le marché gris des adresses IPv4 : pourquoi votre hébergeur vous facture désormais l'IP fixe
Quand une ressource devient rare et qu'elle reste indispensable, il se crée un marché. C'est exactement ce qui s'est passé.
Des courtiers spécialisés achètent et revendent des blocs d'adresses IPv4. Les prix ont connu une trajectoire assez spectaculaire : quelques dollars l'unité au début des années 2010, puis une montée régulière, avec des pics autour de 50 à 60 dollars par adresse sur certaines périodes. Les tarifs fluctuent, mais la tendance de fond reste haussière, et personne ne s'attend sérieusement à un retournement.
Conséquence directe pour vous : votre hébergeur, qui distribuait autrefois une adresse fixe sans y penser, la considère désormais comme un actif. Les grands fournisseurs cloud ont commencé à facturer chaque adresse IPv4 publique à l'heure. Les hébergeurs mutualisés européens ont suivi, avec des lignes qui apparaissent sur les factures sous des intitulés parfois obscurs.
Si vous avez vu une ligne « adresse IP dédiée » apparaître sur votre facture ces derniers mois, vous savez maintenant d'où elle vient. Ce n'est pas une invention commerciale. C'est le reflet d'une pénurie réelle.
CGNAT : la rustine que votre opérateur vous impose sans vous prévenir
Voici le point qui provoque le plus d'appels au support, et le moins de compréhension.
Le CGNAT, ou Carrier-Grade NAT, consiste pour un opérateur à faire partager une seule adresse IPv4 publique entre des dizaines, parfois des centaines d'abonnés. Chacun conserve une adresse privée en interne, et l'opérateur joue les aiguilleurs. Techniquement, c'est astucieux. Économiquement, c'est ce qui permet aux opérateurs de continuer à recruter des clients sans acheter d'adresses hors de prix.
Le problème ? Vous n'êtes plus joignable depuis l'extérieur. Vous pouvez naviguer, envoyer des emails, consulter vos applications en ligne. Mais rien ni personne ne peut initier une connexion vers vous.
Or beaucoup d'entreprises ne réalisent pas à quel point elles dépendent de cette joignabilité. Le technicien qui se connecte à distance sur l'automate de production. Le comptable qui accède au serveur de fichiers depuis chez lui. Le gérant qui consulte les caméras de son entrepôt sur son téléphone. Tout cela repose sur une adresse publique atteignable.
Et le pire, dans cette histoire, c'est que le basculement se fait souvent en silence. Un changement d'offre, un renouvellement de contrat, un remplacement de box, et voilà. Personne n'a menti, personne n'a fauté, mais un lundi matin le lien VPN ne monte plus et l'équipe technique passe deux jours à chercher une panne qui n'existe pas.
IPv4 contre IPv6 : les différences qui ont un impact concret sur votre activité
Format d'adresse, notation et lecture d'une adresse IPv6
Une adresse IPv4 tient en quatre nombres séparés par des points : 192.168.1.1. Familier, lisible, mémorisable.
Une adresse IPv6 fait 128 bits et s'écrit en hexadécimal, par groupes de quatre caractères séparés par des deux-points. Quelque chose comme 2001:0db8:85a3:0000:0000:8a2e:0370:7334. Avouons-le, c'est nettement moins convivial.
Deux règles simplifient la lecture. Les zéros en début de groupe s'omettent. Et une suite de groupes entièrement nuls se remplace par un double deux-points, une seule fois par adresse. L'exemple précédent devient 2001:db8:85a3::8a2e:370:7334. Toujours pas mémorisable, mais plus manipulable.
Combien d'adresses au total ? Environ 340 sextillions. Un 3 suivi de 38 chiffres. On a coutume de dire qu'on pourrait attribuer une adresse à chaque grain de sable de la planète, et il en resterait. La formule est éculée mais elle rend bien l'idée : cette fois, la réserve ne s'épuisera pas.
Ce que l'IPv6 apporte vraiment : fin du NAT, autoconfiguration, IPsec natif
Le gain le plus structurant, c'est la disparition du NAT. Chaque équipement peut disposer d'une adresse publique propre. Fini les redirections de ports laborieuses, fini les schémas d'adressage privés qui se chevauchent quand deux entreprises fusionnent leurs réseaux.
L'autoconfiguration sans état, ou SLAAC, permet à une machine de se construire elle-même une adresse valide à partir des informations diffusées par le routeur. Plus besoin d'un serveur DHCP dans tous les cas de figure. Le déploiement s'en trouve allégé, notamment sur les réseaux d'objets connectés.
Quant à IPsec, il a été pensé dès l'origine comme un composant du protocole. Attention toutefois : intégré au standard ne signifie pas activé par défaut. C'est une nuance que certains commerciaux oublient de préciser.
Ajoutons un détail qui compte pour les infrastructures à fort trafic : les en-têtes IPv6 sont de taille fixe et plus simples à traiter. Les routeurs les analysent plus vite. Sur un backbone opérateur, ça pèse. Sur le réseau d'une entreprise de vingt personnes, franchement, vous ne le verrez pas.
Les fausses promesses : non, l'IPv6 ne rendra pas votre site plus rapide par magie
Passons aux idées reçues, parce qu'elles circulent beaucoup.
Non, activer l'IPv6 ne va pas accélérer votre site. Certaines mesures montrent des gains sur des trajets mobiles, principalement parce que le trafic évite les couches de traduction du CGNAT. Mais le facteur déterminant de la vitesse d'un site, c'est le poids des pages, la qualité du code, le temps de réponse du serveur et la configuration du cache. Pas le protocole réseau.
Non, l'IPv6 n'est pas intrinsèquement plus sécurisé. Il déplace certains risques et en crée d'autres. Un équipement qui était protégé par le simple fait d'être derrière un NAT se retrouve potentiellement exposé.
Et non, ce n'est pas non plus une catastrophe annoncée. C'est un changement d'infrastructure, comparable au passage du RTC à la fibre : il faut le préparer, l'accompagner, vérifier ce qui casse. Rien de plus, rien de moins.
Double pile (dual-stack), tunnels, traduction : les trois stratégies de transition
La double pile consiste à faire fonctionner les deux protocoles en parallèle sur les mêmes équipements. Votre serveur répond en IPv4 et en IPv6, chaque visiteur emprunte le chemin dont il dispose. C'est de loin l'approche la plus répandue et la plus sûre. Son seul défaut : vous maintenez deux configurations réseau au lieu d'une. Deux jeux de règles de pare-feu, deux séries de tests.
Les tunnels encapsulent du trafic IPv6 dans de l'IPv4, ou l'inverse, pour traverser un réseau qui ne supporte qu'un seul protocole. Utile en dépannage, en attendant que l'opérateur suive. Rarement satisfaisant sur la durée : latence supplémentaire, point de défaillance en plus, et des soucis de MTU qui produisent des symptômes bizarres, du genre « le site s'affiche mais les images ne chargent pas ».
La traduction, avec des mécanismes comme NAT64 ou 464XLAT, permet à un réseau purement IPv6 de joindre des services restés en IPv4. C'est ce que font déjà plusieurs opérateurs mobiles à grande échelle, sans que leurs abonnés en aient conscience.
Pour une PME, la réponse est presque toujours la même : double pile. On garde l'existant, on ajoute le nouveau, on observe.
Votre site web : ce qui change côté hébergement et référencement
Enregistrements DNS AAAA : le point de bascule technique à comprendre
Un enregistrement A dans votre DNS associe un nom de domaine à une adresse IPv4. Son équivalent IPv6 s'appelle AAAA, prononcé « quad A ».
Tant que vous n'avez pas d'enregistrement AAAA, votre site reste invisible pour tout client qui ne dispose que d'IPv6. Et inversement : si vous publiez un AAAA pointant vers un serveur mal configuré, une partie de vos visiteurs va se heurter à un mur.
C'est là que le mécanisme du Happy Eyeballs entre en scène. Les navigateurs modernes tentent les deux protocoles quasi simultanément et retiennent celui qui répond en premier. Ce comportement sauve beaucoup de situations bancales. Il masque aussi les problèmes, ce qui est nettement moins réjouissant : votre IPv6 peut être cassé pendant des mois sans qu'aucun visiteur ne se plaigne, parce que son navigateur bascule discrètement sur IPv4. Jusqu'au jour où un utilisateur en IPv6 seul se présente.
Règle à retenir : ne publiez jamais un AAAA sans avoir vérifié que le serveur répond correctement dessus. Un enregistrement DNS qui pointe vers le vide, c'est pire que pas d'enregistrement du tout.
Votre hébergeur est-il prêt ? Les questions précises à lui poser
Les réponses évasives sont fréquentes sur ce sujet. Voici de quoi les éviter.
Mon offre inclut-elle une adresse IPv6 publique, et à quel coût ? Puis-je publier un enregistrement AAAA depuis votre interface de gestion DNS ? Votre panneau d'administration permet-il de gérer des règles de pare-feu IPv6, ou uniquement IPv4 ? Vos serveurs de messagerie sortants disposent-ils d'un reverse DNS correctement configuré en IPv6 ? Vos outils de statistiques et vos journaux enregistrent-ils bien les deux formats d'adresse ?
Cette dernière question paraît anodine. Elle ne l'est pas. Il existe encore des interfaces d'administration qui refusent purement et simplement une adresse IPv6 dans leurs champs de saisie, parce que le champ a été prévu pour quinze caractères.
Si votre interlocuteur botte en touche sur trois questions sur cinq, vous avez votre réponse sur sa maturité.
Impact SEO réel : ce que Google explore, ce qu'il ignore, ce qui compte vraiment
Rassurons tout de suite : Google explore l'IPv6 depuis des années. Ses robots gèrent les deux protocoles sans difficulté. Vous ne serez ni récompensé ni pénalisé pour avoir activé l'IPv6.
Là où le référencement peut réellement souffrir, c'est dans les cas de figure suivants. Un enregistrement AAAA publié vers un serveur qui ne répond pas : le robot rencontre des erreurs, la fréquence d'exploration diminue, et les positions finissent par en pâtir. Un site accessible en IPv4 mais servant un contenu différent en IPv6, ce qui arrive quand la bascule s'est faite sur un serveur intermédiaire mal synchronisé. Des redirections qui fonctionnent d'un côté et pas de l'autre.
Autrement dit, le risque ne vient jamais du protocole. Il vient d'une transition bâclée. Ce qui, soit dit en passant, est aussi vrai pour une migration de CMS ou un changement de structure d'URL.
Un conseil pratique : après avoir publié votre AAAA, surveillez la Search Console pendant deux à trois semaines. Les erreurs d'exploration s'y voient vite.
Géolocalisation et bases GeoIP : le risque de contenus mal servis à vos visiteurs
Voilà un effet de bord auquel presque personne ne pense, et qui produit pourtant des situations cocasses.
Les bases de données GeoIP, qui associent une adresse à un pays ou une région, sont beaucoup plus matures en IPv4 qu'en IPv6. Les blocs IPv6 étant attribués plus récemment et par plages énormes, la granularité géographique reste souvent approximative.
Conséquence : un visiteur lyonnais se voit proposer la version allemande de votre site. Ou vos statistiques attribuent soudain 30 % de votre trafic à un pays où vous n'avez aucun client. Ou votre module de calcul de frais de port applique un tarif international à une commande de Saint-Étienne.
Si votre site adapte son contenu, sa langue, ses prix ou sa TVA selon la localisation, testez impérativement ce comportement en IPv6 avant de basculer. Et prévoyez, dans tous les cas, un choix manuel accessible pour le visiteur. C'est de toute façon une bonne pratique, indépendamment de cette histoire de protocole.
CDN, reverse proxy et WAF : la couche qui peut vous faire gagner du temps
Il existe un raccourci, et il serait dommage de ne pas le mentionner.
Si votre site passe par un réseau de diffusion de contenu ou un proxy inverse, celui-ci accepte généralement l'IPv6 côté visiteur et discute en IPv4 avec votre serveur d'origine. Vous devenez accessible en IPv6 sans avoir touché à votre infrastructure. Quelques minutes de configuration, parfois une simple case à cocher.
C'est une solution élégante pour un site vitrine ou une boutique de taille moyenne. Elle a ses limites, cependant. Votre serveur ne verra que l'adresse du proxy, ce qui perturbe les journaux, les outils antifraude et les règles de limitation de débit si vous n'exploitez pas correctement les en-têtes transmis. Et vous ajoutez une dépendance externe supplémentaire à votre chaîne de production.
À noter aussi : votre pare-feu applicatif doit savoir interpréter les adresses IPv6 dans ses règles. Un blocage configuré sur une plage IPv4 ne protégera absolument rien si l'attaque arrive par l'autre protocole. On y revient un peu plus bas, parce que c'est un angle mort classique.
Analytics, logs serveur et filtrage par IP : ce qui casse silencieusement
Voici la catégorie de problèmes la plus sournoise. Rien ne tombe en panne. Tout continue de fonctionner. Sauf que les données deviennent fausses.
Vos scripts d'analyse de journaux, écrits il y a huit ans, cherchent un motif à quatre nombres séparés par des points. Ils ignorent purement et simplement les lignes en IPv6. Vos statistiques de trafic sous-estiment votre audience, sans le moindre message d'erreur.
Vos règles de blocage anti-spam, basées sur des listes d'adresses IPv4, laissent passer tout ce qui arrive en IPv6. Votre dispositif de limitation de tentatives de connexion aussi.
Et puis il y a le classique du genre : la restriction d'accès à l'administration de votre site, limitée à l'adresse fixe du bureau. Le jour où le poste de travail bascule en IPv6, l'accès est refusé. Ou, plus embêtant, le jour où un attaquant se présente en IPv6, la restriction ne s'applique plus.
Faites l'inventaire de tous les endroits où une adresse IP est stockée, comparée ou filtrée dans vos systèmes. Vous allez probablement en trouver plus que prévu.
Vos emails : le point le plus sensible de la transition
Pourquoi la délivrabilité en IPv6 est plus stricte qu'en IPv4
Si vous ne deviez retenir qu'une section de ce guide, ce serait celle-ci. La messagerie est, de très loin, l'endroit où une transition mal préparée fait le plus de dégâts.
La logique des grands fournisseurs de messagerie est la suivante. En IPv4, les adresses sont rares, donc coûteuses, donc un spammeur qui brûle sa réputation perd un actif de valeur. Cette rareté fait office de barrière naturelle. En IPv6, les adresses sont abondantes au point d'être quasi gratuites. Un spammeur peut en changer toutes les minutes pendant des années.
Face à cela, Gmail, Outlook et les autres ont adopté une position beaucoup plus sévère sur le trafic IPv6. Ce qui passait sans encombre en IPv4 se fait rejeter en IPv6. Pas mis en spam : rejeté, avec un code d'erreur au moment de l'envoi.
La conséquence pratique est brutale. Un serveur de messagerie qui bascule en IPv6 sans préparation voit ses emails refusés en masse dès la première heure. Devis, factures, confirmations de commande, réinitialisations de mot de passe. Tout.
Reverse DNS obligatoire : la règle de Google et de Microsoft que beaucoup ignorent
Le reverse DNS, ou enregistrement PTR, associe une adresse IP à un nom de domaine. C'est le chemin inverse du DNS classique.
En IPv4, un PTR manquant vous vaut une pénalité de réputation. Désagréable, mais souvent survivable. En IPv6, Google le refuse tout simplement. Sa documentation est explicite sur ce point depuis des années : pas de PTR valide, pas de livraison. Microsoft applique une politique comparable.
Et il ne suffit pas que le PTR existe. Il doit être cohérent : l'adresse IPv6 pointe vers un nom, et ce nom doit pointer en retour vers la même adresse IPv6. C'est ce qu'on appelle la correspondance directe-inverse. Une incohérence ici et vos messages sont refoulés.
Autre difficulté : configurer un PTR IPv6 nécessite une délégation de zone inverse chez votre hébergeur ou votre opérateur. Tous ne le proposent pas. Certains le font sur simple demande, d'autres facturent, d'autres encore ne savent pas de quoi vous parlez. Posez la question avant de basculer, pas après.
SPF, DKIM et DMARC : réviser vos enregistrements avant la bascule
Ces trois mécanismes constituent la carte d'identité de votre messagerie. Ils étaient recommandés il y a cinq ans. Ils sont devenus indispensables, notamment depuis que Google et Yahoo ont durci leurs exigences pour les expéditeurs de volume.
SPF déclare quels serveurs ont le droit d'envoyer du courrier en votre nom. DKIM appose une signature cryptographique sur chaque message, prouvant qu'il n'a pas été altéré en route. DMARC indique quoi faire quand SPF ou DKIM échouent, et vous fait remonter des rapports.
Un passage à l'IPv6 est l'occasion parfaite de faire le ménage dans tout ça. Vérifiez que votre SPF ne dépasse pas les dix résolutions DNS autorisées, une limite que beaucoup d'entreprises franchissent sans le savoir à force d'empiler des mécanismes include pour chaque outil marketing. Vérifiez que DKIM signe bien tous vos flux, y compris ceux de votre CRM et de votre plateforme de newsletter. Et si votre DMARC est encore en politique none, envisagez de passer progressivement à quarantine.
Le piège du SPF incomplet : votre mécanisme ip4 ne couvre pas votre trafic ip6
Celui-là mérite un paragraphe à lui seul, tant il est fréquent et tant il est simple à éviter.
Votre enregistrement SPF contient probablement une mention du type ip4 suivie de l'adresse de votre serveur d'envoi. Le jour où ce serveur commence à émettre en IPv6, cette déclaration ne couvre plus rien. Le contrôle SPF échoue. Selon votre politique DMARC, les messages partent en spam ou sont rejetés purement et simplement.
La correction est triviale : ajouter un mécanisme ip6 avec la ou les adresses concernées. Trente secondes de travail. Encore faut-il y avoir pensé.
Le scénario typique se déroule ainsi. L'hébergeur active l'IPv6 sur son parc, dans le cadre d'une mise à niveau générale. Le serveur privilégie alors l'IPv6 pour ses connexions sortantes, comme le veut le comportement par défaut. Le SPF ne suit pas. Et l'entreprise passe une semaine à se demander pourquoi ses clients ne reçoivent plus rien, en cherchant du côté du contenu de ses messages.
Vérifiez votre SPF. Aujourd'hui. C'est trois minutes et ça peut vous éviter une très mauvaise semaine.
Serveur mutualisé, solution SaaS ou serveur d'envoi dédié : arbitrer selon votre volume
Une question revient systématiquement : faut-il gérer sa messagerie soi-même ou la déléguer ?
Sur un serveur mutualisé, vous partagez la réputation de l'adresse d'envoi avec les autres clients de l'hébergeur. Si l'un d'eux se fait pirater et envoie du spam, vous en subissez les conséquences. En IPv6, ce risque partagé devient plus lourd, puisque la tolérance est réduite. Pour de faibles volumes et une messagerie strictement interne, ça reste acceptable.
Les solutions SaaS de messagerie transactionnelle gèrent la réputation, le reverse DNS, les signatures et les listes noires à votre place. C'est leur métier. Pour une boutique en ligne ou toute activité qui dépend d'emails automatiques, c'est presque toujours le bon choix. Le coût est modeste au regard du risque évité.
Le serveur d'envoi dédié ne se justifie qu'au-delà d'un certain volume, disons plusieurs dizaines de milliers de messages par mois, et à condition d'avoir en interne quelqu'un qui suit la délivrabilité. Sans cette compétence, un serveur dédié se transforme vite en source de problèmes.
Listes noires et réputation d'IP : comment repartir proprement
Nouvelle adresse IPv6 égale réputation vierge. Ce qui est à double tranchant.
D'un côté, vous repartez sans passif. De l'autre, les filtres se méfient par défaut d'un expéditeur inconnu. Une adresse neuve qui envoie brutalement cinq mille messages sera considérée comme suspecte, et c'est logique.
La méthode consiste à monter en charge progressivement. Quelques dizaines de messages le premier jour, puis un doublement quotidien sur deux à trois semaines. En privilégiant d'abord les destinataires qui interagissent avec vous, ceux qui ouvrent et répondent. Les signaux d'engagement positif construisent la réputation bien plus vite que le simple volume.
Surveillez les listes noires publiques pendant cette période. Certaines listent par bloc entier plutôt que par adresse unitaire en IPv6, ce qui signifie que vous pouvez être affecté par le comportement d'un voisin de plage. Si cela arrive, les procédures de retrait existent et fonctionnent, mais elles prennent du temps.
Accès distant et sécurité : VPN, télétravail et administration serveur
Le filtrage par IP fixe ne fonctionne plus : les alternatives à mettre en place
Pendant des années, restreindre l'accès à une application par adresse IP a constitué une protection simple et efficace. L'accès à l'ERP n'était possible que depuis l'adresse du siège. Le panneau d'administration du site n'était joignable que depuis le bureau.
Le CGNAT et l'IPv6 démolissent ce modèle. Votre adresse de sortie change. Les collaborateurs en télétravail arrivent depuis des adresses variables. Et en IPv6, un même poste peut changer d'adresse plusieurs fois par jour, à cause des extensions de confidentialité qui génèrent des adresses temporaires.
Les alternatives existent, et elles sont d'ailleurs meilleures que ce qu'elles remplacent. L'authentification multifacteur d'abord, qui protège réellement quel que soit le point d'origine. Les certificats clients, qui identifient une machine autorisée indépendamment de son adresse. Un accès VPN obligatoire, où le filtrage porte sur l'adresse interne stable attribuée par le VPN lui-même.
Le filtrage par IP peut rester une couche complémentaire, jamais une protection principale. Il ne l'a d'ailleurs jamais vraiment été, mais on faisait comme si.
VPN d'entreprise et compatibilité IPv6 : vérifier avant de subir une fuite
Un point technique qui mérite votre attention, parce qu'il touche à la confidentialité.
Beaucoup de configurations VPN, notamment les plus anciennes, ne routent que le trafic IPv4. Si le poste dispose aussi d'une connectivité IPv6, le trafic correspondant sort en dehors du tunnel. C'est ce qu'on appelle une fuite IPv6.
Concrètement : votre collaborateur croit travailler dans un tunnel chiffré, et une partie de ses échanges circule en clair sur le réseau de son fournisseur d'accès. Le VPN affiche fièrement « connecté ». Tout va bien, en apparence.
Trois options selon votre situation. Faire transiter l'IPv6 dans le tunnel, ce qui est la bonne réponse si votre solution le permet. Désactiver l'IPv6 sur le poste pendant la connexion VPN, réponse acceptable mais qui vieillit mal. Ou remplacer un VPN qui ne sait faire ni l'un ni l'autre, parce qu'il date d'une époque révolue.
Un test rapide suffit à trancher : connectez le VPN, puis consultez un site qui affiche votre adresse publique. Si une adresse IPv6 apparaît et qu'elle correspond à votre connexion locale, vous avez une fuite.
Pare-feu et règles de sécurité : deux protocoles, deux jeux de règles à maintenir
Voici sans doute le risque de sécurité le plus concret de toute cette transition, et il est d'une banalité déconcertante.
Sur la plupart des systèmes, les règles de filtrage IPv4 et IPv6 sont gérées séparément. Deux tables distinctes, deux jeux de commandes. Autrement dit : un pare-feu parfaitement verrouillé en IPv4 peut être grand ouvert en IPv6.
Imaginez le scénario. Vous avez soigneusement fermé l'accès à votre base de données depuis l'extérieur. Un jour, l'IPv6 s'active sur le serveur, par une mise à jour ou un changement chez l'hébergeur. Le service écoute maintenant aussi sur IPv6. Et aucune règle ne le protège de ce côté.
Ce n'est pas théorique. Les scanners automatisés balayent désormais les plages IPv6 utilisées, en s'appuyant sur les données DNS et les journaux de certificats pour cibler leurs recherches. L'idée selon laquelle l'immensité de l'espace IPv6 rendrait le balayage impossible était vraie il y a dix ans. Elle ne l'est plus.
Règle absolue : toute règle IPv4 doit avoir son équivalent IPv6. Vérifiez-le explicitement, ne le supposez pas.
Accès aux caméras, NAS et automates industriels derrière le CGNAT
C'est la situation qui génère le plus d'appels paniqués, en particulier dans l'industrie et le commerce.
Vous accédez à votre système de vidéosurveillance depuis votre téléphone. Le technicien intervient à distance sur une machine de production. Le NAS synchronise les sauvegardes avec un site distant. Tout cela repose sur une redirection de ports depuis une adresse publique fixe.
Le passage en CGNAT anéantit ce montage. Il n'y a plus de port à rediriger, plus d'adresse publique à vous.
Les solutions, par ordre de préférence. Demander à votre opérateur une adresse IPv4 publique, souvent disponible en option payante ou sur les offres professionnelles. Utiliser l'IPv6, qui redonne une adresse publique à chaque équipement et résout élégamment le problème, sous réserve que le matériel la supporte. Passer par un service de relais fourni par le constructeur, pratique mais qui implique de faire transiter vos flux par un tiers, ce qui n'est pas neutre pour des images de vidéosurveillance. Ou monter un VPN site à site, la réponse la plus propre pour un usage professionnel régulier.
Un mot sur les automates industriels : beaucoup ne parlent tout simplement pas IPv6, et ne le parleront jamais. Il faudra les placer derrière une passerelle. Ce qui, au passage, est de toute façon souhaitable pour des raisons de sécurité.
Fin du NAT : ce que cela implique en matière d'exposition de vos équipements
Terminons cette partie par une nuance importante, souvent mal comprise.
Le NAT n'a jamais été un dispositif de sécurité. C'était un contournement de la pénurie d'adresses. Mais il produisait un effet secondaire protecteur : les machines internes n'étaient pas joignables depuis l'extérieur.
Avec l'IPv6, chaque équipement peut disposer d'une adresse publique. Cette protection accidentelle disparaît. Ce qui n'est pas grave en soi, à condition d'avoir un pare-feu correctement configuré. Ce qui est grave, c'est de découvrir après coup que l'imprimante du service comptable, avec son interface web sans mot de passe et son micrologiciel de 2016, est désormais accessible depuis internet.
La bonne pratique consiste à bloquer tout le trafic entrant par défaut, puis à ouvrir explicitement ce qui doit l'être. C'est exactement ce que font les box grand public récentes, d'ailleurs. En entreprise, mieux vaut le vérifier soi-même que de le supposer.
Diagnostiquer votre exposition : l'audit à mener maintenant
Cartographier votre patrimoine numérique : sites, boîtes mail, applications métier, objets connectés
On ne migre pas ce qu'on n'a pas inventorié. Et l'expérience montre que l'inventaire réserve toujours des surprises.
Listez vos noms de domaine, tous, y compris ceux qui redirigent vers le site principal et celui acheté pour une campagne oubliée. Vos sites et applications web, en n'oubliant pas les environnements de préproduction. Vos flux de messagerie : boîtes nominatives, adresses génériques, formulaires de contact, notifications automatiques, newsletter, factures. Vos applications métier hébergées en interne. Vos équipements réseau et objets connectés. Vos accès distants et VPN.
Pour chaque élément, notez trois informations : qui l'héberge, qui l'administre, et quelle serait la conséquence d'une indisponibilité de deux jours.
Cette cartographie prend une demi-journée à une PME classique. Elle sert bien au-delà de la question IPv6, soit dit en passant. C'est le document qu'on regrette de ne pas avoir le jour où quelque chose casse.
Tester la compatibilité IPv6 de votre infrastructure : outils gratuits et méthode
Plusieurs services en ligne gratuits permettent de vérifier l'état des lieux en quelques minutes.
Des sites de test de connectivité indiquent si votre connexion bureau dispose d'IPv6 et si elle fonctionne correctement. Des outils d'analyse de domaine évaluent votre configuration DNS, votre messagerie, vos enregistrements de sécurité et votre compatibilité IPv6, avec des rapports détaillés et pédagogiques. Des vérificateurs de messagerie testent SPF, DKIM, DMARC et le reverse DNS sur les deux protocoles.
La méthode, en pratique. Testez depuis le bureau, puis depuis une connexion mobile 4G ou 5G, qui utilise très souvent l'IPv6 en priorité. Testez votre site public, puis vos applications internes exposées. Envoyez un email de test vers une boîte Gmail et examinez les en-têtes du message reçu : ils vous diront par quel protocole il est arrivé et si les contrôles ont réussi.
Consignez tous les résultats. Vous en aurez besoin comme point de référence après la migration.
Identifier les dépendances externes : prestataires, API, passerelles de paiement, ERP
Votre système ne vit pas en autarcie. Il dialogue avec des services extérieurs, et chacun constitue un point de rupture potentiel.
Votre passerelle de paiement, qui autorise peut-être les appels entrants uniquement depuis une liste d'adresses IP déclarées. Votre transporteur, dont l'API de suivi de colis reste en IPv4 seul. Votre ERP hébergé chez un éditeur, avec ses propres restrictions d'accès. Votre outil de facturation, votre plateforme d'emailing, votre solution de sauvegarde externalisée.
Le point de vigilance principal : partout où vous avez déclaré une adresse IP chez un partenaire, cette déclaration devra être mise à jour. Et parfois la procédure prend plusieurs jours, avec validation manuelle côté prestataire.
Anticipez ces demandes. Rien de plus frustrant qu'une migration bloquée pendant une semaine parce qu'on attend qu'un partenaire ajoute une adresse dans sa liste.
Repérer les équipements en fin de vie qui ne migreront jamais
Il faut le dire clairement : certains matériels ne passeront pas la transition. Jamais.
Les imprimantes réseau d'avant 2012. Les caméras de surveillance premier prix. Les automates industriels et systèmes de supervision anciens. Les copieurs multifonctions. Les vieux points d'accès wifi. Les onduleurs avec carte réseau intégrée. Les systèmes de contrôle d'accès et de badgeuse.
Ces équipements fonctionnent souvent parfaitement pour leur usage principal. Les remplacer uniquement pour une histoire de protocole réseau serait absurde, surtout quand il s'agit d'un automate qui pilote une chaîne de production.
La réponse consiste à les isoler dans un segment réseau dédié, en IPv4 privé, avec une passerelle qui assure le lien vers le reste. C'est une architecture parfaitement viable, qui présente en plus l'avantage de limiter les risques de sécurité liés à des micrologiciels qui ne reçoivent plus aucune mise à jour.
Hiérarchiser les risques : criticité métier contre effort technique
Une fois l'inventaire fait, ne cédez pas à la tentation de tout traiter en même temps.
Classez selon deux axes. La criticité métier d'abord : que se passe-t-il si ce service tombe ? Perte de chiffre d'affaires immédiate, gêne interne, ou simple inconfort ? L'effort technique ensuite : quelques minutes de configuration, une journée d'intervention, ou un projet de remplacement complet ?
Traitez en priorité ce qui est critique et facile. C'est souvent le cas de la messagerie : quelques enregistrements DNS à corriger, un impact majeur sur l'activité. Rentabilité immédiate.
Programmez ensuite ce qui est critique et lourd, en y consacrant un vrai budget. Et acceptez de laisser en l'état ce qui est peu critique et coûteux à migrer. Un vieux serveur d'archives interne peut très bien rester en IPv4 encore quelques années. Ce n'est pas de la négligence, c'est de la gestion de priorités.
Plan de migration en six étapes pour une PME ou une TPE
Étape 1 : obtenir la connectivité IPv6 auprès de votre opérateur et de votre hébergeur
Point de départ obligatoire : sans connectivité, pas de migration.
Côté opérateur, la plupart des offres fibre professionnelles proposent l'IPv6, parfois désactivé par défaut dans la configuration de la box. Un appel au support ou une case à cocher dans l'interface suffit généralement. Demandez la taille du préfixe attribué : un /56 vous permet de découper votre réseau en plusieurs segments, un /64 vous limite à un seul. Ça compte si vous avez plusieurs VLAN.
Côté hébergeur, vérifiez que votre offre inclut une adresse IPv6, ou demandez son activation. C'est gratuit chez la plupart des acteurs, l'abondance d'adresses ne justifiant aucune facturation.
Si votre opérateur ne propose rien, sur une ligne ancienne par exemple, la question du renouvellement de contrat mérite d'être posée. Le marché a évolué, et rester sur une offre sans IPv6 en 2026 revient à accumuler de la dette technique.
Étape 2 : activer la double pile sur un périmètre de test
Ne touchez pas à la production. Jamais en premier.
Choisissez un périmètre sans enjeu : un serveur de préproduction, un site secondaire, quelques postes de travail volontaires. Activez l'IPv6 dessus et observez pendant une à deux semaines.
Ce que vous surveillez : les temps de réponse, les journaux d'erreur, le comportement des applications, l'accès aux services externes. Vous cherchez les anomalies discrètes, pas les pannes franches. Une page qui met huit secondes au lieu d'une, une API qui échoue une fois sur vingt, un formulaire qui ne valide plus.
Cette phase paraît lente quand tout va bien. Elle vous évite des semaines de galère quand quelque chose cloche. Et il y a presque toujours quelque chose qui cloche : la question est de savoir si vous le découvrez sur un serveur de test ou sur votre boutique un vendredi soir.
Étape 3 : publier les enregistrements AAAA et surveiller le trafic
Le moment de vérité. À partir de la publication d'un enregistrement AAAA, une partie de vos visiteurs empruntera l'IPv6.
Procédez avec méthode. Abaissez d'abord la durée de vie de vos enregistrements DNS à cinq minutes, quelques jours avant. Ce détail vous permettra de revenir en arrière rapidement si nécessaire, sans attendre l'expiration des caches.
Publiez ensuite l'AAAA d'un sous-domaine secondaire, vérifiez que tout répond correctement, puis passez au domaine principal.
Surveillez pendant quarante-huit heures : taux d'erreur du serveur, trafic dans vos statistiques, exploration dans la Search Console, retours des utilisateurs. Une chute brutale du trafic est le signal d'alarme à ne pas manquer. Elle signifie qu'une catégorie de visiteurs n'accède plus au site.
Remontez la durée de vie DNS une fois la situation stabilisée.
Étape 4 : sécuriser la messagerie avant d'ouvrir le flux sortant
Traitons la messagerie séparément, avec un soin particulier. On l'a dit : c'est le domaine le moins pardonnant.
Avant tout envoi en IPv6, vérifiez cette liste. Le reverse DNS est configuré et cohérent dans les deux sens. Le SPF inclut un mécanisme ip6 couvrant vos adresses d'envoi. DKIM signe correctement les messages émis en IPv6. DMARC est en place, avec des rapports qui arrivent dans une boîte réellement consultée.
Testez ensuite en conditions réelles : envoyez vers Gmail, Outlook, Yahoo et un fournisseur professionnel type Office 365. Lisez les en-têtes des messages reçus, ils contiennent le verdict de chaque contrôle.
Si un seul élément coince, n'activez pas l'envoi en IPv6. Restez en IPv4 pour le flux sortant, ce qui est parfaitement supporté et le restera longtemps. La réception en IPv6 pose bien moins de problèmes et peut être activée indépendamment.
Il n'y a aucune honte à laisser sa messagerie sortante en IPv4. Il y a en revanche un vrai risque à la basculer sans avoir fait ces vérifications.
Étape 5 : adapter la supervision, les sauvegardes et la documentation
Une migration n'est pas terminée quand ça marche. Elle est terminée quand vous savez que ça marche, et quand la personne qui vous remplacera le comprendra.
Votre supervision doit contrôler les deux protocoles. Un service qui répond en IPv4 mais pas en IPv6 doit déclencher une alerte, pas passer inaperçu. Beaucoup d'outils de monitoring testent uniquement le protocole par défaut et laissent l'autre dans l'ombre.
Vos sauvegardes doivent être vérifiées : si elles transitent par un serveur distant, l'accès fonctionne-t-il toujours ? Une sauvegarde silencieusement interrompue est un classique dont on ne s'aperçoit qu'au moment d'en avoir besoin.
Et documentez. Le plan d'adressage, les préfixes attribués, les correspondances entre équipements et adresses, les règles de pare-feu. Une adresse IPv6 ne se retient pas de tête, contrairement à une IPv4. Sans documentation, votre infrastructure devient opaque en six mois.
Étape 6 : maintenir les deux protocoles dans la durée sans doubler la charge
La double pile va durer des années. Il faut donc qu'elle soit tenable au quotidien.
Le principe directeur : automatiser et centraliser. Si vos règles de pare-feu sont gérées par un outil de configuration automatisée, elles se déclineront sur les deux protocoles sans effort supplémentaire. Si vous les saisissez à la main sur chaque équipement, vous doublez effectivement la charge et vous oublierez la moitié des cas.
Intégrez la vérification IPv6 dans vos routines existantes. Chaque nouveau service déployé doit être testé sur les deux protocoles, au même titre qu'on vérifie qu'il répond en HTTPS. Ce n'est pas une tâche en plus, c'est une case en plus dans une liste qui existe déjà.
Et prévoyez une revue annuelle : quels équipements peuvent désormais passer en IPv6 seul, lesquels ont été remplacés, où en est la compatibilité de vos prestataires. L'objectif à long terme reste de sortir de l'IPv4, mais personne ne vous demande de le faire cette année.
Budget, délais et compétences : à quoi s'attendre concrètement
Parlons chiffres, avec les précautions d'usage.
Pour une TPE avec un site vitrine et une messagerie chez un prestataire, la migration se limite souvent à quelques vérifications et corrections DNS. Comptez une demi-journée à une journée d'intervention. Le coût est marginal.
Pour une PME avec un site marchand, des applications métier et du télétravail, le chantier s'étale sur deux à quatre mois en mode progressif, avec un effort concentré sur quelques journées d'intervention. Le poste principal reste l'audit et les tests, pas la configuration elle-même.
Pour une structure industrielle avec des automates et des systèmes de supervision, le sujet devient un vrai projet, potentiellement couplé à un renouvellement de matériel. Là, il faut budgéter sérieusement et impliquer les équipes de production.
Sur les compétences : votre prestataire habituel sait probablement faire, même s'il n'a jamais eu à le faire. Les concepts sont proches de ce qu'il maîtrise déjà. La vraie question à lui poser n'est pas « savez-vous faire », mais « l'avez-vous déjà fait, et sur quel type d'infrastructure ».
Le rôle du prestataire digital dans cette transition
Ce qui relève de l'opérateur, de l'hébergeur et de l'agence : clarifier les responsabilités
Le grand classique du dossier : chacun renvoie la balle au voisin, et l'entreprise attend.
Votre opérateur télécom est responsable de la connectivité IPv6 de vos sites physiques, du préfixe attribué et de la configuration de l'équipement terminal qu'il fournit. Il n'est pas responsable de votre réseau interne.
Votre hébergeur est responsable de la disponibilité de l'IPv6 sur ses serveurs, de la délégation du reverse DNS et de la compatibilité de son interface de gestion. Il ne configure pas vos enregistrements DNS à votre place, sauf contrat spécifique.
Votre agence ou votre infogérant est responsable de la configuration applicative, des enregistrements DNS, du pare-feu, de la messagerie et des tests. C'est elle qui doit détenir la vision d'ensemble.
Écrivez cette répartition noir sur blanc, et faites-la valider par chacun. Ça paraît bureaucratique. Ça vous fera gagner un temps considérable le jour où quelque chose ne fonctionne pas et que trois interlocuteurs se regardent en chiens de faïence.
Les clauses à intégrer dans vos contrats de maintenance et d'infogérance
Quelques formulations à glisser dans vos prochains contrats ou avenants.
Une obligation de maintien de la double pile sur l'ensemble des services couverts, avec un contrôle périodique documenté. Une obligation de test des deux protocoles avant toute mise en production, mentionnée explicitement dans la procédure de recette. Un engagement sur la conformité de la messagerie : reverse DNS, SPF incluant ip6, DKIM, DMARC. Une obligation d'information préalable en cas de changement d'adressage, avec un délai raisonnable.
Ajoutez aussi une clause de documentation : le plan d'adressage et les configurations doivent vous être remis et tenus à jour. C'est votre propriété, et c'est ce qui vous permettra de changer de prestataire un jour sans repartir de zéro.
Ces clauses ne coûtent rien à négocier au moment de la signature. Elles deviennent impossibles à obtenir une fois le contrat en cours.
Comment évaluer la maturité IPv6 d'un prestataire avant de signer
Quelques tests simples, à faire avant même le premier rendez-vous.
Le site du prestataire est-il accessible en IPv6 ? Vérifiez la présence d'un enregistrement AAAA sur son domaine. Un spécialiste du numérique qui n'a pas activé l'IPv6 sur sa propre vitrine, c'est un signal.
Sa messagerie est-elle correctement configurée ? Testez son domaine avec un outil d'analyse. S'il n'a ni DMARC ni DKIM, posez-vous des questions sur les conseils qu'il vous donnera.
En rendez-vous, demandez un exemple concret de migration menée, avec les difficultés rencontrées. Un prestataire expérimenté vous racontera un problème de SPF, une histoire de pare-feu asymétrique, un souci de MTU. Celui qui vous répond « ça se passe toujours bien » n'a probablement jamais fait.
Et méfiez-vous du discours inverse, celui qui dramatise pour vendre un gros projet. Pour la majorité des PME, cette transition reste un chantier modeste et maîtrisé.
Le coût de l'inaction : perte de délivrabilité, visiteurs inaccessibles, dette technique
Que se passe-t-il si vous ne faites rien ? À court terme, honnêtement, pas grand-chose de spectaculaire. C'est justement ce qui rend le sujet facile à repousser.
À moyen terme, les effets s'accumulent. Une part croissante des internautes navigue en IPv6, notamment sur mobile, où la proportion est déjà largement majoritaire chez certains opérateurs. Ces visiteurs passent aujourd'hui par des passerelles de traduction. Chaque couche ajoutée dégrade un peu la performance et multiplie les points de panne.
Sur la messagerie, le durcissement des filtres se poursuit. Ce qui passe encore aujourd'hui pourrait ne plus passer demain.
Et puis il y a la dette technique, la plus insidieuse. Chaque année sans migration, votre infrastructure s'éloigne un peu plus du standard. Les compétences pour maintenir de l'IPv4 pur se raréfient. Les équipements neufs supposent l'IPv6. Le jour où vous devrez basculer en urgence, parce qu'un opérateur aura cessé de fournir de l'IPv4 sur votre offre, le chantier sera bien plus lourd et bien plus cher.
La question n'est pas de savoir s'il faut y aller, mais quand. Et le meilleur moment reste celui où l'on n'y est pas contraint.
Cas concrets rencontrés sur le terrain
Un e-commerce dont les emails transactionnels finissent en spam après un changement d'hébergeur
Une boutique en ligne d'une trentaine de salariés change d'hébergement pour gagner en performance. La migration technique se passe bien, le site est plus rapide, tout le monde est satisfait.
Trois jours plus tard, le service client croule sous les appels. Les clients ne reçoivent plus leurs confirmations de commande. Ni les liens de suivi de colis. Ni les réinitialisations de mot de passe.
L'équipe cherche du côté du module de commande, du serveur d'envoi, du contenu des messages. Deux jours perdus. Le diagnostic arrive enfin : le nouvel hébergeur a activé l'IPv6 par défaut, le serveur émet donc en IPv6, et l'enregistrement SPF ne contenait qu'un mécanisme ip4. Contrôle échoué, politique DMARC en reject, messages rejetés par Gmail.
La correction a pris cinq minutes. Le manque à gagner sur ces cinq jours, avec les commandes abandonnées et les clients mécontents, se chiffrait en milliers d'euros. Sans compter la réputation d'expéditeur à reconstruire ensuite.
Une PME industrielle privée d'accès à son automate après un passage en CGNAT
Une entreprise de mécanique de précision, une cinquantaine de personnes. Le fabricant de sa machine à commande numérique intervient à distance pour les diagnostics et les mises à jour, via une redirection de port depuis l'adresse publique fixe du site.
Renouvellement du contrat internet, nouvelle offre plus avantageuse, nouvelle box. Trois semaines plus tard, un dysfonctionnement sur la machine. Le fabricant tente de se connecter. Impossible.
L'opérateur avait basculé l'entreprise en CGNAT, sans mention particulière autre qu'une ligne dans les conditions de la nouvelle offre. Il n'y avait plus d'adresse publique dédiée, donc plus de redirection possible.
Résultat : un déplacement du technicien depuis l'autre bout de la France, deux jours d'arrêt partiel de production, et une facture d'intervention sans commune mesure avec le prix de l'option adresse fixe qu'il aurait fallu souscrire.
La solution définitive a consisté à reprendre une adresse IPv4 publique, et à préparer en parallèle un accès via IPv6 pour la suite.
Un site vitrine invisible pour une partie des visiteurs mobiles
Un cabinet de conseil régional constate une baisse progressive des demandes de contact. Rien de brutal, une érosion sur plusieurs mois. Le positionnement dans les résultats de recherche reste correct, les impressions ne bougent pas. Mais les clics baissent, et le taux de rebond mobile grimpe de manière suspecte.
L'analyse révèle un enregistrement AAAA publié un an plus tôt, lors d'une opération de maintenance, et pointant vers une adresse qui n'avait jamais été configurée sur le serveur. Une erreur de copier-coller, jamais détectée.
Pourquoi personne n'avait rien vu ? Parce que les navigateurs de bureau, grâce au Happy Eyeballs, basculaient silencieusement sur IPv4 après un court délai. Le site s'affichait, avec juste une seconde de retard que personne ne remarquait. Sur mobile, en revanche, sur certains réseaux privilégiant fortement l'IPv6, l'attente était suffisante pour que les visiteurs abandonnent.
La suppression de l'enregistrement erroné a suffi. Le trafic est revenu en quelques semaines. Un an d'affaires perdues pour une ligne de configuration fautive.
Ce que ces situations ont en commun : un défaut d'anticipation, jamais un défaut de technologie
Reprenons ces trois cas. Dans aucun, l'IPv6 n'est en cause. Le protocole a fonctionné exactement comme prévu.
Ce qui a manqué, c'est autre chose. Une vérification du SPF au moment d'un changement d'hébergeur. Une lecture attentive des conditions d'une nouvelle offre télécom. Un test après une modification DNS.
Trois moments où quelqu'un aurait pu consacrer dix minutes à contrôler, et où personne ne l'a fait. Non par incompétence, mais parce que le sujet n'était identifié nulle part comme un point de vigilance.
C'est précisément l'intérêt d'anticiper. Non pas pour éviter une technologie, mais pour savoir où regarder quand elle arrive. La transition IPv6 n'est pas un risque en soi. Elle révèle simplement les fragilités déjà présentes dans une infrastructure.
Réponses aux questions les plus fréquentes
Mon site est-il obligé de passer en IPv6 en 2026 ?
Aucune obligation légale ne pèse sur les entreprises privées. Un site accessible uniquement en IPv4 fonctionne encore parfaitement pour la quasi-totalité des visiteurs, grâce aux mécanismes de traduction déployés par les opérateurs.
Les administrations publiques, elles, sont soumises à des recommandations plus contraignantes, et cette exigence se répercute progressivement sur leurs prestataires.
Ceci dit, la vraie question n'est pas celle de l'obligation. C'est celle de la qualité de service. Chaque couche de traduction ajoute de la latence et un point de défaillance potentiel. Passer en double pile est simple, peu coûteux, et vous rend indépendant de ces mécanismes.
Vais-je perdre mes positions Google en activant l'IPv6 ?
Non, pas du fait de l'IPv6 lui-même. Google explore les deux protocoles sans distinction et n'applique aucun bonus ni aucune pénalité.
En revanche, vous perdrez des positions si vous publiez un enregistrement AAAA vers un serveur qui ne répond pas correctement. Le robot rencontrera des erreurs, réduira sa fréquence d'exploration, et les conséquences suivront.
La règle est donc simple : vérifiez avant de publier, surveillez après. Et si vous constatez la moindre anomalie, retirez l'enregistrement AAAA le temps de corriger. C'est réversible en quelques minutes si vous avez pensé à abaisser la durée de vie DNS au préalable.
Puis-je conserver une IPv4 fixe et à quel prix ?
Oui, dans la plupart des cas. Les opérateurs professionnels proposent des adresses IPv4 fixes, généralement en option payante ou incluses dans les offres haut de gamme. Comptez de quelques euros à quelques dizaines d'euros par mois selon l'opérateur et le type d'accès.
Côté hébergement, la tendance est à la facturation à l'unité, avec des ordres de grandeur de quelques euros mensuels par adresse.
Attendez-vous à ce que ces tarifs progressent. La rareté ne va pas se résorber, et les fournisseurs répercutent leurs propres coûts d'acquisition. Conserver de l'IPv4 restera possible longtemps, mais de moins en moins bon marché.
Mon vieux logiciel métier va-t-il cesser de fonctionner ?
Probablement pas, à condition de ne rien précipiter. En double pile, l'IPv4 continue de fonctionner exactement comme avant. Un logiciel qui ne connaît que ce protocole poursuivra son activité sans rien remarquer.
Les difficultés surviennent uniquement si vous supprimez l'IPv4, ce que personne ne vous demande de faire aujourd'hui, ou si votre opérateur vous bascule en CGNAT et que votre logiciel a besoin d'être joignable depuis l'extérieur.
Si vous exploitez une application ancienne et critique, la bonne approche consiste à l'isoler dans un segment réseau IPv4 dédié, avec une passerelle. Vous gagnez du temps sans remettre en cause son fonctionnement, et vous améliorez au passage son cloisonnement de sécurité.
Combien de temps l'IPv4 restera-t-il utilisable ?
Personne ne peut donner de date, et il faut se méfier de ceux qui prétendent le contraire.
Ce qu'on peut affirmer avec une certaine confiance : l'IPv4 restera utilisable pendant au moins une dizaine d'années. Trop d'infrastructures en dépendent pour qu'une extinction brutale soit envisageable.
Ce qui va changer, en revanche, c'est le coût et la qualité. L'IPv4 deviendra progressivement une option premium, avec des adresses de plus en plus chères et un trafic de plus en plus souvent traduit, donc dégradé. Les nouveaux services seront pensés IPv6 d'abord, l'IPv4 devenant la compatibilité héritée.
La transition ressemblera moins à une bascule qu'à une lente évolution des rapports de force. Ce qui laisse tout le temps de s'organiser, à condition de commencer.
Ce qu'il faut retenir et par où commencer dès cette semaine
Résumons l'essentiel, sans jargon.
Les adresses IPv4 sont épuisées depuis 2019 en Europe. L'IPv6 les remplace. Cette transition ne présente aucun danger en soi, mais elle révèle les fragilités existantes dans votre infrastructure, principalement sur la messagerie, le filtrage par adresse et l'accès distant.
Les trois points de vigilance prioritaires, dans cet ordre. Votre messagerie, parce qu'un SPF incomplet ou un reverse DNS absent bloque vos emails du jour au lendemain. Votre pare-feu, parce que des règles IPv4 impeccables ne protègent absolument rien en IPv6. Vos accès distants, parce que le CGNAT peut vous couper de vos équipements sans préavis.
Concrètement, que faire cette semaine ? Trois actions, chacune réalisable en moins d'une heure.
Testez votre domaine avec un outil d'analyse en ligne gratuit. En cinq minutes vous saurez où vous en êtes sur l'IPv6, le DNS et la messagerie. Vérifiez votre enregistrement SPF et ajoutez-y un mécanisme ip6 si votre serveur d'envoi dispose d'une adresse IPv6. Appelez votre opérateur et posez deux questions : mon accès est-il en CGNAT, et l'IPv6 est-il activé sur ma ligne ?
Ces trois gestes ne coûtent rien et écartent d'emblée les scénarios les plus douloureux. Le reste peut se planifier tranquillement, sur plusieurs mois, en fonction de vos priorités et de votre budget.
Une dernière remarque, pour finir. Les entreprises qui traversent cette transition sans encombre ne sont pas celles qui disposent des meilleurs moyens techniques. Ce sont celles qui ont pris une demi-journée pour faire l'inventaire et poser les bonnes questions à leurs prestataires. Le reste suit naturellement.
