GUIDE RÉSEAU · SD-WAN MULTISITE
Concevoir un SD-WAN multisite sans déplacer les risques.
Le SD-WAN peut simplifier le pilotage de plusieurs accès et améliorer le routage applicatif. Il ne rend toutefois ni les liens indépendants, ni les applications disponibles, ni la sécurité automatique. La réussite dépend de l’inventaire, du modèle d’exploitation et d’une migration vérifiable site par site.
Que faut-il décider avant de choisir une solution SD-WAN ?
Définissez d’abord les profils de sites, les applications critiques, les chemins d’accès réellement disponibles, le modèle de sécurité et les responsabilités d’exploitation. Le produit vient ensuite. Un pilote représentatif doit prouver le routage, la bascule, la visibilité, la performance applicative et le retour arrière avant tout déploiement industriel.
- Point de départ
- Applications, sites et dépendances
- Preuve attendue
- Pilote mesuré sur plusieurs scénarios
- Risque fréquent
- Confondre deux contrats et deux chemins
- Condition de réussite
- Exploitation et sécurité clairement attribuées
Décisions structurantes d’un projet SD-WAN
| Domaine | Décision à prendre | Preuve à demander | Erreur à éviter |
|---|---|---|---|
| Accès | Combinaison fibre, Internet, mobile ou satellite par profil de site. | Éligibilité, chemins connus, mesures et délais écrits. | Supposer l’indépendance parce que les opérateurs diffèrent. |
| Applications | Règles de chemin, priorité, sortie Internet et comportement en mode dégradé. | Tests applicatifs avec latence, perte et coupure simulée. | Limiter la recette à un test de débit. |
| Sécurité | Segmentation, chiffrement, inspection, administration et journalisation. | Schéma des flux, matrice des droits et journaux exploitables. | Superposer des fonctions sans propriétaire opérationnel. |
| Exploitation | Supervision, changements, incidents, escalade et réversibilité. | RACI, tableaux de bord, procédures et export des configurations. | Découvrir le partage des rôles pendant une panne. |
1. Segmenter le parc en profils de sites
Un siège, un entrepôt, une agence et un point de vente n’ont ni les mêmes flux ni le même impact métier. Regroupez les sites selon leur activité, leur taille, leurs applications, leur exposition Internet et la durée de coupure acceptable. Chaque profil doit disposer d’une cible lisible : accès principal, secours, équipement, règles de routage et mode dégradé.
Cette segmentation limite les exceptions et permet de chiffrer le projet. Elle révèle aussi les sites atypiques qui nécessitent une étude dédiée plutôt qu’un modèle standard forcé. Associez à chaque donnée une date et une source afin que l’architecture ne repose pas sur un inventaire historique invérifiable.
- Profil métier et criticité
- Applications locales et cloud
- Accès et équipements existants
- Contraintes de locaux, d’énergie et de maintenance
2. Concevoir le routage à partir des applications
Le routage dynamique doit traduire une intention mesurable. Pour chaque application, précisez le chemin préféré, les seuils de dégradation, le chemin de secours et le comportement lorsqu’aucun accès ne respecte les objectifs. Une politique trop sensible provoque des bascules répétées ; une politique trop tolérante maintient un trafic critique sur un lien devenu inutilisable.
Testez la voix, la visioconférence, les VPN, le SaaS et les flux internes avec des scénarios de perte, de gigue, de latence et de coupure franche. Une session peut ne pas survivre à un changement d’adresse IP même si le second lien est disponible. La mesure doit donc porter sur l’usage, pas uniquement sur l’état du tunnel.
- Chemin préféré et seuils par application
- Sortie Internet locale ou centralisée
- Comportement des sessions pendant la bascule
- Capacité réservée aux flux prioritaires
3. Intégrer sécurité et administration dès la cible
Le plan doit montrer où s’appliquent segmentation, filtrage, chiffrement, inspection et authentification des administrateurs. Une fonction proposée par la plateforme n’est utile que si ses politiques, journaux, mises à jour et alertes sont exploités. Définissez les frontières entre l’équipe réseau, la sécurité, l’intégrateur et l’opérateur.
Protégez le plan d’administration avec des comptes nominatifs, une authentification forte, des droits minimaux et une journalisation centralisée. Prévoyez la perte du contrôleur ou de la liaison de gestion : les sites doivent conserver un comportement documenté et les opérations d’urgence doivent rester possibles sans contourner les règles.
- Segmentation et flux autorisés
- Identités, rôles et authentification forte
- Conservation et exploitation des journaux
- Fonctionnement en cas de perte du contrôle central
4. Piloter, migrer et préparer la réversibilité
Choisissez un pilote qui combine au moins un site critique, un accès imparfait et une application sensible. Écrivez les critères d’acceptation avant l’installation : performance, bascule, alertes, visibilité, sécurité, retour au lien principal et procédure de retour arrière. Un pilote qui ne teste que le cas nominal ne réduit pas le risque du déploiement.
La migration industrielle doit inclure la préparation du site, la fenêtre, les contacts, la recette et la mise à jour documentaire. Demandez les modalités d’export des politiques et configurations, les formats de journaux, la récupération des équipements et la continuité en fin de contrat. La réversibilité se négocie avant la dépendance technique.
- Pilote représentatif et scénarios de panne
- Critères d’acceptation signés
- Vague de déploiement et retour arrière
- Export, documentation et réversibilité contractuelle
Checklist avant décision
- Classer les sites par profil et criticité
- Cartographier les applications et leurs dépendances
- Vérifier les chemins physiques des accès
- Écrire les politiques et seuils par application
- Définir segmentation et administration
- Attribuer supervision, changement et escalade
- Tester le cas nominal et plusieurs pannes
- Documenter recette, retour arrière et réversibilité
Réponses complémentaires
Le SD-WAN remplace-t-il les accès opérateurs ?
Non. Il pilote plusieurs chemins mais dépend toujours de leur disponibilité, de leur capacité et de leur diversité physique.
Faut-il deux opérateurs sur chaque site ?
Pas nécessairement. Le choix dépend de la criticité et des infrastructures disponibles. Deux contrats ne garantissent pas deux chemins indépendants.
Peut-on migrer tous les sites en une seule vague ?
C’est rarement prudent pour un parc hétérogène. Un pilote puis des vagues par profil permettent de corriger la cible et les procédures.
Comment mesurer le succès ?
Avec des critères applicatifs, des temps de bascule, la qualité des alertes, la stabilité des politiques et la capacité des équipes à exploiter le service.
Sources et limites
Ces ressources publiques complètent l’étude. Elles ne remplacent ni un test sur place, ni l’éligibilité opérateur, ni les conditions contractuelles applicables au service concerné.
- ANSSI — Architecture sécurisée de système d’informationPrincipes de conception, de cloisonnement et d’administration d’une architecture sécurisée.
- Arcep — Guide numérique des entreprises 2026Ressources publiques sur les accès, la qualité de service et les réseaux professionnels.
Guide préparé par l’équipe éditoriale de Nicholas Owen Global Telecom et mis à jour le . Les prix, couvertures, délais et performances doivent être confirmés par écrit.