Architectures réseau conçues pour ne pas tomber

Pourquoi reprendre un réseau existant est plus difficile qu'en construire un

Parce qu'un réseau en production porte vingt ans de décisions dont personne ne se souvient. Chaque ajout répondait à un besoin réel, aucun n'a été documenté, et l'ensemble fonctionne : jusqu'au jour où il faut y toucher. Reprendre cet existant suppose d'abord de le comprendre, ce qui n'est jamais une phase courte.

Un commutateur ajouté pour un déménagement, un VLAN créé pour un projet pilote devenu permanent, un lien opérateur reconduit par défaut à chaque échéance : la structure qui en résulte n'est l'intention de personne.

Elle a deux conséquences. Personne dans l'organisation ne sait plus quels flux traversent le cœur de réseau, ce qui rend toute modification risquée. Et un attaquant qui obtient un pied dans ce réseau y circule sans obstacle, parce qu'aucun cloisonnement n'a été pensé.

C'est pourquoi nos interventions commencent par la mesure et non par la proposition d'architecture. Une architecture cible dessinée sans connaître l'existant est un exercice de style.

Comment migre-t-on un réseau multi-sites sans interruption ?

Par vagues réversibles, site par site, avec une architecture cible unique définie à l'avance. Chaque bascule dispose d'une fenêtre planifiée hors période de service, d'un critère de validation écrit et d'un retour arrière essayé. La supervision centralisée est déployée avant la première vague, pas après.

• L'architecture cible d'abord. Un seul modèle, appliqué partout, plutôt qu'une adaptation par site. Les exceptions se paient pendant dix ans en coût d'exploitation.
• La supervision avant la bascule. Sans mesure préalable, il est impossible de dire si un site va mieux ou moins bien après migration, et donc impossible d'arbitrer la suite.
• Le pilote sur un site représentatif. Ni le plus simple, ni le plus critique. Le premier ne révèle rien, le second ne pardonne rien.
• Le retour arrière essayé. Un plan de repli jamais exécuté est une hypothèse. Nous l'exerçons sur le site pilote, pendant la fenêtre, avant de poursuivre.

Qu'est-ce qui rend un Wi-Fi industriel différent ?

L'environnement physique et la tolérance à la coupure. En entrepôt ou en usine, les structures métalliques, les rayonnages mobiles et les engins créent des zones d'ombre qui n'apparaissent sur aucun plan. Et une microcoupure qui passerait inaperçue en bureautique provoque ici un arrêt de ligne.

La conception se fait donc sur site, pas sur plan. Une étude de couverture menée depuis un logiciel donne un résultat plausible et faux : elle ignore ce que les palettes, les cloisons mobiles et les chariots font aux ondes.

Le second écart concerne l'itinérance. Un terminal embarqué sur un chariot change de borne en permanence ; la qualité de ces transitions compte davantage que la puissance du signal, et c'est elle qui détermine si la ligne s'arrête.

Enfin, le parc terminal impose ses contraintes. Des équipements industriels anciens ne supportent pas les protocoles récents, et la conception doit composer avec eux plutôt que les ignorer.

Faut-il passer au SD-Access ?

Pas systématiquement. Le SD-Access apporte une segmentation pilotée par politique plutôt que par configuration d'équipement, ce qui change l'exploitation en profondeur, pour le meilleur quand le parc est homogène et les équipes formées, pour le pire dans le cas inverse.

Le gain réel est opérationnel : appliquer une politique d'accès sans reconfigurer chaque équipement, et la faire suivre l'utilisateur plutôt que la prise réseau. Sur un parc multi-sites, cela supprime une classe entière d'erreurs de configuration.

Le coût réel est la montée en compétence. L'exploitation quotidienne change de nature, et une équipe qui n'a pas été accompagnée retombe sur les anciennes pratiques, en ayant payé la technologie.

Nous vérifions donc trois choses avant de recommander cette direction : l'homogénéité du parc, la maturité de la gestion des identités, et la disponibilité réelle des équipes pour la transition.

Questions fréquentes