Migrer depuis ScreenConnect : le guide pas à pas

Migrer un outil d’accès à distance fait peur, surtout quand des centaines de machines dépendent de lui. La méthode est pourtant simple : inventaire, déploiement en parallèle, bascule, retrait. Voici le chemin pas à pas.

Pourquoi planifier sa migration maintenant

En septembre 2026, la CISA a ajouté une faille critique de ScreenConnect à son catalogue des vulnérabilités activement exploitées, une alerte couverte par BleepingComputer. L’épisode rappelle une réalité simple : un outil d’accès à distance doit être tenu à jour et surveillé en permanence. Si vous évaluez vos options, comparez méthodiquement, puis migrez proprement. Une migration bien menée est aussi l’occasion de nettoyer le parc : comptes dormants, agents obsolètes, accès qui n’ont plus de raison d’être.

Étape 1. Inventorier avant de toucher à quoi que ce soit

Avant la moindre installation, dressez l’état des lieux.

• Le nombre de postes sous gestion, avec système d’exploitation et rôle de chacun.
• La répartition entre sessions assistées et accès non surveillés.
• La liste des techniciens et de leurs droits.
• Les propriétés personnalisées et scripts que vous devrez reproduire.

Cet inventaire sert de jauge : il mesure l’avancement de la migration et détecte les machines oubliées.

Étape 2. Cartographier les usages

Chaque usage trouve sa place côté Ubidesk. Les sessions assistées correspondent au support à distance, les postes à maintenir à l’accès non surveillé. Notez aussi les besoins annexes : Wake-on-LAN, redémarrage en mode sans échec, accès depuis un mobile.

Étape 3. Déployer en parallèle

Les deux outils peuvent cohabiter sans conflit. Commencez par un groupe pilote : quelques postes, quelques techniciens.

• Déployez l’agent via votre méthode habituelle, GPO, Intune ou Jamf.
• Vérifiez la traversée des pare-feu : Ubidesk ne passe que par le port 443.
• Testez la reconnexion automatique après redémarrage, y compris en mode sans échec.
• Validez le Wake-on-LAN sur un poste éteint.

Chaque test raté se corrige sans pression : c’est tout l’intérêt du groupe pilote. Une fois les quatre validés, la bascule devient une formalité.

Étape 4. Basculer les sessions assistées

Côté client, le changement se résume à un nouveau point d’entrée. La session démarre par un code à 6 chiffres, sans installation ni droits administrateur, avec un client temporaire qui ne laisse rien sur la machine. Vos clients n’ont rien à apprendre de plus. Les habitudes de vos techniciens suivent : invitation, prise en main, fin de session.

Étape 5. Migrer les agents non surveillés

Poussez l’agent sur l’ensemble du parc, puis contrôlez dans la console que chaque machine remonte. Une fois le parc complet, désinstallez l’ancien agent. Le plan Pro d’Ubidesk, à 24 euros par technicien et par mois en facturation annuelle, n’impose aucune limite de postes non surveillés. Vous n’avez donc pas à arbitrer entre les machines à migrer et celles à laisser de côté.

Étape 6. Retirer l’ancien outil

Gardez l’ancienne solution en lecture seule le temps de régler les cas restants, puis coupez. Conservez les journaux d’accès avant de supprimer le compte, par prudence juridique.

Les erreurs qui font échouer une migration

• Migrer sans inventaire : des machines restent sans agent et sans accès.
• Couper l’ancien outil trop tôt : gardez-le en lecture seule jusqu’au dernier cas réglé.
• Oublier les cas limites : postes hors domaine, machines personnelles, remplacements urgents.
• Ne pas prévenir les clients : un nouveau point d’entrée inexpliqué génère des appels inutiles.

Checklist de bascule

• Inventaire des postes et des techniciens terminé.
• Groupe pilote validé : connexion, redémarrage, Wake-on-LAN, port 443.
• Agents déployés sur tout le parc et vérifiés dans la console.
• Clients informés du nouveau point d’entrée.
• Ancien agent désinstallé, licences révoquées, journaux archivés.

La même méthode s’applique aux MSP comme aux équipes internes : ce qui compte, c’est de ne jamais couper l’ancien accès avant que le nouveau soit prouvé.