SD-WAN vs MPLS, quel réseau pour vos flux critiques ?

Une entreprise industrielle française, qui deviendra par la suite notre client, choisit de migrer l’intégralité de son infrastructure réseau en SD-WAN. À cette période, les médias spécialisés vantaient les mérites de cette technologie tandis que de nombreux prestataires improvisaient des offres pour surfer sur la tendance. Pour beaucoup, le MPLS vivait ses derniers moments de gloire. Trois ans plus tard, cette entreprise a choisi de reconstruire une partie de son réseau autour d’un backbone MPLS. La téléphonie IP était devenue très difficile à exploiter aux heures de pointe, les visioconférences avec les clients subissaient des dégradations régulières et l’ERP ralentissait lorsque plusieurs synchronisations importantes sollicitaient simultanément les accès.

Ce retour d’expérience n’a pas démontré que le SD-WAN était une mauvaise technologie. Il a surtout montré qu’une couche de pilotage ne corrige pas les caractéristiques du transport situé en dessous. Le SD-WAN était capable de mesurer la qualité des chemins et de déplacer les flux lorsqu’un accès se dégradait, mais il ne pouvait pas créer sur des accès Internet best effort les propriétés qu’ils ne possédaient pas. C’est le point central de notre position sur le SD-WAN vs MPLS. Le SD-WAN pilote très efficacement les chemins disponibles, tandis que le MPLS conserve un avantage lorsque nous voulons maîtriser et contractualiser le transport des flux critiques.

La technologie SD-WAN a donc toute sa place dans un réseau WAN multi-sites, mais cette place n’est pas nécessairement celle d’un remplacement généralisé du MPLS. L’expérience nous conduit plutôt à distinguer les applications, les implantations et le niveau de service attendu. Une agence principalement tournée vers Microsoft 365 n’a pas les mêmes contraintes qu’un siège hébergeant un ERP, une plateforme téléphonique ou des applications industrielles. Le choix d’architecture doit commencer par cette différence.

Le SD-WAN pilote plusieurs liens mais reste dépendant de leur qualité

Comment fonctionne le SD-WAN dans un réseau multi-sites

Le SD-WAN, ou Software-Defined Wide Area Network, ajoute une couche de pilotage au WAN afin d’identifier les flux et de choisir le chemin utilisé selon des politiques définies. Selon les architectures, les accès sous-jacents peuvent être une fibre FTTO, une fibre FTTH, une connexion Internet, de la 4G ou de la 5G, mais également une liaison MPLS. Réduire le SD-WAN à une technologie fonctionnant exclusivement sur Internet serait donc inexact. Son intérêt vient précisément de sa capacité à exploiter plusieurs transports et à leur attribuer des rôles différents.

Le contrôleur et les équipements SD-WAN mesurent la qualité des chemins disponibles et appliquent les politiques de routage définies pour les applications. Un trafic SaaS peut être envoyé directement vers Internet, tandis qu’un flux intersites plus sensible emprunte un autre transport. Lorsqu’un accès se dégrade ou devient indisponible, le SD-WAN peut réorienter les flux vers un chemin encore exploitable. Cette capacité à piloter plusieurs accès constitue son principal avantage face à un WAN construit autour d’un seul transport.

La liberté dans le choix des opérateurs et des technologies d’accès reste également un argument fort. Chaque implantation peut être raccordée avec la solution disponible localement, sans imposer une boucle locale identique à l’ensemble du parc. Pour des entreprises géographiquement dispersées, des sites temporaires ou des implantations principalement orientées vers le cloud, cette souplesse est particulièrement intéressante. Le point de vigilance apparaît lorsqu’on attribue au SD-WAN des propriétés qui appartiennent en réalité aux liens qu’il pilote.

La QoS du SD-WAN reste limitée par les transports disponibles

Un moteur SD-WAN peut classifier un flux, lui attribuer une politique spécifique et mesurer en permanence la qualité des chemins susceptibles de le transporter. Il peut donc éviter un accès qui commence à perdre des paquets ou dont la latence se dégrade. En revanche, lorsqu’un flux traverse l’Internet public, la plateforme SD-WAN ne contrôle pas les files d’attente et les politiques appliquées par tous les réseaux intermédiaires. Le SD-WAN sait sélectionner le meilleur chemin disponible, mais il ne transforme pas un accès Internet instable en transport prévisible.

La différence devient particulièrement sensible avec des applications temps réel. Une navigation Web, un transfert de fichiers ou la majorité des échanges de messagerie supportent relativement bien certaines variations du réseau. La voix et la visioconférence sont plus sensibles à la gigue, aux pertes et aux variations de latence. Un SD-WAN peut détecter une dégradation et déplacer le trafic vers un autre chemin, ce qui constitue une protection utile, mais ce mécanisme ne doit pas être confondu avec une QoS appliquée sur l’ensemble du réseau traversé.

Ce constat ne remet pas en cause la pertinence du SD-WAN. Il remet en cause la promesse parfois formulée selon laquelle une intelligence logicielle placée aux extrémités permettrait de recréer les caractéristiques d’un réseau privé sur n’importe quels accès Internet. Ajouter une couche SD-WAN au-dessus de deux liens best effort ne crée pas une troisième liaison possédant les garanties absentes des deux premières. Pour comprendre pourquoi cette nuance compte autant pour la voix, notre article consacré à la QoS pour la téléphonie IP détaille l’effet de la latence, de la gigue et de la perte de paquets sur les communications temps réel.

Les coûts du SD-WAN dépassent le prix des accès Internet

Licences, équipements et services SD-WAN doivent entrer dans le calcul

Le SD-WAN n’est pas un simple paramétrage réseau ajouté gratuitement à deux connexions Internet. Chaque site doit disposer d’une fonction SD-WAN, portée par un CPE dédié, un firewall intégrant cette fonction ou une appliance virtuelle selon l’architecture retenue. À cela peuvent s’ajouter des licences logicielles, le contrôleur ou l’orchestrateur, les fonctions de sécurité, le support et éventuellement un service managé. Le coût d’un réseau SD-WAN doit donc être évalué à l’échelle de l’architecture complète et pas uniquement à partir du prix des liens Internet.

Le MPLS supporte lui aussi des coûts d’équipement, de supervision et d’exploitation, mais ceux-ci sont généralement intégrés dans le service opérateur plutôt que présentés sous la forme de licences logicielles distinctes. Cette différence de modèle économique peut donner une perception trompeuse au moment du devis. Une FTTH et une licence SD-WAN semblent facilement moins coûteuses qu’un accès privé opéré lorsqu’on ne compare que les deux premières lignes du tableau. Sur plusieurs années, la redondance, les équipements, le support et le temps consacré à l’exploitation peuvent réduire cet écart.

L’inverse reste évidemment vrai sur des sites légers. Une agence à trois postes utilisant presque exclusivement des services SaaS n’a aucune raison de financer le même niveau de transport qu’une plateforme de production. Notre position pro-MPLS ne consiste donc pas à installer du MPLS partout, mais à comparer le coût du service au coût réel d’une dégradation sur les sites qui portent des flux critiques.

L’administration SD-WAN centralise les règles mais ne supprime pas le diagnostic

L’administration centralisée est l’une des forces du SD-WAN. Une politique de routage peut être déployée sur plusieurs implantations depuis une même plateforme, sans configurer indépendamment chaque routeur. Cette centralisation facilite l’exploitation d’un grand nombre de sites, mais elle ne fait pas disparaître les différentes couches impliquées lorsqu’un incident survient. Les accès opérateurs, les équipements locaux, l’overlay SD-WAN, les éventuels tunnels chiffrés, les politiques applicatives et les services utilisés par l’entreprise restent autant d’éléments à examiner.

Prenons le cas d’un utilisateur du site de Lyon qui signale une mauvaise qualité d’appel. L’équipe IT peut constater dans la plateforme SD-WAN qu’un chemin présente une hausse de gigue et que le trafic a basculé sur un second accès. Elle doit néanmoins déterminer pourquoi le premier lien s’est dégradé, vérifier si le second possède suffisamment de capacité et identifier l’acteur responsable du rétablissement. La console SD-WAN améliore la visibilité sur le comportement de l’overlay, mais la qualité de l’exploitation dépend aussi de la visibilité disponible sur les réseaux sous-jacents.

C’est à cet endroit que le modèle de support devient aussi important que la technologie. Lorsque trois opérateurs différents fournissent les accès, une architecture peut être techniquement très résiliente tout en laissant la DSI coordonner trois supports lors d’un incident complexe. À l’inverse, une exploitation à guichet unique peut masquer cette diversité et prendre en charge directement la relation avec les fournisseurs physiques. Le vrai coût ne se mesure donc pas uniquement dans les licences et les accès, mais également dans le temps nécessaire pour comprendre puis résoudre une dégradation.

La dépendance à l’éditeur SD-WAN doit être traitée comme un choix d’architecture

Le réseau SD-WAN repose généralement sur une plateforme logicielle propriétaire et sur son modèle d’orchestration. Cela n’implique pas qu’une panne du contrôleur fasse systématiquement tomber tout le réseau, puisque le comportement en mode dégradé dépend de chaque implémentation. En revanche, une entreprise doit connaître précisément ce qui continue de fonctionner lorsque le plan de contrôle ou l’orchestrateur n’est plus joignable, ainsi que les mécanismes de haute disponibilité, les cycles de support et les conditions de licence de la plateforme retenue.

La pérennité de l’éditeur mérite également d’être intégrée dans la décision. Le marché du SD-WAN a connu plusieurs acquisitions importantes et ces changements peuvent influer sur les roadmaps, les licences ou les politiques de support. Là encore, le sujet n’est pas de considérer cette dépendance comme rédhibitoire, mais de l’assumer dans une infrastructure appelée à fonctionner pendant plusieurs années. Un WAN ne se remplace pas avec la même facilité qu’une application SaaS secondaire.

Le MPLS présente une dépendance différente. Le protocole et les mécanismes associés sont standardisés, mais le service dépend évidemment de l’architecture, du backbone et des engagements de l’opérateur qui l’exploite. Le choix ne consiste donc pas à opposer une technologie propriétaire à une technologie sans dépendance, mais à décider quelle dépendance la DSI souhaite confier à son opérateur et laquelle elle souhaite conserver dans sa propre architecture.

Le MPLS conserve un avantage lorsque la QoS doit être maîtrisée

La QoS MPLS s’applique sur le domaine exploité par l’opérateur

Le détail du fonctionnement du MPLS est traité dans notre article consacré au protocole, aux labels et aux LSP. Pour le comparatif avec le SD-WAN, la différence déterminante tient au périmètre sur lequel la politique de trafic peut être réellement appliquée. MPLS fournit les mécanismes permettant de prendre en charge DiffServ et de différencier les traitements dans le réseau. La qualité obtenue dépend ensuite du dimensionnement, des files d’attente, des classes configurées et du service que l’opérateur s’engage effectivement à fournir.

Dans un service MPLS correctement dimensionné, l’opérateur maîtrise les équipements sur lesquels la politique de QoS doit être appliquée. Cette maîtrise permet de réserver ou de protéger de la capacité pour certaines classes de trafic, de superviser les indicateurs réseau et de contractualiser des engagements qui ne reposent plus uniquement sur l’état instantané d’un accès Internet. Chez Napsis, jusqu’à cinq classes de service permettent notamment de distinguer la voix et la visioconférence des applications métier puis des flux moins prioritaires.

Quand une entreprise fait transiter téléphonie, visioconférence, ERP et sauvegardes sur un même WAN, cette hiérarchisation devient très concrète. Un commercial qui passe deux heures par jour au téléphone ne voit pratiquement aucune différence lorsque le réseau est peu sollicité. Il la perçoit immédiatement lorsqu’une sauvegarde ou un transfert important commence à consommer une part significative du lien. L’intérêt du MPLS n’est pas d’empêcher toute congestion, mais de donner à l’opérateur les moyens de protéger les flux qui ne doivent pas être sacrifiés lorsqu’elle apparaît.

La cybersécurité n’est imposée ni par le SD-WAN ni par MPLS

L’article original opposait une sécurité SD-WAN nécessairement distribuée à une sécurité MPLS nécessairement centralisée. Cette distinction est trop simple. Un SD-WAN peut s’appuyer sur des firewalls locaux, des politiques centralisées ou une architecture SASE, tandis qu’un réseau MPLS peut lui aussi combiner des fonctions de sécurité centrales et locales. Le choix SD-WAN vs MPLS ne définit donc pas à lui seul l’architecture de cybersécurité.

Dans l’architecture que nous privilégions pour certains réseaux MPLS, la sortie Internet et le firewall peuvent être centralisés en cœur de réseau. Cette organisation présente un intérêt opérationnel lorsque plusieurs sites doivent partager les mêmes règles, la même journalisation et une supervision commune. Une modification de politique peut alors être appliquée de manière cohérente sans dépendre d’une configuration indépendante sur chaque agence.

Le SD-WAN permet également de maintenir des politiques homogènes lorsque l’architecture de sécurité a été conçue pour cela. La différence apparaît surtout avec les sorties Internet locales et les architectures multi-éditeurs, qui demandent de vérifier que les règles restent cohérentes quel que soit le chemin utilisé par le trafic. La question utile pour une DSI n’est pas de savoir si le firewall est central ou distribué, mais si la politique de sécurité reste identique lorsque les applications et les chemins réseau évoluent. Notre article sur le firewall d’entreprise approfondit cette articulation entre filtrage, segmentation et architecture WAN.

La supervision doit couvrir le SD-WAN et les liens qu’il pilote

Les plateformes SD-WAN mesurent la performance des différents chemins et disposent généralement de fonctions de supervision très utiles pour comprendre les décisions de routage. Elles peuvent montrer qu’un lien se dégrade, qu’un trafic a été déplacé ou qu’une politique donnée a été appliquée. Le problème opérationnel commence lorsque la console constate le symptôme sans fournir suffisamment d’informations sur la cause située dans le réseau de l’opérateur.

Dans un réseau MPLS opéré, la supervision peut couvrir à la fois les accès et le domaine de transport dont le fournisseur a la responsabilité. Latence, gigue, perte de paquets, disponibilité et consommation peuvent alors être rapprochées de l’état du lien et des engagements contractuels. Pour nous, la valeur de la supervision vient surtout de sa capacité à distinguer une saturation locale, une dégradation opérateur et un problème applicatif, puis à déclencher la bonne chaîne de support.

Notre architecture VPN d’entreprise opérée repose précisément sur cette logique d’exploitation. Les accès dédiés peuvent bénéficier d’une disponibilité mensuelle contractuelle de 99,8 %, d’une GTR de quatre heures et d’une prise en charge en trente minutes pour un incident bloquant selon le niveau de service souscrit. Ces indicateurs appartiennent au service opéré par Napsis et ne doivent pas être confondus avec des propriétés intrinsèques du protocole MPLS.

Les réseaux MPLS modernes ont corrigé une partie de leur rigidité historique

Le reproche historique fait au MPLS était sa rigidité. L’ajout d’un site pouvait demander du temps, la dépendance à un opérateur limitait parfois le choix de la boucle locale et la visibilité applicative était faible côté client. Ces critiques expliquent en partie pourquoi le SD-WAN a trouvé aussi rapidement sa place dans les réseaux d’entreprise, mais les architectures MPLS ont elles aussi évolué depuis les premiers déploiements.

Segment Routing illustre cette évolution. Dans un environnement SR-MPLS, une liste de segments portée par des labels permet de piloter le chemin suivi dans le domaine MPLS sans maintenir le même état par tunnel sur tous les équipements intermédiaires. Cette architecture apporte davantage de souplesse à l’ingénierie du backbone et facilite certains mécanismes de steering. Elle ne transforme pas pour autant MPLS en SD-WAN, puisque le SD-WAN continue d’agir à un autre niveau en choisissant entre plusieurs transports disponibles.

La virtualisation des fonctions réseau, l’automatisation et les plateformes de supervision ont également réduit une partie de l’écart qui existait historiquement entre réseau privé et architectures logicielles. De notre côté, la collecte multi-opérateurs supprime également l’obligation de choisir le même opérateur physique sur tous les sites. Le MPLS que nous exploitons aujourd’hui n’est donc plus un réseau monolithique qui impose la même boucle locale partout, mais un service de transport capable de s’appuyer sur des collectes différentes selon l’éligibilité de chaque implantation.

Cela ne signifie pas que MPLS absorbe tous les cas d’usage du SD-WAN. La sortie locale vers le cloud, l’utilisation simultanée de plusieurs accès ou certaines politiques applicatives restent précisément des domaines où le SD-WAN est très pertinent. Notre conviction est simplement que les arguments qui présentaient autrefois le MPLS comme une technologie nécessairement rigide et le SD-WAN comme son successeur direct décrivent de moins en moins les architectures réellement déployées.

Comparatif SD-WAN vs MPLS sur les critères opérationnels

Critère	SD-WAN	MPLS opéré
Fonction principale	Pilotage et sélection de plusieurs chemins	Transport opéré et services réseau
Types de liens	Internet, MPLS, fibre, 4G/5G selon l’architecture	Accès collectés vers le réseau privé
QoS	Classification et sélection de chemin, qualité finale dépendante des transports	Classes de service applicables sur le domaine maîtrisé
Internet public obligatoire	Non	Non
Multi-liens	Fonction centrale du SD-WAN	Possible selon l’architecture
Multi-opérateurs	Compatible avec plusieurs fournisseurs	Possible avec une collecte multi-opérateurs
Chiffrement	Généralement utilisé sur l’overlay selon la solution	Non natif au MPLS, IPsec peut être ajouté
Cloud et SaaS	Très adapté aux sorties Internet locales	Possible, mais un passage systématique par le cœur n’est pas toujours pertinent
Détection des dégradations	Mesure active et politiques de basculement	Supervision opérateur et SLA selon le service
Résilience	Arbitrage dynamique entre les liens disponibles	Redondance construite selon les accès souscrits
Exploitation	Interne ou managée, dépend de la plateforme et des underlays	Souvent prise en charge par l’opérateur
Dépendance principale	Plateforme SD-WAN et qualité des transports	Opérateur et architecture de transport
Usage privilégié chez Napsis	Multi-liens, SaaS, sites légers ou hybrides	Flux intersites critiques nécessitant QoS et engagements

Notre préférence pour le MPLS sur les flux critiques apparaît clairement dans ce tableau, mais elle ne repose pas sur l’idée que le SD-WAN serait une technologie inférieure. Les deux ne remplissent simplement pas la même fonction. Le SD-WAN décide comment utiliser les chemins disponibles, tandis qu’un service MPLS peut fournir l’un de ces chemins avec un niveau de maîtrise supérieur à celui d’un accès Internet best effort.

L’architecture hybride conserve MPLS là où le SD-WAN ne suffit pas

La question n’est donc pas simplement de choisir entre SD-WAN et MPLS pour l’ensemble de l’entreprise. Elle consiste à déterminer quels flux et quels sites ont réellement besoin d’un transport dont la qualité peut être maîtrisée. Dans l’architecture que nous privilégions, MPLS reste le socle des implantations critiques tandis que SD-WAN, Internet ou IPsec couvrent les usages pour lesquels une garantie de transport équivalente n’apporte pas de valeur métier.

Un siège qui concentre la téléphonie, l’ERP et plusieurs applications centrales peut conserver un accès MPLS dimensionné avec différentes classes de service. Une agence principalement tournée vers Microsoft 365 peut utiliser une fibre Internet. Un site temporaire peut rejoindre le réseau en IPsec sur une connexion fixe ou mobile. Enfin, un site important peut disposer simultanément d’un transport MPLS, d’un accès Internet et d’une 4G ou 5G de secours pilotés par un équipement SD-WAN.

Cette combinaison évite deux erreurs fréquentes. La première consiste à déployer du MPLS sur chaque site simplement parce qu’il fait partie de l’architecture historique. La seconde consiste à remplacer partout le réseau privé par des accès Internet sous prétexte qu’une couche SD-WAN saura compenser leur variabilité. Le travail d’ingénierie consiste précisément à réserver le transport le plus exigeant aux usages qui justifient son coût.

Collecte multi-opérateurs et MPLS natif dans l’approche Napsis

Notre approche repose sur un constat d’ingénierie. La couche MPLS est native sur notre backbone, ce qui nous permet de construire des réseaux privés sans dépendre d’un opérateur physique unique pour chaque boucle locale. Grâce à une collecte sur plus de quinze opérateurs nationaux et cinquante opérateurs locaux, nous pouvons choisir l’accès en fonction de l’éligibilité, du coût et du niveau de service disponible sur chaque implantation, tout en maintenant une architecture commune au-dessus de ces accès.

Le choix de l’opérateur d’accès et le choix du mode de transport deviennent ainsi deux décisions distinctes. Une agence peut être raccordée par un opérateur local tandis qu’une autre utilise une infrastructure nationale, sans obliger le client à administrer lui-même plusieurs réseaux indépendants. Cette capacité réduit une partie de l’avantage historique du SD-WAN sur la liberté de choix des fournisseurs, tout en conservant un réseau privé opéré pour les flux qui le nécessitent.

Le coût doit ensuite être comparé architecture par architecture. Un accès Internet complété par un second lien, un équipement SD-WAN, les licences et le service managé peut se rapprocher du coût d’un accès privé sur certains sites. Sur d’autres, l’écart reste suffisamment important pour justifier Internet. Nous ne cherchons donc pas à démontrer que MPLS est toujours moins cher, mais qu’il faut comparer le coût global au niveau de service réellement obtenu.

Lorsqu’un site ne justifie pas un transport MPLS, un tunnel IPsec peut également l’intégrer au réseau privé. Notre comparatif MPLS vs IPsec détaille les différences entre les deux modèles sur le chiffrement, la QoS, la supervision et la résilience.

Un guichet unique pour superviser MPLS, Internet et SD-WAN

L’autre dimension de l’architecture concerne l’exploitation quotidienne. En cas de problème sur un accès, un seul interlocuteur doit pouvoir traiter la sollicitation quel que soit l’opérateur physique concerné. L’interface de supervision doit également permettre de rapprocher la consommation, la disponibilité et les indicateurs de qualité du site sans obliger la DSI à reconstruire elle-même le diagnostic à partir de plusieurs consoles.

C’est sur ce point que nous préférons une architecture multi-opérateurs exploitée comme un seul réseau plutôt qu’une simple juxtaposition de liens et de plateformes. Le SD-WAN peut parfaitement participer à cette architecture, mais il ne doit pas devenir une couche supplémentaire dont le client supporte seul les interactions avec les fournisseurs d’accès, la sécurité et la téléphonie.

Cette logique d’exploitation se retrouve dans la durée moyenne de nos relations clients, qui approche les dix ans. La technologie du WAN évolue beaucoup plus vite que les besoins fondamentaux qui nous sont confiés. Les sites doivent communiquer, les applications critiques doivent conserver un niveau de service stable et le client doit savoir qui appeler lorsque ce n’est plus le cas.

SD-WAN vs MPLS se décide à partir des flux réels

Notre position reste volontairement favorable au MPLS pour les flux critiques. Elle ne repose pourtant pas sur l’idée que le SD-WAN aurait échoué ou qu’il faudrait revenir à une architecture identique à celles des années 2010. Le SD-WAN est un excellent outil lorsqu’il faut exploiter plusieurs chemins, orienter les applications et adapter rapidement le WAN. Le MPLS reste notre choix privilégié lorsqu’un de ces chemins doit offrir un niveau de transport prévisible et exploitable avec des engagements mesurables.

La nuance est importante pour une DSI. Un SD-WAN peut améliorer très fortement un réseau composé de plusieurs accès correctement choisis. Il ne peut pas rendre inutile le travail de conception de ces accès. Si deux liens sont sous-dimensionnés, mal diversifiés ou tous deux soumis aux mêmes contraintes de transport, le meilleur moteur de routage du marché ne pourra qu’arbitrer entre deux mauvaises options.

À l’inverse, maintenir tout le trafic sur MPLS alors que les usages migrent vers Microsoft 365, les applications SaaS et les services cloud n’est pas davantage une bonne architecture. Certains flux peuvent sortir directement vers Internet et certaines implantations peuvent parfaitement fonctionner sans réseau privé opéré. Notre lecture du SD-WAN vs MPLS consiste donc à garder MPLS là où sa maîtrise du transport a une valeur opérationnelle mesurable, et à utiliser le SD-WAN là où sa souplesse apporte réellement quelque chose.

Pour passer de cet arbitrage à une architecture exploitée, notre page consacrée au VPN d’entreprise multi-sites détaille la façon dont MPLS, IPsec, accès Internet et liens de secours peuvent être combinés sous une supervision commune.

Questions fréquentes sur SD-WAN et MPLS

Quelle est la différence entre SD-WAN et MPLS ?

Le SD-WAN pilote plusieurs chemins réseau selon des politiques et leur qualité mesurée, tandis que MPLS est utilisé pour construire des services de transport opérés avec des classes de trafic maîtrisées. Un SD-WAN peut d’ailleurs utiliser une liaison MPLS parmi ses transports. Les deux technologies ne travaillent donc pas exactement au même niveau de l’architecture WAN.

Le SD-WAN peut-il remplacer le MPLS ?

Le SD-WAN peut remplacer le MPLS sur des sites et des flux qui ne nécessitent pas le même niveau de maîtrise du transport. Pour des usages sensibles à la latence, à la gigue ou aux pertes, nous conservons du MPLS lorsqu’un service opéré avec QoS et engagements mesurables apporte une garantie utile. Une architecture hybride permet d’éviter d’appliquer la même réponse à tous les sites.

Le SD-WAN garantit-il la QoS sur Internet ?

Le SD-WAN peut classifier les applications, mesurer la qualité des chemins et déplacer un flux vers un meilleur accès. Il ne peut pas imposer à des réseaux Internet tiers les politiques de file d’attente ou de traitement qu’ils doivent appliquer. La qualité finale dépend donc toujours des transports disponibles et de leur dimensionnement.

Le SD-WAN coûte-t-il moins cher que le MPLS ?

Un accès Internet est souvent moins coûteux qu’un service privé équivalent, mais le coût complet du SD-WAN comprend aussi les équipements, les licences éventuelles, la sécurité, les accès de secours, la supervision et l’exploitation. La comparaison pertinente porte sur le coût global du réseau et non sur le seul prix de l’accès.

Pourquoi combiner SD-WAN et MPLS ?

Une architecture hybride permet de conserver MPLS pour les sites ou les flux qui exigent un transport maîtrisé et d’utiliser Internet, la 4G ou la 5G pour les usages moins sensibles. Le SD-WAN peut ensuite arbitrer entre ces différents chemins selon les politiques définies. C’est cette architecture que nous privilégions lorsque les contraintes diffèrent fortement d’un site à l’autre.

Le MPLS est-il encore utile avec des applications cloud ?

Le MPLS reste utile lorsque certains flux intersites ou applications centralisées demandent de la prévisibilité, mais tout le trafic cloud n’a pas besoin de transiter par le réseau privé. Une architecture hybride peut conserver MPLS pour les flux critiques et sortir les usages SaaS directement vers Internet afin d’éviter des détours inutiles.

Infographie comparant les architectures SD-WAN et VPN MPLS pour les réseaux multi-sites