Depuis plusieurs années, l’activation par téléphone constitue le « plan B » préféré de nombreux administrateurs : lorsque une machine ne pouvait pas (ou ne devait pas) sortir sur Internet — laboratoires isolés, environnements industriels, machines virtuelles de test, équipements hérités — la solution classique restait l’assistant téléphonique avec le traditionnel Identification d’installation / Identification de confirmation. Cependant, cette option commence à se faire désirer.
Ces dernières semaines, les rapports se multiplient indiquant que le processus traditionnel « de toujours » ne fournit plus de confirmation vocale. À la place, le système automatisé redirige l’utilisateur vers un portail web d’activation, envoyant un lien par SMS pour compléter la démarche via le navigateur. Un cas souvent cité dans la communauté illustre parfaitement cette évolution : appeler, entendre que l’activation se réalise « en ligne », et finir sur un portail moderne avec authentification, parfois avec Microsoft Authenticator dans certains scénarios.
Ce qui est frappant : Microsoft documente encore l’activation par téléphone
Voici le paradoxe : dans sa propre documentation de support, Microsoft décrit toujours l’activation de Windows comme un processus pouvant se faire en ligne, par téléphone ou avec le support technique. Il est même question de lancer le classique SLUI 4 si l’option « activation par téléphone » n’apparaît pas.
Autrement dit : sur le papier, la voie existe encore ; dans la pratique, de plus en plus d’utilisateurs constatent que le « téléphone » n’est plus qu’un simple port d’accès vers le web, et non un canal autonome.
Impacts concrets pour les administrateurs (et pourquoi cela compte)
1) Moins de marge pour les environnements sans connexion Internet
L’objectif historique de l’activation téléphonique était de résoudre les activations sans dépendre de la connectivité (ou avec une connectivité limitée). Si le processus exige désormais un navigateur, une authentification ou un téléphone pour recevoir des SMS, le concept de « hors ligne » en est sérieusement affecté.
Cela concerne particulièrement :
- Les systèmes anciens (par exemple, Windows 7 ou Office 2010 dans des environnements hérités).
- Les réseaux isolés (air-gapped) où même un accès temporaire à Internet n’est pas permis.
- La déploiement massif / images de référence : activation répétée suite à des changements de matériel virtuel (UUID, BIOS, TPM, vTPM), snapshots ou déploiements clonés.
2) Augmentation de la friction opérationnelle et des « dépendances humaines »
Autrefois, le processus téléphonique était linéaire : appel → dictée/entrée des IDs → confirmation. Le nouveau processus introduit des variables problématiques en pratique :
- Compatibilité du navigateur, cookies, bloqueurs,
- Authentification supplémentaire (comptes, authenticators),
- Réception de SMS (politiques BYOD, couverture réseau, etc.),
- Et surtout, traçabilité : qui a activé quel ordinateur, quand, et sous quelle identité.
3) Une tendance stratégique : moins de chemins « legacy », plus de portail et gestion d’identité
Il ne s’agit pas uniquement d’un aspect technique ; c’est une orientation claire : Microsoft pousse de plus en plus à lier le cycle de vie du logiciel aux flux en ligne et aux identités gérées. Les rapports récents confirment cette tendance, même si la documentation continue d’évoquer l’activation téléphonique.
Ce que les équipes IT doivent vérifier maintenant
Évaluer votre approche d’activation actuelle (et repérer les difficultés)
- Combien de machines dépendent encore d’une activation « alternative » (téléphone, manipulation manuelle) ?
- Combien se trouvent dans des réseaux restreints ?
- Quel pourcentage sont des VMs recréées fréquemment ?
Réfléchir à une stratégie d’activation pour les environnements d’entreprise
Sans recourir à des pratiques douteuses : la meilleure démarche en entreprise consiste généralement à privilégier l’activation par volume (conformément au contrat et au mode de licence), avec une infrastructure et des politiques capables de supporter la rotation d’équipements ou de virtualisation sans devoir ouvrir des tickets à chaque changement.
Mettre en place un « runbook » pour faire face aux incidents
Si le téléphone ne suffit plus, il est utile de documenter une procédure d’urgence :
- Exigences minimales (dispositif pour SMS, navigateur compatible, identité),
- Responsables et enregistrements,
- Procédure alternative si le portail rencontre un problème ou si les politiques internes empêchent son accès.
Une lecture entre les lignes
Le fait que le système téléphonique serve désormais principalement de « point de passage » vers un portail n’est pas une simple évolution technique : cela modifie l’équilibre entre contrôle opérationnel et dépendance envers le fournisseur. Pour un utilisateur privé, cela peut passer inaperçu ; pour un administrateur gérant un parc legacy ou des environnements sensibles, cela peut devenir une problématique de continuité.
Le point le plus préoccupant est l’ambiguïté : Microsoft continue de présenter l’activation par téléphone comme une option, tandis que la réalité montre de plus en plus que cette voie est en train de se transformer en un accès guidé vers l’activation web, avec des couches supplémentaires liées à l’identité.
