Le vendredi soir, l'ancien contrôleur WiFi est à nouveau surchargé. La réception d'un hôtel réinitialise les points d'accès entre deux arrivées, un magasin de détail perd sa connectivité de paiement, un service hospitalier signale une mobilité clinique instable, ou les résidents d'un immeuble géré font la queue devant un bureau d'assistance parce que le portail des locataires a cessé d'authentifier. Le programme de migration a déjà pris du retard, et chaque solution de contournement "temporaire" se retrouve désormais intégrée à l'environnement de production.
Cette situation constitue le point de départ de la migration de systèmes existants. Le problème n'est pas que le matériel ou le logiciel soit ancien. Le problème est qu'une organisation a construit son modèle opérationnel autour d'une infrastructure fragile, de dépendances non documentées, d'une administration manuelle, d'un support expiré et de services d'identité que personne ne veut désactiver. Ce guide traite le WiFi, l'identité et les services réseau multi-locataires comme des cibles de migration à part entière, et non comme de la simple plomberie à traiter après le déplacement des applications.
Pourquoi la migration des systèmes existants mérite un vrai plan
Une pile réseau défaillante tombe rarement en panne de manière isolée. Une panne de WiFi d'hôtel peut affecter l'accès aux chambres, les intégrations de gestion d'établissement, la connexion de fidélité et les flux de récupération des clients. Un détaillant peut perdre la connectivité entre les caisses, les services de paiement, les systèmes de stock et le WiFi des clients. Dans le secteur de la santé, la chaîne de dépendances peut inclure les services d'annuaire, RADIUS, les certificats, les intégrations d'appel malade, les dispositifs cliniques et les applications mobiles. Dans un complexe résidentiel, un service d'authentification partagé peut prendre en charge les locataires, les sous-traitants, le personnel du bâtiment, les caméras, les ascenseurs et les installations communes.
L'argument commercial est donc opérationnel, et non esthétique. Comptabilisez les incidents, les échecs d'authentification, les réinitialisations manuelles, les minutes d'interruption, les heures d'ingénierie d'urgence, les licences obsolètes et les pièces de rechange rares. Identifiez ensuite ce que ces défaillances empêchent de faire. Une migration peut réduire les frais administratifs, améliorer la maintenabilité, exposer plus clairement les problèmes de couverture et d'authentification, simplifier l'intégration et donner aux équipes de sécurité une base plus saine pour les revues d'accès.
Règle pratique : Si l'entreprise ne peut pas expliquer qui est propriétaire d'une source d'identité, qui approuve une modification de politique et qui peut autoriser un retour arrière (rollback), elle n'est pas prête pour la bascule (cutover).
Le secteur public britannique offre un avertissement utile concernant le report. Une réponse parlementaire britannique de 2025 sur les systèmes existants estimait que ces derniers représentaient 28 % des systèmes des ministères du gouvernement central en 2024, contre 26 % en 2023. Les mêmes données ont révélé que 60 % des services numériques gouvernementaux avaient migré vers le cloud, mais que ce progrès avait pris 13 ans, avec 28 % du parc informatique toujours considéré comme obsolète. L'adoption majoritaire du cloud n'a pas éliminé le noyau dur des anciennes dépendances.
Un remplacement standard préserve souvent les mêmes faiblesses derrière de nouveaux logos. Si l'ancienne plateforme repose sur des comptes partagés, des modifications manuelles de VLAN, un routage RADIUS fragile ou un point de gestion unique, la transférer vers un nouveau matériel rend la défaillance plus difficile à identifier. Construisez le plan autour de la responsabilité, des preuves de dépendance, des vagues de migration, de la confiance d'identité, du fonctionnement parallèle et de la réversion. Le résultat n'est pas un simple renouvellement de matériel. C'est le retrait d'un modèle opérationnel défaillant sans abandonner les clients, les cliniciens, les employés ou les résidents.
Évaluer l'infrastructure existante avant de déplacer la moindre charge de travail
Commencez par un inventaire, pas par une présentation de fournisseur. Établissez un registre vérifié couvrant chaque contrôleur, point d'accès, commutateur, pare-feu, Captive Portal, annuaire, autorité de certification, serveur RADIUS, VLAN, SSID et console de gestion. Enregistrez l'emplacement, le propriétaire, le locataire ou l'unité commerciale, le modèle, le firmware, le statut du support, le trafic observé, la méthode d'authentification, la source de configuration et les dépendances connues.
Le mot vérifié est essentiel. Un tableur assemblé à partir des dossiers d'achat passera à côté des points d'accès non gérés, des intégrations abandonnées, des SSID temporaires et des appareils installés par les équipes locales. Comparez les exports de configuration avec le trafic observé, les données de surveillance, les tickets de support et les entretiens avec les personnes qui gèrent chaque site.
Cartographier les personnes, les appareils et les relations de confiance
Traitez l'identité comme un inventaire à part entière. Séparez le personnel, les sous-traitants, les invités, les patients, les étudiants, les résidents, les appareils IoT et les comptes de service. Pour chaque groupe, documentez la source de vérité, le processus d'arrivée et de départ, la durée de vie des identifiants, la propriété des certificats, le parcours d'approbation et la méthode d'accès d'urgence.
Testez ensuite des flux de travail représentatifs plutôt qu'une connectivité générique. Un hôtel a besoin de l'enregistrement, de l'accès aux chambres, du WiFi invité et des transferts vers le système de gestion de propriété. Un détaillant a besoin de la connectivité des points de vente, de la connexion au programme de fidélité, des appareils portables et du basculement en magasin. Un hôpital a besoin d'une mobilité clinique, d'équipements connectés, de l'authentification du personnel et d'une résilience au niveau des services. Un complexe résidentiel a besoin de l'intégration des locataires, d'installations partagées, d'un accès visiteurs et d'une isolation entre les occupants.
Prendre des décisions de migration basées sur des preuves
Classifiez chaque actif ou flux de travail par criticité métier, sensibilité des données, risque de compatibilité et urgence. Signalez les protocoles non pris en charge, l'expiration des certificats, les points de défaillance uniques, les règles de pare-feu non documentées, les comptes de service codés en dur et les lacunes de qualité des données. Attribuez un propriétaire responsable et définissez les preuves requises pour valider chaque vague.
| Actif ou flux de travail | Preuves à collecter | Évaluation des risques | Vague de migration |
|---|---|---|---|
| RADIUS et chemin d'annuaire | Journaux d'authentification, cartographie des sources de vérité, configuration de basculement, propriétaire du service | Élevé si partagé entre plusieurs sites | Vague de fondation initiale |
| Captive Portal et identité des invités | Flux de redirection, enregistrements de coupons ou de profils, enregistrements de consentement, dépendances CRM et PMS | Élevé dans les environnements orientés clients | Pilote par site ou par locataire |
| SSID cliniques ou opérationnels | Registre des appareils, méthode d'authentification, tests de flux de travail clinique, fenêtre de support | Critique là où la continuité du service est essentielle | Vague contrôlée, spécifique au site |
| Services multi-locataires | Règles de séparation des locataires, configuration iPSK ou équivalente, flux SSO, responsabilité du support | Élevé là où l'isolation est contractuelle | Vagues de cohortes de locataires |
| Points d'accès et contrôleurs | Firmware, statut du support, historique de connexion, sauvegarde de configuration, emplacement physique | Moyen à élevé selon la couverture | Alignement sur les vagues de services validées |
Un fournisseur peut aider à découvrir les actifs, mais aucun outil ne peut réparer une cartographie des responsabilités incomplète. Le registre doit devenir le journal de décision du programme. Si un élément n'a pas de propriétaire, pas de dépendance prouvée ou pas de scénario de retour arrière (rollback), il n'a pas sa place dans une phase de mise en production.
Choisir la bonne approche de migration
Choisissez l'approche qui correspond aux contraintes réelles. Suivre la tendance est une mauvaise méthode de migration, surtout lorsque le réseau véhicule l'identité et les opérations de première ligne.
Le Rehosting déplace un service existant vers une infrastructure plus récente avec un minimum de modifications. Utilisez-le pour une sortie urgente de matériel ou d'hyperviseur, un déploiement RADIUS stable ou une plateforme qui se comporte toujours de manière prévisible mais a atteint une limite opérationnelle. C'est rapide, mais cela perpétue les processus manuels, les hypothèses de licence, les défauts de configuration et la dette technique.
Le replatforming modifie l'environnement d'exécution tout en préservant le comportement central du service. Un Captive Portal peut être déplacé vers des conteneurs gérés, ou une intégration d'annuaire peut migrer vers une couche de service prise en charge. C'est la voie intermédiaire la plus logique lorsque la logique métier est saine mais que la plateforme d'exploitation est coûteuse ou difficile à maintenir.
Le refactoring modifie la conception interne. Cela peut signifier remplacer des règles de réseau statiques par des services de politique, exposer des API ou séparer les décisions d'identité de la présentation du portail. Le refactoring crée une meilleure base, mais il exige des décisions de produit plus claires et plus de tests qu'un simple transfert standard.
La migration par étranglement (Strangler migration) fait fonctionner l'ancien et le nouveau service en parallèle tout en routant un site, un locataire, un SSID ou un flux de travail à la fois. Pour les parcs WiFi et d'identité, c'est généralement l'option par défaut la plus sûre car l'équipe peut valider la coexistence, comparer les résultats des politiques et renvoyer une cohorte définie vers l'ancien système.
| Approche | Idéal pour | Principal avantage | Principal risque |
|---|---|---|---|
| Réhébergement (Rehost) | Sortie urgente d'infrastructure | Changement de service minimal | Conserve les faiblesses de conception |
| Reformatage (Replatform) | Intégrations stables avec un runtime coûteux | Meilleure supportabilité sans réécriture | Le travail de compatibilité demeure |
| Refactoring (Refactor) | Refonte des politiques, des API et de l'orchestration | Modèle opérationnel à long terme plus solide | Demande de livraison et de test plus élevée |
| Strangler (Étranglement) | Identité partagée et réseaux multi-sites | Petites cohortes et repli rapide | La coexistence doit être planifiée techniquement |
Un programme pratique peut réhéberger une plateforme RADIUS stable, replaterformer le portail invité et refactoriser l'application des politiques. Enregistrez la méthode choisie, les alternatives rejetées, la période de coexistence, le propriétaire et la condition de sortie pour chaque charge de travail. Les organisations qui évaluent les services professionnels managés peuvent également consulter l'offre de services professionnels de Purple parallèlement à leur modèle de prestation interne.
Évitez une bascule de type "big-bang" à moins que l'environnement ne soit simple, que la synchronisation ne soit validée et que la fenêtre de retour arrière (rollback) soit acceptable. Dans un environnement multi-tenant, une bascule simultanée signifie généralement un afflux simultané d'appels au support.
Migrer les données et l'identité sans rompre la confiance
L'identité est la colonne vertébrale de la migration. Si elle échoue, les points d'accès peuvent être opérationnels et les commutateurs peuvent acheminer le trafic, mais le service restera inaccessible pour l'utilisateur qui en a besoin.
Commencez par cartographier chaque source d'authentification. Incluez les serveurs RADIUS, les Captive Portals, les intégrations de gestion hôtelière (PMS), les forêts Active Directory, les connexions Microsoft Entra ID, Google Workspace, Okta, les comptes de service partagés, les certificats d'appareil et les comptes d'urgence locaux. Décidez quelles sources survivront, lesquelles seront synchronisées temporairement et lesquelles doivent être retirées avant que le nouveau service ne devienne d'autorité.
Construisez la coexistence de manière délibérée
Exécutez la synchronisation de l'annuaire par étapes. Associez les identités à l'aide d'attributs stables, résolvez les doublons avant d'activer l'accès et définissez la manière dont les utilisateurs désactivés ou partis sont propagés vers le nouveau service. N'utilisez pas la migration comme prétexte pour créer un second annuaire d'identités non contrôlé. Chaque compte temporaire doit avoir un propriétaire, une condition d'expiration et une piste d'audit.
Les certificats exigent la même rigueur. Recensez les autorités de certification, les modèles, les systèmes émetteurs, la responsabilité des renouvellements, les chaînes de confiance et les parcs d'appareils utilisant EAP-TLS ou 802.1X. Renouvelez les certificats de manière séquentielle et contrôlée, en commençant par une cohorte représentative. Maintenez l'ancien chemin de confiance disponible jusqu'à ce que la nouvelle chaîne ait passé avec succès les vérifications d'authentification et de révocation sur chaque classe d'appareil concernée.
« Une migration d'identifiants est une migration de service. Traitez les réinitialisations de mots de passe, le renouvellement de certificats et la désactivation de comptes comme des changements ayant un impact direct sur les clients. »
L'identité des invités nécessite un flux de travail distinct. Préservez la relation entre les profils, le consentement, les coupons, les dossiers de fidélité et les utilisateurs récurrents lorsque l'entreprise en dépend. Testez l'inscription, l'accès des utilisateurs récurrents, les informations oubliées, l'expiration, la désinscription et la récupération assistée par le support. Les invités ne devraient pas découvrir que la migration a réussi uniquement parce que leur accès précédent a disparu.
Séquencer les accès, pas seulement les équipements
Déplacez les services d'identité avant de procéder à des modifications majeures de SSID et de VLAN. Migrez ensuite un SSID, un site, un locataire ou un flux de travail défini tout en surveillant l'authentification et le comportement du trafic. Dans le secteur de la santé, séparez les parcours cliniques et d'appareils connectés de l'accès général du personnel. Dans les environnements résidentiels, préservez l'isolation des locataires tout en modifiant le service qui la gère. Dans le secteur de l'hôtellerie, vérifiez le transfert vers le système de gestion de propriété avant d'ouvrir le nouveau flux invité à toutes les chambres.
Utilisez le Purple data and security overview comme point de référence lors de l'évaluation des exigences en matière d'identité, de sécurité et de traitement des données. Le choix de l'outil importe moins que les preuves de validation. Avant que le trafic ne suive le nouveau plan d'identité, prouvez la réussite de l'authentification, l'autorisation correcte, la confiance des certificats, la désactivation des répertoires, la finalisation du portail, l'affectation des VLAN et la récupération après une interruption de service.
Tests, basculement et plan de repli : un fonctionnement garanti
Construisez le plan de bascule à l'envers, en partant du retour arrière. La plupart des plans médiocres décrivent comment le nouveau service sera activé, puis ajoutent une consigne vague de "revenir à l'état antérieur si nécessaire". Ce n'est pas un plan de retour arrière. Un véritable retour arrière nomme le déclencheur, le décideur, l'action technique, le responsable de la communication et la limite de temps.
Utiliser un fonctionnement en parallèle comme outil de test
Faites fonctionner en parallèle l'ancien et le nouveau plan d'identité et de réseau pendant une période définie. Utilisez des requêtes RADIUS fantômes lorsque l'architecture le permet, des parcours de Captive Portal miroirs, des comparaisons de configuration et des sondes synthétiques de connexion invité. Testez les authentifications réussies et échouées, les certificats expirés, les comptes désactivés, le roaming, l'attribution de VLAN, la dépendance DNS, le comportement du pare-feu et la perte d'un annuaire ou d'un point de terminaison RADIUS.
Testez par cohorte métier. Une aile d'hôtel, un site de vente au détail, un groupe d'appareils approuvés par un service ou un bâtiment résidentiel est plus utile qu'un test en laboratoire qui exclut les intégrations réelles. Conservez un dossier de preuves contenant les horodatages, les identités de test, les types d'appareils, les résultats des politiques, les défauts et les approbations.
Rédiger le cahier de mise en production minute par minute
La séquence de basculement doit inclure :
- Geler les modifications : Arrêtez les modifications non liées concernant le réseau, l'annuaire, les certificats et le portail.
- Prendre un instantané de l'état : Exportez les configurations, enregistrez les versions des politiques, conservez les mappages d'identité et confirmez que les fichiers de restauration sont exploitables.
- Migrer la cohorte : Basculez le site, le tenant, l'SSID ou le flux de travail défini, et non un "environnement" ambigu.
- Observer le comportement : Surveillez l'authentification, les redirections, les jonctions de points d'accès, les contacts de support, les transactions applicatives et le cloisonnement des tenants.
- Étendre ou inverser : Ne poursuivez que lorsque le propriétaire désigné confirme les critères de sortie. Si un déclencheur s'active, exécutez le retour arrière répété.
Les notes du plan identifient des exemples tels qu'un taux d'échec d'authentification supérieur à 1,5 %, des boucles de redirection de Captive Portal et des échecs d'association de points d'accès supérieurs à un seuil convenu. Utilisez ces exemples uniquement si vos indicateurs de référence les valident, et définissez le déclencheur final avec les responsables de service avant la fenêtre de changement. L'objectif n'est pas de choisir un chiffre universel, mais d'éliminer les débats au sein de la cellule de crise.
Répétez le retour arrière (rollback) avec les personnes qui géreront la production. Un plan de repli qui n'existe que sur papier échouera lorsque les certificats, les caches, les routes et les décisions humaines interagiront sous pression.
Coût, calendrier et conformité : l'épreuve de la réalité
L'estimation de livraison optimiste d'un fournisseur n'est pas un budget prêt à être présenté au conseil d'administration. Construisez votre modèle autour de la phase de découverte, de la correction des anomalies, des intégrations, des tests, du temps de travail du personnel interne, de la couverture du support, des licences, des communications, de la formation, de l'exposition aux temps d'arrêt et des imprévus. Intégrez la couche réseau en tant que travail de livraison : conception WiFi, services d'identité, captive portals, certificats, routage, isolation des locataires et support lors du basculement site par site. Une migration n'est pas économique si l'ancienne plateforme reste opérationnelle indéfiniment.
Le secteur public britannique fournit un avertissement clair concernant les travaux reportés. L'étude State of Digital Government Review a enregistré des technologies héritées dans 28 % des systèmes du gouvernement central en 2024. Elle a également constaté des niveaux d'obsolescence allant de 10 % à 60-70 % au sein des forces de police et des trusts de l'NHS, a mentionné des services critiques reposant sur des systèmes remontant aux années 1970, et a cité des problèmes d'obsolescence dans 153 systèmes répartis dans 16 ministères. Ces chiffres ne sont pas une liste de prix du secteur privé. Ils démontrent pourquoi la découverte des dépendances et leur remédiation doivent figurer dans le budget de déploiement, et non dans une ligne de frais généraux que l'on supprime.
Une analyse du secteur public britannique sur les coûts de l'informatique héritée a révélé que l'informatique héritée coûte 4 à 7 % des dépenses annuelles du secteur public en perte de productivité. Utilisez ce chiffre comme une incitation à mesurer le gaspillage opérationnel au sein de votre organisation, y compris la gestion manuelle des identités, les appels d'assistance répétés, les échecs d'accès des invités et les solutions de contournement du service réseau. Ne le présentez pas comme une économie de migration garantie.
| Secteur | Fourchette de coûts indicative | Durée typique | Principaux moteurs de conformité |
|---|---|---|---|
| Hôtellerie | Périmètre défini selon le nombre de sites, l'identité des invités, l'intégration PMS, la conception WiFi et la couverture du support | Séquençage en fonction de l'occupation et des événements | Sécurité des paiements, confidentialité, registres d'accès, assurance fournisseur |
| Commerce de détail | Périmètre défini selon les variations des magasins, les dépendances POS, l'identité de fidélité, le WiFi et les heures d'ouverture | Pilote en dehors des périodes de forte activité, puis déploiement par cohorte | PCI DSS, confidentialité, contrôles des terminaux, auditabilité |
| Santé | Périmètre défini selon les flux de travail cliniques, la validation des appareils, la résilience sans fil et la gouvernance du changement | Fenêtres de planification et de validation plus longues | Sécurité des patients, confidentialité, assurance des dispositifs médicaux, continuité |
| Résidences et parcs étudiants | Périmètre défini selon l'isolation des locataires, l'intégration, les installations partagées et les systèmes du bâtiment | Vagues par bâtiment ou par portefeuille | Confidentialité, isolation contractuelle, gouvernance des accès, contrôles des fournisseurs |
Pour les réseaux invités, évaluez le consentement, la rétention, les registres d'accès, la gestion de l'identité et la séparation des locataires avant de vous engager dans une conception. Utilisez l'outil de vérification de conformité du WiFi invité Purple pour examiner cette posture et identifier les lacunes nécessitant un financement.
L'ONS propose une autre leçon difficile. Les rapports sur la migration des systèmes existants de l'ONS ont indiqué que les contraintes budgétaires ont ralenti sa transition, malgré des progrès vers le remplacement de 80 % des services obsolètes. La même source a signalé que 90 % des organisations présentaient une dette technique Microsoft Windows, 60 % disposaient de nombreux serveurs ou postes de travail Windows non pris en charge, et 51 % faisaient état de pannes liées à la dette technique. La pression de la fin de vie ne supprime pas la nécessité d'une planification de la continuité.
Alignez le programme sur les normes PCI DSS, ISO 27001, Cyber Essentials, la directive NIS2 lorsqu'elle s'applique, ainsi que les obligations sectorielles spécifiques. La conformité mettra en lumière les hypothèses fragiles : chiffrez donc les contrôles, les preuves, les tests et la responsabilité opérationnelle avant la fenêtre de changement.
Suivi post-migration et démantèlement continu
La mise en production est le début de la responsabilité. Une fois que le nouveau service prend en charge le trafic réel, l'équipe a besoin d'un référentiel de base pour prouver si la migration a amélioré les opérations ou si elle a simplement déplacé les mêmes dysfonctionnements vers une autre console.
Suivez la latence d'authentification RADIUS, le taux d'échec du Captive Portal, le succès d'association des points d'accès, le délai de renouvellement des certificats, les incohérences de politique, les demandes d'assistance et les objectifs de service au niveau des locataires lorsque l'isolation multi-locataire est importante. Attribuez à chaque signal un propriétaire désigné, une voie d'escalade et un rythme d'examen. Un tableau de bord sans opérateur responsable n'est que de la décoration.
Exécuter une courbe de stabilité
Utilisez un rythme d'examen à 30, 60 et 90 jours. Le premier examen doit détecter les dérives de configuration, les alertes manquantes, les échecs d'authentification récurrents et les solutions de contournement du support. Le deuxième doit tester si le service fonctionne sans l'intervention de l'équipe de migration. Le troisième doit décider si l'ancienne plateforme est prête à être mise hors service.
Ne criez pas victoire simplement parce que la nouvelle plateforme est opérationnelle depuis un week-end calme. Comparez les comportements à travers les cycles d'activité, les groupes de locataires, les classes d'appareils et les événements opérationnels. L'hôtellerie a besoin de variations d'occupation, le commerce de détail a besoin de conditions commerciales réelles, la santé a besoin de flux de travail cliniques approuvés et les résidences ont besoin de l'intégration des locataires et d'un accès commun.
Décommissionner par étapes contrôlées
Ne mettez hors service l'ancien service qu'une fois les critères de sortie validés et signés par le responsable métier. Ensuite, procédez au démantèlement de manière méthodique :
- Fermeture administrative : Arrêtez les modifications, fermez les canaux de support, archivez les configurations approuvées et mettez à jour les registres de propriété.
- Révocation de la confiance : Révoquez les certificats obsolètes, désactivez les anciens comptes de service, supprimez la synchronisation d'annuaire inutilisée et éliminez les chemins d'accès résiduels.
- Retrait du réseau : Supprimez les tunnels VPN hérités, les politiques, les intégrations et les dépendances de gestion, puis récupérez l'espace d'adressage et les licences.
- Transfert de connaissances : Stockez l'architecture finale, le registre des décisions, les preuves de test, l'historique des incidents et les procédures opérationnelles là où l'équipe de support peut les trouver.
Une analyse du gouvernement britannique sur la complexité du parc existant a décrit les systèmes hérités comme obsolètes, vulnérables, impossibles à supporter et constituant une contrainte pour la transformation. Cette source a déjà établi l'ampleur du problème. Après la migration, votre rôle consiste à veiller à ce que l'ancien parc ne subsiste pas en tant que zone de sécurité non attribuée.
Purple propose une authentification WiFi basée sur le cloud et un réseau basé sur l'identité pour les invités, le personnel et les environnements multi-locataires, avec des intégrations pour les services d'annuaire et les plateformes réseau. Visitez Purple pour évaluer si ses capacités d'identité, d'accès invité, d'analyses et de migration s'intègrent dans votre plan de migration de système existant.
