Nous sommes en 2026. Le protocole IPv6 existe depuis 1998. C’est un standard RFC depuis plus d’un quart de siècle. Tout système d’exploitation moderne le prend en charge. Tout composant réseau moderne sait le gérer. Tout manuel, tout cours, toute certification le couvre. Et pourtant des millions de personnes naviguent encore exclusivement en IPv4 — non parce qu’elles le veulent, mais parce que d’autres l’ont négligé.

Ce n’est plus seulement une lacune technique. C’est une gêne.

La honte conspicue

Commençons par l’évidence. GitHub — la plus grande plateforme de développement logiciel au monde, propriété de Microsoft, l’une des entreprises technologiques les plus riches de la planète — ne prend pas en charge IPv6. Pas un seul octet. Quiconque a une connexion IPv6-only ne peut atteindre GitHub. Pas de dépôts, pas de tickets, pas de pull requests, pas de documentation. Microsoft achète GitHub pour 7,5 milliards de dollars, mais déployer IPv6 — apparemment cela dépasse ses moyens.

Reddit, qui se présente comme la Front Page of the Internet, ne prend pas non plus en charge IPv6. Une plateforme se targuant d’être la page d’accueil d’Internet ne maîtrise pas le protocole fondamental d’Internet.

La liste continue. Docker Hub. Cloudflare Workers (partiellement). De nombreux fournisseurs SaaS. La liste des entreprises qui échouent complètement sur ce sujet de base est longue. Et elle est gênante.

Un quart de siècle d’ignorance

IPv6 n’est pas une nouveauté. Ce n’est pas une technique expérimentale. Ce n’est même pas controversé. Les adresses IPv4 sont épuisées depuis 2011 — l’IANA a attribué les derniers blocs libres. Depuis lors, Internet ne grandit que parce que NAT, carrier-grade NAT et autres béquilles torturent le réseau IPv4 au-delà de sa conception.

IPv6 résout ce problème. Le résout depuis 1998. L’espace d’adressage est si vaste que chaque personne, chaque appareil et chaque grille-pain pourrait avoir sa propre adresse — sans épuiser le stock. Il simplifie l’architecture réseau, élimine les bidouilles NAT, améliore la connectivité de bout en bout, réduit la latence dans les réseaux mobiles, permet une véritable communication pair-à-pair.

Et pourtant, en 2026, nous débattrons encore de l’adoption. Comme s’il s’agissait d’une extension facultative. Comme d’un bonus agréable.

C’est un impératif. Qui ne l’a pas n’a rien compris.

Dual Stack : l’état permanent que personne ne veut

Parce que certains ne suivent pas, tous les autres doivent faire du Dual Stack. Dual Stack — fonctionnement parallèle d’IPv4 et d’IPv6 — était conçu comme une transition. Un pont qu’on traverse puis qu’on démolit. Au lieu de cela, on a bâti sur le pont, construit des maisons dessus, et on l’appelle désormais chez-soi.

Dual Stack signifie un effort doublé. Dans chaque dimension.

Règles de pare-feu. Chaque règle existante pour IPv4 nécessite un pendant pour IPv6. Et les règles IPv6 ne sont pas des copies — ICMPv6 est critique pour le fonctionnement, la découverte de voisins requiert un traitement spécial, les en-têtes d’extension exigent leur propre logique de filtrage. Qui configure des pare-feu IPv6 comme des pare-feu IPv4 se retrouve avec soit des trous, soit des connexions cassées.

Bindings de services. Chaque service doit écouter sur les deux protocoles. Serveurs web, serveurs de messagerie, bases de données, courtiers de messages, agents de supervision. Certains logiciels le font automatiquement. D’autres non. Certains le prétendent et ne le font pas.

Connexions VPN. IPSec, WireGuard, OpenVPN — tous prennent en charge IPv6. Mais les configurations de tunnel ne transportant que l’IPv4 sont endémiques. Qui monte un tunnel VPN ne routant que l’IPv4 a divisé son réseau en deux sans s’en apercevoir.

Résolution DNS. Les enregistrements AAAA existent depuis 1999. Néanmoins il existe des hébergeurs qui ne les proposent pas. Des API de registraires qui ne les gèrent pas. Des configurations CDN qui les ignorent. Le DNS est l’annuaire d’Internet — et un annuaire qui ne connaît que la moitié des numéros est cassé.

Débogage. Un timeout de connexion en Dual Stack peut avoir dix causes différentes. Est-ce un problème IPv4 ? Un problème IPv6 ? Une condition de course Happy Eyeballs où le client essaie IPv6 d’abord, échoue, puis tente IPv4 — mais si lentement que le timeout se déclenche ? Qui a déjà diagnostiqué une panne IPv6 intermittente dans un réseau hybride sait combien de temps de vie s’y perd.

Conformité et certification. Les audits doivent examiner les deux protocoles. Les tests de pénétration doivent attaquer les deux protocoles. La documentation doit couvrir les deux protocoles. Les certifications ne testant que l’IPv4 sont sans valeur — et constituent malheureusement encore la norme.

Si moins de gens circulaient avec des œillères, nous aurions pu achever la migration depuis longtemps et passer à un fonctionnement IPv6-only. Au lieu de cela, administrateurs et équipes réseau devront probablement trimballer cette merde de Dual Stack encore cinq à dix ans. Cinq à dix ans d’efforts doublés, de sources d’erreur doublées, de complexité doublée. Parce que certains ont jugé cela superflu.

L’exemple T-Online

Le centre hospitalier universitaire de la RWTH Aachen propose un Wi-Fi gratuit. Fourni via T-Online. Accès à Internet : IPv4 uniquement. Pas d’IPv6.

C’est plus que gênant. C’est un fleuron allemand — Deutsche Telekom, qui se pose en pionnier technologique, investit des milliards dans l’infrastructure, fanfaronne dans ses campagnes publicitaires avec des réseaux gigabit et la 5G — et n’arrive pas à proposer IPv6 dans sa solution Wi-Fi. Dans une université. Dans un hôpital. Dans une institution qui fait de la recherche, enseigne, soigne. IPv4 uniquement. En 2026.

Que dire ? La même chose que toujours : ce n’est pas la technique qui manque. C’est la volonté. Telekom sait faire IPv6. Elle le déploie sur les connexions fixes. Elle en a l’infrastructure. Mais à cet endroit, dans cette solution, quelqu’un décide que ce n’est pas nécessaire. Que ce qui existe suffit. Que personne ne remarquera que la moitié d’Internet manque.

Mais on le remarque. Chacun le remarque, qui a une connexion moderne et constate soudain que des pages ne chargent pas, que des applications ne se connectent pas, que des services sont injoignables — parce que le client veut IPv6, le réseau n’en offre pas, et le repli vers IPv4 est si lent que les timeouts se déclenchent.

Dans un article récemment publié — Tout ou rien — il était question d’entreprises qui travaillent à moitié. Qui étiquettent joliment les tas d’ordures. Qui prétendent fournir une prestation tandis qu’elles encaissent. T-Online, en l’occurrence, fournit l’illustration gratuitement : si tu ne sais pas faire IPv6, alors mieux vaut ne rien faire du tout — mais arrête de t’appeler fournisseur.

La conséquence

Il est temps d’arrêter d’édulcorer le sujet.

Un fournisseur qui n’offre pas IPv6 ou l’implémente insuffisamment devrait perdre le droit de s’appeler fournisseur, point. Qui ne maîtrise pas le protocole fondamental d’Internet n’est pas un fournisseur. C’est une relique IPv4 en route vers l’irrévélation à échéance prévisible.

Qui met sur le marché un appareil capable de réseau non pleinement compatible IPv6 ne devrait pas recevoir d’agrément pour le marché européen. Point. Pas d’exceptions, pas de réglements transitoires, pas de clause de droits acquis. Qui vend encore des appareils sans IPv6 en 2026 vend de la marchandise défectueuse.

Qui doute d’IPv6 n’a rien compris. Ni la technique, ni la nécessité, ni la responsabilité. IPv6 n’est pas une guerre de religion. C’est un standard. Qui doute des standards parce qu’ils sont inconfortables n’a pas sa place dans une industrie bâtie sur des standards.

Qui échoue appartient au pilori. Pas derrière portes closes, pas dans des post-mortems internes, mais publiquement. Parce que la gêne publique est la seule langue que certaines entreprises comprennent.

Ce que libcom.de signifie

libcom.de planifie, construit et exploite des réseaux — depuis plus de deux décennies. IPv6 n’y est pas un projet qu’on introduit. C’est un prérequis qu’on présuppose.

Qui vient à moi obtient une réponse honnête : Avez-vous IPv6 ? Si non, pourquoi ? Si oui, totalement ou partiellement ? Vos services sont-ils Dual Stack ou IPv4-only ? Vos enregistrements DNS sont-ils complets ? Vos règles de pare-feu sont-elles symétriques ? Vos tunnels VPN sont-ils compatibles IPv6 ?

La réponse à ces questions n’est pas académique. Elle décide si votre infrastructure est pérenne ou si elle succombera dans cinq ans à une migration qui aurait dû avoir lieu depuis longtemps.

Si vous vous demandez si votre informatique est compatible IPv6 — véritablement compatible, pas théoriquement —, ou si vous cherchez quelqu’un qui le pense honnêtement : écrivez à contact@libcom.de. Nous faisons un inventaire honnête. Sans pression commerciale. Avec le regard sur ce qui dure à long terme.

IPv6 n’est pas optionnel. Qui le traite encore comme optionnel est le problème.