Boucle OOBE / « Quelque chose s’est mal passé » : Correctifs rapides pour les désastres d’installation

Ce que vous voyez réellement : boucles OOBE et le bassin « Quelque chose s’est mal passé »

OOBE (Out-of-Box Experience) est le pipeline de première exécution de Windows : langue, région, clavier, réseau, création de compte,
nommage de l’appareil, bascules de confidentialité, puis inscription (flux de compte Microsoft grand public ou join/MDM/Autopilot en entreprise).
Lorsqu’il échoue, Windows ne donne souvent pas une erreur nette. Il vous donne une ambiance : « Quelque chose s’est mal passé. »

Traitez ce message comme une catégorie, pas comme un diagnostic. Sous ce libellé se cachent plusieurs problèmes courants :

• Préconditions réseau (pas de route, portail captif, proxy, points de terminaison bloqués, inspection TLS, étrangetés DNS).
• Heure et cryptographie (RTC erronée, mauvais fuseau horaire, TLS qui échoue, chaîne de certificats non validable, points d’inscription qui vous rejettent).
• Orchestration d’inscription (incompatibilité de profil Autopilot, délais ESP, appareil non enregistré, utilisateur sans licence).
• Pilotes/firmware (pilote Wi‑Fi instable, pilote du contrôleur de stockage manquant, anomalies Secure Boot/TPM).
• État du disque (espace libre insuffisant, table de partitions corrompue, pré-provisionnement BitLocker raté, redémarrage en attente).
• Interactions avec les mises à jour (OOBE tente de récupérer des mises à jour, heurte des politiques, puis boucle).

Votre travail est d’arrêter de deviner et de commencer à réduire le périmètre. Le chemin le plus rapide n’est pas « réimager immédiatement. » La réimagerie est un outil, pas un réflexe.
D’abord, isolez si l’échec est local (état de l’appareil) ou externe (réseau/service/stratégie).

Playbook de diagnostic rapide (premier/deuxième/troisième)

Premier : confirmez que vous ne luttez pas contre le réseau (5 minutes)

1. Tentez un réseau connu bon : hotspot de téléphone ou un Wi‑Fi domestique simple sans portail captif.
2. Privilégiez l’Ethernet si disponible (dongle USB‑C OK). Les pilotes Wi‑Fi en début d’OOBE peuvent être… aspirants.
3. Si le réseau d’entreprise est obligatoire, testez la résolution DNS et la connectivité TLS depuis l’invite de commandes OOBE (étapes ci‑dessous).

Deuxième : validez l’heure, le TPM et la santé basique de l’appareil (5–10 minutes)

1. Vérifiez l’horloge. Si l’heure est erronée, TLS casse et l’inscription échoue silencieusement.
2. Confirmez l’espace disque libre et la sanity des partitions. OOBE peut boucler si elle ne peut pas engager l’état.
3. Si c’est Autopilot : confirmez que l’identité de l’appareil est ce que le service attend (pas une carte mère recyclée avec un hash recyclé).

Troisième : décidez de contourner, réinitialiser l’état OOBE ou réimager (10–30 minutes)

• Contournez les exigences réseau pour compléter l’installation et corriger l’inscription plus tard si le seul blocage est réseau/politique.
• Réinitialisez l’état OOBE si vous voyez des boucles répétées au même stade et que les journaux indiquent un provisionnement corrompu/incomplet.
• Réimagez lorsque le stockage/la partition est cassé, ou si vous avez des échecs répétés sur plusieurs réseaux avec la même image.

Idée paraphrasée de Werner Vogels (CTO d’Amazon) : la fiabilité vient du postulat que les échecs arrivent et de la conception de la récupération comme un chemin normal.
OOBE est hostile à la récupération par défaut ; vous devez apporter votre propre discipline.

Faits intéressants et contexte historique (pourquoi ça arrive encore)

1. OOBE existe sous sa forme moderne depuis l’ère Windows XP, mais sa dépendance aux services en ligne s’est accélérée avec l’identité cloud et le MDM.
2. Windows 10/11 a déplacé le « premier démarrage » d’une UI majoritairement locale vers un flux médiatisé par des services : compte, stratégie et applications peuvent être décidés à distance.
3. La promesse d’Autopilot (zéro intervention) est aussi son piège : c’est un système distribué avec identité, inventaire d’appareils, politiques et points de terminaison — chacun peut échouer indépendamment.
4. « Quelque chose s’est mal passé » n’est pas de la paresse ; c’est un choix de conception d’interface pour éviter d’exposer des codes internes. Cela évite aussi d’aider au dépannage.
5. Les échecs TLS ressemblent souvent à des boucles OOBE génériques parce que la couche UI n’affiche pas les erreurs de chaîne de certificats.
6. Les portails captifs sont du poison pour l’installation : OOBE ne peut pas toujours les détecter et peut « se connecter » tout en n’ayant aucune connectivité exploitable.
7. Le décalage horaire casse la validation des certificats ; même quelques minutes peuvent faire échouer des points stricts, et les horloges BIOS sur les nouveaux appareils ne sont pas toujours correctes.
8. L’injection de pilotes était auparavant la principale douleur ; désormais c’est souvent DNS/proxy/appareils d’inspection qui modifient le trafic en vol.

Blague n°1 : OOBE est la seule « expérience de bienvenue » qui peut vous faire sentir personnellement indésirable en moins de 30 secondes.

Correctifs rapides qui fonctionnent en conditions réelles (avec commandes)

Tout ce qui suit suppose que vous pouvez ouvrir une invite de commandes pendant OOBE. Sur la plupart des builds :
appuyez sur Shift+F10. Si cela ne fait rien, essayez Fn+Shift+F10 sur les portables avec des modes de touches de fonction étranges.
Vous obtiendrez un terminal en tant que defaultuser0 ou similaire.

Tâche 1 : Identifier la build Windows exacte (décidez si vous luttez contre une image connue défaillante)

cr0x@server:~$ reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v DisplayVersion

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
    DisplayVersion    REG_SZ    23H2

Ce que ça signifie : Vous regardez le marqueur de version de fonctionnalité.
Décision : Si une build particulière échoue de manière répétée sur plusieurs appareils, cessez de dépanner l’appareil et commencez à interroger l’image/la ring de mise à jour.

Tâche 2 : Vérifier l’état de l’interface réseau (décidez si vous avez un lien ou juste l’illusion)

cr0x@server:~$ ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . : DESKTOP-9P2K7S3
   Ethernet adapter Ethernet:

      Connection-specific DNS Suffix  . :
      Description . . . . . . . . . : USB 10/100/1000 LAN
      Physical Address. . . . . . . : 00-1A-2B-3C-4D-5E
      DHCP Enabled. . . . . . . . . : Yes
      IPv4 Address. . . . . . . . . : 10.40.12.83(Preferred)
      Subnet Mask . . . . . . . . . : 255.255.255.0
      Default Gateway . . . . . . . : 10.40.12.1
      DNS Servers . . . . . . . . . : 10.40.1.10
                                          10.40.1.11

Ce que ça signifie : Vous avez une IP, une passerelle et un DNS.
Décision : S’il n’y a pas de passerelle par défaut ou de DNS, les étapes cloud d’OOBE échoueront. Corrigez le réseau d’abord ; ne touchez pas encore aux politiques d’inscription.

Tâche 3 : Détecter un portail captif (décidez si « connecté » est un mensonge)

cr0x@server:~$ nslookup www.msftconnecttest.com

Server:  dns.corp.local
Address:  10.40.1.10

Non-authoritative answer:
Name:    www.msftconnecttest.com
Address:  13.107.4.52

Ce que ça signifie : DNS résout normalement.
Décision : Si DNS renvoie une IP interne/portail captif, vous êtes intercepté. Changez de réseau ou autorisez les points de détection de portail captif pour les VLANs de provisioning.

Tâche 4 : Tester TLS sans navigateur (décidez si le proxy/l’inspection casse les certificats)

cr0x@server:~$ powershell -NoProfile -Command "try { (Invoke-WebRequest -UseBasicParsing -Uri 'https://login.microsoftonline.com' -TimeoutSec 10).StatusCode } catch { $_.Exception.Message }"
200

Ce que ça signifie : TLS et le routage vers un point d’identité clé fonctionnent.
Décision : Si vous voyez des erreurs de certificat ou de poignée de main, suspectez un décalage horaire ou une inspection TLS avec des certificats racines non fiables dans le contexte WinPE/OOBE. Essayez un hotspot pour confirmer.

Tâche 5 : Vérifier l’horloge (décidez si TLS échoue parce que l’heure est erronée)

cr0x@server:~$ w32tm /query /status

Leap Indicator: 0(no warning)
Stratum: 2 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Last Successful Sync Time: 2/5/2026 9:16:41 AM
Source: time.windows.com
Poll Interval: 6 (64s)

Ce que ça signifie : Le service temps se synchronise et a une source valide.
Décision : Si cela échoue ou que l’heure est franchement décalée, réglez l’heure manuellement (ou corrigez l’horloge BIOS) et retentez OOBE. Le décalage horaire cause « Quelque chose s’est mal passé » plus souvent qu’on ne l’admet.

Tâche 6 : Forcer une resynchronisation de l’heure (décidez si vous pouvez récupérer sans reboot)

cr0x@server:~$ w32tm /resync
Sending resync command to local computer...
The command completed successfully.

Ce que ça signifie : L’heure a été corrigée.
Décision : Retentez immédiatement l’étape qui a échoué (connexion/inscription). Si cela échoue encore sur le réseau d’entreprise mais marche sur hotspot, c’est vos contrôles réseau, pas l’appareil.

Tâche 7 : Contourner l’exigence réseau pour terminer OOBE (décidez si vous pouvez reporter les étapes en ligne)

cr0x@server:~$ OOBE\BYPASSNRO

Ce que ça signifie : L’appareil va redémarrer et proposer un chemin d’installation hors ligne (varie selon la build/la politique).
Décision : Utilisez ceci quand le réseau est le seul blocage et que vous avez besoin d’un bureau fonctionnel pour poursuivre le diagnostic ou la préparation. Si votre organisation exige Autopilot, il se peut que vous deviez réinitialiser et relancer plus tard.

Tâche 8 : Vérifier la disposition des disques et l’espace libre (décidez si l’installation peut engager l’état)

cr0x@server:~$ diskpart
Microsoft DiskPart version 10.0.22631.1

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          476 GB      0 B        *

Ce que ça signifie : Le disque 0 est GPT et pleinement alloué. C’est normal sur des installations fraiches.
Décision : Si le disque est Offline, Read-only, ou affiche des erreurs, arrêtez. Corrigez le stockage d’abord (mode contrôleur, BIOS, NVMe défectueux) ou réimagez.

Tâche 9 : Vérifier l’état de BitLocker (décidez si le chiffrement bloque le provisionnement)

cr0x@server:~$ manage-bde -status c:

BitLocker Drive Encryption: Configuration Tool version 10.0.22631
Volume C: [OS]
[OS Volume]

    Size:                 475.30 GB
    BitLocker Version:    2.0
    Conversion Status:    Fully Decrypted
    Percentage Encrypted: 0.0%
    Protection Status:    Protection Off
    Lock Status:          Unlocked
    Identification Field: None
    Key Protectors:       None Found

Ce que ça signifie : BitLocker n’est pas actif actuellement.
Décision : Si vous voyez « Encryption in Progress » combiné avec des boucles OOBE répétées, vous pourriez être confronté à un problème d’ordonnancement politique (ESP attendant le chiffrement ou l’escrow des clés). C’est un problème Autopilot/MDM, pas un problème de « cliquer plus fort ».

Tâche 10 : Récupérer les logs OOBE qui comptent vraiment (décidez ce qui a échoué, pas ce que l’UI laisse sentir)

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Path 'C:\Windows\Panther' | Select-Object Name,Length,LastWriteTime | Sort-Object LastWriteTime -Descending | Select-Object -First 5"

Name                           Length LastWriteTime
----                           ------ -------------
setupact.log                  1253380 2/5/2026 9:18:02 AM
setuperr.log                    32444 2/5/2026 9:18:02 AM
DiagErr.xml                      9921 2/5/2026 9:17:55 AM
DiagWrn.xml                     18823 2/5/2026 9:17:55 AM
BlueBox.log                      6732 2/5/2026 9:17:41 AM

Ce que ça signifie : Les logs Panther existent et ont été mis à jour pendant votre fenêtre d’échec.
Décision : Ouvrez setuperr.log en premier. S’il pointe vers la connectivité, la validation de certificat, ou l’inscription, arrêtez de chasser des pilotes.

Tâche 11 : Lire rapidement le journal d’erreurs (décidez si une réinitialisation est nécessaire)

cr0x@server:~$ powershell -NoProfile -Command "Select-String -Path 'C:\Windows\Panther\setuperr.log' -Pattern 'Error|Failed' | Select-Object -First 20"

2026-02-05 09:17:52, Error                 [0x0a0033] MIG    Error: Apply during OOBE failed.
2026-02-05 09:17:52, Error                 [0x0a0042] MIG    Failure occurred during provisioning.

Ce que ça signifie : L’étape de provisionnement a échoué. C’est un indice, pas toute l’histoire.
Décision : Si les erreurs sont reproductibles au même pas lors des tentatives, il est souvent préférable de réinitialiser l’état OOBE (ou faire une réinitialisation complète) que de boucler indéfiniment.

Tâche 12 : Vérifier les journaux de l’Observateur d’événements depuis la ligne de commande (décidez si c’est MDM/inscription)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' -MaxEvents 20 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-List"

TimeCreated : 2/5/2026 9:17:49 AM
Id          : 404
LevelDisplayName : Error
Message     : MDM Enroll: Failed (Unknown Win32 Error code: 0x80180014)

Ce que ça signifie : L’inscription MDM a échoué avec un code spécifique.
Décision : Maintenant vous pouvez arrêter de le traiter comme « l’installation est cassée ». C’est une inscription. Gérez les licences, les restrictions d’inscription, les limites d’appareils ou l’enregistrement Autopilot.

Tâche 13 : Confirmer si l’appareil est déjà joint à un espace de travail (décidez si un enregistrement obsolète provoque des boucles)

cr0x@server:~$ dsregcmd /status

+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+

AzureAdJoined : NO
EnterpriseJoined : NO
DomainJoined : NO
DeviceName : DESKTOP-9P2K7S3

Ce que ça signifie : L’appareil n’est pas encore joint.
Décision : S’il affiche AzureAdJoined/EnterpriseJoined de manière inattendue sur un appareil « neuf », vous travaillez peut‑être sur une unité retournée ou un remplacement de carte mère. Nettoyez‑la correctement (enregistrement Autopilot et état local) avant de relancer.

Tâche 14 : Réinitialiser l’état OOBE sans tout détruire l’OS (décidez si vous pouvez sauver rapidement)

cr0x@server:~$ %windir%\system32\sysprep\sysprep.exe /oobe /reboot

Ce que ça signifie : Sysprep redémarre le flux OOBE.
Décision : Utilisez lorsque l’UI OOBE est bloquée/boucle à cause d’une défaillance transitoire et que vous voulez une relance propre. Si Autopilot ou ESP est corrompu par un provisionnement partiel, vous pourriez encore avoir besoin d’une réinitialisation complète.

Tâche 15 : Réinitialisation complète (dernier recours avant réimagerie) et comprendre le compromis

cr0x@server:~$ systemreset -factoryreset

Ce que ça signifie : Lance le flux de réinitialisation de Windows.
Décision : Si vous avez des échecs OOBE répétés et que l’appareil n’est pas encore utilisable, la réinitialisation est souvent plus rapide qu’une exploration forensique. Mais elle ne corrigera pas une politique réseau cassée ni une mauvaise configuration Autopilot.

Blague n°2 : Le moyen le plus rapide de reproduire une boucle OOBE est de dire « ça va aller » à voix haute dans une salle de réunion.

Modes d’échec spécifiques Autopilot/ESP (et comment les prouver)

En entreprise, « boucle OOBE » signifie souvent en réalité « Autopilot/ESP n’a pas pu finir, donc il vous ramène à un écran sécurisé. »
L’ESP (Enrollment Status Page) est la partie qui attend la configuration de l’appareil, les applications et parfois les baselines de sécurité. C’est une porte.
Les portes sont utiles tant qu’elles ne sont pas soudées.

Prouver si c’est réseau vs politique vs service

L’astuce est de créer un test A/B contrôlé :

• Même appareil, réseau différent : Wi‑Fi d’entreprise vs hotspot de téléphone.
• Même réseau, appareil différent : un appareil connu bon qui s’inscrit avec succès.
• Même appareil, même réseau, utilisateur différent : les licences et restrictions d’inscription peuvent être limitées à l’utilisateur.

Tâche 16 : Vérifier le proxy WinHTTP (OOBE utilise souvent WinHTTP, pas les réglages ultérieurs du navigateur)

cr0x@server:~$ netsh winhttp show proxy

Current WinHTTP proxy settings:

    Direct access (no proxy server).

Ce que ça signifie : Aucun proxy WinHTTP configuré.
Décision : Si votre réseau d’entreprise exige un proxy explicite, OOBE peut échouer même si le Wi‑Fi indique « connecté ». Configurez le proxy (ou utilisez un VLAN de provisioning sans exigences de proxy).

Tâche 17 : Si vous devez définir un proxy WinHTTP, faites‑le délibérément (et annulez ensuite)

cr0x@server:~$ netsh winhttp set proxy proxy-server="http=proxy.corp.local:8080;https=proxy.corp.local:8080" bypass-list="*.corp.local"

WinHTTP proxy settings successfully updated.

Ce que ça signifie : Les composants système utilisant WinHTTP passeront par ce proxy.
Décision : N’utilisez ceci que si vous comprenez votre proxy et la chaîne de certificats. Si une inspection TLS est impliquée, vous pourriez avoir besoin que le certificat racine du proxy soit approuvé tôt — souvent irréaliste en OOBE. Un réseau de provisioning propre est une meilleure solution que des acrobaties proxy.

Tâche 18 : Confirmer que le journal de diagnostic MDM est présent et actif (décidez si ESP est en cause)

cr0x@server:~$ powershell -NoProfile -Command "wevtutil gl Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin | Select-String enabled"

enabled: true

Ce que ça signifie : Ce journal est activé et devrait contenir des erreurs utiles.
Décision : S’il est vide alors que vous échouez, vous n’atteignez peut‑être même pas l’inscription MDM. Cela pointe de nouveau vers le réseau/TLS/le flux de compte.

Tâche 19 : Repérer les blocages d’installation d’applications (ESP attend quelque chose qui n’installera jamais)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-AppXDeploymentServer/Operational' -MaxEvents 10 | Select-Object TimeCreated,Id,Message | Format-List"

TimeCreated : 2/5/2026 9:18:10 AM
Id          : 404
Message     : AppX Deployment operation failed for package Microsoft.CompanyPortal...

Ce que ça signifie : Une opération de déploiement d’app a échoué, pouvant bloquer l’ESP.
Décision : Si une seule application bloque l’inscription, corrigez la logique d’affectation/détection ou ajustez l’ESP pour ne pas bloquer dessus. « Bloquer sur tout » est une excellente façon de bloquer sur des futilités.

Tâche 20 : Vérifier que vous n’êtes pas coincé à cause d’un redémarrage requis (piège classique d’« optimisation »)

cr0x@server:~$ reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired" /s

ERROR: The system was unable to find the specified registry key or value.

Ce que ça signifie : Aucune réinitialisation en attente indiquée par cette clé.
Décision : Si la clé existe, vous pouvez être dans un état où le provisionnement nécessite un redémarrage mais le flux ne le fera pas proprement. Un redémarrage contrôlé peut aider ; les tentatives sans fin ne le feront pas.

Angle stockage et disque : quand l’installation vous ment

Les échecs OOBE ne sont pas toujours des « problèmes d’identité ». Parfois, l’appareil ne peut pas persister l’état — parce que le disque est plein,
le système de fichiers est mal en point, ou le contrôleur de stockage est dans un mode inattendu par l’image Windows.
Les défaillances de stockage se présentent souvent sous forme de boucles UI parce que la couche UX n’a aucun moyen de dire :
« J’ai essayé d’écrire un marqueur de provisioning et votre disque a dit non. »

Ce qu’il faut rechercher

• Peu d’espace libre sur le volume OS, surtout sur les petits SSD préchargés avec des logiciels OEM et des partitions WinRE.
• Particularités NVMe après mises à jour firmware (rare, mais réel) : erreurs d’E/S intermittentes lors d’écritures lourdes de setup.
• Changements de mode contrôleur (AHCI/RAID) qui invalident les pilotes sur une image préchargée.
• Pré-provisionnement BitLocker qui démarre avant que l’appareil ait une identité/réseau stable pour l’escrow des clés (ordonnancement des politiques).

Tâche 21 : Vérifier l’espace libre du volume (décidez si vous avez besoin de nettoyage ou de réimagerie)

cr0x@server:~$ powershell -NoProfile -Command "Get-PSDrive -Name C | Select-Object Name,Used,Free | Format-List"

Name : C
Used : 414285373440
Free : 61783527424

Ce que ça signifie : Vous avez ~57 Go de libre. Probablement correct.
Décision : Si l’espace libre est à un chiffre en Go, ne soyez pas surpris par des boucles OOBE. Supprimez les inutiles OEM (si vous pouvez atteindre le bureau) ou réimagez avec une image corporate propre.

Tâche 22 : Lancer un contrôle rapide du système de fichiers (décidez si une corruption est en cause)

cr0x@server:~$ chkdsk c: /scan
The type of the file system is NTFS.
Volume label is OS.

Stage 1: Examining basic file system structure ...
  512000 file records processed.
File verification completed.
No errors found.

Ce que ça signifie : NTFS est sain.
Décision : Si des erreurs sont trouvées, attendez-vous à un comportement d’installation imprévisible. Corrigez les problèmes disque d’abord ou remplacez le matériel si les erreurs se répètent.

Tâche 23 : Vérifier la santé SMART-esque NVMe depuis Windows (pas parfait, mais utile)

cr0x@server:~$ powershell -NoProfile -Command "Get-PhysicalDisk | Select-Object FriendlyName,MediaType,HealthStatus,OperationalStatus | Format-Table -AutoSize"

FriendlyName      MediaType HealthStatus OperationalStatus
------------      --------- ------------ -----------------
NVMe SAMSUNG 512G SSD       Healthy      OK

Ce que ça signifie : Windows considère le disque sain.
Décision : Si HealthStatus est Warning/Unhealthy ou OperationalStatus n’est pas OK, arrêtez d’essayer de « réparer l’installation ». Vous avez un problème matériel/stockage qui se cache derrière un masque logiciel.

Trois mini-histoires d’entreprise venues du terrain

Mini-histoire 1 : L’incident causé par une fausse supposition

Une entreprise de taille moyenne a déployé un nouveau SSID « setup Wi‑Fi » pour le provisioning. Il était propre, rapide et avait un nom sympathique.
L’équipe IT a supposé « s’il donne une IP, il a accès à Internet. » Cette supposition a vécu exactement un lundi matin.

Les appareils se connectaient, puis OOBE a lancé « Quelque chose s’est mal passé » à l’étape de connexion de compte. L’équipe a réimagé trois portables,
remplacé deux cartes Wi‑Fi (parce que pourquoi pas), et perdu une demi-journée.
Pendant ce temps, des employés à distance regardaient des écrans de bienvenue et se demandaient si c’était un test.

Le coupable réel était le DNS. Le SSID distribuait des serveurs DNS internes uniquement accessibles depuis certains VLANs.
DHCP fonctionnait ; le routage fonctionnait ; le DNS non. OOBE ne pouvait pas résoudre les points d’identité de manière cohérente et échouait en boucle.
Le hotspot a fonctionné instantanément, ce qui aurait dû être le premier indice.

La correction était ennuyeuse : corriger la plage DHCP, valider la résolution DNS depuis ce réseau, et ajouter un élément de checklist de provisioning :
« Résoudre un nom public, récupérer une page TLS. » Pas d’héroïsme. Juste moins d’hypothèses.

Mini-histoire 2 : L’optimisation qui a mal tourné

Une équipe endpoints a décidé de « accélérer l’onboarding » en faisant bloquer l’ESP sur tout :
baselines de sécurité, trois agents VPN (ne demandez pas), un scanner de conformité, un logiciel d’imprimante, et une poignée d’apps métier.
La logique semblait infaillible : aucun utilisateur ne touche un appareil tant qu’il n’est pas conforme.

Ça fonctionnait en labo. Bien sûr que oui. Le labo avait une bande passante parfaite, pas d’inspection TLS et aucun mot de passe expiré.
En production, l’ESP est devenu un mécanisme de déni de service contre l’onboarding. Un installateur d’app avait une dépendance CDN capricieuse,
et quand il a échoué, l’ESP a attendu — puis expiré — puis OOBE a bouclé.

L’optimisation visait à réduire les tickets. Elle a créé une nouvelle catégorie de tickets :
« Mon portable est bloqué sur l’installation pour toujours. » L’équipe ne pouvait même pas se connecter à distance parce que l’utilisateur n’avait jamais eu de bureau.

La reprise a été politique et technique. Ils ont scindé les apps en « indispensables pour se connecter » versus « peuvent s’installer plus tard »,
réduit les exigences bloquantes, et veillé à ce que le client VPN ne soit pas requis avant que l’appareil n’ait le réseau pour le récupérer.
La conformité n’a pas disparu. Elle a été déplacée à un stade où l’utilisateur pouvait au moins faire quelque chose pendant que la politique convergait.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise globale avait une règle simple pour les réseaux de provisioning : un VLAN dédié avec egress direct, filtrage minimal,
pas de portail captif, et une surveillance explicite des échecs DNS et TLS. Ce n’était pas sophistiqué, et ça ne gagnait aucun prix d’architecture.

Une semaine, un changement de politique de pare‑feu a resserré accidentellement les règles sortantes de plusieurs réseaux de bureau.
Beaucoup de choses ont cassé, mais le VLAN de provisioning est resté intact parce qu’il était traité comme une infrastructure critique
et que les changements nécessitaient un second réviseur.

Pendant que d’autres équipes paniquaient, le provisionnement des endpoints a continué de fonctionner. Les nouvelles recrues ont reçu leurs appareils. Les remplacements sur le terrain se sont inscrits.
Le support n’a pas été submergé.

Le postmortem était presque irritant de simplicité : le réseau « spécial » n’était pas spécial parce qu’il avait des configurations magiques.
Il était spécial parce qu’il avait un contrôle des changements et une surveillance. Les pratiques ennuyeuses ne font pas le buzz, mais elles survivent au contact de la réalité.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom : « Quelque chose s’est mal passé » juste après la connexion Wi‑Fi

• Cause racine : portail captif ou interception DNS ; l’appareil « se connecte » mais ne peut pas atteindre les points requis.
• Correctif : utilisez un hotspot/Ethernet pour confirmer ; créez un SSID/VLAN de provisioning sans portail captif ; validez DNS et TLS depuis Shift+F10.

2) Symptom : La boucle survient à l’écran de connexion compte Microsoft / compte professionnel

• Cause racine : décalage horaire ou inspection TLS sans racines de confiance ; parfois des identifiants expirés ou un contrôle d’accès conditionnel inadapté au contexte OOBE.
• Correctif : validez w32tm /query /status ; resynchronisez ; testez Invoke-WebRequest ; essayez un réseau propre ; ajustez le contrôle d’accès conditionnel pour l’inscription.

3) Symptom : L’Autopilot ESP reste bloqué indéfiniment, puis échoue et revient au début

• Cause racine : apps/politiques bloquantes, échec d’installation d’une app, redémarrage requis, ou dépendance inaccessible sur le réseau de provisioning.
• Correctif : vérifiez les logs MDM et AppX ; réduisez la portée bloquante de l’ESP ; assurez-vous que les points critiques sont atteignables sans VPN ; évitez « tout installer avant d’avoir un bureau ».

4) Symptom : L’appareil s’inscrit sur le hotspot mais échoue sur le réseau d’entreprise

• Cause racine : exigences de proxy, filtrage sortant, ou particularités d’inspection SSL dans le contexte early‑boot.
• Correctif : réseau de provisioning avec egress direct ; si le proxy est requis, validez le proxy WinHTTP et la chaîne de confiance, pas seulement les paramètres proxy du navigateur.

5) Symptom : La boucle apparaît après une mise à jour ou après « recherche de mises à jour » durant l’installation

• Cause racine : récupération de mise à jour bloquée, mise à jour partiellement appliquée, ou mise à jour de pilote qui déstabilise le réseau/stockage.
• Correctif : relancez OOBE hors ligne (BYPASSNRO), complétez l’installation, puis mettez à jour sous politique contrôlée ; si reproductible sur plusieurs appareils, mettez la ring de mise à jour en pause.

6) Symptom : L’UI de setup plante ou revient instantanément après avoir cliqué sur Suivant

• Cause racine : état OOBE corrompu, dépendance manquante, ou échec d’écriture disque.
• Correctif : vérifiez les logs Panther ; lancez chkdsk /scan ; si les logs montrent des échecs de provisionnement répétés, relancez sysprep /oobe ou réinitialisez.

7) Symptom : « Se connecter avec Microsoft » est bloqué ou manque des chemins attendus

• Cause racine : différences d’édition/politique, paramètres régionaux, ou politiques d’entreprise qui forcent certains chemins de jonction.
• Correctif : vérifiez la build et les politiques ; utilisez le chemin hors ligne pour atteindre le bureau ; appliquez ensuite délibérément la méthode de join/inscription désirée.

8) Symptom : Vous voyez un comportement étrange d’identité d’appareil (branding organisationnel inattendu, invites d’inscription inattendues)

• Cause racine : l’appareil était précédemment enregistré dans Autopilot/MDM, ou le hash matériel pointe vers un locataire différent.
• Correctif : validez l’enregistrement de l’appareil dans votre plateforme de gestion ; supprimez les enregistrements obsolètes ; réinitialisez l’appareil ; relancez l’inscription.

Listes de contrôle / plan étape par étape

Checklist A : « J’ai juste besoin que ce portable arrête de boucler » (15–30 minutes)

1. Tentez un réseau différent (hotspot). S’il fonctionne, arrêtez de blâmer l’appareil.
2. Ouvrez Shift+F10 et exécutez :
   • ipconfig /all (avez‑vous passerelle et DNS ?)
   • w32tm /query /status (heure correcte ?)
   • powershell Invoke-WebRequest vers un endpoint TLS (TLS correct ?)
3. Si le réseau est le blocage, exécutez OOBE\BYPASSNRO et complétez l’installation hors ligne.
4. Une fois sur le bureau, corrigez les pilotes, installez les mises à jour sous politique, puis inscrivez/joinz proprement.

Checklist B : Triage Autopilot entreprise (30–90 minutes)

1. Confirmez que l’appareil est censé utiliser Autopilot :
   • Si le branding organisationnel apparaît de façon inattendue, suspectez un enregistrement d’appareil obsolète.
2. Validez la joignabilité sur le réseau de provisioning :
   • nslookup pour des noms publics
   • Invoke-WebRequest vers des endpoints d’identité
   • netsh winhttp show proxy
3. Récupérez les logs d’inscription :
   • Journal du provider de diagnostics MDM Admin
   • Panther setuperr.log
4. Décidez :
   • Si les échecs correspondent à l’installation d’app : corrigez l’affectation/la détection ou réduisez le blocage de l’ESP.
   • Si les échecs correspondent à l’authentification/CA : ajustez les politiques pour le contexte d’inscription.
   • Si les échecs correspondent au réseau : créez/réparez le VLAN de provisioning et autorisez l’egress nécessaire.
5. Réinitialisez et relancez une fois la dépendance externe corrigée. Répéter un flux cassé n’est pas un « test ».

Checklist C : Sanity stockage avant de perdre une journée

1. Get-PSDrive C vérification d’espace libre.
2. chkdsk c: /scan pour corruption évidente.
3. Get-PhysicalDisk pour l’état de santé.
4. Si quelque chose semble anormal, arrêtez. Remplacez le matériel ou réimagez avec les bons pilotes/firmware stockage.

FAQ

1) Est-ce que « Quelque chose s’est mal passé » est toujours une panne de service Microsoft ?

Non. La plupart du temps c’est l’environnement local : DNS, proxy, décalage horaire, portail captif, ou un impasse de politique Autopilot/MDM.
Vous prouvez une panne en reproduisant sur plusieurs réseaux et appareils et en voyant des échecs cohérents de points d’extrémité.

2) Pourquoi le hotspot « répare » souvent OOBE ?

Les hotspots ont généralement un routage simple, DNS public, pas de portail captif et pas d’inspection TLS. Vous retirez la complexité d’entreprise,
ce qui est excellent pour le diagnostic et légèrement embarrassant pour la politique réseau.

3) Quelle est la façon la plus rapide de savoir si c’est le DNS ?

Depuis Shift+F10, exécutez nslookup pour un nom public. S’il échoue, ou résout vers une IP interne/portail captif,
le DNS est votre suspect principal. Corrigez le DNS ou changez de réseau.

4) Pourquoi l’heure compte autant durant l’installation ?

L’inscription moderne dépend de TLS. TLS dépend des périodes de validité des certificats. Si l’appareil pense être dans le passé ou le futur,
les endpoints rejettent la connexion. L’UI vous dit rarement cela ; elle vous renvoie simplement en boucle.

5) Utiliser OOBE\BYPASSNRO est‑il « dangereux » ?

Ce n’est pas dangereux ; c’est un compromis. Vous différez les étapes d’identité/inscription en ligne. En entreprise, cela peut violer votre posture zéro‑touch,
mais c’est un chemin de récupération valide pour obtenir un bureau fonctionnel en vue d’une remédiation.

6) Pourquoi l’ESP bloque‑t‑il sur l’installation d’apps ?

L’ESP est conçu pour garantir une conformité de base et les outils requis avant de remettre l’appareil à l’utilisateur.
Le problème survient lorsque le « requis » s’étend à « tout ce que nous avons jamais voulu », y compris des installateurs fragiles et des apps non critiques.

7) Que faire si Shift+F10 n’ouvre pas d’invite ?

Certains claviers d’appareil exigent des mods Fn, et certains builds le verrouillent. Essayez Fn+Shift+F10.
Si c’est bloqué par conception, vos options se limitent au changement de réseau et aux décisions de réinitialisation/réimagerie.

8) Quand dois‑je arrêter de dépanner et réimager ?

Réimagez lorsque vous avez des problèmes disque/contrôleur, des échecs répétés sur plusieurs réseaux connus bons,
ou si vous suspectez que le preload OEM est corrompu. Réimagez aussi quand le coût en temps dépasse le coût de la réimagerie.
Suivez cette décision — si vous réimagez fréquemment, vous avez un problème systémique en amont.

9) Les outils de sécurité comme l’inspection SSL peuvent‑ils casser OOBE ?

Oui. Si l’environnement d’installation ne fait pas confiance au certificat racine de l’appareil d’inspection, TLS échoue.
La correction n’est pas « ignorer les erreurs de certificat » (impossible). La correction est un réseau de provisioning propre ou une stratégie de chaîne de confiance qui fonctionne avant l’inscription.

10) Pourquoi ces problèmes semblent‑ils intermittents ?

Parce que les systèmes distribués échouent de façon intermittente. Timeouts DNS, charge proxy, roaming Wi‑Fi et throttling d’endpoints peuvent transformer une configuration marginale
en pile ou face. Votre objectif est d’éliminer la marginalité : réseau stable, heure correcte, blocage minimal et contrôles de santé mesurables.

Conclusion : prochaines étapes pour éviter que cela ne se reproduise

Si vous ne retenez qu’une chose : traitez OOBE comme un workflow de production, pas comme un jouet grand public. Il dépend de l’identité, du réseau,
de la cryptographie, des politiques et du stockage. C’est beaucoup de surface pour un « écran de bienvenue ».

Prochaines étapes pratiques :

1. Déployez un réseau de provisioning avec egress propre, pas de portail captif et DNS prévisible.
2. Ajoutez un test d’acceptation en deux commandes à votre processus de staging : résolution DNS et récupération TLS depuis Shift+F10.
3. Auditez la portée de blocage ESP : bloquez sur ce qui est nécessaire pour être sécurisé et fonctionnel, pas sur ce qui est agréable à avoir.
4. Instrumentez vos échecs : capturez Panther et les événements diagnostics MDM lorsque les appareils bouclent, et classez les causes racines.
5. Faites de la réimagerie un outil contrôlé, pas un bouton de panique — puis corrigez les conditions amont qui entraînent les réimages.

Les désastres d’installation ne se résolvent pas en cliquant plus fort sur « Réessayer ». Ils se résolvent en supprimant l’incertitude : réseau connu bon, heure correcte,
vérifiabilité des points d’extrémité, politiques sensées, et disques capables d’écrire réellement ce que Windows tente de sauvegarder.