[🛠] IT Operations #1: Comment j’ai résolu le problème ‘Pas de connexion Internet’ du routeur de l’entreprise (avec Codex)

✨ Résumé de GPT-5.6 Sol

Le récit de la connexion du téléphone au routeur du 2e étage et du navigateur du Mac au routeur principal pour permettre à Codex de diagnostiquer directement les équipements réels, tout en apprenant le réseau en temps réel jusqu’au rétablissement du service.

Aujourd’hui, le Wi-Fi du 2e étage de l’entreprise fonctionnait mal. Le signal était excellent, mais Internet ne passait pas. Le routeur était allumé et le téléphone connecté, pourtant l’écran continuait à afficher Pas de connexion Internet.

Le routeur devant moi était sous tension et ses voyants LAN clignotaient. Rien dans son apparence ne permettait de savoir où la communication était bloquée.

Autrefois, j’aurais redémarré plusieurs fois le routeur, vérifié si le câble réseau était mal branché, puis commencé à chercher sur le Web si cela ne suffisait pas. Mais deux jours plus tôt, en écrivant Savoir utiliser activement l’IA ouvre un nombre infini de possibilités, j’avais découvert une nouvelle manière de travailler.

Il suffisait que je relie à l’IA les équipements et les écrans réels.

Cette fois, j’ai immédiatement appliqué cette méthode. J’ai connecté le téléphone au Mac par USB et ouvert ADB. Le téléphone était relié au Wi-Fi défaillant du 2e étage. Dans Chrome sur le téléphone, j’ai ouvert la page d’administration du routeur du 2e étage et je me suis connecté. Dans Chrome sur le Mac, j’ai ouvert la page d’administration du routeur principal de l’entreprise et je me suis connecté. Puis j’ai parlé à Codex.

Le point essentiel n’était pas que j’avais découvert seul toutes les configurations des routeurs. J’avais d’abord préparé les équipements physiques, l’environnement d’exécution des commandes et les écrans d’administration déjà connectés pour que Codex puisse réellement travailler.

Commence par comprendre la situation actuelle. Modifier quelque chose à la légère pourrait causer un problème. Essaie autant que possible de résoudre le problème d’abord avec des commandes.

Désormais, Codex n’était plus un chatbot qui se contentait d’expliquer. Il pouvait lire par commande l’état réseau du téléphone, passer avec Computer Use entre les deux écrans d’administration auxquels je m’étais connecté, puis vérifier et modifier les réglages réels.

J’ai relié le téléphone et les navigateurs pour montrer les deux réseaux en même temps

Au début, je ne savais même pas pourquoi 192.168.0.1 ne s’ouvrait pas. La vérification a montré que les deux routeurs jouaient des rôles différents.

Routeur principal 192.168.0.1
  └─ WAN ipTIME du 2e étage 192.168.0.86
       └─ Wi-Fi / LAN du 2e étage 192.168.1.x
            └─ Administration du routeur du 2e étage 192.168.1.1

Le Mac étant connecté au réseau principal, il pouvait ouvrir le routeur de l’entreprise à l’adresse 192.168.0.1. En revanche, le téléphone connecté au Wi-Fi du 2e étage recevait une adresse 192.168.1.x et utilisait 192.168.1.1 comme passerelle. C’est pourquoi le navigateur du Mac affichait le routeur principal et celui du téléphone, le routeur du 2e étage.

Je ne lui ai pas seulement montré les écrans. Avec ADB connecté, Codex pouvait lire l’adresse IP et la route reçues par le téléphone, puis cibler l’interface Wi-Fi du 2e étage pour tester directement la communication. Comme le téléphone pouvait réussir une requête Internet par les données mobiles même lorsque le Wi-Fi ne fonctionnait plus, un simple ping pouvait donner un résultat trompeur.

adb shell "ping -I wlan0 -c 3 -W 2 192.168.1.1"
adb shell "ping -I wlan0 -c 3 -W 2 192.168.0.1"
adb shell "ping -I wlan0 -c 3 -W 2 1.1.1.1"

adb shell "curl --interface wlan0 -k -sS -o /dev/null \
  -w '%{http_code}' --connect-timeout 5 --max-time 10 \
  https://www.google.com/generate_204"

Les résultats étaient les suivants.

• Le routeur du 2e étage 192.168.1.1 répondait depuis le téléphone.
• Le routeur principal 192.168.0.1 ne répondait déjà plus.
• L’adresse IP externe 1.1.1.1 ne répondait pas non plus.
• Le test HTTPS se terminait par 000.

J’ai observé tout le processus juste à côté. Un signal Wi-Fi signifiait seulement que le téléphone et le routeur du 2e étage étaient reliés. Le problème se trouvait après cette liaison, sur le segment par lequel le WAN du routeur du 2e étage devait rejoindre le réseau principal.

Je n’avais pas commencé par ouvrir un manuel de réseau pour étudier dans l’ordre LAN, WAN, passerelle et double NAT. En regardant Codex découper et tester la panne étape par étape, j’ai immédiatement compris pourquoi 192.168.0.1 et 192.168.1.1 existaient tous les deux.

Une attribution DHCP normale pouvait tout de même masquer une communication bloquée

Le même jour, les adresses IP du NAS de développement et du NAS de données avaient aussi changé. Dans la liste des clients DHCP du routeur principal, j’ai retrouvé leurs adresses et leurs adresses MAC actuelles, puis réservé les adresses pour que les deux NAS reçoivent les mêmes la prochaine fois. J’ai aussi corrigé les redirections de ports HTTP et HTTPS vers lesquelles arrivait l’automatisation des congés précédemment déplacée sur le NAS afin qu’elles pointent vers les nouvelles adresses.

C’est à ce moment précis que j’ai appris ce qu’était DHCP.

• Une attribution DHCP ordinaire prête à un équipement une adresse IP disponible.
• Une réservation DHCP attribue la même adresse IP lorsqu’une adresse MAC donnée se connecte.
• Configurer une IP statique directement sur l’équipement est différent de réserver une adresse DHCP sur le routeur.

Pourtant, le problème du routeur du 2e étage ne s’expliquait pas par une simple réservation DHCP. L’écran d’administration ipTIME affichait l’adresse externe 192.168.0.86 avec l’état Connecté à Internet. Le routeur principal indiquait lui aussi que cette adresse était actuellement louée à l’ipTIME.

À un moment, Codex a regardé uniquement la page courante de la liste DHCP et conclu à tort que .86 n’existait pas. Plus de 90 clients répartissaient la liste sur plusieurs pages, et j’avais déjà vu la ligne sur une autre page.

Elle est bien là, non ?

Lorsque j’ai montré de nouveau l’adresse MAC et la ligne de bail .86, la direction de l’enquête a changé. Ce n’était pas un problème d’obtention d’adresse IP : il fallait trouver le réglage qui bloquait la communication après son attribution.

Déconnecter puis reconnecter le WAN n’a rien changé. Le contrôle d’accès était activé, mais la liste noire était vide. La cause est finalement apparue sur l’écran Liaison IP&MAC. .86 n’était pas liée à l’adresse MAC WAN actuelle de l’ipTIME, mais à celle d’un ancien ordinateur de bureau.

Serveur DHCP : loue actuellement 192.168.0.86 à l’ipTIME
Liaison IP&MAC : enregistre 192.168.0.86 comme appartenant à l’ancienne adresse MAC du PC

DHCP avait donné l’adresse à l’équipement actuel, mais le réglage de sécurité considérait qu’elle appartenait à un autre équipement. L’ipTIME semblait donc avoir reçu une adresse IP sur l’écran d’administration, tout en étant incapable de communiquer avec le routeur principal.

Avoir reçu une adresse IP et pouvoir communiquer avec cette adresse IP ne signifiaient pas la même chose. Là encore, j’ai compris naturellement la différence en suivant la panne.

J’ai supprimé une seule ancienne liaison et revérifié sur le véritable Wi-Fi

Je n’ai pas désactivé toute la fonction de sécurité du routeur. J’ai supprimé uniquement l’ancienne liaison IP–MAC de .86, puis renégocié la connexion WAN de l’ipTIME.

Cette fois, le résultat a immédiatement changé.

192.168.0.1  ping réussi
1.1.1.1      ping réussi
HTTPS        204
Wi-Fi Android VALIDATED

Après le rétablissement, j’ai ajouté une réservation DHCP pour que l’adresse MAC WAN actuelle de l’ipTIME reçoive toujours .86. La réservation DHCP donne en permanence la même adresse à l’équipement actuel, tandis que la liaison IP–MAC impose quel équipement a le droit de l’utiliser. La panne venait du fait que ces deux enregistrements désignaient des équipements différents.

Internet était revenu, mais la structure de double NAT, dans laquelle l’ipTIME du 2e étage créait un réseau 192.168.1.x distinct sous le réseau principal, restait en place. Passer en mode AP ou hub aurait exigé de modifier DHCP et l’adresse d’administration, mais aussi l’endroit où le câble réel était branché entre WAN et LAN. Une modification distante imprudente aurait pu faire perdre à la fois l’écran d’administration et les équipements du 2e étage ; je n’ai donc corrigé aujourd’hui que la cause confirmée de la panne Internet.

Je n’ai pas réparé après avoir tout appris sur le réseau : j’ai appris en réparant

L’essentiel de mon travail aujourd’hui n’était pas d’avoir étudié tout le réseau à l’avance pour réparer le routeur.

Lorsque le problème est apparu, j’ai immédiatement repris la méthode de travail découverte le 22 juillet. J’ai commencé par les connexions physiques et les identifications que moi seul pouvais effectuer. J’ai relié le téléphone au Wi-Fi du 2e étage puis au Mac par USB. J’ai ouvert séparément les deux écrans d’administration. J’ai fixé le périmètre des changements et, quand Codex a manqué la ligne DHCP, je la lui ai montrée de nouveau.

À partir de là, Codex pouvait agir. Il a identifié par commande jusqu’où la communication passait, lu les réglages des deux écrans d’administration avec Computer Use, éliminé les causes possibles une à une, modifié uniquement l’enregistrement nécessaire, puis vérifié de nouveau le résultat sur le même téléphone.

Je n’ai pas étudié toutes sortes de notions réseau avant de les mettre en pratique. Les concepts nécessaires sont arrivés au moment exact où ils se rattachaient à de véritables écrans et résultats de commandes. DHCP, adresse MAC, passerelle, LAN et WAN, liaison IP–MAC et double NAT ont cessé d’être des termes à mémoriser : ils sont devenus des outils pour expliquer la panne visible devant moi.

L’IA n’avait pas toujours raison dès le départ. Elle s’est aussi trompée, comme lorsqu’elle a manqué .86. Mais lorsque je regardais l’écran réel et lui signalais de nouveau ce qui paraissait anormal, Codex passait aussitôt au test suivant. Je n’avais pas besoin de connaître d’avance chaque commande et chaque menu, mais je devais toujours juger si le résultat était étrange et réorienter l’objectif.

Deux jours plus tôt, j’avais compris pour la première fois que connecter un navigateur et un téléphone à l’IA élargissait ce que je pouvais directement manipuler. Aujourd’hui, j’ai appliqué activement cette découverte à une véritable panne dans l’entreprise.

Étudier un domaine inconnu pendant des semaines avant de l’appliquer un jour n’était pas la seule méthode possible. Je pouvais aussi résoudre un problème réel avec l’IA, apprendre juste ce qui était nécessaire à cet instant et obtenir immédiatement un résultat.