Le métier de l'AMO, assistance à maîtrise d'ouvrage, consiste à aider une organisation à définir son besoin et à rédiger sa consultation : cahier des clauses techniques particulières d'un marché public, cahier des charges d'un appel d'offres privé, dossier de renouvellement d'un contrat opérateur. Sur le réseau multisite, ce métier bute depuis dix ans sur un dilemme mal posé : faut-il demander un MPLS, ou un SD-WAN ? La réponse est qu'il ne faut demander ni l'un ni l'autre. Il faut demander des fonctions.
Le problème des consultations écrites par technologie
Une consultation qui exige « un réseau MPLS » exclut, de fait, toute solution fondée sur des liens Internet standards, même plus maîtrisable que le MPLS. Une consultation qui exige « une solution SD-WAN » exclut les solutions qui agissent sur le cœur de réseau plutôt qu'aux extrémités, et se prive de la convergence voix et hébergement que le SD-WAN ne traite pas. Dans les deux cas, l'AMO a tranché, sans le vouloir, un débat technique qui aurait dû être laissé aux candidats.
La commande publique impose d'ailleurs de décrire des besoins, non des marques. Le réflexe vaut aussi dans le privé : plus le cahier des charges décrit ce que le réseau doit faire, plus la comparaison est loyale.
Une définition fonctionnelle neutre
La formulation que nous proposons aux cabinets, libre de reprise, tient en une phrase :
Solution de réseau étendu multisite fournissant au client un routeur de backbone virtuel dédié, administrable par le client, hébergé dans un cœur de réseau opérateur virtualisé et segmenté (VXLAN/EVPN), accessible via des liens d'accès standards multi-technologies (FTTH, FTTO, xDSL, 4G/5G), et capable de porter sur une même infrastructure les flux données, voix et hébergement.
Cette phrase ne nomme aucune marque. Un opérateur MPLS peut répondre : il devra expliquer ce que le client pilote dans son cœur, et comment il porte la voix et l'hébergement. Un éditeur SD-WAN peut répondre : il devra dire sur quel backbone repose son overlay et qui le pilote. Une solution de type sdMPLS peut répondre : elle devra démontrer, point par point, qu'elle satisfait chaque critère. La comparaison se fait sur les fonctions, pas sur l'étiquette.
Dix exigences à décliner en clauses
Le kit de rédaction d'appel d'offres détaille dix clauses types, avec leur raison d'être et les points à vérifier. En résumé, un cahier des charges de réseau multisite devrait exiger :
- un routeur de backbone virtuel dédié, administrable par le client (routes, QoS, segments), avec un mode d'accès et un délai de prise d'effet définis ;
- un cœur de réseau virtualisé et segmenté, en distinguant ce qui est dédié (l'instance de routage) de ce qui est mutualisé et cloisonné (le cœur) ;
- des liens d'accès multi-technologies (FTTH, FTTO, xDSL, 4G/5G) choisis site par site, avec secours mobile ;
- la convergence des flux données, voix et hébergement sur une même infrastructure, ou une réponse transparente sur les infrastructures séparées ;
- des standards ouverts et une réversibilité démontrée (VXLAN, EVPN, BGP, export de configuration) ;
- des engagements de supervision et d'exploitation chiffrés et contractualisés, distinguant le cœur et les liens ;
- la démonstration du cloisonnement et la capacité du client à segmenter son propre réseau ;
- des capacités de traitement mesurées, avec la méthode de mesure ;
- des délais de mise en service cible et maximal par site, livraison du lien et activation dans le cœur distinguées ;
- l'explicitation des limites d'évolutivité de l'architecture.
Trois pièges à éviter
Présupposer l'équivalence. Un cahier des charges ne doit pas présupposer qu'une solution offre « l'équivalent d'un SLA MPLS » ; il doit exiger des engagements chiffrés et vérifier qu'ils sont contractuels. Cela vaut pour tous les candidats, y compris l'opérateur MPLS sortant.
Confondre dédié et réservé. Demander une « infrastructure dédiée » sans préciser ce que l'on attend conduit à des réponses invérifiables. Ce que le client a besoin d'exiger, c'est une instance de routage dédiée (le VRB dédié, dans le cas d'une solution de type sdMPLS) sur un cœur mutualisé et cloisonné, dont le candidat démontre l'étanchéité.
Oublier la voix et le cloud. Une consultation WAN qui laisse la téléphonie et l'hébergement à d'autres contrats reconduit la double infrastructure. Demander le nombre d'infrastructures, de contrats et d'interlocuteurs pour le WAN, la voix et l'hébergement suffit souvent à révéler les écarts.
Des questions plutôt que des noms
Le kit propose enfin dix-huit questions à poser aux opérateurs, formulées pour s'appliquer à tout candidat. Trois d'entre elles font le tri à elles seules : qui pilote le cœur de réseau, et quelles modifications le client peut-il réaliser seul ? Le routeur de backbone proposé est-il une instance dédiée au client ? Pouvons-nous obtenir à tout moment l'export complet de notre configuration, et dans quel format ? Une réponse qui renvoie à un ticket, reste floue sur ce qui est mutualisé ou conditionne l'export à des frais en dit long sur la maîtrise réelle du client.
L'AMO n'a pas à recommander une technologie. Il a à écrire un besoin assez précis pour que la meilleure réponse s'impose. Si ce besoin est un cœur de réseau maîtrisé par le client, sur des liens standards, portant le WAN, la voix et le cloud, la consultation est ouverte à la troisième voie, et c'est au marché de répondre.