MPLS en entreprise, ce que le protocole change vraiment dans le réseau
Le MPLS structure le transport des flux dans les réseaux d’entreprise multi-sites. Labels, LSP, QoS, VPN et architectures hybrides expliqués à partir des usages réels.
Le MPLS reste une brique structurante des réseaux d’entreprise multi-sites, mais son intérêt actuel ne se résume plus à l’argument historique d’une commutation plus rapide que le routage IP. Pour une DSI, l’enjeu se situe ailleurs. Il s’agit de transporter sur un même WAN de la téléphonie, des applications métier, des flux de réplication, de la visioconférence ou des sauvegardes qui n’ont ni la même criticité ni la même tolérance aux variations du réseau. Le MPLS fournit aux opérateurs les mécanismes nécessaires pour construire des services capables de différencier ces flux, de les intégrer dans des VPN et d’appliquer des politiques cohérentes sur un domaine qu’ils exploitent.
Cette précision est importante parce qu’on attribue encore au MPLS des propriétés qu’il ne possède pas seul. Il ne chiffre pas nativement les données et la présence d’un label ne garantit ni la QoS ni la disponibilité d’un service. Ces garanties viennent de l’architecture construite autour du protocole, du dimensionnement du backbone, des politiques de trafic et des engagements de l’opérateur. Comprendre le MPLS revient donc moins à étudier une étiquette de vingt bits qu’à comprendre ce qu’un opérateur peut construire autour d’elle dans un réseau d’entreprise.
Pourquoi la technologie MPLS existe dans les réseaux d’entreprise
À la fin des années 1990, les réseaux d’entreprise commencent à concentrer sur IP des usages qui étaient auparavant séparés. Les données, la voix, la vidéo puis les applications métier convergent progressivement vers la même infrastructure. Le réseau ne sert plus seulement à déplacer des paquets entre deux machines, il devient un élément de production dont la qualité influe directement sur l’expérience utilisateur et parfois sur la continuité de l’activité. Une latence excessive, une gigue mal maîtrisée ou une saturation ne sont plus de simples anomalies techniques lorsqu’elles perturbent les appels, un ERP ou une application centralisée.
Le routage IP traditionnel repose pourtant sur un principe remarquablement efficace. Chaque routeur examine les informations dont il dispose et choisit le prochain saut permettant d’atteindre la destination. Cette approche assure la résilience et la scalabilité qui ont fait le succès d’IP, mais elle ne signifie pas que l’entreprise contrôle le traitement de ses flux sur tous les réseaux traversés. Le protocole TCP/IP permet par exemple d’utiliser DSCP pour signaler une classe de trafic, mais ce marquage n’a de valeur de bout en bout que si les équipements qui le reçoivent appliquent effectivement la politique attendue.
C’est précisément à ce niveau que MPLS apporte une autre logique. Il ne remplace pas IP et ne cherche pas à concurrencer les protocoles de routage. MPLS ajoute un mécanisme de forwarding qui permet à l’opérateur d’associer des paquets à des traitements définis dans son propre domaine réseau, puis de construire autour de cette mécanique des VPN, des classes de service et des architectures d’ingénierie de trafic. L’IETF a posé les fondations de cette architecture dans la RFC 3031, publiée en 2001. Cette logique reste aujourd’hui au cœur de nombreux réseaux VPN d’entreprise opérés, lorsque la simple connectivité ne suffit plus à répondre au niveau de service attendu.
MPLS, définition et signification dans les réseaux d’entreprise
MPLS est l’acronyme de Multiprotocol Label Switching. Le principe consiste à associer les paquets entrant dans le domaine MPLS à une Forwarding Equivalence Class, ou FEC, puis à utiliser des labels pour appliquer le traitement de forwarding correspondant. Les paquets appartenant à une même FEC sont ainsi considérés de manière équivalente pour leur acheminement, sans obliger chaque équipement intermédiaire à reprendre l’ensemble de la logique qui a conduit à cette classification.
Multiprotocol, une technologie réseau agnostique
Le terme Multiprotocol indique que l’architecture MPLS n’a pas été conçue exclusivement pour IP. Historiquement, elle a pu être utilisée avec d’autres technologies de réseau, notamment dans des environnements où ATM ou Frame Relay occupaient encore une place importante. Ces usages sont aujourd’hui largement hérités du passé, mais le principe reste intéressant pour comprendre MPLS. La mécanique de forwarding du backbone est distincte du protocole et du service réseau transportés pour le client, ce qui permet à l’opérateur de fournir plusieurs services sur une infrastructure commune.
Cette indépendance explique en partie la longévité de MPLS dans les réseaux d’opérateurs. Le protocole n’impose pas aux applications de connaître son existence et ne remplace pas les mécanismes de niveau supérieur. Il constitue une couche de transport et de service interne au réseau, tandis que les utilisateurs continuent à échanger sur des réseaux IP classiques.
Label, le cœur du protocole MPLS
Le mot Label désigne l’élément le plus visible du mécanisme. Lorsqu’un paquet entre dans le domaine MPLS, le routeur d’entrée l’associe à une FEC puis lui applique un label. Cette valeur de vingt bits n’a de sens que dans le contexte où elle est utilisée. Le label ne signifie pas directement « voix », « ERP » ou « sauvegarde », il représente le traitement de forwarding associé à la classe à laquelle appartient le paquet.
Cette distinction évite un raccourci fréquent. MPLS ne reconnaît pas spontanément l’application transportée. La classification du trafic dépend des politiques mises en œuvre à l’entrée du réseau et peut s’appuyer sur la destination, le service, des marquages existants ou d’autres critères définis par l’architecture. La RFC 3031 décrit précisément la FEC comme un ensemble de paquets recevant le même traitement de forwarding.
Switching, la commutation par labels dans le réseau
Dans le cœur du réseau MPLS, les équipements utilisent le label présent en tête de pile pour déterminer le traitement à appliquer. Selon le contexte, ils peuvent remplacer ce label, en ajouter un ou le retirer. Cette logique de label switching permet de dissocier le service fourni au client de la logique IP utilisée pour construire et exploiter le backbone.
Historiquement, la rapidité de lookup faisait partie des arguments majeurs du MPLS face aux routeurs IP de l’époque. Cet argument a perdu une grande partie de sa pertinence avec les équipements modernes, capables eux aussi de traiter les tables IP à très haut débit. L’intérêt du label switching se situe désormais davantage dans la construction de services, la séparation des contextes de forwarding, l’ingénierie de trafic et les VPN opérateurs que dans une prétendue supériorité de vitesse face à IP.
L’analogie logistique reste utile pour visualiser le fonctionnement. Dans un centre de tri classique, chaque colis peut être orienté à partir de son adresse complète. Dans un domaine MPLS, le travail réalisé à l’entrée permet ensuite aux équipements intermédiaires de s’appuyer sur une information plus compacte correspondant au traitement prévu. Le label agit davantage comme l’identifiant d’un circuit logistique que comme une seconde adresse de destination, ce qui permet au cœur du réseau de transférer le trafic sans connaître tous les détails du service client.
Comment fonctionne le MPLS
Une logique de réseau organisée dès l’entrée
Le fonctionnement du MPLS repose sur une séparation des rôles entre les équipements situés en bordure du domaine et ceux qui assurent le forwarding dans le cœur. Lorsqu’un paquet arrive sur un routeur d’entrée, celui-ci détermine d’abord la FEC à laquelle il appartient. La classification peut être relativement simple, par exemple à partir de la destination, ou intégrer les politiques nécessaires au service fourni. Une politique QoS peut notamment tenir compte du marquage DSCP ou d’autres informations afin d’associer différents flux à des traitements adaptés, mais cette intelligence provient de la configuration du réseau et non du protocole MPLS lui-même.
Le routeur d’entrée est souvent désigné comme un LER, pour Label Edge Router. C’est sur cette périphérie que se concentre une partie importante de la logique du service. Une fois la FEC déterminée, le paquet peut entrer dans le domaine MPLS avec les informations nécessaires à son acheminement. Le backbone n’a alors pas besoin de reproduire à chaque saut l’ensemble de cette classification.
L’étiquette MPLS comme décision de transport
Le paquet reçoit une entrée de pile MPLS de 32 bits. Elle comprend une valeur de label de 20 bits, un champ Traffic Class de 3 bits, un bit Bottom of Stack qui indique la dernière entrée de la pile et un TTL de 8 bits. Plusieurs labels peuvent être empilés, ce qui permet par exemple de distinguer le transport dans le backbone d’un service VPN porté par-dessus. Cette pile de labels est l’une des clés de la capacité de MPLS à mutualiser une infrastructure tout en fournissant plusieurs contextes de service.
Le paquet suit ensuite un Label Switched Path, ou LSP. Il est tentant de décrire ce LSP comme une route rigide prédéfinie à l’avance, mais cette représentation serait trop restrictive. Selon l’architecture, un LSP peut suivre le chemin issu du routage ou être explicitement construit pour répondre à des contraintes d’ingénierie de trafic. MPLS apporte donc un cadre de forwarding, mais le comportement concret dépend du plan de contrôle et des politiques utilisées par l’opérateur.
Un cœur de réseau construit autour du label switching
Les routeurs intermédiaires, souvent appelés LSR pour Label Switching Router, consultent leur table de forwarding MPLS afin de traiter le label reçu. L’opération la plus connue est le swap, qui consiste à remplacer le label entrant par celui attendu pour le segment suivant. Le routeur peut aussi pousser une nouvelle entrée sur la pile ou en retirer une lorsqu’elle n’est plus nécessaire. Le cœur peut ainsi transporter les services clients sans avoir à exposer l’intégralité de leurs informations de routage à chaque équipement intermédiaire.
Cette propriété joue un rôle important dans la scalabilité des réseaux opérateurs. Elle ne rend pas le backbone trivial à exploiter, car le plan de contrôle, la distribution des labels, la résilience et l’ingénierie du réseau restent complexes. Elle permet en revanche de répartir cette complexité différemment et de préserver un cœur dont le rôle principal reste le forwarding.
Une sortie transparente pour les réseaux IP
Lorsque le paquet approche de la sortie du domaine MPLS, les labels utilisés pour son transport sont retirés selon la logique de la pile. Le trafic peut ensuite poursuivre son parcours dans le contexte IP ou dans le service VPN auquel il appartient. Pour l’utilisateur et pour la plupart des applications, cette mécanique est invisible. MPLS structure le transport à l’intérieur du réseau opérateur sans obliger les systèmes situés à ses extrémités à fonctionner autrement.
C’est cette transparence qui permet de construire des architectures WAN d’entreprise capables d’interconnecter plusieurs dizaines de sites tout en conservant des politiques communes. Le comportement n’est pas pour autant garanti par le simple protocole. La prévisibilité, la QoS et la disponibilité viennent du service construit sur le domaine MPLS, du dimensionnement et de la façon dont l’opérateur l’exploite.
MPLS Network Actions, quand le réseau MPLS devient intentionnel
D’un réseau optimisé à un réseau capable d’agir
MPLS est parfois présenté comme une technologie achevée depuis le début des années 2000, essentiellement maintenue parce qu’elle est profondément implantée dans les réseaux d’opérateurs. Les travaux récents de l’IETF montrent une réalité plus intéressante. Le plan de données MPLS continue d’évoluer pour transporter non seulement des informations de forwarding, mais aussi des indications permettant à certains équipements d’effectuer des actions supplémentaires sur les paquets.
Le cadre MPLS Network Actions, ou MNA, s’inscrit dans cette logique. La RFC 9613, publiée en 2024, décrit les exigences auxquelles les solutions MNA doivent répondre. La RFC 9789, publiée en juillet 2025, pose le framework architectural, tandis que la RFC 9791 documente plusieurs cas d’usage. L’objectif n’est pas de remplacer le principe du label switching, mais d’étendre ce que le plan de données MPLS peut demander aux équipements rencontrés sur le parcours.
Quand le paquet transporte aussi une instruction réseau
Une MPLS Network Action peut demander un traitement lié au forwarding, à l’OAM ou à d’autres fonctions du réseau et être accompagnée des données auxiliaires nécessaires à cette action. Cette approche évite de multiplier des mécanismes indépendants pour chaque nouvelle fonction et fournit un cadre commun à des évolutions jusque-là traitées de manière plus spécifique. Le paquet MPLS peut ainsi transporter, en plus des informations nécessaires à son chemin, des indications destinées à certains équipements capables de les interpréter.
Cette évolution devient plus concrète depuis juin 2026. La RFC 9994, publiée comme Proposed Standard, spécifie le MPLS Network Action Sub-Stack. Elle définit la manière d’encoder dans la pile MPLS des actions réseau et les Ancillary Data associées, avec notamment la possibilité d’influencer certaines décisions de forwarding ou de transporter des informations utiles aux opérations OAM.
Un MPLS plus observable et plus programmable
Pour les réseaux d’opérateurs, l’intérêt dépasse largement la nouveauté protocolaire. La visibilité sur le comportement du plan de données devient aussi importante que sa capacité brute de transport. Les mécanismes MNA ouvrent la possibilité de transporter de manière standardisée des informations supplémentaires directement dans les paquets et de déclencher certains traitements au cours du LSP. MPLS évolue donc vers un plan de données capable de fournir davantage de contexte au réseau sans abandonner le modèle de forwarding qui a fait sa scalabilité.
Pour une DSI qui souscrit un VPN MPLS, cette évolution ne change pas la manière de raccorder une agence demain matin. Elle remet cependant en cause l’idée selon laquelle MPLS serait une technologie figée alors que seuls le SD-WAN ou les réseaux programmables continueraient à évoluer. Les travaux récents portent précisément sur l’observabilité, le traitement des paquets et l’intégration de fonctions supplémentaires dans des architectures de backbone modernes.
Une évolution dans la continuité du MPLS
Le MNA reste cohérent avec le principe historique du protocole. Les fonctions complexes de contrôle et d’orchestration ne sont pas déplacées arbitrairement dans chaque routeur du cœur. Le plan de données reçoit au contraire des informations structurées lui permettant d’appliquer les traitements prévus lorsque l’équipement concerné doit les exécuter. La modernisation du MPLS ne consiste donc pas à transformer le backbone en plateforme applicative, mais à enrichir les capacités du forwarding tout en préservant son rôle.
Cette continuité explique pourquoi le MPLS continue d’être utilisé dans des réseaux qui ont pourtant beaucoup évolué depuis 2001. Segment Routing, automatisation, télémétrie, SD-WAN et MNA ne forment pas nécessairement des générations de technologies qui se remplacent les unes les autres. Elles interviennent à des niveaux différents et peuvent cohabiter dans la même architecture.
Le MPLS entre niveau 2 et niveau 3 dans le modèle OSI
La question revient régulièrement, y compris chez des professionnels expérimentés. Le MPLS appartient-il à la couche 2 ou à la couche 3 du modèle de référence des réseaux OSI ? La réponse la plus utilisée consiste à parler de « couche 2.5 ». Cette expression n’appartient pas officiellement au modèle OSI, mais elle décrit assez bien la position particulière de MPLS entre les mécanismes de liaison et le routage IP.
La notion de couche 2.5 comme clé de lecture
Ethernet est généralement associé à la couche 2 et IP au niveau 3. MPLS utilise pour sa part des labels qui sont insérés entre l’encapsulation de liaison et le paquet de niveau supérieur. Son forwarding n’est donc pas fondé sur les adresses MAC comme celui d’un commutateur Ethernet, ni uniquement sur l’adresse IP de destination comme celui d’un routeur IP classique. Cette position intermédiaire explique l’expression de couche 2.5, même si elle ne doit pas être interprétée comme l’ajout d’un niveau officiel au modèle OSI.
Cette singularité constitue surtout un moyen pratique de séparer les rôles. L’application peut continuer à fonctionner sur IP sans connaître la mécanique MPLS du backbone. L’opérateur peut de son côté organiser le transport, construire des VPN ou appliquer des politiques de forwarding sans modifier le fonctionnement des réseaux locaux situés aux extrémités.
Une séparation des rôles pensée pour l’ingénierie réseau
MPLS ne fait pas disparaître les protocoles de routage. BGP, OSPF, IS-IS et d’autres mécanismes continuent d’être utilisés pour construire la topologie, distribuer des routes ou fournir les informations nécessaires aux différents services. Le plan de contrôle détermine la connaissance du réseau tandis que MPLS apporte une logique de forwarding et de service adaptée au backbone.
Cette distinction devient particulièrement visible dans les infrastructures opérateurs. Le même réseau physique peut transporter des VPN clients, de l’Internet, des services de voix ou des interconnexions entre datacenters, tandis que les informations de service nécessaires à chaque usage restent séparées. MPLS n’est donc ni un concurrent d’IP ni une évolution d’Ethernet, mais une brique d’ingénierie qui permet d’organiser autrement le transport à grande échelle.
Ce qu’un réseau MPLS apporte vraiment en entreprise
Lorsqu’on présente les avantages du MPLS, la liste revient souvent aux mêmes termes, QoS, sécurité, performances, stabilité. Cette présentation mélange pourtant les capacités du protocole et celles du service fourni par l’opérateur. Pour une entreprise, la valeur du MPLS vient moins du label lui-même que de la capacité du fournisseur à construire autour de ce mécanisme un réseau prévisible, supervisé et exploitable avec des engagements mesurables.
La prévisibilité vient du domaine réseau maîtrisé
Sur Internet, le trajet et les conditions de transport peuvent dépendre de plusieurs réseaux et de plusieurs domaines administratifs. L’entreprise maîtrise son accès et son infrastructure locale, mais beaucoup moins les équipements traversés ensuite. Dans un service MPLS opéré, le fournisseur contrôle une part beaucoup plus importante du domaine transportant les flux et peut donc dimensionner, mesurer et superviser les chemins utilisés. C’est cette maîtrise du périmètre qui rend le comportement des échanges intersites plus prévisible, pas la simple présence d’une étiquette MPLS.
Un réseau MPLS peut évidemment subir des pannes, des changements de chemin ou des congestions. Parler de déterminisme absolu serait donc excessif. En revanche, lorsque l’opérateur maîtrise l’ensemble du domaine concerné, il dispose de davantage de leviers pour mesurer les variations, protéger certaines classes et identifier l’origine d’une dégradation qu’une entreprise utilisant uniquement des chemins Internet best effort.
Une qualité de service cohérente sur le domaine MPLS
La QoS reste l’un des principaux arguments techniques en faveur d’un service MPLS. La RFC 3270 décrit précisément la prise en charge de DiffServ dans un environnement MPLS et la manière dont différents comportements peuvent être associés aux LSP. Un opérateur peut ainsi construire plusieurs classes de traitement et les appliquer sur le domaine qu’il contrôle, ce qui donne au marquage du trafic une portée que l’entreprise ne peut pas imposer à l’ensemble de l’Internet public.
Cette nuance est essentielle. MPLS ne garantit pas une bonne QoS par nature. Un réseau sous-dimensionné ou mal configuré restera mauvais, même avec des labels. La différence vient de la possibilité de dimensionner les classes, d’appliquer des files d’attente cohérentes et de contractualiser le service correspondant. Pour les flux temps réel, les conséquences sont détaillées dans notre article consacré à la QoS pour la téléphonie IP.
Un cœur de réseau qui ne porte pas toute la connaissance client
Une autre propriété importante du MPLS concerne la séparation entre le backbone et les services qu’il transporte. Les routeurs intermédiaires n’ont pas nécessairement besoin de maintenir toutes les routes appartenant aux réseaux clients pour assurer leur forwarding. Cette architecture permet au cœur de transporter des services à grande échelle tout en concentrant une partie de la connaissance client sur les équipements de bordure.
Il ne faut pas en déduire que MPLS rend automatiquement le réseau plus simple ou plus robuste. Les opérateurs doivent toujours gérer le plan de contrôle, les mécanismes de résilience, les protocoles de distribution et l’ingénierie du backbone. La simplification tient davantage à la répartition des responsabilités qu’à la disparition de la complexité.
Les VPN MPLS mutualisent le backbone sans mélanger les routages
Les VPN BGP/MPLS constituent l’une des applications les plus répandues de MPLS. La RFC 4364 décrit la manière dont plusieurs VPN IP peuvent être fournis au-dessus d’une infrastructure opérateur commune. Les différents clients peuvent partager le même backbone physique tout en conservant des espaces de routage logiquement distincts, ce qui évite de multiplier les infrastructures pour chaque réseau privé.
Cette séparation ne constitue pas un chiffrement. Les données ne deviennent pas illisibles parce qu’elles circulent dans un VPN MPLS. Si la confidentialité cryptographique est requise par la politique de sécurité, IPsec peut être utilisé en complément. Cette distinction entre isolation et chiffrement doit rester claire, notamment dans les environnements soumis à des exigences réglementaires.
Les cas d’usage concrets du MPLS en entreprise
L’intérêt du MPLS devient plus évident lorsqu’on quitte la description protocolaire pour regarder les réseaux que les équipes IT doivent réellement exploiter. Un siège, une usine, un petit bureau SaaS et un datacenter n’imposent pas les mêmes contraintes. Le MPLS prend surtout de la valeur lorsque la performance d’un flux intersites produit une conséquence métier directe et que l’entreprise veut pouvoir attribuer un niveau de service précis à ce transport.
Le MPLS dans les réseaux multi-sites d’entreprise
Le cas le plus évident reste celui d’une entreprise disposant de plusieurs agences, bureaux ou établissements fortement dépendants de ressources centrales. Un réseau MPLS permet d’intégrer ces implantations dans un service commun et d’appliquer des politiques de trafic homogènes sur le domaine opéré. Les boucles locales peuvent s’appuyer sur des technologies différentes. Un site critique utilisera par exemple une fibre FTTO avec engagements de rétablissement d’un accès critique lorsque la symétrie, la disponibilité et la GTR sont nécessaires, tandis qu’un autre pourra être raccordé différemment selon son niveau de criticité.
Le MPLS ne désigne donc pas la fibre qui entre dans le bâtiment, mais le service de transport construit au-dessus des différents accès. Cette distinction devient particulièrement utile dans les réseaux multi-opérateurs, où la meilleure infrastructure physique n’est pas forcément fournie par le même acteur sur toutes les implantations.
Le MPLS pour la téléphonie IP et la voix sur IP
La voix sur IP constitue un cas particulièrement parlant parce qu’elle dépend moins du débit brut que de la régularité du transport. Une connexion peut disposer de centaines de mégabits disponibles et produire malgré tout une mauvaise qualité d’appel si la gigue ou la perte de paquets augmente. Dans ce contexte, la valeur d’un service MPLS vient de la capacité à protéger une classe voix sur le domaine opéré et à empêcher un transfert volumineux de lui prendre toute la capacité disponible.
Le MPLS ne rend pas la voix insensible aux problèmes locaux et ne compense pas un accès trop petit ou défaillant. Il fournit en revanche à l’opérateur un cadre dans lequel le trafic temps réel peut recevoir un traitement cohérent sur les différents équipements traversés. C’est cette maîtrise qui le rend encore pertinent pour des réseaux où la téléphonie IP fait partie des usages critiques.
L’interconnexion de datacenters via MPLS
Les interconnexions de datacenters ou d’environnements hébergés produisent souvent des volumes élevés et des flux dont les comportements sont très différents. Une réplication de stockage peut consommer beaucoup de capacité sans exiger la même priorité qu’une application interactive. À l’inverse, certains échanges entre bases de données ou applications centrales supportent mal les variations de latence.
Le MPLS permet de placer ces flux dans une politique de transport commune tout en différenciant leur traitement lorsque l’architecture l’exige. Les réplications, sauvegardes et machines virtuelles peuvent ainsi partager les mêmes accès sans nécessairement entrer en concurrence directe avec les usages métier prioritaires.
Le MPLS dans les environnements industriels et logistiques
Dans une usine ou une plateforme logistique, une dégradation WAN peut avoir des conséquences beaucoup plus concrètes que le simple ralentissement d’un poste de travail. Les systèmes de supervision, certaines applications de production ou les échanges avec un datacenter central dépendent directement de la disponibilité du réseau. Le MPLS devient pertinent lorsque l’interruption ou la dégradation des échanges intersites produit un impact opérationnel suffisamment important pour justifier un transport supervisé et priorisé.
Il ne faut toutefois pas confondre MPLS et continuité de service. La disponibilité globale dépend également de la diversité des accès, des équipements locaux, de l’alimentation, des mécanismes de basculement et des procédures d’exploitation. Un réseau privé sans redondance physique reste vulnérable à une coupure de fibre.
Le MPLS comme socle d’architectures hybrides MPLS et SD-WAN
Le développement du SD-WAN n’a pas supprimé l’intérêt du MPLS. Il a surtout rendu plus facile l’utilisation simultanée de plusieurs transports. Un même site peut conserver un chemin MPLS pour les flux intersites critiques, utiliser Internet pour Microsoft 365 et disposer d’une 4G ou d’une 5G pour le secours, tandis que le SD-WAN orchestre l’utilisation de ces différents chemins.
Cette architecture est plus cohérente que l’opposition systématique entre « ancien MPLS » et « nouveau SD-WAN ». MPLS fournit un transport possible avec ses caractéristiques de service, tandis que le SD-WAN décide comment exploiter les transports disponibles. Notre comparatif SD-WAN vs MPLS approfondit précisément cette distinction.
Quand envisager une solution MPLS en entreprise
Choisir MPLS ne dépend ni d’un nombre magique de sites ni de la taille de l’entreprise. Cinq établissements fortement dépendants de la téléphonie et d’un ERP centralisé peuvent avoir davantage besoin d’un transport maîtrisé qu’un groupe de cinquante bureaux utilisant presque exclusivement des applications SaaS. Le premier critère reste donc la criticité réelle des flux, leur sensibilité à la latence, à la gigue ou aux pertes et l’impact d’une dégradation sur l’activité.
Le deuxième critère concerne le modèle d’exploitation. Une DSI peut vouloir piloter elle-même plusieurs accès Internet, leurs politiques et leur redondance, ou préférer confier une part plus importante du transport à un opérateur capable de superviser le réseau et d’assumer les engagements associés. Le troisième concerne l’architecture applicative. Plus les flux restent concentrés entre les sites et des ressources centrales, plus la maîtrise du WAN conserve de la valeur. À l’inverse, lorsque l’essentiel des usages part directement vers des applications SaaS, il devient difficile de justifier le passage systématique de tout le trafic par un réseau privé.
| Profil réseau | Architecture à étudier | Point déterminant |
|---|---|---|
| Sites avec voix et applications centrales critiques | MPLS ou architecture hybride | QoS et maîtrise du transport |
| Sites majoritairement orientés SaaS | Internet, IPsec ou SD-WAN | Faible dépendance aux flux intersites |
| Réseau avec besoins très différents selon les implantations | MPLS, Internet et SD-WAN | Adaptation site par site |
| Site temporaire ou petite implantation | Internet ou 4G/5G avec IPsec | Rapidité et simplicité du raccordement |
| Flux exigeant un chiffrement de bout en bout | IPsec seul ou au-dessus de MPLS | Confidentialité des données |
| Plusieurs liens par site | SD-WAN avec transports adaptés | Sélection et basculement entre les chemins |
Le MPLS devient pertinent lorsque l’entreprise achète réellement de la prévisibilité, de la QoS et un niveau de service sur ses échanges intersites. Le protocole n’est pas une justification en soi. Ce sont les conséquences d’une dégradation et le niveau de maîtrise attendu qui permettent de savoir si ce service mérite d’être conservé.
Pour les environnements où le transport privé doit être complété par du chiffrement, du filtrage ou une segmentation plus fine, le WAN doit naturellement s’intégrer à une stratégie de cybersécurité plus large.
MPLS face au SD-WAN et au VPN IPsec
MPLS, SD-WAN et IPsec sont souvent comparés comme s’ils étaient trois produits interchangeables. Ils n’agissent pourtant pas au même niveau. MPLS fournit des mécanismes de forwarding et sert de base à des services opérateurs, IPsec protège cryptographiquement un flux IP et le SD-WAN pilote l’utilisation de plusieurs transports selon des politiques et leur état mesuré. Cette distinction est essentielle pour éviter de chercher un gagnant là où les technologies peuvent parfaitement cohabiter.
MPLS face au routage IP classique sur Internet
Internet excelle à connecter des réseaux indépendants et à acheminer les paquets à grande échelle. L’entreprise ne maîtrise cependant pas tous les domaines administratifs traversés et ne peut pas imposer ses propres politiques de traitement à l’ensemble de ces réseaux. Un accès Internet performant peut parfaitement fournir une excellente qualité pendant de longues périodes, mais cette qualité n’équivaut pas à un engagement de traitement de bout en bout sur les flux.
Dans un service MPLS, la différence utile pour une DSI tient au périmètre sur lequel l’opérateur peut réellement mesurer, dimensionner et appliquer ses politiques. Un mauvais service MPLS restera évidemment moins satisfaisant qu’un excellent accès Internet. Le protocole ne remplace jamais l’ingénierie ni la qualité d’exploitation, mais il permet de construire un type de service que l’entreprise ne peut pas imposer à l’Internet public.
MPLS et SD-WAN, deux rôles qui se complètent
Le SD-WAN apporte une capacité de pilotage particulièrement intéressante lorsqu’un site dispose de plusieurs transports. Il peut mesurer leurs caractéristiques, orienter les applications selon des politiques et déplacer certains flux lorsqu’un chemin se dégrade. Cette approche est particulièrement adaptée aux environnements cloud, aux sorties Internet locales et aux réseaux où les besoins varient fortement d’un site à l’autre.
Le MPLS peut être l’un des transports pilotés par le SD-WAN plutôt que son concurrent direct. Un siège peut conserver MPLS pour la voix et certaines applications internes, tout en utilisant Internet pour Microsoft 365. Une agence plus légère peut fonctionner uniquement sur des accès Internet. Un site industriel peut conserver plusieurs chemins dont un réseau privé. Cette complémentarité permet de réserver le transport le plus exigeant aux usages qui en ont réellement besoin.
VPN MPLS et VPN IPsec, deux modèles de protection différents
Notre comparatif MPLS vs IPsec traite en détail cette distinction. IPsec chiffre les données, assure leur intégrité et authentifie les extrémités du tunnel. MPLS ne fournit pas ce chiffrement. En revanche, un service VPN MPLS construit un contexte de routage privé sur le réseau de l’opérateur et peut appliquer des politiques de trafic sur le domaine qu’il contrôle.
Les deux mécanismes répondent donc à des problèmes différents et peuvent être superposés. Lorsqu’une entreprise veut disposer à la fois d’un transport privé avec QoS et d’un chiffrement de bout en bout, IPsec peut être utilisé au-dessus du réseau MPLS.
Le MPLS dans les architectures cloud et hybrides
Le développement du SaaS a profondément modifié le WAN. Faire remonter systématiquement Microsoft 365, les visioconférences et le Web vers un datacenter central avant de ressortir vers Internet peut créer des détours inutiles. Cela ne signifie pas pour autant que tous les flux intersites disparaissent. Les entreprises conservent souvent des applications centralisées, de la téléphonie, des environnements hébergés ou des flux métier qui continuent à dépendre du WAN.
Le MPLS peut donc devenir un transport spécialisé dans une architecture hybride plutôt qu’un chemin obligatoire pour tout le trafic. Le SD-WAN facilite souvent cette évolution en permettant d’orienter les usages cloud directement vers Internet tout en conservant un transport maîtrisé pour les applications qui le justifient.
Comparaison MPLS, SD-WAN, IPsec et Internet
| Critère | MPLS | SD-WAN | IPsec | Internet |
|---|---|---|---|---|
| Fonction principale | Forwarding et services opérateur | Pilotage de plusieurs chemins | Chiffrement d’un trafic IP | Connectivité IP publique |
| QoS | Possible sur le domaine maîtrisé | Dépend des transports utilisés | Possible localement, sans garantie sur Internet | Best effort sauf service spécifique |
| Chiffrement natif | Non | Dépend de l’implémentation | Oui | Non |
| Multi-liens | Dépend de l’architecture | Fonction centrale | Possible selon les équipements | Dépend de l’équipement local |
| Contrôle du transport | Dans le domaine opérateur | Sélection des transports disponibles | Dépend du réseau sous-jacent | Limité pour l’entreprise |
| Site temporaire | Possible | Très adapté | Très adapté | Très adapté |
| Exploitation | Souvent opérée | Interne ou managée | Locale ou centralisée | Dépend du service |
| Usage typique | Flux intersites nécessitant maîtrise et QoS | WAN hybride et multi-accès | Tunnels intersites ou accès distant | SaaS, Web et connectivité générale |
Le MPLS reste pertinent quand l’entreprise achète de la prévisibilité
Présenter le MPLS comme une technologie ancienne ne permet pas de décider de sa pertinence. Ethernet, IP et BGP ont eux aussi plusieurs décennies et continuent pourtant de structurer les réseaux modernes. La vraie question porte sur le service rendu. MPLS garde une place lorsqu’une entreprise veut obtenir sur certains flux intersites un comportement prévisible, des classes de trafic cohérentes et des engagements que l’opérateur peut réellement mesurer.
Son intérêt diminue lorsque les sites travaillent presque exclusivement avec des services SaaS et échangent peu entre eux. Dans ce contexte, une architecture Internet ou SD-WAN peut être plus économique et plus directe. Entre ces deux extrêmes, le réseau hybride devient souvent la réponse la plus rationnelle. Un siège conserve MPLS pour certaines applications, une agence sort directement vers Internet, un site utilise deux accès pilotés en SD-WAN et une implantation temporaire rejoint le réseau en IPsec.
Un WAN cohérent n’a pas besoin d’utiliser la même technologie partout. Il doit appliquer les mêmes règles de conception sur la criticité des flux, la sécurité, la supervision et la continuité de service. C’est précisément la frontière entre cet article consacré au protocole et une offre de réseau opérée. Une fois l’architecture choisie, notre page sur le VPN d’entreprise multi-sites détaille comment MPLS, IPsec, accès Internet et liens de secours peuvent être réunis sous une exploitation commune.
Questions fréquentes sur le MPLS
C’est quoi le MPLS en informatique ?
Le MPLS, ou Multiprotocol Label Switching, est une technologie de forwarding qui associe les paquets à des labels pour les transporter dans un domaine MPLS. Les labels sont liés à des Forwarding Equivalence Classes et permettent de construire des services réseau comme les VPN MPLS tout en appliquant des politiques de traitement cohérentes sur le domaine de l’opérateur.
Comment fonctionne un réseau MPLS ?
Un réseau MPLS associe les paquets entrant dans son domaine à une Forwarding Equivalence Class puis à un label. Les routeurs MPLS utilisent ensuite les labels pour acheminer les paquets le long d’un Label Switched Path. Selon l’architecture, ce LSP peut suivre la logique du routage ou être construit pour répondre à des contraintes particulières d’ingénierie de trafic.
Le MPLS chiffre-t-il les données ?
Le MPLS ne chiffre pas nativement les données. Les services VPN MPLS peuvent séparer logiquement les espaces de routage de plusieurs clients sur une infrastructure opérateur commune, mais cette isolation ne remplace pas un chiffrement. IPsec peut être ajouté lorsque la confidentialité des données en transit l’exige.
Le MPLS permet-il de garantir la QoS ?
Le MPLS fournit les mécanismes nécessaires pour transporter et différencier des classes de trafic, mais le label MPLS ne garantit pas à lui seul la QoS. La qualité obtenue dépend du dimensionnement du réseau, des politiques DiffServ, des files d’attente et des engagements réellement appliqués par l’opérateur sur son domaine.
Quelle différence entre MPLS et IPsec ?
MPLS et IPsec n’agissent pas au même niveau. MPLS organise le forwarding et permet de construire des services de transport et des VPN sur le réseau d’un opérateur. IPsec apporte du chiffrement, de l’intégrité et de l’authentification aux flux transportés sur un réseau IP. Les deux peuvent donc être utilisés ensemble.
Quelle différence entre MPLS et SD-WAN ?
Le MPLS est un mécanisme de forwarding utilisé notamment dans les réseaux opérateurs, tandis que le SD-WAN pilote plusieurs transports selon des politiques et des mesures de qualité. Une architecture SD-WAN peut utiliser du MPLS, Internet et de la 4G ou 5G dans le même réseau. Les deux technologies répondent donc à des fonctions différentes.
Quand utiliser MPLS dans une entreprise ?
Le MPLS reste pertinent lorsque des flux intersites exigent une qualité de transport prévisible, des classes de service ou des engagements opérateur mesurables. Le nombre de sites ne suffit pas à décider. La sensibilité des applications, les échanges intersites, la résilience attendue et le modèle d’exploitation comptent davantage.
Le MPLS est-il encore pertinent en 2026 ?
Le MPLS reste pertinent en 2026 pour les réseaux qui ont besoin de services de transport maîtrisés et son architecture continue d’évoluer au sein de l’IETF. La RFC 9994 publiée en juin 2026 spécifie notamment le MPLS Network Action Sub-Stack, qui permet de transporter des actions réseau et des données auxiliaires directement dans la pile MPLS.