SD-WAN avec FortiGate : relier plusieurs sites sans lien dédié coûteux

Pendant longtemps, relier un siège et ses agences voulait dire louer des liaisons dédiées, chères et lentes à installer. Le SD-WAN change l’équation : plusieurs accès internet classiques, fibre ou 4G/5G, deviennent un réseau privé fiable grâce à un équipement intelligent sur chaque site. Pour un dirigeant ou un responsable informatique de PME, au Maroc, en Afrique ou en Europe, la question n’est plus « faut-il une ligne dédiée ? » mais « comment faire travailler ensemble des liens ordinaires sans que les utilisateurs voient la différence ? ». En tant que partenaire Fortinet depuis 2021, voici comment fonctionne le SD-WAN FortiGate, comment nous le concevons, et les erreurs que nous corrigeons le plus souvent.

Le principe

Un pare-feu FortiGate sur chaque site monte des tunnels IPsec chiffrés vers les autres sites à travers chaque accès internet disponible. Il mesure en permanence la latence, la gigue et la perte de paquets de chaque chemin, et il dirige chaque type de trafic sur le meilleur lien du moment. Si un accès tombe ou se dégrade, la bascule est automatique et invisible pour les utilisateurs.

Le SD-WAN est intégré à FortiOS : pas de boîtier supplémentaire ni de licence dédiée pour la fonction elle-même. Le même équipement assure le pare-feu, l’inspection des menaces, le VPN et le routage intelligent, ce qui simplifie l’exploitation d’un réseau multi-sites.

Les briques d’un SD-WAN FortiGate

Quatre notions reviennent dans toute conception, et il vaut mieux les connaître avant de lire un devis.

Brique	Rôle	Ce qu’il faut décider
Membres et zones SD-WAN	Regrouper les liens internet et les tunnels d’un site	Quels liens, quel opérateur, quel lien de secours
Sondes de qualité (Performance SLA)	Mesurer latence, gigue et perte vers une cible	Cibles testées et seuils acceptables par usage
Règles SD-WAN	Choisir le lien pour chaque application ou destination	Stratégie : meilleure qualité, respect d’un seuil, répartition de charge ou choix manuel
Topologie des tunnels	Relier les sites entre eux	Étoile autour du siège, ou tunnels directs entre agences avec ADVPN

Les règles s’appuient sur la reconnaissance applicative du FortiGate : on peut traiter différemment la téléphonie, l’ERP, Microsoft 365 et les mises à jour Windows, même si tous passent par le même port. C’est ce qui fait la différence avec un simple routeur double WAN, qui bascule en bloc sans distinguer les usages.

Ce que cela change au quotidien

• La voix reste claire : la téléphonie IP est priorisée et épinglée sur le lien le plus stable.
• L’ERP répond : les applications critiques passent avant les mises à jour Windows et les vidéos.
• Une panne opérateur ne se voit plus : le second lien prend le relais automatiquement.
• Le télétravail est sécurisé : les collaborateurs se connectent par VPN, avec les mêmes règles de sécurité qu’au bureau.
• L’administration est centralisée : une politique cohérente sur tous les sites, au lieu de configurations bricolées agence par agence.

Choisir ses liens : la diversité avant le débit

Deux liens du même opérateur, arrivant par le même fourreau, tombent souvent ensemble. Le SD-WAN n’apporte une vraie continuité que si les chemins sont réellement différents : deux opérateurs, ou une fibre plus un accès 4G/5G. Pour une agence modeste, une fibre et un routeur 4G/5G suffisent souvent ; pour un siège qui héberge l’ERP et le serveur de téléphonie, deux fibres d’opérateurs différents plus un secours radio sont plus prudents. Les critères de choix d’une fibre professionnelle sont détaillés dans notre guide sur la fibre entreprise au Maroc.

Le FortiGate doit ensuite pouvoir inspecter la somme des liens actifs, pas seulement le plus rapide. C’est un point de dimensionnement souvent oublié, que nous expliquons dans quel modèle de FortiGate choisir.

Un piège à connaître

Le SD-WAN répartit le trafic entre les liens. Certains flux détestent cela : SIP, tunnels de SBC, connexions longues vers un serveur de fichiers ou une base de données. Sans règle explicite, une session peut changer de lien en cours de route et se couper. Nous épinglons ces flux sur un lien unique dès la conception, avec un lien de secours défini, et nous vérifions le comportement de la bascule avant la mise en production. C’est un détail qui distingue un déploiement réussi d’un déploiement subi. Les autres causes de coupures et d’échos sont passées en revue dans les 10 erreurs qui ruinent la qualité des appels.

Notre méthode, étape par étape

1. Cartographier les flux : qui parle à quoi, entre quels sites, avec quelles applications critiques (ERP, téléphonie, partage de fichiers, messagerie).
2. Inventorier les liens de chaque site : opérateur, technologie, débit réel, adresse IP fixe ou non, point d’entrée physique.
3. Choisir la topologie : étoile autour du siège dans la plupart des cas, tunnels directs entre agences quand elles échangent beaucoup entre elles.
4. Définir les sondes et les seuils par usage : la voix tolère beaucoup moins de gigue qu’une synchronisation de fichiers.
5. Écrire les règles par application, en épinglant les flux sensibles et en plaçant les mises à jour et le streaming en dernier.
6. Tester la bascule site par site, en coupant réellement chaque lien, appels en cours.
7. Superviser : qualité des liens, bascules et saturation remontent dans notre console, avec une alerte avant que les utilisateurs ne se plaignent.

Les erreurs que nous corrigeons le plus

1. Deux liens du même opérateur présentés comme « redondants » alors qu’ils partagent la même infrastructure.
2. Une seule sonde de qualité vers une cible unique, qui déclare un lien mort alors que seule la cible ne répond plus.
3. Des seuils identiques pour tous les usages, si bien que la voix reste sur un lien dégradé.
4. Téléphonie et SBC non épinglés : les appels se coupent à chaque bascule.
5. Un secours 4G/5G jamais testé, dont le forfait ou la carte SIM a expiré le jour où il sert.
6. Un boîtier de siège dimensionné comme une agence, saturé par l’ensemble des tunnels.
7. Des versions de firmware différentes d’un site à l’autre, qui compliquent le dépannage et laissent des failles ouvertes.
8. Aucune documentation : personne ne sait plus pourquoi telle règle envoie tel flux sur tel lien.

Checklist avant de lancer un projet SD-WAN

• Liste des sites, des utilisateurs par site et des télétravailleurs.
• Applications critiques identifiées, avec leur emplacement (siège, cloud, agence).
• Deux chemins réellement différents par site important : opérateurs ou technologies distincts.
• Modèle de FortiGate par site dimensionné sur le débit avec inspection et le nombre de tunnels.
• Topologie choisie : étoile, ou tunnels directs entre agences.
• Seuils de qualité définis par usage, voix en priorité.
• Flux sensibles épinglés : SIP, SBC, connexions longues.
• Plan de test de bascule, réalisé en conditions réelles.
• Supervision et alertes en place dès la mise en service.

Pour qui ?

Toute entreprise avec au moins deux sites, ou un site et des télétravailleurs, et qui dépend de la téléphonie ou d’un ERP centralisé. Cliniques multi-cabinets, sociétés de services avec agences, industriels avec un dépôt distant, réseaux de points de vente : c’est notre cas le plus fréquent. Un site unique avec deux accès internet en profite aussi : même sans tunnel entre sites, le SD-WAN répartit la charge et bascule automatiquement entre les liens.

Comment nous le déployons

Nous commençons par un audit offert de vos sites, de vos liens et de vos flux, puis nous proposons une architecture et un devis matériel et licences transparent. Le déploiement se fait site par site, en coexistence avec l’existant, pour ne jamais couper l’activité. Ensuite, le réseau entre dans notre supervision 24/7, avec une prise en charge des incidents critiques en moins de 15 minutes. Plusieurs projets de ce type sont décrits, sans nom de client, dans nos réalisations.

Tout cela fait partie de notre offre infrastructure réseau et WiFi. Pour étudier votre interconnexion de sites, contactez-nous : réponse sous 24 h ouvrées.