Quand un navigateur affiche « serveur DNS ne répond pas », la connexion tombe sans prévenir et tout le monde accuse la box internet. Dans la plupart des cas, la panne vient pourtant d’un enchaînement de petits détails mal réglés entre le poste Windows, la console PS5 et le routeur de l’opérateur. Blocage sur le port 53, cache DNS incohérent, serveur mal renseigné dans la configuration IP, ou encore liste de suffixes interminable, les scénarios reviennent souvent et se diagnostiquent assez vite dès que l’on sait où regarder.
Ce texte part des situations concrètes que rencontrent les équipes IT et les familles connectées : un PC qui ping l’adresse IP d’un site mais échoue sur son nom, une PS5 connexion instable sur le PSN, une box qui semble tout faire correctement alors que les requêtes de résolution DNS expirent en silence. L’idée est de démêler ce qui relève du client, du réseau local ou du serveur DNS lui-même, et de proposer des gestes de dépannage DNS reproductibles. Certains s’effectuent en quelques clics dans l’interface de la box, d’autres nécessitent un captureur de paquets ou un PowerShell ouvert, mais tous visent le même résultat : retrouver des temps de réponse cohérents, idéalement sous la seconde, et une navigation qui ne décroche plus.
En bref
- Tester d’abord la différence entre accès par IP et par nom de domaine pour confirmer une erreur DNS avant de toucher à la box internet.
- Contrôler systématiquement la configuration IP locale : serveur DNS renseigné, passerelle, IPv4/IPv6, fichiers Hosts et profils réseau Windows.
- Neutraliser les blocages sur le port UDP/TCP 53, que ce soit dans le pare-feu Windows, un antivirus zélé ou une politique de filtrage sur le routeur.
- Basculer temporairement sur des résolveurs publics fiables (Quad9, Cloudflare, Google DNS) pour isoler un défaut de la box ou du serveur de l’opérateur.
- Sur PS5 et équipements domestiques, fixer manuellement des DNS stables et contrôler le Wi-Fi plutôt que de tout attribuer au PSN ou à la fibre.
Erreur « le serveur DNS ne répond pas » sur Windows : diagnostic terrain précis
Sur Windows 10 ou 11, la mention « serveur DNS ne répond pas » résulte rarement d’un bug mystérieux du système. Dans la majorité des audits réseau réalisés en PME, ce message vient d’un enchaînement prévisible : un client envoie une requête de résolution DNS, n’obtient jamais de réponse exploitable, puis laisse expirer la tentative. Le bon réflexe consiste donc à vérifier si le problème touche uniquement les noms de domaine ou aussi les adresses IP directes.
Le test le plus simple reste de lancer un ping vers une IP publique, par exemple un routeur d’opérateur ou un serveur de test. Si le ping répond en IP mais échoue avec un nom comme « ping www.example.com », la piste « résolution DNS » se confirme. Sur un poste d’admin, la commande PowerShell Resolve-DnsName affine encore le diagnostic en retournant soit une adresse, soit un message d’expiration qui reflète exactement ce que rapporte le navigateur.
Chez plusieurs clients, un point revient souvent : un pare-feu qui filtre discrètement les ports 53 en sortie. Il suffit parfois d’une règle héritée d’un ancien antivirus ou d’un test de sécurité oublié pour bloquer tout trafic DNS UDP. Une capture Wireshark ou un équivalent comme tcpdump sous Windows montre alors des clients silencieux, sans aucune requête vers le serveur DNS attendu. Tant qu’aucun paquet ne sort, inutile d’accuser le résolveur côté serveur.
Autre cas récurrent, plus subtil : une entrée obsolète dans le fichier Hosts de Windows. Un nom de domaine peut y être associé à une adresse interne depuis des années et court-circuiter le serveur DNS pour ce seul nom. Les utilisateurs voient alors une partie du web fonctionner et un site stratégique tomber « sans raison ». Comme le service client DNS interroge d’abord son cache, puis le fichier Hosts avant d’aller vers le serveur DNS, la capture réseau reste muette. L’édition de ce fichier dans C:WindowsSystem32driversetc suffit souvent à lever le blocage.
Le scénario le plus fréquent côté configuration IP reste pourtant plus basique : le poste pointe vers un serveur DNS inexistant ou inaccessible. Un simple ipconfig /all dévoile la situation, avec une adresse de serveur résolvant située sur un sous-réseau qui n’est plus routé, ou une vieille IP de contrôleur de domaine décommissionné. Les logs Wireshark montrent alors des requêtes répétées vers cette IP fantôme, sans la moindre réponse, jusqu’à l’expiration de la requête.
Pour compléter l’analyse, un poste Windows avec plusieurs serveurs DNS configurés peut générer des délais agaçants. Le client essaie successivement plusieurs adresses, parfois injoignables, avant de tomber sur le bon résolveur. Sur le papier, cela assure la résilience ; dans la pratique, certains logiciels qui attendent une réponse rapide voient leur délai d’attente expirer avant que le bon serveur n’ait répondu. Là encore, une capture filtrée sur le nom de domaine incriminé montre une séquence de requêtes espacées de plusieurs secondes.
En pratique, corriger ces erreurs Windows DNS repose sur une poignée de gestes simples : nettoyer la liste des serveurs pour n’y laisser que ceux réellement accessibles, vérifier les politiques de pare-feu locales, et inspecter les fichiers Hosts. Une règle utile consiste à mesurer le temps de réponse d’un Resolve-DnsName avec Measure-Command et à considérer qu’au-delà de 1 000 millisecondes, le confort utilisateur commence à se dégrader.
Cache DNS, suffixes et petits détails qui plombent la résolution de noms
Dès que les principaux problèmes réseau sont éliminés, il reste toute une série de détails locaux qui suffisent à provoquer une erreur DNS intermittente. Le cache DNS du poste, par exemple, peut défendre une vision complètement périmée d’un nom de domaine. Une migration d’hébergement qui modifie les enregistrements A ou AAAA, couplée à un TTL long, laisse parfois des PC coincés vers l’ancienne IP pendant que les autres postes naviguent sans souci.
Sur Windows, un simple ipconfig /flushdns permet de repartir à zéro. Sur certains serveurs d’applications ou sur des postes techniques, l’ajout de scripts réguliers de purge de cache s’avère pertinent lors d’une phase de transition. Là où cela choque parfois, c’est que les mêmes symptômes surviennent sur un site web en HTTPS pourtant bien sécurisé via certificat : l’utilisateur accuse alors la couche TLS, alors que la racine du problème reste la résolution DNS initiale.
La gestion des suffixes de recherche DNS joue aussi un rôle, surtout sur les postes intégrés à des domaines d’entreprise. Une liste interminable de suffixes comme « microsoft.com », « azure.com », différents domaines locaux et celui réellement utilisé entraîne une cascade de requêtes pour un même nom court. Chaque tentative ajoute quelques dizaines de millisecondes, voire plus si certains domaines ne répondent pas. Sur des applications sensibles à la latence, ces délais s’additionnent et déclenchent des erreurs.
Un exemple concret : un utilisateur saisit simplement « internal » dans un outil web interne. Le client DNS construit successivement internal.microsoft.com, internal.ms.com, internal.contoso.local, puis enfin internal.contoso.com, qui correspond réellement au service visé. La capture de paquets montre une frise dense de requêtes, et le temps total dépasse largement ce qui est attendu pour une simple résolution locale. Remonter le bon suffixe en haut de la liste réduit immédiatement la latence.
Dans les environnements où la sécurité réseau est poussée, le pare-feu Windows combiné à un agent EDR peut aussi réécrire silencieusement la manière dont les requêtes DNS sortent. Les logs des produits de sécurité affichent parfois des « DNS sinkhole » ou des redirections vers des serveurs internes de filtrage. Sans visibilité, un administrateur peut croire à un incident côté FAI, alors que la politique interne détourne simplement certaines requêtes. D’où l’intérêt de documenter précisément les services de filtrage DNS employés.
Un autre détail trop souvent négligé touche la coexistence IPv4 / IPv6. Certains serveurs DNS internes renvoient des enregistrements AAAA qui pointent vers des adresses IPv6 non routées sur le réseau local. Le poste client tente alors de se connecter en IPv6, échoue, puis retombe en IPv4 avec retard. Du point de vue de l’utilisateur, le site semble « ne pas répondre de temps en temps ». Ajuster la configuration IP pour n’annoncer que des adresses compatibles avec l’infrastructure réelle évite ces faux positifs.
La morale de ces situations, côté Windows comme côté serveurs, tient en une phrase : un DNS rapide repose sur une configuration simple et cohérente, sans artifice inutile ni listes de suffixes kilométriques.
Serveur DNS et box internet : quand le problème vient du routeur de l’opérateur
Dans les foyers comme dans les petites structures, la box internet sert de routeur, de point d’accès Wi-Fi et surtout de relais DNS. Elle propage aux clients le ou les serveurs DNS de l’opérateur, voire agit en cache récursif. Quand l’erreur « serveur DNS ne répond pas » touche plusieurs appareils à la fois, le soupçon se porte logiquement sur ce maillon.
Les pannes globales des résolveurs d’opérateurs restent assez rares, mais elles existent. Le symptôme typique : toutes les machines du réseau local perdent la résolution des noms, alors que le ping vers l’adresse IP de la box répond encore. Dans ce scénario, passer temporairement les machines critiques sur des DNS publics (1.1.1.1, 9.9.9.9, 8.8.8.8) permet de trancher. Si la navigation repart immédiatement, le cœur du problème se situe bien dans la chaîne DNS de l’opérateur ou dans la box.
Plus fréquents sont les cas où la box filtre elle-même certaines requêtes, par exemple sous l’effet d’un contrôle parental mal configuré. Une liste noire mal gérée peut bloquer des domaines entiers et renvoyer des réponses incohérentes ou des timeouts. En B2B, on rencontre aussi des routeurs qui redirigent tout le trafic DNS vers une appliance de filtrage externe, ce qui complique la chasse aux « erreurs DNS » puisque la configuration côté poste semble correcte.
Pour sécuriser la chaîne, beaucoup fixent dans la box des serveurs DNS tiers jugés plus stables ou plus respectueux de la vie privée. Avant toute modification, il reste utile de documenter la configuration actuelle, de noter les temps de réponse moyens et de surveiller la charge de la ligne. Une stratégie simple consiste à placer un résolveur de l’opérateur en primaire, un résolveur public en secondaire, puis à vérifier, via une capture, que le routeur relaie bien les requêtes vers les deux.
Les problématiques de DNS se croisent souvent avec celles de sécurité web, notamment autour du HTTPS et des certificats. Un domaine mal résolu peut donner l’impression d’un certificat invalide, alors que le souci se trouve en amont. Pour approfondir cet aspect, l’analyse d’un certificat serveur avec OpenSSL, comme présenté dans des guides dédiés à la vérification de certificat TLS (exemple détaillé ici), aide à distinguer ce qui relève du chiffrement de ce qui relève purement de la résolution DNS.
La box se retrouve aussi au centre du jeu lorsqu’on héberge un service à domicile ou dans un atelier, que ce soit un cloud privé, un portail de domotique ou un webmail auto-hébergé. Une IP publique changeante couplée à un DNS dynamique mal actualisé provoque alors des erreurs intermittentes : le nom pointe vers l’ancienne IP pendant quelques minutes ou quelques heures. Du point de vue des utilisateurs, le message « serveur DNS ne répond pas » masque en réalité un simple décalage de mise à jour.
Pour ce type d’architecture légère, beaucoup combinent un DNS dynamique robuste, une redirection de ports propre et un reverse-proxy type Nginx ou équivalent. Des ressources qui détaillent la mise en place de virtual hosts ou de load-balancing DNS côté Nginx (configuration d’hôtes virtuels par exemple) éclairent aussi la manière dont la couche HTTP s’appuie sur la couche DNS, surtout quand plusieurs sous-domaines partagent la même machine.
Dans les faits, chaque fois que plusieurs équipements crient à la panne DNS en même temps, la box mérite une inspection en priorité : serveurs propagés, éventuels caches internes, logs de pare-feu et état du lien vers le FAI. Ce n’est qu’après cette vérification que l’on gagne à incriminer la couche applicative.
Comparatif des causes typiques d’erreur DNS côté box et côté client
Pour clarifier les responsabilités entre poste client et routeur, un tableau synthétique aide souvent les équipes support à orienter les tests. Il ne remplace pas une capture détaillée, mais permet d’évacuer les diagnostics trop vagues.
| Symptôme observé | Probabilité cause côté client | Probabilité cause côté box / FAI | Test rapide recommandé |
|---|---|---|---|
| Un seul PC affiche « serveur DNS ne répond pas » | Forte (cache, pare-feu, DNS mal configuré) | Faible | Tester un autre appareil sur le même réseau |
| Tous les appareils perdent accès par nom, mais ping IP ok | Moyenne | Forte (résolveur FAI ou box) | Configurer un DNS public sur un poste et retester |
| Certains domaines seulement échouent en résolution | Moyenne (fichier Hosts, filtrage local) | Moyenne (filtrage DNS de la box) | Tester le même domaine via 4G pour comparer |
| Latence forte avant chargement des pages | Moyenne (liste de suffixes, plusieurs DNS injoignables) | Moyenne (boîte surchargée, lien saturé) | Mesurer le temps de Resolve-DnsName et la latence ping |
| Erreurs aléatoires sur services auto-hébergés | Faible | Forte (DNS dynamique, redirection de ports) | Suivre la mise à jour de l’IP publique et du DNS dynamique |
Ce genre de matrice évite de passer des heures sur le mauvais maillon et structure le dépannage DNS autour de quelques tests ciblés.
PS5 connexion et DNS : stabiliser le jeu en ligne et les services PSN
Sur console, l’erreur DNS se manifeste rarement sous la forme d’un message très technique. La PS5 affiche plutôt un code d’erreur réseau, une impossibilité de se connecter au PSN ou un échec ponctuel de téléchargement. Pourtant, quand un test de connexion depuis le menu système montre une adresse IP attribuée mais un échec à la résolution de noms, le diagnostic rejoint celui d’un PC classique.
Dans de nombreux foyers, la PS5 connexion au Wi-Fi se configure en automatique, en laissant la box distribuer les paramètres réseau. Tant que le serveur DNS annoncé par le routeur répond vite, l’utilisateur ne voit pas la différence. Dès qu’un filtrage est activé sur la box ou que les serveurs DNS de l’opérateur décrochent, les jeux en ligne commencent à perdre leur session et les téléchargements reprennent sans cesse. Les joueurs accusent alors le PSN, alors qu’un simple changement de DNS aurait suffi.
Une méthode robuste consiste à passer la console en configuration manuelle, au moins pour le DNS. L’adresse IP et la passerelle restent fournies par DHCP, mais le menu avancé permet de fixer deux résolveurs publics éprouvés. Test après test, ce réglage réduit l’incidence des caprices de la box internet et isole la console des politiques de filtrage trop agressives du réseau domestique.
Le choix du serveur DNS a aussi un impact discret sur la latence, surtout quand les jeux reposent sur des infrastructures distribuées. Des requêtes DNS plus rapides ne transforment pas une connexion ADSL en fibre, mais elles permettent d’établir plus vite les sessions initiales et de limiter les échecs au moment de rejoindre un lobby ou une partie en mode compétitif. Sur certaines lignes surchargées, ce gain de quelques centaines de millisecondes suffit à la différence entre un échec systématique et une connexion stable.
Dans les environnements partagés où plusieurs consoles, PC et objets connectés se concurrencent, l’approche la plus saine reste d’auditer le réseau domestique comme un petit LAN d’entreprise. Identifier la charge sur le Wi-Fi, vérifier que la box ne change pas de canal toutes les heures, séparer si besoin un réseau invité, puis vérifier comment les requêtes DNS circulent dans tout ça. Les consoles de jeu n’aiment ni les coupures de Wi-Fi, ni les réponses DNS qui varient d’une minute à l’autre.
Une digression intéressante pour les passionnés consiste à comparer la stabilité d’une PS5 sur Wi-Fi, puis sur câble Ethernet, à DNS constant. Les tests montrent souvent que des erreurs attribuées au serveur DNS proviennent en réalité de micro-coupures radio, surtout dans des appartements saturés de réseaux voisins. Une fois la console branchée en filaire, ces erreurs disparaissent et l’on constate que le DNS n’était que le messager mal-aimé d’un réseau radio instable.
En résumé, sur PS5 comme sur tout autre terminal, le DNS reste une brique simple mais exigeante : si la latence est maîtrisée et la configuration claire, la plupart des codes d’erreur mystérieux s’évanouissent.
Problèmes réseau avancés : quand le DNS croise sécurité, IoT et services auto-hébergés
Dès que l’on quitte le cadre du simple surf web pour aller vers l’IoT, la domotique ou l’auto-hébergement, les erreurs de type « serveur DNS ne répond pas » prennent une autre dimension. Un service MQTT qui ne résout plus son broker, un cluster Docker qui ne joint plus son registre privé ou un serveur de mails qui ne trouve plus son relais SMTP, tout cela se manifeste souvent par des timeouts côté applicatif, mais la racine reste un problème de résolution DNS.
Les projets autour de Raspberry Pi illustrent bien cette interconnexion. Un utilisateur configure par exemple un point d’accès Wi-Fi sur Pi 3 pour héberger Home Assistant ou Jeedom, mais oublie de soigner la partie DNS. Les clients se connectent au Wi-Fi, accèdent à l’interface locale, mais échouent dès qu’un composant tente d’atteindre un service externe par nom. Des tutoriels sur la configuration réseau, comme ceux consacrés au Wi-Fi et aux distributions GNU/Linux sur Raspberry (exemple de configuration Wi-Fi sur Pi 3), rappellent d’ailleurs régulièrement cette pièce du puzzle.
Dans un autre registre, les services auto-hébergés comme un cloud privé, une messagerie web ou un reverse-proxy Nginx reposent fortement sur la cohérence DNS. L’adresse publique, les enregistrements de type A/AAAA, les enregistrements MX pour le mail, tout doit pointer proprement vers les bonnes machines. Il suffit d’un changement d’hébergeur, d’un passage chez un acteur cloud différent, pour que quelques zones DNS restent en décalage. Les utilisateurs voient alors des messages « nom de périphérique introuvable » ou des erreurs de certificat, alors que la cause initiale tient à une zone non mise à jour.
On retrouve la même logique dans les environnements industriels où un serveur OPC UA ou un broker AMQP répond sous un nom de domaine interne. Certaines équipes choisissent d’ignorer complètement le DNS et de tout câbler en IP fixe pour « aller plus vite ». Ce choix fonctionne le temps de la maquette, puis devient un frein à toute évolution. À l’inverse, une résolution DNS bien maîtrisée permet de déplacer des services, de migrer des VM ou de refondre une DMZ sans reconfigurer des centaines d’objets.
La cybersécurité ajoute encore une couche de complexité. De plus en plus de solutions de filtrage utilisent le DNS comme vecteur de blocage ou de redirection. Une requête vers un domaine jugé suspect renvoie une IP de sinkhole qui héberge une page d’alerte, ou ne renvoie rien du tout. Pour un développeur ou un intégrateur qui ne connaît pas cette mécanique, il devient difficile de distinguer un blocage légitime d’une erreur de configuration. D’où le besoin de logs clairs côté résolveurs et d’une gouvernance réseau qui ne se résume pas à « on a activé un filtrage DNS quelque part ».
Dans ces contextes avancés, le dépannage DNS doit faire partie intégrante des checklists de déploiement, au même titre que le monitoring système. Scripts de test de résolution, métriques de latence, alertes quand un taux d’échec dépasse un certain seuil, tout cela réduit drastiquement les incidents qu’on attribue trop vite à l’hébergement ou à l’application.
Méthode pratique de dépannage DNS : de la mesure au changement de configuration
Pour ne pas se perdre dans les symptômes, une approche structurée du dépannage DNS aide autant les équipes IT qu’un utilisateur avancé à la maison. La logique reste toujours la même : mesurer, simplifier, puis déployer les corrections. Partir directement sur un changement de serveur DNS sans vérifier le reste revient souvent à masquer un problème plus profond.
Une trame de travail efficace commence par quelques tests simples : ping d’une IP publique, ping d’un nom de domaine connu, Resolve-DnsName ou équivalent, puis mesure du temps de réponse via des outils natifs. L’objectif est de répondre à deux questions basiques : la connectivité IP brute fonctionne-t-elle, et si oui, à quel moment la résolution DNS décroche-t-elle ? Tant que ces deux questions n’ont pas une réponse claire, il reste prématuré de blâmer la box ou le serveur de l’opérateur.
Une fois cette première couche validée, le regard peut se porter sur la configuration IP du poste. DNS primaire, secondaire, éventuelles adresses IPv6, passerelle par défaut, tout doit former un ensemble cohérent. Sur les postes Windows d’entreprise, cette étape se double d’un contrôle des stratégies de groupe qui peuvent imposer des serveurs DNS spécifiques. Sur les machines Linux, la configuration du client DHCP, des fichiers resolv.conf ou des services comme systemd-resolved prend le relais.
La phase suivante consiste à inspecter les couches intermédiaires : pare-feu local, antivirus, agent de sécurité, box internet, routeur d’entreprise, appliance de filtrage DNS. À chaque étape, la question reste la même : la requête DNS sort-elle, arrive-t-elle au bon endroit, et une réponse revient-elle dans des délais raisonnables ? L’usage ponctuel d’outils de capture comme Wireshark ou tcpdump, même sur un laps de temps court, fournit souvent les éléments manquants.
Pour fixer les idées, une petite checklist opérationnelle aide à ne rien oublier au moment de traiter une erreur DNS récalcitrante.
- Vérifier la connexion IP brute (ping IP locale, ping IP externe, traceroute si besoin).
- Tester plusieurs noms de domaine avec un outil explicite (Resolve-DnsName, nslookup, dig).
- Contrôler et documenter la configuration IP (DNS, passerelle, IPv4/IPv6, suffixes de recherche).
- Neutraliser temporairement les filtres locaux (pare-feu, antivirus) pour voir si les requêtes passent.
- Basculer sur des résolveurs publics connus, en gardant une trace des anciens réglages.
En parallèle, tenir un journal des modifications et des temps de réponse mesurés permet de ne pas perdre de vue l’objectif : une résolution DNS stable, rapide et prévisible, aussi bien sur Windows que sur une PS5 ou tout autre équipement de la maison ou du bureau.
Pourquoi certains sites restent accessibles alors que d’autres renvoient une erreur DNS ?
Dans de nombreux cas, le serveur DNS résout encore correctement une partie des domaines, mais renvoie des échecs ou des timeouts pour d’autres. Cela peut venir d’un filtrage sélectif, d’un cache incohérent, d’un enregistrement DNS mal mis à jour pour un site précis, ou d’une entrée résiduelle dans le fichier Hosts. Tester le même domaine depuis un autre réseau, par exemple via un partage 4G, aide à déterminer si le problème est local ou lié aux serveurs DNS utilisés.
Changer de serveur DNS améliore-t-il vraiment la vitesse de connexion ?
Le changement de serveur DNS ne rend pas une ligne plus rapide en débit, mais il peut réduire la latence perçue au chargement des pages. Un résolveur rapide et proche répond en quelques millisecondes, ce qui accélère l’établissement des connexions initiales. Sur des lignes déjà saturées ou très lentes, le gain restera modeste, mais dans un réseau domestique correct, passer d’un DNS surchargé à un résolveur réactif se ressent souvent sur le confort de navigation.
Comment savoir si le problème vient de Windows ou de la box internet ?
Si un seul poste Windows affiche une erreur DNS pendant que les autres appareils naviguent sans souci, la piste locale est la plus probable. Il faut alors vérifier la configuration IP, le cache DNS, le fichier Hosts et les pare-feu. Si au contraire plusieurs équipements différents (PC, smartphone, console) rencontrent le même problème de résolution au même moment, se concentrer sur la box, les serveurs DNS de l’opérateur et d’éventuelles options de filtrage activées sur le routeur devient prioritaire.
La PS5 doit-elle utiliser les mêmes DNS que le reste du réseau ?
Rien n’oblige une PS5 à reprendre les mêmes serveurs DNS que ceux distribués par la box. Pour stabiliser le jeu en ligne, il est fréquent de configurer manuellement deux résolveurs publics sur la console, tout en laissant le reste du réseau utiliser les paramètres par défaut. Cette séparation permet de contourner des filtres ou des lenteurs liés à la box, sans bouleverser les autres appareils de la maison.
Faut-il désactiver IPv6 pour résoudre des problèmes DNS ?
La désactivation d’IPv6 ne devrait être envisagée qu’après avoir confirmé que le réseau ne l’utilise pas réellement, ou que des enregistrements AAAA incorrects provoquent des tentatives de connexion vouées à l’échec. Dans beaucoup de contextes récents, IPv6 apporte au contraire une meilleure résilience. Le bon réflexe consiste plutôt à vérifier la cohérence des adresses annoncées et la capacité réelle du réseau à les router correctement.