Hub-and-Spoke vs Full Mesh : conception d'un VPN d'entreprise pour 5, 20 et 100 succursales

Introduction : pourquoi comparer Hub-and-Spoke et Full Mesh en 2026

Les processus numériques augmentent, et les équipes distribuées ainsi que les bureaux décentralisés deviennent la norme. Parallèlement, les exigences en matière de protection des canaux, d’observabilité et de temps de reprise se renforcent. Connecter une succursale au siège central est devenu facile, mais garantir performances prévisibles, gestion efficace et montée en charge sur des dizaines de sites est plus complexe. Dans cet article, nous analyserons de manière méthodique quand une topologie Hub-and-Spoke est avantageuse pour un réseau d’entreprise, et quand opter pour Full Mesh ou un hybride partial mesh. Nous irons des principes fondamentaux à une architecture détaillée, puis à des méthodes pratiques adaptées aux réseaux avec 5, 20 et 100 succursales. Vous y trouverez des instructions pas à pas, check-lists, configurations types, métriques clés et cas concrets. L’objectif est simple : vous fournir un cadre décisionnel clair pour minimiser les risques, les coûts et le délai de mise en service.

Bases : concepts fondamentaux et terminologie

Topologies

• Hub-and-Spoke : site central nommé hub, succursales appelées spokes. Toutes les communications inter-succursales passent par le hub. Avantages : simplicité, contrôle centralisé, ingénierie de trafic claire. Inconvénients : point unique de défaillance potentiel, goulot d’étranglement en bande passante et latence.
• Full Mesh : chaque site dispose d’un tunnel vers tous les autres. Atouts : latence minimale entre succursales, haute résilience. Limites : croissance quadratique des tunnels et des politiques, complexité de gestion.
• Partial Mesh : hybride, où les nœuds critiques sont reliés directement, les autres via hubs ou agrégateurs régionaux.

Transport et overlays

• Underlay : Internet, MPLS L3VPN, liens mobiles LTE/5G, DIA, haut débit. Il influence latence, gigue, pertes.
• Overlay : tunnels sécurisés — IPsec, WireGuard, OpenVPN, IKEv2, SSTP, L2TP. C’est là que résident chiffrement, authentification, routage.

Routage

• Statique : simple mais peu scalable.
• OSPF : protocole interne de routage pour dynamiques au sein du système autonome, pratique dans les gros Hub-and-Spoke.
• BGP : scénarios inter-domaines, montée en charge dans très grands réseaux et multi-hubs, adapté pour SD-WAN et routage d’overlay vers Internet.

Sécurité

• Profil cryptographique : ensemble d’algorithmes et paramètres — IKEv2, AES-GCM, ChaCha20-Poly1305, PFS, longueur de clé, rotation SA.
• Authentification : X.509, EAP-TLS, PSK, intégration avec PKI d’entreprise.
• Segmentation : VRF, VLAN, routage basé sur politique, groupes de sécurité pour isoler les segments critiques.

Observabilité

• Télémétrie : SNMP, NetFlow/IPFIX, sFlow, gNMI, export métriques et logs de tunnels.
• SLO/SLA : latence, pertes, gigue, disponibilité, temps de configuration et de reprise.

Approfondissement : des modèles d’architectures à la gestion des risques

Quand opter pour Hub-and-Spoke

Si la majorité des applications résident dans un datacenter ou un hub cloud, et que les flux inter-succursales sont faibles, Hub-and-Spoke offre routage prévisible, segmentation facile et contrôle des points de sortie Internet. Il facilite aussi la DLP et l’inspection du trafic. Risques : concentration de charge et dépendance au hub. Ils se maîtrisent par montée en charge du hub, clusters actif-actif, division en hubs régionaux et QoS adapté.

Quand choisir Full Mesh

Si les flux East-West entre succursales dominent, comme la voix ou la réplication de données, Full Mesh réduit latence et évite le hairpin via le hub. Limites : gestion et scalabilité. Elles s’atténuent par automatisation, contrôleurs SD-WAN, BGP avec route-reflector et partial mesh sur liens critiques.

Partial Mesh comme compromis

Souvent, il suffit de tunnels directs entre groupes de succursales à forts échanges, en laissant les autres via hubs. Cela apporte 80% des bénéfices du Full Mesh pour 20% de sa complexité.

Tendances 2026

• Essor de WireGuard dans les succursales grâce à sa simplicité et performance sur CPU standard.
• SD-WAN comme méthode de facto d’automatisation des overlays, choix dynamique d’underlay, routage aware application et politiques centralisées.
• Convergence VPN et Zero Trust : authentification des appareils, vérification d’état, micro-segmentation.
• Utilisation accrue de hubs cloud et POP, avec agrégation régionale plus proche des utilisateurs.
• Infrastructure as code pour les réseaux : manifestes déclaratifs des topologies et politiques.

Pratique 1 : choisir la topologie selon l’ampleur — 5, 20 et 100 succursales

Méthode décisionnelle

1. Évaluez les flux dominants : succursale-datacenter, succursale-cloud, succursale-succursale.
2. Mesurez les SLO réseau : RTT p95, gigue p95, pertes, disponibilité.
3. Recoupez avec besoins applicatifs : voix et vidéo sensibles à la latence, ERP aux pertes, stockage à la gigue.
4. Déterminez la réglementation : loi FZ-152, PCI DSS, ISO 27001, normes sectorielles.
5. Construisez une matrice bénéfices/risques selon topologies et sélectionnez la complexité minimale suffisante.

Scénario : 5 succursales

• Recommandation : Hub-and-Spoke avec mini-hub de secours ou paire actif-actif régionale.
• Routage : OSPF ou statique avec propagation centralisée via hub.
• Crypto : WireGuard ou IKEv2/IPsec avec PFS, AES-GCM ou ChaCha20-Poly1305.
• QoS : 3-4 classes — voix, applications critiques, bulk, best-effort.
• SLA : disponibilité du hub 99,95 %+, latence succursale-hub max 40-60 ms pour la voix.

Scénario : 20 succursales

• Recommandation : Hub-and-Spoke avec 2 hubs régionaux et partial mesh entre les 4-6 succursales les plus chargées.
• Routage : OSPF dans les régions, BGP entre régions et hubs cloud.
• Segmentation : VRF par ligne métier et séparation des sorties Internet en points de breakout locaux.
• Observabilité : export NetFlow, sondes synthétiques, tableaux de bord p95, p99.
• Automatisation : ansible ou contrôleur SD-WAN pour déploiement tunnels et politiques.

Scénario : 100 succursales

• Recommandation : hiérarchie : hubs régionaux, partial mesh sur groupes à trafic chaud, POP cloud centralisés pour SaaS.
• Routage : BGP aux frontières régionales, OSPF en interne, logique route-reflector pour scalabilité.
• Résilience : hubs actif-actif, ECMP, choix SLA-based d’underlay, basculement automatique selon mesures.
• Segmentation : VRF par domaine de sécurité, micro-segmentation aux niveaux politiques d’accès.
• Conformité : pistes d’audit, profils crypto, journaux d’accès, contrôle géographique des flux.

Pratique 2 : conception pas à pas de Hub-and-Spoke

Étape 1. Espaces d’adresses et segmentation

• Attribuez des préfixes uniques par succursale. Évitez les chevauchements : découpez systématiquement les plages 10.0.0.0/8.
• Définissez des VRF : trafic production, bureautique, Wi-Fi invité, OT.
• Planifiez les zones de firewalling sur le hub et les politiques intra/inter-VRF.

Étape 2. Choix des protocoles de tunnel

• WireGuard : simplicité, haute performance, facile à automatiser. Idéal pour succursales sans accélérateurs crypto matériels.
• IPsec IKEv2 : standard enterprise, accélérateurs matériels, profils crypto flexibles, compatibilité multi-constructeurs.
• OpenVPN : polyvalent, moins performant, à utiliser pour compatibilité spécifique.

Étape 3. Paramètres cryptographiques

• PFS activé, groupes équivalents à 3072 bits ou plus, durée de vie SA 1-4 heures avec rotation échelonnée.
• Chiffrement : AES-256-GCM ou ChaCha20-Poly1305. Contrôle strict des algorithmes autorisés.
• Authentification : EAP-TLS ou certificats PKI d’entreprise, CRL/OCSP.

Étape 4. Routage

• OSPF sur zones succursales : area par région, stub ou NSSA pour limiter le bruit LSA.
• Distribution de la route par défaut depuis le hub vers les succursales, routes inverses via résumé.
• Politiques de trafic au hub : PBR pour service voix, breakout local pour SaaS avec inspection.

Étape 5. Résilience

• Deux hubs actif-actif en zones de disponibilité distinctes, synchronisation des politiques.
• Basculement rapide : BFD pour routage dynamique, IKE DPD, sondes SLA.
• Sauvegarde underlay : DIA + LTE/5G. SD-WAN pour steering par flux selon pertes et gigue.

Étape 6. QoS et MTU

• Classes : EF pour voix, AF pour apps importantes, BE pour le reste. Marquage DSCP à la source, mappage sur WAN.
• Prise en compte des overheads : IPsec ajoute 50-70 octets, WireGuard ~60 octets. Configurez clamp MSS, découverte MTU et testez le chemin.

Étape 7. Observabilité et exploitation

• Dashboards : disponibilité des tunnels, RTT p95, gigue p95, pertes, volumes par classe QoS.
• Alerte : seuils SLA, notifications dégradation et basculement automatique underlay.
• Processus de gestion du changement : déploiement progressif (canary), rollback, postmortem en cas d’incident.

Pratique 3 : conception Full Mesh et Partial Mesh

Full Mesh sans douleur

• Utilisez un contrôleur central ou IaC. Décrivez mesh de manière déclarative, générez clés et pairs automatiquement.
• Pour IPsec, superposez BGP sur les tunnels. Employez des communautés pour gérer les annonces et éviter la sur-propagation.
• Résumé de préfixes sur site : minimisez taille des tables. Les petits réseaux utilisent des agrégats /24 ou /23 selon design.

Partial Mesh comme accélérateur ciblé

• Identifiez le top 10 des paires succursales selon volume ou latence. Créez des tunnels directs uniquement pour elles.
• Révisez régulièrement le jeu de paires mesh selon usage. Supprimez les inutilisées, ajoutez les nouveaux besoins.
• Assurez routage symétrique : local-pref BGP et MED pour choix correct des entrées/sorties.

Segmentation et sécurité

• VRF par segment + route-target pour importer uniquement les préfixes nécessaires. En Full Mesh, évitez full import, préférez selective import.
• Contrôle East-West : politiques L4-L7 entre segments, journalisation et vérification dérive des politiques.

Performance

• Optimisation crypto : accélérateurs matériels AES-NI, usage multithreads. Pour WireGuard : pinning CPU sur routeurs x86 succursales.
• Optimisation keepalive : adaptation aux réseaux mobiles et NATés, minimisation du chatter inutile.

Pratique 4 : économie, capacity planning et exploitation

Modèle TCO

• Capex : équipement hubs, licences, déploiement.
• Opex : liens, support, surveillance, SOC, amortissement.
• Coûts cachés : incidents, interruptions, facteur humain, retravail des équipes.

Planification de capacité

• Calculez pics de trafic par classes. Prévoyez marge 30-50 % sur hubs, 20-30 % sur succursales.
• Simulez cas pessimiste : panne underlay, dégradation, pics lors mises à jour.
• Tests : charges synthétiques, iperf avec MTU et QoS réalistes.

Gestion qualité

• Politiques stabilisation gigue : tamponnage passerelles voix, priorisation EF.
• Traffic shaping en sortie, policing en entrée. Évitez le bufferbloat.

Pratiques opérationnelles

• IaC : stockez manifestes VPN dans git, CI pour syntaxe et politiques, CD pour déploiement.
• Runbooks : procédures lancement succursale, basculement, rotation clés, remplacement matériel.
• Journées tests régulières : scénarios panne, temps RTO/MTTR.

Pratique 5 : sécurité, conformité et zero trust

Hygiène cryptographique

• Algorithmes minimaux requis, interdiction des suites obsolètes.
• Rotation régulière clés et certificats, rappels automatiques et remplacements.
• PFS toujours activé, séparation plans de contrôle et données via politiques.

Contrôle d’accès

• Accès au moindre privilège, liaison à appareils et utilisateurs.
• Segmentation : services critiques en VRF dédiée, filtrage inter-VRF au firewall.

Conformité

• Journaux : qui, quand, accès à quelles ressources. Conservation selon normes.
• Inventaire actif : tunnels, certificats, clés, équipements.
• Localisation données : restrictions géographiques, prévention transit par régions non désirées.

Intégration Zero Trust

• Contrôle état des appareils avant accès.
• Micro-segmentation au niveau applicatif, accès proxy-aware aux SaaS.

Pratique 6 : hubs cloud, SASE et modèles hybrides

Hubs cloud

• Positionnement des hubs proche utilisateurs — réduction RTT pour SaaS.
• Support multi-cloud : interception du trafic vers ressources cloud au sein du cloud, sans détour on-premise.

SASE et SD-WAN

• Protection en edge : CASB, SWG, DLP dans le cloud, intégration VPN.
• Routage aware applications : trafic SaaS critique par le chemin le plus court avec QoS garanti.

Topologies hybrides

• Hub-and-Spoke pour on-prem, Partial Mesh pour applis sensibles, POP cloud comme accélérateurs SaaS.

Pratique 7 : pilotes, PoC et démarrage rapide

Pilote en une semaine

1. Définissez métriques cibles : RTT p95, pertes, disponibilité, temps de failover.
2. Choisissez 2-3 succursales avec underlays différents.
3. Configurez 2 topologies : Hub-and-Spoke pur et partial mesh entre deux succursales.
4. Collectez métriques et comparez SLA ainsi que UX des applications.

Démarrage rapide sans cycles d’achat

Pour pilotes et courts PoC, il est pertinent d’utiliser un serveur VPN personnel en mode service. Dans ce contexte, le service vpn.how est pratique : serveur dédié sans partage et IP distincte, support de WireGuard, OpenVPN, IKEv2, L2TP, SSTP avec choix selon cas, serveurs à Moscou, Saint-Pétersbourg, Amsterdam, Francfort, Londres, New York, San José, Chicago, Singapour, Sydney, Madrid, Helsinki, Stockholm, Varsovie, Copenhague, Stavanger, paiement par cartes russes et SBP, ainsi que USDT ou BTC, tarifs dès 490 ₽ par jour et 2490 ₽ par mois avec remises selon durée, lancement automatique 5 minutes après paiement. Ce n’est pas destiné à la production long terme, mais comme démarrage rapide pour valider protocole, mesurer latences et tester politiques — un compromis intelligent. Pour production industrielle, passez ensuite à une infrastructure propre ou à des solutions certifiées classe GOST-VPN.

Erreurs fréquentes : ce qu'il faut éviter

• Un gigabit au hub sans marge. Résultat : goulot d’étranglement à mesure que les succursales augmentent.
• Adresses succursales qui se chevauchent. Cela plombe le routage et complique le NAT.
• Absence de VRF. L’East-West devient incontrôlable et la conformité difficile à garantir.
• Routage statique dans réseau moyen ou large. Tout incident se traduit par une modification manuelle fastidieuse.
• Ignorer MTU et MSS. Symptômes : segmentation, pages web bloquées, latences mystérieuses.
• Pas de sondes synthétiques. Vous découvrez les problèmes à partir des plaintes utilisateurs.
• Profil crypto identique partout sans tenir compte de CPU et accélération matérielle. Charge inutile et baisses de performance.
• Désactivation du PFS pour la performance. Compromis sécurité inacceptable.

Outils et ressources : que choisir

Planification et IaC

• Terraform/Ansible : description déclarative tunnels et politiques, templates de config.
• Git et CI/CD : validation changements, lint auto, bancs de test.

Surveillance

• Métriques Prometheus, exporters tunnels, NetFlow/IPFIX pour flux.
• Synthétiques : sondes ICMP, UDP-voice, HTTPS régulières, mesures p95 et p99.

Tests et diagnostic

• Iperf et générateurs de charge dédiés.
• Profileurs latence, traçage overlay et underlay combinés.

Sécurité

• PKI, gestion certificats, vérification conformité politiques cryptographiques.
• Scan configs pour anti-patterns, contrôle des suites autorisées.

Cas pratiques et résultats : exemples de déploiements

Société Alpha : 5 succursales, Hub-and-Spoke avec mise en service rapide

Situation initiale : succursales connectées au cloud via Internet public, plaintes de qualité instable. Solution : Hub-and-Spoke, WireGuard sur DIA, QoS en 4 classes. Résultats : Réduction RTT p95 de 18 %, pertes sous 0,2 %, reprise en moins de 20 secondes lors panne lien, projet déployé en 14 jours. Économies de 22 % sur les liens en migrer partiellement de MPLS vers DIA+LTE en secours.

Société Beta : 20 succursales, partial mesh pour paires voix

Situation initiale : voix transitait via hub central, fortes latences interrégionales. Solution : deux hubs régionaux, tunnels directs sur 6 paires voix, BGP sur IPsec, ECMP sur hubs. Résultats : latence appels entre succursales divisée par deux (de 85-110 ms à 45-55 ms), gigue p95 réduite de moitié, satisfaction utilisateur accrue, incidents diminués de 40 %.

Société Gamma : 100 succursales, hiérarchie de hubs et SD-WAN

Situation initiale : mix MPLS et Internet, coûts croissants et faible vélocité de changement. Solution : trois hubs régionaux actif-actif, overlay SD-WAN avec routage policy et application-aware, breakout locaux pour SaaS. Résultats : déploiement nouvelle succursale réduit de 4 semaines à 5 jours, disponibilité 99,98 %, économie TCO 27 % la première année, SLO clairs et rapports d’audit standard.

FAQ : questions complexes et réponses détaillées

Comment savoir si Hub-and-Spoke devient un goulot d’étranglement

Signes : augmentation du RTT p95 sur trafic inter-succursales, pics latence sur firewall hub, queues dans QoS, CPU crypto à plus de 80 %. Si ces indicateurs coïncident avec mécontentement UX, il est temps d’implémenter un partial mesh ou d’évoluer les hubs.

Comment évaluer la nécessité de Full Mesh

Construisez une matrice trafic succursales. Si 20 % des paires génèrent plus de 60 % du volume ou sont sensibles à la latence, mettez en place un partial mesh sur celles-ci. Le Full Mesh complet est justifié pour des flux East-West généralisés et avec un contrôleur d’automatisation.

Que choisir : WireGuard ou IPsec

WireGuard est plus simple et efficace sur CPU généraliste, idéal pour pilotes rapides et routeurs x86 en succursales. IPsec IKEv2 assure compatibilité enterprise, offload matériel et réglages crypto fins. Dans les grands réseaux hétérogènes, IPsec est une base universelle, WireGuard offre simplicité et rapidité.

Comment combiner breakout Internet local et contrôle centralisé

Déployez SWG cloud et politiques en edge, avec proxy authentifié et journalisé. Pour applis critiques, forcer le trafic via le hub pour inspection complète.

Comment gérer NAT et liens instables

Utilisez keepalive, IKEv2 avec MOBIKE, NAT-T, pour WireGuard handshakes réguliers. Prévoyez marges sur durée de vie SA et gestion changement IP externe.

Comment assurer conformité en architecture multi-cloud

VRF et routage sélectif par région, contrôle des routes annoncées, restrictions géographiques via politiques, audit routage et chiffrement, preuve de localisation données.

Quelle priorité entre routage centralisé et autonomie locale

Équilibre. Centralisez politiques critiques et segmentation, tout en laissant autonomie aux succursales pour incidents locaux et priorisation trafic. SD-WAN aide à bien calibrer ce mix.

Quelle marge de performance prévoir

Sur hubs, 30-50 % sur charge moyenne maximale, 20-30 % sur succursales. Double réserve pour services critiques en cas de dégradation underlay.

Peut-on combiner IPsec et WireGuard

Oui, particulièrement en environnements hybrides. Par exemple, IPsec pour interopérabilité legacy, WireGuard pour nouvelles succursales et montée en charge rapide.

Faut-il MPLS en 2026

Pas forcément. Pour scénarios très prévisibles, MPLS reste pertinent, mais DIA+SD-WAN avec QoS et SLA adaptés offre comparable prévisibilité avec plus de flexibilité et moindre coût.

Conclusion : cadre stratégique et prochaines étapes

La topologie est un outil, pas une fin. Avec 5 succursales, Hub-and-Spoke offre simplicité et contrôle. Avec 20, ajoutez hubs régionaux et partial mesh ciblé pour flux sensibles. Avec 100, bâtissez une hiérarchie, utilisez BGP, SD-WAN et segmentation VRF. N’oubliez pas hygiène crypto, MTU, QoS, automatisation IaC et sondes synthétiques pour SLO. Lancez des pilotes : mesurez, comparez, documentez. Pour un démarrage express, utilisez un serveur personnel géré comme sur vpn.how, puis migrez vers votre propre infra ou solutions certifiées en production. Prochaines étapes : formalisez plan d’adressage sans chevauchements, définissez VRF et classes QoS, sélectionnez protocoles et profils crypto, développez modèle de monitoring, préparez runbooks et réalisez un PoC d’une semaine. Que votre VPN soit fiable, sécurisé et évolutif, avec des décisions architecturales guidées par faits et expérience.