Ce qui casse réellement dans un réseau multisite
Le problème n'est presque jamais le débit. Il tient à trois choses que l'on découvre toujours au mauvais moment. D'abord la fragilité : un lien unique par site signifie qu'une pelleteuse dans la rue arrête une agence entière pour la journée. Ensuite l'hétérogénéité : chaque site a été raccordé à une époque différente, par un opérateur différent, avec un routeur différent et des règles de pare-feu écrites par quelqu'un qui est parti depuis. Enfin le détour : sur une architecture en étoile classique, un utilisateur de Troyes qui ouvre une application hébergée dans le cloud remonte d'abord au siège rémois avant de ressortir sur Internet, ce qui ajoute de la latence pour rien.
Le SD-WAN traite les trois d'un coup. Il considère les liens comme un réservoir de capacité plutôt que comme des tuyaux séparés, applique une politique unique décrite une seule fois, et choisit la sortie la plus courte pour chaque type de trafic.
Nous déployons ces architectures sur des groupes de cinq à quarante sites, souvent répartis entre la Marne, l'Aube, les Ardennes et l'Île-de-France, avec un site principal à Reims et des antennes commerciales à Paris.
Les quatre fonctions qui justifient le passage au SD-WAN
Le reste relève du confort. Celles-ci changent le quotidien des utilisateurs et de l'exploitation.
Agrégation et bascule sans coupure
Deux ou trois accès par site, de technologies et d'opérateurs différents. Les sessions actives migrent d'un lien à l'autre sans être coupées : un appel en cours ne tombe pas, un transfert ne repart pas de zéro. La bascule se déclenche sur la dégradation mesurée (perte, gigue, latence), pas seulement sur la perte totale du lien — une ligne qui perd 8 % de paquets est inutilisable bien avant d'être considérée comme en panne.
Priorisation par application
Le SD-WAN reconnaît les flux, pas seulement les ports. La téléphonie et la visioconférence obtiennent la garantie dont elles ont besoin, les sauvegardes et les synchronisations de postes se contentent du reste et se font écraser en cas de congestion. C'est le point qui fait disparaître les plaintes sur la qualité des appels.
Chiffrement inter-sites systématique
Tous les flux entre sites sont chiffrés, y compris lorsqu'ils empruntent un accès Internet grand public. On obtient la confidentialité d'un MPLS sans son coût ni ses délais de livraison, et la segmentation reste portée de bout en bout : un VLAN caméras reste un VLAN caméras d'un site à l'autre.
Déploiement et politique centralisés
Un nouveau site se monte à partir d'un gabarit : le boîtier s'auto-configure en se connectant au contrôleur. Une règle de sécurité modifiée une fois s'applique partout. Sur un parc de vingt agences, c'est la différence entre une demi-journée et trois semaines de travail.
MPLS, VPN IPsec ou SD-WAN ?
Les trois coexistent encore, et le MPLS garde des cas d'usage. Voici comment nous tranchons.
| Critère | MPLS opérateur | VPN IPsec classique | SD-WAN |
|---|---|---|---|
| Délai de livraison d'un site | 8 à 16 semaines | Quelques jours | Quelques jours |
| Coût mensuel par site | Élevé | Faible | Faible à moyen (licence incluse) |
| Qualité de service garantie | Contractuelle, de bout en bout | Aucune | Mesurée et pilotée, sans garantie opérateur |
| Bascule sur panne | Selon contrat, souvent lente | Coupure de session | Sans coupure, en quelques centaines de ms |
| Accès direct au SaaS | Non, backhaul obligatoire | Possible mais à gérer site par site | Natif, par politique |
| Exploitation | Déléguée à l'opérateur | Manuelle, boîtier par boîtier | Console unique |
| Bon choix quand… | Contrainte contractuelle forte, flux temps réel critiques | 2 ou 3 sites, budget serré | À partir de 4 ou 5 sites, ou dès qu'il y a du cloud |
↔ Faites défiler le tableau pour consulter toutes les colonnes.
Notre position : en dessous de quatre sites, un VPN IPsec bien fait et deux accès par site suffisent largement, et le SD-WAN ajoute une licence sans valeur proportionnelle. Au-delà, le temps d'exploitation économisé paie l'abonnement dès la première année. Nous le disons aussi quand la réponse est « pas encore ».
Comment nous conduisons une migration
Relevé des liens et des flux réels
Nous mesurons ce qui circule vraiment entre les sites pendant deux à quatre semaines : volumes, applications, pics, et surtout qualité réelle des accès existants. Beaucoup de projets démarrent sur des hypothèses fausses — un lien « fibre 1 Gbit/s » qui s'avère mutualisé et saturé chaque jour à 11 h.
Choix des accès et commande anticipée
C'est le chemin critique : les délais de raccordement opérateur conditionnent tout le calendrier. Nous commandons les accès complémentaires dès la validation de l'architecture, en privilégiant deux infrastructures physiquement distinctes par site quand c'est possible.
Maquette sur deux sites pilotes
Un site principal et une agence, en production, pendant trois à quatre semaines. On y valide la politique applicative, les seuils de bascule et le comportement réel de la téléphonie — c'est toujours la voix qui révèle les réglages trop optimistes.
Déploiement en vagues
Les sites basculent par groupes de trois à cinq, en conservant l'ancien lien actif quelques semaines. Chaque bascule se fait en heures ouvrées, avec un retour arrière possible en quelques minutes.
Supervision et transfert de compétences
Tableaux de bord par site et par application, alertes sur dégradation de lien, procédure d'ajout d'un site. Vos équipes doivent pouvoir monter la treizième agence sans nous : c'est le critère de réussite du projet.
Le SD-WAN ne dispense pas de sécuriser l'intérieur
Un SD-WAN chiffre les liaisons entre sites et filtre les sorties Internet. Il ne dit rien de ce qui se passe à l'intérieur d'un site — et c'est précisément là que se propage un rançongiciel. Relier proprement douze sites dont les réseaux internes sont plats revient à construire douze autoroutes entre douze pièces sans porte.
Nous traitons donc systématiquement les deux ensemble : la microsegmentation interne, qui cloisonne caméras, IoT, automatismes et bureautique, et le contrôle d'accès réseau, qui décide de ce qui a le droit de se brancher. Le SD-WAN transporte ensuite cette segmentation d'un site à l'autre, ce qui évite d'avoir à la redéfinir douze fois.
Cette cohérence a un effet secondaire appréciable : les questionnaires d'assurance cyber et les audits de donneurs d'ordre portent presque tous sur ces trois points. Les traiter ensemble évite de repasser trois fois sur le même réseau.
Questions fréquentes
Le SD-WAN remplace-t-il le pare-feu ?
Partiellement. Les boîtiers SD-WAN embarquent un filtrage applicatif et souvent un filtrage d'URL, ce qui suffit pour une agence commerciale. Sur un site principal qui héberge des serveurs ou expose des services, nous conservons un pare-feu dédié en coupure. La bonne question n'est pas « l'un ou l'autre » mais « quel niveau d'inspection sur quel site », et la réponse dépend de ce qu'il y a à protéger derrière.
Peut-on garder nos accès opérateurs actuels ?
Oui, dans la quasi-totalité des cas. Le SD-WAN est agnostique : il s'installe derrière les accès existants, quels que soient les opérateurs. C'est même un de ses intérêts, puisqu'il vous rend la liberté de changer d'opérateur site par site sans refaire l'architecture. Nous profitons souvent de l'étude pour identifier les accès surdimensionnés ou redondants qui se paient depuis des années.
Combien de temps dure une migration sur dix sites ?
Comptez trois à cinq mois, dont l'essentiel en attente de raccordement opérateur pour les accès complémentaires. La partie technique proprement dite représente une à deux journées par site. C'est pourquoi nous commandons les accès dès la validation de l'architecture : c'est le seul poste que nous ne maîtrisons pas.
Que se passe-t-il si le contrôleur SD-WAN est injoignable ?
Les boîtiers continuent de fonctionner avec la dernière politique reçue. Le contrôleur sert à distribuer la configuration et à agréger la supervision, pas à commuter le trafic : une indisponibilité empêche de modifier les règles, elle n'arrête pas le réseau. Nous vérifions ce comportement en recette, en coupant volontairement l'accès au contrôleur.