Publié le 19 mai 2026
Quand on est appelé pour une refonte LAN, c'est presque toujours trop tard. L'incident est arrivé, la production est dégradée, la DSI est sous pression, et le projet doit être lancé hier. Pourtant les signaux étaient là depuis longtemps : 18 à 24 mois en moyenne d'après ce qu'on observe sur le terrain. Le vrai sujet n'est pas tant de savoir refaire son LAN — n'importe quel intégrateur sérieux sait le faire. C'est de savoir quand il faut le faire. Et donc : à quoi reconnaître que votre infrastructure est entrée dans sa zone de risque.
Une infrastructure LAN, ça ne tombe pas en panne d'un coup. Elle se dégrade lentement, par accumulation de micro-arbitrages qui semblaient raisonnables sur le moment : un VLAN ajouté pour dépanner, une ACL collée en bout de queue, un firmware qu'on ne met plus à jour parce que « ça marche », un switch d'extension intégré dans une stack qui n'était pas dimensionnée pour. Pris isolément, chacun de ces gestes est compréhensible. Cumulés sur 5 à 7 ans, ils construisent un environnement où plus personne n'a la vision d'ensemble, où chaque changement devient risqué, et où le moindre incident révèle des dépendances qu'on ignorait.
Le problème, c'est que cette dérive est silencieuse. Tant que rien ne casse, rien ne pousse à agir. Et quand quelque chose casse, on entre en mode pompier : on stabilise, on patche, on repousse la refonte de six mois. Encore et encore. Jusqu'au moment où ce n'est plus tenable. Les cinq signaux qui suivent permettent de sortir de cette logique, et de prendre la décision avant l'incident.
Sur les missions de refonte LAN que nous menons, deux profils reviennent. Les organisations qui agissent à 2-3 signaux cochés font des projets maîtrisés, planifiés, en phases. Celles qui agissent à 4-5 signaux font des projets sous tension, avec des choix techniques contraints par le calendrier et un budget qui dérape. La différence n'est pas dans le projet : elle est dans le moment où on l'a lancé.
Le premier signal est aussi le plus mesurable, donc en théorie le plus simple à détecter. En pratique, c'est celui qu'on rate le plus souvent, parce qu'il n'apparaît que sur des indicateurs qu'on ne regarde pas au quotidien.
Les liens d'agrégation entre les switches d'accès et les cœurs, ainsi que les uplinks inter-cœurs, dépassent régulièrement les 70 % d'utilisation en heures de pointe. À ces niveaux, le réseau fonctionne encore — mais sans aucune marge pour absorber un pic, une bascule, ou simplement la croissance organique de l'usage. Les buffers se remplissent, les microbursts deviennent perceptibles, et la latence applicative commence à dériver sans qu'on sache pourquoi.
On pourrait penser qu'il suffit d'ajouter des liens. Mais quand la saturation arrive sur une infrastructure conçue il y a 5 à 7 ans, les chemins d'évolution sont souvent fermés : les châssis n'acceptent plus de cartes plus rapides, le câblage en place ne supporte pas les débits supérieurs, le backplane des cœurs atteint sa limite. Ajouter de la capacité revient alors à empiler du matériel qui ne sera plus là dans 3 ans. La saturation n'est pas le problème : elle est le symptôme d'une architecture qui n'a plus de marge d'évolution.
Le deuxième signal est probablement le plus négligé, parce qu'il ne se voit pas dans le trafic. Pourtant c'est celui qui crée le risque le plus immédiat : un risque de sécurité, et un risque opérationnel.
Les constructeurs annoncent typiquement la fin de commercialisation (End of Sale) 5 à 7 ans après le lancement d'un modèle. La fin de support logiciel (End of Software Maintenance) suit 1 à 3 ans plus tard, et la fin de support technique total (End of Support) 1 à 2 ans après. Au-delà : plus de correctifs, plus de TAC, plus de RMA. Un parc dont la majorité des équipements a franchi l'End of Software Maintenance est dans une zone à risque même si tout fonctionne — parce que la prochaine vulnérabilité critique n'aura pas de correctif.
Au-delà de la sécurité, le manque de maintenance logicielle a un effet pernicieux : il bloque progressivement toute évolution. Pas de support pour les protocoles récents (par exemple les évolutions 802.1X liées à MACsec, le support TLS 1.3 sur les briques d'administration, certaines fonctions d'observabilité moderne), incompatibilité avec les outils de monitoring récents, fonctions de sécurité absentes (pas de support de certains profils de chiffrement par exemple). On hérite d'un parc figé techniquement.
Sortez la liste de vos équipements actifs, et croisez avec les bulletins End of Life du constructeur. Si plus de 30 % du parc est en End of Software Maintenance ou au-delà, vous êtes en zone rouge. Entre 10 et 30 %, en zone orange. En dessous, c'est gérable par renouvellement progressif. La plupart des organisations qui nous contactent pour une refonte sont en zone rouge sans en avoir conscience.
La segmentation est le sujet le plus visible aux yeux d'un RSSI, et le plus difficile à traiter sur une infrastructure héritée. Parce qu'il ne s'agit pas seulement d'un sujet technique : c'est un sujet de remise à plat des usages.
Le VLAN spaghetti. Le plan d'adressage et la liste des VLAN ont été construits par strates : un VLAN ajouté à chaque nouvelle population (commerciaux, ateliers, prestataires, visiteurs), à chaque nouveau site, à chaque migration. Plus personne ne sait précisément ce que contient chaque VLAN, et certains contiennent désormais des équipements qui n'ont rien à y faire historiquement.
L'absence de séparation OT/IT. Sur les sites industriels, les équipements de production (automates, supervision, capteurs) partagent souvent le même réseau que les utilisateurs bureautiques. Quand cela a été conçu il y a 10 ans, le risque était théorique. Aujourd'hui, c'est le scénario classique d'un mouvement latéral après une compromission bureautique.
Les ACL fossiles. Les listes de contrôle d'accès ont été enrichies au fil des demandes ponctuelles, mais jamais nettoyées. Elles contiennent des règles pour des serveurs décommissionnés, des exceptions pour des projets terminés, des ouvertures temporaires devenues permanentes. Personne n'ose les toucher de peur de casser quelque chose.
Une segmentation pertinente ne peut plus se penser uniquement en VLAN statiques. Elle s'articule avec une politique d'authentification réseau (NAC, 802.1X) qui place dynamiquement chaque équipement et chaque utilisateur dans la bonne zone. Ce sujet est suffisamment structurant pour mériter ses propres articles — voir notre guide Pourquoi déployer un NAC en entreprise et notre guide de déploiement 802.1X.
Le quatrième signal n'est pas technique. C'est un signal organisationnel, mais c'est probablement celui qui pèse le plus lourd dans le coût réel d'un projet de refonte.
Dans une majorité de contextes, la documentation existante consiste en : un schéma physique daté de plusieurs années, un plan d'adressage IP partiellement à jour dans un tableur, et la mémoire de la personne qui s'occupait du réseau (parfois encore en poste, parfois partie depuis 18 mois). Le Document d'Architecture Technique formel est rarement maintenu après le projet initial qui l'a produit.
Une documentation à jour, c'est l'image projetée d'une architecture qu'on comprend. Quand elle dérive, c'est le symptôme que l'architecture elle-même n'est plus comprise — qu'on l'opère par habitude, sans vision d'ensemble. Reprendre la documentation a posteriori sur une infrastructure dont personne ne maîtrise plus les choix initiaux coûte presque aussi cher qu'une refonte. Et n'apporte rien : on documente un existant qui devra de toute façon être revu.
Posez cette question à votre équipe réseau : « Si nous devions remplacer un de nos cœurs demain, combien de temps faudrait-il pour cartographier toutes les dépendances avant d'agir ? » Si la réponse se compte en semaines, vous avez votre signal.
Le dernier signal est probablement le plus inconfortable à aborder, parce qu'il touche à des engagements pris dans le passé et à des compétences présentes dans l'équipe. Mais c'est aussi celui qui crée le plus de risque structurel.
Une dépendance fournisseur n'est pas un problème en soi : travailler avec un constructeur unique apporte de la cohérence, simplifie le support, optimise les coûts de licence. Le problème commence quand cette dépendance devient irréversible : licences propriétaires non transférables, mécanismes de stacking incompatibles avec un autre constructeur, fonctions de contrôle d'accès liées à un écosystème spécifique. Le jour où le constructeur révise sa politique commerciale ou son catalogue, l'organisation n'a plus de levier de négociation.
Plus discrète, plus fréquente, et plus immédiate : l'infrastructure ne peut être opérée que par une seule personne qui connaît son historique. Les choix techniques ont été faits sur sa lecture, les exceptions sont dans sa tête, et les procédures d'exploitation reposent sur sa présence. Le départ de cette personne — retraite, mobilité, démission — fait tomber l'organisation dans le scénario « reprise à froid sans documentation » (cf. signal n°4).
Deux questions simples permettent d'objectiver la dépendance :
Pris isolément, aucun de ces signaux ne justifie à lui seul une refonte. Pris ensemble, ils dessinent une trajectoire. Voici la lecture que nous proposons à nos clients en amont d'un projet :
| Nombre de signaux actifs | Posture recommandée | Horizon |
|---|---|---|
| 0 à 1 | Veille standard. Suivi du cycle de vie matériel et logiciel. | Pas de projet à déclencher. |
| 2 à 3 | Audit d'architecture. Cartographie de l'existant, identification des chantiers prioritaires. | 12 à 18 mois. |
| 4 à 5 | Refonte à planifier. Budgétisation, phasage, choix d'architecture cible. | 6 à 12 mois. |
L'audit d'architecture est l'étape qu'on saute le plus volontiers et qu'on regrette le plus systématiquement. C'est elle qui transforme « on sent qu'il faut faire quelque chose » en « on sait précisément ce qu'il faut faire, dans quel ordre, et avec quel budget ». Sans cette étape, un projet de refonte se construit sur des intuitions, et les surprises arrivent en phase d'exécution — quand elles coûtent le plus cher.
Plus de 3 cases cochées ? C'est le moment d'ouvrir le sujet en interne, idéalement par un audit d'architecture avant tout choix de cible technique. Cet audit, mené par un regard externe, produit deux livrables : une cartographie de l'existant (avec ses zones de risque hiérarchisées) et un schéma directeur qui pose les bases d'un projet maîtrisable. C'est l'investissement le plus rentable d'un projet de refonte — parce qu'il évite les autres.
Audit d'architecture réseau, schéma directeur, accompagnement à la refonte : nous intervenons en amont, sans engagement sur la phase aval. Décrivez-nous votre contexte.
Discuter de votre projet