En 2011, j’étais chez un client PME de la région lyonnaise — une quinzaine de postes, un serveur de fichiers, une imprimante réseau qui refusait obstinément de répondre depuis trois postes sur quinze. Le prestataire précédent avait changé le pare-feu deux semaines plus tôt et personne n’avait pensé à vérifier ce que ce changement impliquait pour les flux internes. J’ai passé quatre heures sur place ce jour-là, et honnêtement, la moitié de ce temps aurait pu être évitée si j’avais eu, quinze ans plus tôt, une explication claire de TCP/IP au lieu de la documentation Cisco indigeste qu’on me refilait à l’époque. Ce guide, c’est celui que j’aurais voulu lire en 2008, avant mon premier poste en SSII.
Je ne vais pas vous noyer sous les couches OSI et les RFC. Je vais vous expliquer TCP/IP avec le cas réel de ce client, parce que c’est comme ça qu’on comprend vraiment un protocole réseau : en voyant ce qui casse quand il est mal compris.
Le contexte : une panne qui n’en avait pas l’air
Le ticket disait : « l’imprimante ne marche plus pour certains utilisateurs ». Sur le papier, ça ressemble à un problème de pilote ou de file d’attente d’impression. Sauf que trois postes sur quinze étaient touchés, et pas les mêmes tous les jours selon qui allumait son PC en premier. Ce genre de symptôme intermittent, dans mon expérience, pointe presque toujours vers une couche plus basse que l’application — c’est-à-dire le réseau, pas le logiciel.
J’ai posé la question bête en arrivant : « qu’est-ce qui a changé récemment ? » Le gérant m’a répondu qu’un technicien était passé changer le routeur pare-feu deux semaines avant. Bingo. Neuf fois sur dix, quand un problème réseau apparaît « sans raison », il y a eu un changement de matériel ou de configuration juste avant, et personne ne fait le lien parce que le symptôme met du temps à se manifester (redémarrages de postes, renouvellement de bail DHCP, etc.).
Pour comprendre ce qui s’est passé chez ce client, il faut d’abord comprendre ce qu’est réellement TCP/IP — pas la définition Wikipédia, mais ce que ça fait concrètement quand deux machines veulent se parler.
TCP/IP expliqué sans jargon superflu
TCP/IP n’est pas un protocole unique, c’est une famille de deux protocoles complémentaires qui travaillent ensemble, plus un système d’adressage qui les rend possibles. Décomposons.
IP : l’adresse postale
IP (Internet Protocol) s’occupe d’une seule chose : faire en sorte qu’un paquet de données parte d’une machine A et arrive à une machine B, en traversant éventuellement plusieurs réseaux intermédiaires. Chaque machine a une adresse IP, un peu comme une adresse postale — sauf qu’une adresse IP n’identifie pas juste « qui » mais aussi « où » dans la logique du réseau. C’est ce deuxième point qui a piégé mon client, et j’y reviens dans deux paragraphes.
IP ne garantit rien : il envoie le paquet et espère qu’il arrive. Pas d’accusé de réception, pas de vérification. C’est voulu — c’est rapide et léger. Le contrôle de qualité, c’est le travail de TCP.
TCP : le contrôleur de livraison
TCP (Transmission Control Protocol) s’assure que les données arrivent complètes, dans l’ordre, et sans erreur. Avant même d’envoyer la première donnée utile, TCP fait ce qu’on appelle une « poignée de main en trois temps » (three-way handshake) : la machine A dit « je veux te parler » (SYN), la machine B répond « d’accord, vas-y » (SYN-ACK), et A confirme « c’est parti » (ACK). Ces trois échanges se font en quelques millisecondes sur un réseau local, mais ils doivent aboutir avant qu’un seul octet de vos données ne soit transmis.
C’est ce détail — la poignée de main préalable — qui explique pourquoi un pare-feu mal configuré casse une connexion de façon si nette : si le premier paquet SYN est bloqué, il n’y a jamais de conversation qui démarre. Pas de message d’erreur clair côté utilisateur, juste un délai d’attente (timeout) et puis rien.
Les ports : la porte précise dans le bâtiment
Une adresse IP vous amène au bon bâtiment (la bonne machine). Le port vous amène à la bonne porte à l’intérieur de ce bâtiment — c’est-à-dire au bon service. Le port 80 ou 443, c’est le serveur web. Le port 445, c’est le partage de fichiers Windows (SMB). Le port 631 ou 9100, très souvent, c’est l’impression réseau. Un pare-feu qui filtre par port peut laisser passer une machine (l’IP est autorisée) mais bloquer un service précis (le port ne l’est pas). C’est exactement ce qui s’est passé chez mon client : le nouveau pare-feu autorisait les postes à joindre l’imprimante en IP (les pings passaient), mais bloquait le port 9100 utilisé par le protocole d’impression direct, sauf pour une plage d’adresses spécifique — celle des postes qui fonctionnaient encore.
Ce qui a vraiment cassé chez le client : deux erreurs, pas une
Après une heure de diagnostic, j’ai identifié deux problèmes distincts, superposés — ce qui expliquait pourquoi le symptôme semblait incohérent.
Premier problème : un mauvais port ouvert sur le pare-feu. Le technicien précédent avait configuré une règle autorisant le port 515 (LPD, un vieux protocole d’impression) alors que l’imprimante utilisait le port 9100 (RAW/JetDirect, standard depuis une bonne quinzaine d’années sur le matériel professionnel). Résultat : la règle de pare-feu ne servait à rien, elle autorisait un port que personne n’utilisait.
Deuxième problème, plus sournois : un décalage de sous-réseau. Trois postes avaient été configurés manuellement avec un masque de sous-réseau en /24 (255.255.255.0) alors que le reste du parc, et le nouveau routeur, opéraient en /23 (255.255.254.0) suite à une extension du plan d’adressage faite par le prestataire précédent pour anticiper l’ajout de nouveaux postes. Sur le papier ces trois machines avaient des adresses IP qui semblaient correctes (192.168.1.x), mais leur masque de sous-réseau leur faisait croire que l’imprimante (192.168.2.x) était sur un réseau distant, à joindre via une passerelle — alors qu’elle était en réalité sur le même segment physique. Ces trois postes envoyaient donc leurs paquets d’impression vers la passerelle par défaut au lieu de les envoyer directement sur le réseau local, et la passerelle, elle, les redirigeait vers une route qui n’existait plus depuis la migration.
C’est ce deuxième point qui a pris le plus de temps à diagnostiquer, parce qu’il ne dépendait pas du pare-feu du tout — c’est une pure question de calcul d’adressage IP, invisible tant qu’on ne va pas vérifier la configuration de chaque poste individuellement.
Diagnostic étape par étape : la méthode que j’utilise depuis 15 ans
Voici exactement la séquence que j’ai suivie ce jour-là, et que j’applique systématiquement sur tout problème de connectivité réseau en PME. Elle part du plus bas niveau (la couche IP) vers le plus haut (l’application), parce que c’est l’ordre dans lequel les données transitent réellement.
- Étape 1 — Ping. Depuis un poste qui ne fonctionne pas,
ping 192.168.2.50(l’IP de l’imprimante). Si ça répond, la couche IP fonctionne au moins pour les paquets ICMP — mais ça ne garantit rien pour TCP. Chez le client, le ping passait sur les trois postes en panne : premier indice trompeur. - Étape 2 — Vérifier la configuration IP locale.
ipconfig /allsous Windows, ouip addrsous Linux/Mac. C’est là que j’ai repéré le masque de sous-réseau différent sur les trois postes fautifs : 255.255.255.0 au lieu de 255.255.254.0 partout ailleurs. - Étape 3 — Tester le port applicatif précis, pas juste la présence de la machine. Avec
telnet 192.168.2.50 9100(ou Test-NetConnection sous PowerShell avec le paramètre -Port). Si la connexion s’ouvre, le port est bien accessible bout en bout. Chez le client, ce test échouait avec un timeout — pas un refus explicite, ce qui est la signature typique d’un pare-feu qui droppe silencieusement les paquets plutôt que de les rejeter. - Étape 4 — Comparer un poste qui marche et un qui ne marche pas. Le contraste entre les deux configurations révèle presque toujours l’anomalie plus vite qu’une lecture isolée. C’est en comparant les
ipconfig /allcôte à côte que le décalage de masque m’a sauté aux yeux. - Étape 5 — Vérifier les règles du pare-feu elles-mêmes. Sur l’interface d’administration du routeur, j’ai listé les règles NAT et filtrage actives. La règle censée autoriser l’impression pointait vers le port 515, jamais utilisé par ce modèle d’imprimante.
Sur le terrain, cette méthode en cinq étapes prend en général 20 à 40 minutes sur un problème réseau standard. Ici, la superposition des deux causes a fait grimper le total à un peu plus de deux heures rien que pour le diagnostic — le reste du temps sur place a servi à corriger et à documenter.
La correction, concrètement
Deux actions distinctes, correspondant aux deux causes identifiées :
- Sur le pare-feu : suppression de la règle inutile sur le port 515, ajout d’une règle explicite autorisant le port TCP 9100 depuis l’ensemble du sous-réseau des postes vers l’IP de l’imprimante.
- Sur les trois postes concernés : correction du masque de sous-réseau à 255.255.254.0, alignement sur la configuration DHCP standard du reste du parc (les trois postes avaient une IP fixe configurée manuellement par un ancien salarié, donc ils ne recevaient jamais la bonne config par DHCP).
Après ces deux corrections, test immédiat avec le telnet sur le port 9100 depuis les trois postes : connexion établie en moins d’une seconde, plus de timeout. Impression testée sur chaque poste, fonctionnelle. Zéro incident réseau signalé depuis, sur cette machine en tout cas — je fais un suivi à distance mensuel chez ce client depuis, et le sujet n’est jamais revenu.
Ce qu’il faut retenir si vous gérez le réseau d’une PME
Vous n’avez pas besoin de maîtriser TCP/IP en profondeur pour éviter ce genre de panne. Trois principes suffisent à couvrir 80 % des cas que je vois sur le terrain :
- Un ping qui répond ne prouve rien sur l’application. ICMP (le protocole du ping) et TCP sont deux choses différentes. Une machine peut répondre au ping et refuser toute connexion applicative sur le port qui vous intéresse.
- Toute modification de pare-feu doit lister explicitement les ports utilisés par chaque service métier (imprimante, logiciel de gestion, sauvegarde) — pas juste « autoriser le trafic local ». Demandez cette liste par écrit à votre prestataire à chaque intervention sur le pare-feu.
- Les IP fixes configurées manuellement sont la première cause de dérive de configuration que je rencontre en PME. Dès qu’un poste a une IP fixe, il devient invisible aux mises à jour de configuration réseau centralisées (DHCP). Documentez-les, ou évitez-les.
Une action à faire dans les 24h si vous lisez ceci après une intervention réseau récente
Si votre pare-feu ou votre routeur a été touché dans les deux à quatre dernières semaines, ne pas attendre qu’un utilisateur se plaigne. Faites ceci aujourd’hui : sur trois postes au hasard (idéalement un dans chaque service), lancez ipconfig /all et comparez le masque de sous-réseau et la passerelle par défaut. Si les trois valeurs ne sont pas identiques, vous avez potentiellement le même problème que mon client, en incubation. Cinq minutes de vérification contre plusieurs heures de diagnostic plus tard — le calcul est vite fait.
Le piège à éviter absolument
Le piège classique, que j’ai vu répété chez au moins une dizaine de clients en quinze ans, c’est de rouvrir tous les ports « pour être tranquille » dès qu’un problème de connectivité apparaît après un changement de pare-feu. Ça résout le symptôme en quelques secondes, et ça expose l’ensemble du réseau interne à des risques inutiles — un poste compromis par un ransomware ou un malware peut alors dialoguer librement avec n’importe quel service interne. J’ai été appelé deux fois en urgence sur des incidents de ce type, où la cause racine remontait directement à une règle de pare-feu « temporaire » ouverte en grand six mois plus tôt et jamais refermée. Corrigez la cause précise (le bon port, la bonne configuration IP), pas le symptôme au sens large.
En résumé
TCP/IP, ce n’est pas un concept abstrait réservé aux ingénieurs réseau. C’est la mécanique concrète qui décide si votre imprimante, votre logiciel de gestion ou votre sauvegarde cloud fonctionne ou pas. IP amène le paquet à la bonne machine, TCP garantit qu’il arrive intact via une poignée de main en trois temps, et le port dirige la donnée vers le bon service à l’intérieur de cette machine. Un pare-feu ou une configuration IP mal alignée sur l’un de ces trois éléments suffit à casser une connexion — souvent de façon silencieuse, avec un simple timeout plutôt qu’un message d’erreur clair.
La prochaine fois qu’un service réseau « ne marche plus pour certains utilisateurs seulement », commencez par comparer la configuration IP des postes en panne à celle des postes qui fonctionnent. Neuf fois sur dix sur le terrain, la réponse est là avant même de toucher au pare-feu.