REX #3 — Migration VPN à l'échelle groupe

L'essentiel

Un projet VPN à l'échelle groupe engage souvent plus de 800 K€. À ce niveau de budget, quatre piliers sont non-négociables : une pré-étude RFI/RFP rigoureuse avec les équipes Achats et Legal, un POC exhaustif avant tout engagement, un éditeur maintenu dans la boucle jusqu'à la fin, et un plan de communication par vagues sur l'ensemble du déploiement.

Pré-étude RFI/RFP : un projet contractuel avant d'être technique

Dans les grands groupes, un projet de transformation VPN dépasse systématiquement les seuils budgétaires qui imposent un processus d'appel d'offres formel. Un RFI/RFP est donc incontournable — et c'est une bonne chose, car il structure la sélection et protège le projet.

La collaboration avec les équipes Procurement et Legal est indispensable dès le début. Il ne s'agit pas seulement de choisir la meilleure solution technique : il faut obtenir le meilleur contrat possible en termes de prix, de SLA, de conditions de sortie et de support. La phase de négociation avec le couple Éditeur/Intégrateur est souvent sous-estimée — c'est pourtant là que se joue une grande partie de la valeur du projet.

💡

Les budgets engagés sur ce type de projet

Pré-étude, RFP & POC ~50–100 K€ Licences & abonnements ~300–600 K€ Intégration & déploiement ~80–100 K€ Total programme > 800 K€

Points clés du RFI/RFP & Gestion Procurement

Gestion Procurement intégrée dès le départ — Impliquer le Procurement dès la rédaction du cahier des charges : sourcing, homologation fournisseurs, processus d'appel d'offres, validation Legal

Exigences techniques exhaustives — QoS, charge par utilisateur, nombre de connexions simultanées, pays couverts, profils VPN

Exigences Cyber/RSSI — Chiffrement, conformité, intégration SIEM, posture de sécurité des endpoints

Critères contractuels — SLA de disponibilité, pénalités, conditions de résiliation, portabilité des données

Grille de notation Achats/Technique — Pondération entre le critère prix et les critères techniques, validée avec Legal

Shortlist d'éditeurs — 3 à 5 éditeurs max (ex. Cisco, Netskope, Zscaler, Palo Alto) avec une phase de démonstration encadrée

Le POC : la ceinture et les bretelles avant tout engagement

Quand on engage plus de 800 K€ sur une solution, valider la promesse de l'éditeur en conditions réelles n'est pas une option — c'est une obligation. Le POC (Proof of Concept) est la seule façon de s'assurer que la solution choisie est capable d'absorber le trafic cible et de respecter les exigences métier avant de signer quoi que ce soit.

La bonne nouvelle : la plupart des éditeurs proposent une option Try-and-Buy (en moyenne 90 jours). Ne pas hésiter à le demander lors des négociations — c'est un argument de poids pour le Sponsor et le CTO, car cela démontre une volonté de mitiger le risque technique avant tout engagement financier définitif.

« Proposer un POC au Sponsor, c'est la preuve d'un professionnalisme et d'une vraie volonté de mitiger le risque. Aucun CTO sérieux ne peut refuser ça. »

Retour terrain — Migration VPN grands comptes

Cas d'usage à couvrir impérativement dans le POC

Charge & QoS — Tests de montée en charge simulant le pic d'utilisation réel (connexions simultanées, bande passante)

Authentification AD/MFA — Intégration avec l'Active Directory du groupe, MFA, SSO, gestion des comptes de service

Profils VPN par pays et par usage — Split tunneling, full tunnel, profils nomades, profils site-to-site

Posture & Certificats — Vérification de la conformité du poste avant connexion, gestion des certificats client

Compatibilité poste de travail — Windows, macOS, Linux, compatibilité avec les suites bureautiques et outils métier existants

Ergonomie utilisateur — Expérience de connexion, messages d'erreur, comportement en cas de perte réseau

Zéro régression — Le nouveau client VPN doit fonctionner sans régression dans l'écosystème existant du groupe

⚠️

Prendre le temps de tout tester — vraiment tout Un POC expédié en 2 semaines sur 10 utilisateurs ne vaut rien. Il faut couvrir tous les profils, tous les OS, tous les cas d'usage métier critiques. Un bug découvert après le déploiement sur 30 000 postes coûte infiniment plus cher qu'un POC prolongé de 30 jours.

Garder l'éditeur dans la boucle — jusqu'à la fin

C'est l'un des pièges les plus fréquents sur ce type de projet : une fois le contrat signé et l'intégrateur en place, l'éditeur est progressivement écarté des ateliers techniques. C'est une erreur.

L'éditeur — qu'il s'agisse de Cisco, Netskope, Zscaler ou un autre — reste le seul garant de sa solution en cas de problème d'intégration. En cas de bug complexe ou de comportement inattendu pendant le POC ou le déploiement, c'est lui qui a les clés. L'intégrateur, aussi compétent soit-il, ne peut pas se substituer au support niveau 3 de l'éditeur.

Règles d'or pour la gestion éditeur/intégrateur

Éditeur dans tous les ateliers de debug — Pas de réunion de résolution de problème sans le TAC ou l'ingénieur éditeur

Démantèlement des anciennes GW en dernier — Les anciennes passerelles (ex. ASA Cisco) ne sont désactivées qu'après une période de stabilisation validée

Build-to-RUN validé avec l'infogérant — Le passage en exploitation ne se fait qu'après une validation formelle avec l'équipe RUN

Documentation complète avant transfert — CMDB à jour, runbooks, procédures d'escalade éditeur documentées pour l'infogérant

⚠️

Ne jamais démanteler l'ancienne infrastructure avant la fin de la période de stabilisation Les anciennes passerelles VPN (ASA, Fortinet, etc.) doivent rester opérationnelles en parallèle jusqu'à ce que le nouveau système soit validé en production réelle. Une coupure prématurée sans rollback disponible peut paralyser l'accès distant de milliers d'utilisateurs.

Le plan de communication et le déploiement par vagues

Sur un projet touchant 30 000 utilisateurs, la communication n'est pas un à-côté — c'est un workstream à part entière. Elle doit être structurée à deux niveaux : le niveau Copil/Sponsor pour le suivi du programme, et le niveau utilisateurs sur sites locaux pour accompagner chaque vague de déploiement.

Le déploiement par vagues via SCCM (ou équivalent) est la seule approche viable à cette échelle. Chaque vague est une opportunité de détecter les anomalies avant qu'elles ne touchent la masse des utilisateurs. Le pourcentage de chaque vague doit être défini en fonction de la criticité des sites et de la capacité du support à absorber les incidents.

5% Pré-pilote

10% Pilote

25% Vague 1

50% Vague 2

100% Généralisation

Plan de communication — Ce qui doit être couvert

Communication Sponsor/Copil — Reporting d'avancement à chaque jalon, indicateurs de déploiement et taux d'incidents par vague

Communication utilisateurs — Email d'annonce, guide de prise en main, FAQ, contact support dédié — au moins 5 jours avant chaque vague

Référents locaux (Key Users) — Désigner un point de contact IT sur chaque site pour remonter les anomalies terrain rapidement

Dashboard de suivi par vague — Taux de déploiement, incidents ouverts/fermés, utilisateurs bloqués — mis à jour en temps réel

⚠️

Éviter absolument les périodes de congés pour les vagues de déploiement Déployer en juillet-août génère une masse de faux positifs : utilisateurs absents, postes non connectés, tickets ouverts par des collègues qui ne savent pas pourquoi l'outil a changé. Préférez les périodes de rentrée (septembre, janvier) où les taux de présence sont maximaux et les retours terrain fiables.

VPN Migration Grands comptes RFI/RFP Procurement POC Cisco Netskope Zscaler SCCM Try-and-Buy Build-to-RUN Cyber RSSI REX

Vous pilotez un projet de transformation réseau ?

Fort de plusieurs migrations VPN à l'échelle groupe (30 000+ users), je peux vous accompagner de la pré-étude jusqu'au déploiement final. Discutons-en.

Me contacter →

← Article précédent

REX #2 — Réussir un Carve-In IT

Lire →

Article suivant →

REX #4 — Migration d'infrastructure DC à DC : les pièges à éviter