Le Wi-Fi a réussi quelque chose d’assez drôle : il devient normal exactement au moment où ses pannes commencent à nous fâcher. Tant que le sans-fil est un gadget, voir un portable connecté sans câble est impressionnant. Dès qu’on compte dessus, une zone morte devient le coin de la pièce où rien ne marche.

Sous l’icône réseau, le portable doit d’abord trouver une borne qui annonce son nom de réseau, le SSID. Il choisit un canal et s’associe à cette borne. Selon l’installation, il passe une authentification et établit les paramètres WEP. Ensuite seulement, DHCP peut lui fournir une adresse IP, une passerelle et des serveurs DNS. Une belle force de signal ne garantit donc pas que l’adresse, le DNS ou la route vers le serveur fonctionnent.

La radio partage un médium que personne ne peut utiliser en même temps dans le même espace. Ethernet peut détecter une collision sur un câble; une station Wi-Fi entend mal une autre station pendant qu’elle transmet. La norme utilise plutôt l’évitement de collision, CSMA/CA : écouter le canal, attendre s’il est occupé, choisir un petit délai aléatoire, envoyer une trame, puis attendre un accusé de réception. Sans accusé, la trame est retransmise après un délai plus grand.

application → TCP → IP → trame 802.11 ⇄ borne → Ethernet → serveur
                              ↳ attente / retry si aucun accusé radio

Ce mécanisme rend le réseau robuste, mais chaque retry consomme le même air partagé. Une borne annoncée à 11 Mbit/s ne livre pas 11 Mbit/s à chaque portable : il faut compter les en-têtes, les accusés, les temps d’attente et les autres clients. La distance réduit le débit choisi. Les murs, les fours à micro-ondes et d’autres appareils dans la bande de 2,4 GHz ajoutent du bruit. Deux bornes mal placées sur le même canal se partagent aussi la capacité.

Au-dessus, TCP voit seulement les paquets perdus ou retardés. Il remet les données en ordre, retransmet ce qui manque et ralentit lorsqu’il soupçonne de la congestion. Une courte perte radio peut donc devenir une pause bien plus longue dans l’application. Pendant un déplacement, le portable peut rester attaché trop longtemps à une borne faible, puis se réassocier à une autre. Si le nouveau segment lui donne une nouvelle adresse, les connexions TCP existantes ne survivent généralement pas.

Le cas important est une écriture interrompue :

1. l’application envoie CréerCommande;
2. le serveur écrit et valide la transaction;
3. le portable traverse une zone morte avant de recevoir la réponse;
4. TCP abandonne et le client affiche un timeout;
5. la personne reclique lorsque le signal revient.

Le réseau ne peut pas dire au client ce qui a déjà été commis. Je générerais un identifiant d’opération avant l’étape 1, le stockerais avec la commande et rendrais cet identifiant unique. Le deuxième envoi peut alors retrouver le résultat du premier. Le formulaire garde aussi la saisie locale tant qu’il n’a pas une confirmation et affiche un état distinct pour « envoi en cours », « confirmé » et « résultat à vérifier ».

La sécurité de 2003 mérite de la prudence. Le SSID n’est pas un secret et le filtrage d’adresses MAC se contourne. WEP chiffre les trames, mais ses faiblesses sont déjà documentées; il ne faut pas traiter la présence du cadenas comme une protection absolue. Pour des données sensibles, un VPN et les contrôles du serveur ajoutent une vraie défense. Les mêmes permissions s’appliquent peu importe que le paquet arrive par câble ou radio.

Pour diagnostiquer, je sépare les couches : association à la borne, adresse DHCP, résolution DNS, route vers le serveur, puis session applicative. Je marche aussi avec un ping continu et un transfert réel, car l’icône de signal seule masque les retries. Mon test final consiste à fermer le couvercle ou sortir de la couverture au moment exact d’une écriture.

Je vais davantage faire confiance au Wi-Fi après une coupure dont l’application revient sans perte ni doublon qu’après une première connexion réussie. Pour l’instant, je garde le câble dans le sac — et un identifiant de reprise dans le protocole.