VPN, SD-WAN ou MPLS : comment relier plusieurs sites

01

Commencer par les besoins, pas par les sigles

L’Arcep recommande aux entreprises multisites de préciser le nombre de sites, les débits souhaités et le niveau de qualité de service attendu. Cette base doit être enrichie par la cartographie des applications. Où se trouvent les logiciels : siège, centre de données, cloud public, service hébergé ou chaque agence ? Quels utilisateurs y accèdent ? Quels flux sont sensibles à la latence, à la perte, au débit montant ou aux changements d’adresse ? Une architecture optimisée pour un ancien centre informatique central peut être inefficace lorsque la majorité des usages se trouve désormais dans le cloud.

Classez ensuite les sites. Un siège, une usine, une boutique, un entrepôt et un bureau temporaire n’ont pas le même nombre d’utilisateurs, les mêmes heures ni la même conséquence en cas de coupure. Pour chaque site, documentez les accès disponibles, le débit actuel mesuré, les flux critiques, la durée d’interruption acceptable, les contraintes de sécurité et les compétences locales. La taille n’est pas un indicateur suffisant : un petit site peut porter une opération indispensable.

Enfin, définissez qui doit exploiter le service. Une équipe interne peut souhaiter contrôler les tunnels et les politiques. Une autre organisation préfère un service géré avec un interlocuteur unique. Entre les deux, un intégrateur peut administrer les équipements sur des accès achetés séparément. Le modèle opérationnel influe sur la technologie, les responsabilités, la visibilité et la vitesse de changement. Une solution techniquement riche mais incomprise par l’équipe devient un risque.

• Sites, utilisateurs, horaires et criticité métier
• Applications, lieux d’hébergement et sens des flux
• Débits, latence, pertes et priorités par usage
• Accès disponibles, secours et diversité souhaitée
• Responsabilités internes, opérateur, intégrateur et fournisseurs cloud

02

Séparer le réseau de transport et la couche de service

Une interconnexion multisite comprend au moins des technologies d’accès physiques ou radio, comme la fibre, la 4G ou la 5G, puis un service de transport tel qu’un accès à internet ou un réseau privé opérateur. Des équipements de bordure, des mécanismes de routage, une sécurité et une exploitation complètent l’ensemble. Un VPN chiffré ou un SD-WAN forme ensuite une couche logique au-dessus d’un ou plusieurs de ces accès et services de transport. Mélanger ces niveaux conduit à comparer une fonction logicielle à un réseau complet.

Cette distinction permet aussi de comprendre les performances. Un SD-WAN ne crée pas de capacité absente : il utilise les liens fournis. Un VPN ne corrige pas une forte perte de paquets sur l’accès. Un réseau privé opérateur peut proposer une qualité maîtrisée dans son périmètre, mais les performances vers une application cloud dépendent aussi de la sortie, de l’interconnexion et du fournisseur distant. Chaque engagement doit être localisé sur la chaîne.

Dessinez donc deux schémas. Le schéma physique montre sites, liens, opérateurs, chemins et équipements. Le schéma logique montre segments, tunnels, routes, politiques, sorties internet et zones de sécurité. Ajoutez les points de supervision et les frontières contractuelles. Cette vue rend les combinaisons possibles : un accès MPLS principal et un internet de secours, deux accès internet avec VPN, ou un SD-WAN utilisant MPLS, fibre mutualisée et mobile selon les sites.

03

VPN site à site : une approche directe et maîtrisable

Dans son sens courant, un VPN site à site crée un tunnel logique entre des passerelles afin de relier des réseaux locaux. Lorsqu’il utilise IPsec, il peut apporter confidentialité, intégrité et authentification des communications selon sa configuration. L’ANSSI publie des recommandations dédiées à IPsec, qui rappellent l’importance du choix des mécanismes, de la gestion des clés et du paramétrage. Le mot VPN ne garantit donc pas seul un niveau de sécurité : le protocole, la configuration, les équipements et leur maintien comptent.

Cette approche est souvent lisible pour un petit nombre de sites et de chemins. Elle permet à l’organisation de choisir ses accès internet, ses pare-feu et son routage. Son coût et sa souplesse peuvent être adaptés lorsque les applications tolèrent la qualité de l’internet disponible et que l’équipe sait administrer les tunnels. Elle devient plus exigeante lorsque le nombre de sites croît : maillage, clés, routes, changements, supervision et résolution d’incidents doivent rester cohérents.

Le VPN ne fournit pas automatiquement une garantie de débit, une priorité de bout en bout ou un support unique. Ces éléments viennent des accès, des équipements et du service géré éventuellement souscrit. Un tunnel actif peut transporter un service dégradé. La supervision doit donc mesurer le chemin utile, pas seulement l’état cryptographique. Il faut aussi anticiper l’adressage, les chevauchements de réseaux, la traduction d’adresses, l’accès au cloud et le comportement lors d’une bascule de lien.

04

MPLS : comprendre le service opérateur derrière le terme

MPLS est une technologie de commutation utilisée dans les réseaux d’opérateurs. Dans les échanges commerciaux, le terme désigne souvent une offre de réseau privé reliant plusieurs sites avec une exploitation opérateur et, selon le contrat, des classes de service. Il faut demander la description exacte du service : accès inclus, cœur de réseau, routage, équipements, qualité, supervision, sortie internet, interconnexion cloud, support et responsabilités. Deux offres appelées MPLS peuvent avoir des périmètres différents.

Un service géré peut simplifier la responsabilité et offrir un comportement prévisible dans le périmètre couvert. Des classes permettent de traiter différemment la voix, les applications interactives ou les transferts, à condition que le trafic soit correctement marqué et que les capacités soient dimensionnées. Le bénéfice disparaît si tous les flux arrivent déjà saturés sur un accès trop petit ou si l’application se trouve au-delà du périmètre de qualité. Les classes et leur traitement doivent être écrits et testés.

Un réseau privé opérateur n’est pas synonyme de chiffrement de bout en bout. Selon la sensibilité et l’analyse de risque, un chiffrement supplémentaire peut être requis. L’accès au cloud et à internet doit aussi être conçu : sortie centralisée, sortie locale sécurisée, passerelle opérateur ou combinaison. Une centralisation peut faciliter le contrôle mais allonger certains chemins ; une sortie locale peut améliorer l’accès au cloud mais multiplie les points à protéger. Aucun choix n’est automatiquement correct.

05

SD-WAN : piloter plusieurs chemins avec des politiques

Le SD-WAN ajoute une couche de contrôle et d’orchestration aux connexions de réseau étendu. Selon la solution, des équipements ou logiciels en bordure établissent un réseau logique, mesurent les chemins et appliquent des politiques par application, site ou niveau de qualité. L’administration centralisée peut accélérer le déploiement de règles et donner une visibilité commune. La valeur apparaît surtout lorsque l’entreprise gère plusieurs sites, plusieurs accès ou des applications aux exigences différentes.

La sélection dynamique de chemin peut envoyer une application interactive sur le lien offrant les meilleures mesures et basculer lorsque celles-ci se dégradent. Mais la qualité dépend des sondes, seuils, temporisations et capacités réelles. Une mauvaise politique peut déplacer trop souvent les sessions, saturer un secours ou classer un flux incorrectement. Le comportement doit être défini par cas d’usage et validé pendant un pilote, y compris le retour au chemin principal.

Le SD-WAN ne constitue pas automatiquement une sécurité complète. Certaines offres intègrent chiffrement, pare-feu ou fonctions de sécurité ; d’autres s’articulent avec des services séparés. Il faut vérifier les fonctions, leur certification éventuelle, la segmentation, l’administration, les journaux, les mises à jour et la localisation du plan de contrôle. La plateforme centrale et les équipements de bordure deviennent des composants critiques. Le gain d’automatisation s’accompagne donc d’exigences de gouvernance et de maintien en condition de sécurité.

06

Comparer sans déclarer un vainqueur universel

Un VPN géré directement peut être le meilleur compromis pour quelques sites stables et une équipe compétente. Un service opérateur reposant sur MPLS peut rester pertinent lorsque la responsabilité unique, les classes de service et le comportement privé sont prioritaires. Un SD-WAN peut simplifier le pilotage d’un grand nombre de sites, diversifier les accès et orienter les flux cloud. Ces phrases décrivent des cas possibles, pas des règles. Le marché propose des services hybrides qui brouillent volontairement les frontières.

La comparaison doit porter sur des critères mesurables : disponibilité des accès à chaque adresse, débit garanti ou maximal, latence, perte, classes, délai de rétablissement, visibilité, délai d’ajout d’un site, prise en charge du cloud, segmentation, chiffrement, administration, réversibilité et coût complet. Ajoutez l’effort interne : expertise, astreinte, changements, inventaire, audits et traitement des incidents. Une offre moins chère en abonnement peut déplacer beaucoup d’exploitation vers l’entreprise.

Évaluez les limites assumées. Le VPN sur internet hérite de la variabilité et des frontières de support de ses accès. Le réseau opérateur peut réduire la liberté de changement ou imposer un chemin moins direct vers certains services. Le SD-WAN peut créer une dépendance à une plateforme, à des licences ou à un intégrateur. Ces limites ne condamnent aucune approche ; elles doivent être rendues compatibles avec les priorités et la capacité opérationnelle de l’organisation.

• VPN : contrôle direct et simplicité possibles, exploitation et qualité sous-jacente à maîtriser
• MPLS géré : périmètre opérateur et classes possibles, sécurité et accès cloud à préciser
• SD-WAN : politiques et visibilité centralisées possibles, plateforme et règles à administrer
• Hybride : adaptation fine par flux et site, architecture et responsabilités plus nombreuses

07

Concevoir l’accès au cloud et à internet

Les architectures historiques ramenaient souvent les flux des agences vers le siège ou un centre de données avant la sortie internet. Lorsque les utilisateurs travaillent principalement avec des services cloud, ce détour peut augmenter la latence et concentrer la capacité et le risque sur un point. Une sortie internet locale peut raccourcir le chemin, mais elle exige un filtrage, une protection, une journalisation et une administration cohérents sur chaque site ou via un service distribué.

Le choix doit suivre les flux. Les applications internes peuvent rester sur une interconnexion privée ; les services cloud approuvés peuvent sortir localement ; certaines données sensibles peuvent passer par une inspection centrale. Un SD-WAN peut appliquer ces politiques, mais un routage classique ou un service opérateur peut aussi réaliser certains scénarios. La technologie n’exonère pas de tenir une liste des destinations, des exigences de sécurité et des dépendances DNS, identité et authentification.

Pour une liaison directe vers un fournisseur cloud, vérifiez le point d’interconnexion, les débits, la redondance, les routes, les responsabilités et le comportement de secours vers internet. Une connexion privée au cloud n’améliore pas toutes les applications si celles-ci utilisent des services publics dispersés. Le pilote doit mesurer les parcours depuis plusieurs sites et en situation dégradée. La décision est réévaluée lorsque l’hébergement change, car l’architecture réseau doit suivre la localisation réelle des services.

08

Intégrer sécurité, cloisonnement et administration

L’ANSSI recommande de partir d’une analyse de risque, de cartographier le système d’information, de cloisonner les ressources selon leur sensibilité, de filtrer les flux et de protéger les opérations d’administration. Une interconnexion multisite étend le périmètre de confiance : un incident sur une agence peut atteindre d’autres sites si les segments communiquent librement. Les utilisateurs, serveurs, téléphonie, objets connectés, invités, prestataires et administration doivent recevoir seulement les communications nécessaires.

Le chiffrement est décidé selon le transport et le risque. IPsec peut protéger les échanges sur internet et, si nécessaire, ajouter une protection sur un réseau privé opérateur. Les algorithmes, clés, certificats, durées de vie, pairs et mécanismes de renouvellement sont gérés. Un tunnel chiffré entre deux équipements compromis ne sécurise pas les réseaux situés derrière eux. Il complète les contrôles d’accès, la segmentation, les mises à jour, l’authentification et la détection.

Les équipements de bordure et consoles d’orchestration sont particulièrement sensibles. L’ANSSI souligne dans son Panorama de la cybermenace 2025 l’intérêt persistant des attaquants pour les équipements de bordure vulnérables. Les interfaces d’administration ne sont pas exposées inutilement, l’authentification forte est utilisée lorsque disponible, les comptes sont maîtrisés, les versions suivies et les correctifs appliqués selon une procédure. Les sauvegardes de configuration et journaux sont protégés et testés pour la restauration.

09

Construire la résilience sur des causes de panne concrètes

Deux liens ne suffisent pas à prouver la haute disponibilité. Ils peuvent emprunter la même adduction, le même génie civil, le même point de mutualisation, le même opérateur, le même routeur, la même alimentation ou le même local. Cartographiez les dépendances communes et sélectionnez les scénarios prioritaires : coupure physique, panne d’équipement, incident opérateur, erreur de configuration, indisponibilité de la plateforme de contrôle, perte d’un tunnel ou coupure électrique.

La diversité peut combiner fibre dédiée ou mutualisée, accès d’un second opérateur, réseau mobile ou autre technologie. Le niveau nécessaire dépend du site et du coût de l’arrêt. Le secours doit disposer de routes, de tunnels, de capacité et de sécurité prêtes. Une bascule qui exige de reconfigurer manuellement plusieurs équipements par un expert absent ne respecte pas un objectif de reprise court. Inversement, l’automatisation ajoute des règles et doit être surveillée pour éviter les oscillations.

Testez le réseau de bout en bout. Coupez un accès, rendez un chemin dégradé, interrompez un tunnel et observez la sélection, les sessions, les appels et les applications. Vérifiez les alertes et le retour à la normale. Si un réseau MPLS reste principal, testez le secours internet ou mobile. Si le SD-WAN dépend d’un orchestrateur cloud, vérifiez le comportement des sites lorsqu’il devient injoignable. Si les VPN sont en maillage, confirmez que les routes convergent sans créer de boucle ou d’isolement.

10

Choisir un modèle d’exploitation et des responsabilités claires

Trois modèles sont fréquents : exploitation interne, service entièrement géré et modèle partagé. Dans le premier, l’entreprise contrôle les politiques et assume les compétences, l’astreinte et la maintenance. Dans le second, un fournisseur livre un résultat défini, mais l’entreprise doit conserver visibilité, gouvernance et capacité d’escalade. Dans le troisième, il faut éviter les zones grises : qui modifie une route, qui renouvelle un certificat, qui diagnostique l’accès et qui valide une règle de sécurité ?

Un catalogue de changements précise les délais et autorisations pour ajouter un site, augmenter un débit, créer un segment, ouvrir un flux, intégrer une application cloud ou remplacer un équipement. Les changements urgents suivent une procédure différente avec traçabilité et retour arrière. Les droits sur l’orchestrateur sont séparés selon les rôles. L’entreprise garde un export de sa configuration et connaît les conditions de restitution ou de migration en fin de contrat.

Le support est évalué sur sa chaîne réelle. Un intégrateur peut dépendre de plusieurs opérateurs d’accès et d’un éditeur SD-WAN. Le contrat doit indiquer l’interlocuteur, le périmètre, les heures, les garanties, les exclusions et l’escalade. Une GTR d’accès ne vaut pas nécessairement pour le service intersite complet. Les identifiants de chaque circuit et les contacts sont accessibles, et la supervision doit permettre de distinguer une panne locale, un transport dégradé, une politique incorrecte et une application indisponible.

11

Préparer un pilote représentatif et une migration réversible

Le pilote ne doit pas choisir uniquement le site le plus simple. Sélectionnez un petit ensemble représentant les situations importantes : siège ou centre, agence standard, site avec mauvaise couverture, application temps réel, cloud, téléphonie et secours. Définissez avant l’installation les critères de réussite : performances, stabilité, visibilité, délai de bascule, facilité de changement, sécurité et qualité du support. Sans critères, une démonstration réussie peut masquer les difficultés quotidiennes.

La migration se réalise par vagues. Le nouvel équipement est préparé, la configuration relue et sauvegardée, les routes et segments testés, puis le site bascule dans une fenêtre connue. Une coexistence temporaire permet de revenir au chemin antérieur lorsque c’est techniquement possible. Les règles de routage doivent éviter les asymétries et boucles pendant cette période. Chaque vague produit des enseignements intégrés au modèle avant la suivante.

Les applications sont testées depuis le site, pas seulement par un ping entre équipements. Mesurez ouverture de session, voix, transfert, accès cloud et comportement en panne. Les utilisateurs signalent les différences. Après stabilisation, les anciens liens ne sont résiliés qu’après vérification du périmètre, des dépendances et des engagements. Pour une transformation MPLS vers internet ou SD-WAN, conservez une stratégie de retour réaliste : certaines opérations contractuelles ou de routage deviennent difficiles à inverser après suppression du service historique.

• Sites pilotes représentatifs des contraintes réelles
• Critères mesurables définis avant la démonstration
• Configurations revues, sauvegardées et restaurables
• Applications, sécurité, bascule et retour testés
• Déploiement par vagues avec décision de passage documentée

12

Mesurer le service après la mise en production

La supervision combine état des liens, débit, latence, variation, pertes, tunnels, routes, classes de trafic et disponibilité des équipements. Elle doit montrer le parcours utilisé par une application et les changements de chemin. Les mesures sont conservées assez longtemps pour distinguer un incident ponctuel d’une dégradation progressive. Un tableau de bord trop agrégé peut afficher un site disponible alors que son application critique ne fonctionne plus.

Les indicateurs contractuels et métiers sont rapprochés. Nombre d’incidents, durée, respect des engagements, qualité des notifications et récurrence par site complètent les mesures techniques. Les règles SD-WAN ou de qualité de service sont revues lorsque le trafic évolue. Une nouvelle application cloud, un changement d’horaires ou une augmentation de sauvegarde peut invalider le dimensionnement initial. La capacité se pilote avant saturation plutôt qu’après plaintes.

Des revues de sécurité vérifient versions, vulnérabilités, comptes, certificats, flux autorisés, journaux et exposition des interfaces. Les exercices de panne confirment que les équipes savent diagnostiquer et que le secours reste opérationnel. Enfin, la cartographie, les contrats et les contacts sont mis à jour à chaque ajout ou suppression de site. Le réseau multisite reste maîtrisé lorsqu’un tiers peut comprendre son architecture, ses dépendances et ses procédures à partir d’une documentation tenue à jour.

13

Checklist de décision VPN, SD-WAN, MPLS ou hybride

La décision finale doit expliquer pourquoi l’architecture répond mieux au contexte que les alternatives sérieuses. Elle reprend les flux, sites, performances, sécurité, disponibilité, exploitation, migration et réversibilité. Elle distingue les faits confirmés des hypothèses de disponibilité ou de délai. Chaque offre est comparée sur le même périmètre et avec ses conditions contractuelles, pas sur des appellations générales.

Un VPN sur internet peut être retenu si les accès répondent au besoin, si la qualité acceptable est connue et si l’administration est maîtrisée. Un service MPLS peut être retenu si ses classes, son support et sa responsabilité opérateur correspondent aux applications. Un SD-WAN peut être retenu si la politique multi-chemins, la visibilité et l’automatisation apportent une valeur supérieure à la complexité introduite. Une architecture hybride peut répartir ces rôles par site et par flux.

Le bon résultat n’est donc pas une technologie gagnante, mais une architecture explicable et testable. Ses limites sont écrites : applications non secourues, dépendances communes, performance non garantie sur internet, changement de sessions lors d’une bascule ou fonctions dépendantes d’une plateforme. Cette honnêteté permet d’organiser le mode dégradé, de négocier les bons engagements et de faire évoluer le réseau sans reconstruire tout le raisonnement.

• Cartographie des flux, applications et lieux d’hébergement validée
• Disponibilité et qualité des accès confirmées par adresse
• Sécurité, chiffrement, segmentation et administration définis
• Responsabilités, support, garanties et exclusions relus
• Pilote, migration, retour arrière et réversibilité préparés
• Coût complet incluant licences, équipements et exploitation comparé

FAQ

Questions fréquentes