Modernisation des réseaux étendus (WAN) : la bande passante ne résout rien

04.07.2026

7 min de lecture

Les réseaux d’entreprise échouent rarement par manque de Mbit. Ils échouent à cause de la latence, du contrôle des chemins et des SLA flous entre les opérateurs, le cloud et les sites. Qui oriente son prochain appel d’offres principalement sur le prix par Mbit finance souvent de la capacité, mais hérite malgré tout des risques opérationnels.

Les points clés en bref

La bande passante, un levier trompeur. Pour l’ERP, la voix et les workflows proches du cloud, ce sont la latence, le gigue (jitter) et la stabilité du chemin qui comptent. Les tableaux de bord KPI axés sur la disponibilité et le débit masquent les changements de chemin et le comportement de sortie vers le cloud.
La maturité opérationnelle avant les labels. Les solutions SD-WAN et SASE se jugent sur la gouvernance des politiques, l’observabilité et le basculement sous charge. Selon Gartner, en 2025, le SASE dual-vendor avec des contrats séparés restera la norme du marché.
Des indicateurs communs. La latence par classe d’application, le gigue (jitter), la perte de paquets, le temps de basculement et la disponibilité de sortie vers le cloud doivent figurer dans les appels d’offres, les SLA et le modèle opérationnel. La norme MEF 70.2 définit des attributs mesurables pour les services SD-WAN.
La gouvernance avant la comparaison des fonctionnalités. Il faut clarifier les classes de sites, les limites opérationnelles et les clauses de sortie avant de comparer les fournisseurs. Une approche multi-opérateurs sans rôle de leader ni points de mesure communs alourdit la charge des interfaces.

Articles associésConstellation Enterprise Intelligence Avril 2026 : Trois observations à inclure dans chaque briefing du conseil / Agilité d’entreprise : pourquoi Scrum échoue au niveau du C-Level – et ce qui fonctionne à la place

Pourquoi les KPI de bande passante seuls induisent en erreur

La bande passante indique combien de trafic peut théoriquement être transporté par unité de temps. Elle ne dit rien sur la capacité d’une application à rester utilisable sur un site critique en situation de charge. Pour l’ERP, la voix, la vidéo et les workflows proches du cloud, ce sont souvent la latence, le gigue (jitter) et la stabilité du chemin qui font la différence. Une liaison à haute capacité mais avec une priorisation floue peut, au quotidien, offrir de moins bonnes performances qu’un chemin plus étroit mais mieux maîtrisé.

De nombreux tableaux de bord KPI affichent la disponibilité et le débit. Ils occultent les changements de chemin, les pics de charge et le comportement de sortie vers le cloud. C’est justement là que surviennent les incidents que le DSI qualifiera plus tard de « problème réseau ». Si les achats et l’exploitation ne comparent que des niveaux de bande passante, ils optimisent une donnée qui, en cas de panne, est rarement la cause racine. La vraie question est : quelle qualité de service est contractuellement et techniquement garantie dans des scénarios de charge et de défaillance ?

Les KPI de bande passante sont en outre faciles à mesurer, ce qui les rend attractifs pour les tableaux de bord. Cela incite à minimiser la complexité. Un site doté de deux liens et d’une logique de basculement défaillante reste risqué, même si les deux liens sont « suffisamment larges ». Sans mesure des chemins applicatifs ni responsabilité claire entre l’opérateur et la connexion cloud, la bande passante n’est qu’un chiffre de confort.

SD-WAN, SASE et MPLS classique en conditions réelles

Le MPLS reste pertinent là où des chemins déterministes, des fenêtres de latence étroites et des processus opérationnels établis font la différence. Le prix à payer ? Des temps de déploiement plus longs, des topologies rigides et souvent un point de couplage étroit avec l’opérateur. Lorsqu’une entreprise dispose de nombreux sites et de charges cloud fluctuantes, elle se heurte à des limites dès qu’un simple changement de politique devient un ticket de modification. Le MPLS ne répond pas automatiquement à la question de savoir comment le trafic sort proprement des environnements SaaS et des hyperscalers.

Le SD-WAN déplace la gestion et la visibilité plus près de l’application et du site. En conditions réelles, ce qui compte n’est pas l’étiquette, mais la maturité opérationnelle : gouvernance des politiques, fenêtres de modification, observabilité et capacité à basculer les chemins de manière traçable sous charge. Sans une base solide et sans rôles clairement définis entre les équipes réseau, sécurité et support de l’opérateur, on se retrouve avec des vérités parallèles sur le même incident. Le SD-WAN devient alors une couche supplémentaire qui doit expliquer pourquoi un chemin a été choisi, au lieu d’éliminer la cause du problème.

Les approches SASE regroupent les fonctions WAN et sécurité, promettant une politique unifiée en edge et pour l’accès au cloud. Pour les DSI et les RSSI, c’est le cas d’usage opérationnel qui décide : qui possède la politique, qui voit les métriques de bout en bout et qui est responsable si l’identité, la passerelle web sécurisée et le choix de chemin relèvent de contrats d’exploitation différents ? Les guides constructeurs comme le Cisco SASE Design Guide (version septembre 2025) et le Cisco SASE/SSE Architecture Guide (version janvier 2025) structurent les questions opérationnelles autour de la haute disponibilité, du routage et de la détection de réseau de confiance. Ils séparent le plan de contrôle et le plan de données, marquant ainsi les limites de confiance et d’exploitation. Le Design Guide maintient même délibérément l’intégration du SD-WAN avec le Secure Access en dehors du périmètre actuel. Le Magic Quadrant for SASE Platforms de Gartner (9 juillet 2025) souligne que les déploiements multi-fournisseurs restent répandus sur le marché. L’identité, la passerelle web sécurisée et le choix de chemin se retrouvent souvent dans des contrats et des lignes de support distincts. Un guide d’architecture aide à discuter de la cible, mais il ne remplace pas la validation dans son propre scénario de charge et de conformité.

C’est dans le fonctionnement mixte associant MPLS, accès internet et rampes cloud que se situe l’épreuve de vérité. Les applications ne choisissent pas leurs chemins en fonction de catégories de magazines. Elles suivent ce que DNS, routage et politique autorisent à l’instant T. Qui ne reflète pas cette réalité dans son cahier des charges achète, plus tard, des contournements.

Indicateurs que l’achat et l’exploitation doivent partager

L’achat a besoin de critères comparables. L’exploitation a besoin d’un pilotage mesurable. Les deux ne fonctionnent que si les mêmes grandeurs figurent dans le RFP, le SLA et le modèle opérationnel. Parmi les indicateurs pertinents : latence aller simple et aller-retour par classe d’application, gigue et taux de perte de paquets sous charge définie, temps de basculement incluant la convergence des politiques, disponibilité des sorties cloud critiques ainsi que le temps nécessaire pour établir un diagnostic commun entre l’opérateur et le NOC interne.

La disponibilité seule est trop grossière. Un lien peut être « up » tout en rendant la voix inutilisable. C’est pourquoi les seuils applicatifs doivent figurer dans le contrat, et pas seulement l’état des ports. La méthode de mesure est tout aussi cruciale : qui mesure où, à quelle fréquence, avec quel profil de trafic et avec quel droit d’accès aux données brutes ? Sans ces clarifications, l’incident se termine en dispute sur la méthodologie.

La transparence sur le choix des chemins et les modifications de politique doit figurer dans le même tableau. Lorsque le SD-WAN ou le SASE contrôle dynamiquement les chemins, il faut documenter quelles décisions s’appliquent dans quelles conditions et pendant combien de temps elles restent traçables. La norme MEF 70.2 de l’Mplify Alliance (anciennement MEF Forum) définit les attributs de service pour les services SD-WAN. Acheteurs et fournisseurs y conviennent de propriétés mesurables des flux applicatifs et de la démarcation entre abonné et fournisseur. Deutsche Telekom indique dans la description de son produit Premium Internet Underlay que les SLA classiques de performance internet ne fournissent généralement pas de garanties sur la latence, la gigue et le taux de perte de paquets. L’achat lie les crédits de service et les temps d’escalade aux mêmes indicateurs que ceux utilisés par l’exploitation dans la salle de crise.

La capacité reste un élément du jeu, mais elle est secondaire par rapport à la qualité de service sous charge. Les discussions budgétaires deviennent plus transparentes lorsque les Capex et Opex sont liés à la qualité mesurable des chemins et aux coûts liés à la double connexion, à l’observabilité et aux limites de support.

Risques liés aux multi-opérateurs et clauses de sortie

Les stratégies multi-opérateurs réduisent la dépendance tout en alourdissant la charge des interfaces. Deux opérateurs impliquent deux processus de perturbation, deux univers portails et souvent deux interprétations du même chiffre de latence. Sans rôle de leader clair dans la gestion des incidents ni points de mesure communs, l’avantage reste théorique. La diversité au niveau des couches 1 et 2 est peu utile si les deux chemins passent par le même goulot d’étranglement régional ou la même rampe d’accès cloud.

Les clauses de sortie déterminent si un changement d’architecture restera financièrement viable plus tard. Il est crucial de prêter attention aux délais de préavis, aux durées minimales par site, à l’accompagnement lors de la migration, à l’export des données et des configurations, ainsi qu’aux coûts liés à l’exploitation parallèle pendant la transition. Autre point tout aussi pertinent : que devient l’adressage IP, les classes de QoS et l’historique des tickets en cas de changement ? Sans ces garanties, le « deuxième opérateur stratégique » devient une solution temporaire permanente.

Les risques contractuels résident souvent dans les détails de définition. Un « best effort » sur l’accès Internet, des responsabilités floues dans le cloud ou des mesures de SLA uniquement jusqu’au bord du réseau de l’opérateur transfèrent discrètement le risque vers l’entreprise. C’est pourquoi les achats doivent exiger des matrices de responsabilité : opérateur, exploitation SD-WAN/SASE, fournisseur cloud, réseau local. Chaque lacune dans cette matrice représente un futur point d’escalade. Des tests en laboratoire indépendants confirment ces risques opérationnels. Dans une évaluation Miercom portant sur la haute disponibilité et l’optimisation des meilleurs chemins dans le SD-WAN, les comportements de basculement et la dépendance au plan de contrôle variaient considérablement selon les fournisseurs. Lors d’un test comparatif, les observateurs ont enregistré environ dix secondes d’interruption de trafic lors du basculement. Le Gartner Magic Quadrant for SD-WAN (30 septembre 2024) et le Magic Quadrant for SASE Platforms (9 juillet 2025) fournissent une cartographie du marché, mais ne remplacent pas une matrice de responsabilité adaptée à votre propre exploitation.

Grille de décision pour le prochain appel d’offres

Une grille pertinente commence par les classes de sites et les chemins applicatifs. Les noms de produits arrivent en dernier. Les sites critiques de production et financiers nécessitent des exigences de latence et de basculement différentes de celles des petits bureaux. Les sites fortement orientés cloud ont besoin de sorties définies et de chemins mesurables vers les régions pertinentes. Ces éléments déterminent ensuite les options architecturales : MPLS proche du cœur, SD-WAN piloté, SASE intégré ou délibérément hybride.

Dans un deuxième temps, l’équipe définit les limites opérationnelles : qui modifie les politiques, qui valide, qui assure un support 24/7 et qui détient la source unique de vérité pour la télémétrie. Parallèlement, les achats déterminent la mécanique contractuelle : méthodes de mesure, intervalles de reporting, crédits, sortie et chemin de migration. Ce n’est qu’ensuite que les fournisseurs et opérateurs sont comparés. Ainsi, le catalogue de fonctionnalités reste secondaire, tandis que le risque opérationnel devient prioritaire.

La grille doit séparer trois niveaux de décision : la pertinence technique dans votre scénario, le modèle opérationnel incluant les compétences et les outils, ainsi que les risques contractuels et de sortie. Une solution brillante techniquement mais floue dans son exploitation coûte plus cher au DSI et au directeur digital qu’une variante plus conservatrice avec une responsabilité claire. La maîtrise des coûts d’investissement est possible si l’exploitation parallèle, l’infrastructure de mesure et le remplacement des anciens contrats figurent comme postes obligatoires dans le business case, et non comme des surprises ultérieures.

Pour évaluer les offres, les tests de scénarios sont plus adaptés que les présentations. Des laboratoires indépendants comme Miercom vérifient notamment la panne du plan de contrôle, le basculement des liens et les changements de chemin pilotés par SLA en cas de latence ou de gigue dépassées. Gartner évalue les fournisseurs dans les Critical Capabilities for SD-WAN et for SASE Platforms selon les cas d’usage. Des PoC internes avec des pannes de sites simulées, des problèmes de régions cloud et des conflits de politiques montrent si les SLA sont adaptés à votre scénario.

La conclusion pour la stratégie IT et les achats est claire : le prochain réseau de sites est une décision de gouvernance et de contrat, avec la technique réseau comme niveau d’exécution. Ceux qui conservent la bande passante comme KPI principal optimisent le mauvais levier. Ceux qui clarifient les critères de mesure, les risques multi-opérateurs et les chemins de sortie avant de comparer les fonctionnalités pilotent conjointement les coûts d’investissement et les risques opérationnels, et restent maîtres de leur appel d’offres.

Foire aux questions

Quand MPLS reste-t-il une option viable pour l’interconnexion de sites ?

Le MPLS conserve son intérêt lorsque des chemins déterministes, des fenêtres de latence strictes et des processus opérationnels établis sont déterminants. Le prix à payer ? Des délais de déploiement plus longs, des topologies rigides et souvent un couplage étroit avec l’opérateur. Avec de nombreux sites et des charges cloud fluctuantes, ce modèle atteint ses limites dès qu’une modification de politique devient un ticket de changement. La sortie propre vers des environnements SaaS et hyperscale doit, en parallèle, être anticipée dans la conception opérationnelle et contractuelle.

Comment éviter les querelles méthodologiques en cas d’incident WAN ?

Le contrat précise qui mesure quoi, à quelle fréquence, avec quel profil de trafic et quels droits d’accès aux données brutes. Des seuils opérationnels basés sur la latence, le gigue et la perte de paquets remplacent le simple statut de port comme indicateur de pilotage. Les crédits de service et les temps d’escalade sont liés aux mêmes métriques que celles utilisées par les équipes opérationnelles en salle de crise. Sans cette cohérence, l’incident se transforme en débat stérile sur la méthodologie.

Pourquoi les stratégies multi-opérateurs comportent-elles des risques pratiques en cas d’incident ?

Deux opérateurs signifient deux processus de gestion d’incident, deux portails et souvent deux interprétations d’un même chiffre de latence. Sans rôle de pilotage clair en cas d’incident et sans points de mesure communs, l’avantage de la diversité reste théorique. La séparation en couche 1 et 2 est peu utile si les deux chemins partagent le même goulot d’étranglement régional ou la même passerelle cloud. Une matrice de responsabilité couvrant les opérateurs, l’exploitation SD-WAN ou SASE, les fournisseurs cloud et le LAN local comble ces lacunes avant la mise en production.

Comment les services achats et opérationnels vérifient-ils qu’une offre SD-WAN est adaptée à leur scénario ?

Les tests de scénarios et les PoC internes constituent la base d’évaluation avant les catalogues de fonctionnalités et les présentations. Des laboratoires indépendants comme Miercom analysent la résilience du plan de contrôle, le basculement de liens et les changements de chemin pilotés par les SLA en cas de latence ou de gigue dépassée. Lors d’un test comparatif, les experts ont mesuré environ dix secondes d’interruption du trafic pendant le basculement. Les pannes simulées de sites, les problèmes de régions cloud et les conflits de politiques permettent de vérifier si les seuils contractuels s’appliquent dans votre propre cas de charge et de conformité.