Des centaines de millions d’utilisateurs à travers le monde ont longtemps cru que l’image de profil attribuée lors du premier démarrage de Windows XP relevait du pur hasard. Le 9 septembre 2026, Raymond Chen, ingénieur chevronné chez Microsoft, a publié un extrait de code levant enfin le voile sur une mécanique système restée secrète pendant un quart de siècle. Ce choix d’avatar apparemment fortuit n’a jamais été un tirage au sort aveugle : il s’agissait du résultat déterministe d’un calcul bien précis.
Un tweet déclenche une séance d’archéologie de code
Le 11 décembre 2025, un internaute du nom de Xeno a lancé une bouteille à la mer sur Twitter : quelqu’un avait-il déjà cherché à comprendre l’algorithme de génération aléatoire utilisé par Windows XP pour attribuer l’image de profil lors de la création du premier compte ? Cette interrogation trottait dans l’esprit de la communauté des développeurs depuis plus de vingt ans. Certes, en avril 2004, Raymond Chen avait brièvement mentionné sur son blog que les images par défaut d’XP étaient choisies au hasard. Mais cette formule allusive ne pouvait rassasier la curiosité des passionnés d’ingénierie. Ils ne voulaient pas d’un résumé de surface ; ils exigeaient d’examiner le code source et la démonstration mathématique sous-jacente.
Raymond Chen a fini par publier l’intégralité de la logique algorithmique sur son blog, The Old New Thing. L’article s’est hissé en tête de Hacker News, cumulant 333 points et 162 commentaires. Les lecteurs y ont découvert que recevoir la guitare, la fleur, le jeu d’échecs ou le canard en plastique ne relevait en rien d’une pioche à l’aveugle dans une boîte noire. Derrière l’écran tournait un enchaînement mathématique d’une rigueur absolue.
La graine initiale : verrouillée sur les millisecondes de démarrage
Dans Windows XP, ces fichiers d’images de profil étaient enfouis au fin fond de l’arborescence : %ALLUSERSPROFILE%\Application Data\Microsoft\User Account Pictures\Default Pictures. Lors de la configuration d’un nouveau compte, le système devait sélectionner une image parmi celles présentes dans ce dossier.
La routine s’appuyait sur le générateur de nombres pseudo-aléatoires interne de Windows, RtlRandomEx. Tout algorithme pseudo-aléatoire requiert une graine initiale (seed). Plutôt que de solliciter une source complexe d’entropie matérielle, les ingénieurs de Microsoft ont simplement utilisé la valeur de retour de la fonction GetTickCount(). Cette API renvoie le nombre exact de millisecondes écoulées depuis la mise sous tension du système d’exploitation.
Un algorithme pseudo-aléatoire obéit à des paramètres d’entrée parfaitement déterministes. Si l’on connaissait le nombre exact de millisecondes mesuré lors du démarrage de la machine, on pouvait prédire à coup sûr quelle image serait attribuée. L’imprévisibilité n’était qu’une illusion d’optique pour l’utilisateur : au niveau du code, le processus était entièrement reproductible.
L’échantillonnage par réservoir pour limiter le parcours à une seule passe
Face à un répertoire dont le nombre de fichiers est inconnu d’avance, la démarche académique consiste à effectuer deux passes : parcourir l’ensemble du dossier pour compter le nombre total n d’éléments, tirer un indice aléatoire entre 1 et n, puis reparcourir le dossier une seconde fois pour charger le fichier correspondant. C’est l’approche naïve classique.
Les ingénieurs de Microsoft ont opté pour une méthode infiniment plus élégante : un algorithme à passe unique. Pendant la lecture du répertoire, le système ne conserve en mémoire que deux variables : un compteur count et le gagnant provisoire winner. À chaque élément rencontré, le compteur count s’incrémente d’une unité. Le système remplace alors winner par l’image courante avec une probabilité de 1/count. Au terme de l’unique parcours du répertoire, le fichier retenu dans winner constitue la décision finale.
Figure : Code de l’algorithme à passe unique selectRandomFromIterator. Source : The Old New Thing
Il s’agit là du cas particulier classique de l’échantillonnage par réservoir (Reservoir Sampling) pour k = 1. Dans un ensemble de n éléments, le tout dernier fichier a une probabilité stricte de 1/n d’être sélectionné. S’il n’est pas retenu, le problème se ramène récursivement à un choix uniforme parmi les n - 1 fichiers précédents. Peu importe le volume de fichiers stockés dans le dossier : chaque image a rigoureusement la même probabilité uniforme de 1/n d’être désignée vainqueur.
La théorie mathématique face aux contraintes d’I/O du système
Pourquoi renoncer à la simplicité des deux passes au profit de l’échantillonnage par réservoir ? La réponse réside dans les goulets d’étranglement de l’architecture du système d’exploitation. Lors de l’initialisation d’un profil utilisateur, le coût d’accès aux appels du système de fichiers est infiniment plus lourd que le coût de calcul du processeur. À l’époque, les disques durs mécaniques subissaient d’importantes pénalités de latence lors de traversées répétées de répertoires contenant de multiples petits fichiers.
Le parcours à passe unique a réduit de manière drastique les appels au système de fichiers, tout en restant insensible aux modifications de répertoire en cours de traitement.
Un parcours en deux passes exige impérativement que le nombre de fichiers demeure inchangé entre la première et la seconde itération. Si, dans l’infime intervalle séparant le comptage et l’extraction, un programme tiers ajoutait ou supprimait un fichier, le système s’exposait à une erreur d’index hors limites ou à une exception de fichier introuvable, provoquant un plantage. Le mécanisme à passe unique éliminait d’emblée ce risque de concurrence critique.
Arrêt net après 100 images parcourues
Sur le plan purement mathématique, l’échantillonnage par réservoir fonctionne à merveille sur des flux infinis : au fur et à mesure que le compteur grimpe, la probabilité d’évincer le candidat retenu diminue de façon inversement proportionnelle. Cependant, le code d’un système d’exploitation commercial ne parie jamais sur une exécution illimitée. Au sein de cette boucle critique, les ingénieurs ont gravé dans le marbre une barrière de sécurité pragmatique.
Dès que l’algorithme atteint le seuil de 100 images inspectées, il interrompt immédiatement la boucle et renvoie le vainqueur en cours.
Figure : Interface Luna par défaut de Windows XP. Source : Wikipedia
Les développeurs système chevronnés ne sacrifient jamais la stabilité à la pureté mathématique. Instaurer un plafond physique à 100 images empêchait qu’un dossier malicieusement garni d’un million de fichiers ne vienne geler le processus de démarrage. Les modèles théoriques exigent une distribution uniforme sur des ensembles infinis, mais le logiciel industriel obéit à un impératif supérieur : le système ne doit jamais planter.
Une précision d’orfèvre sous le masque du hasard
Pour en revenir à l’interrogation initiale de Twitter, des dizaines de millions d’utilisateurs se souviennent de l’émotion ressentie lors du premier allumage de Windows XP entre 2001 et 2014. Découvrir sur son moniteur un ballon de football, un caneton ou une grenouille ressemblait à une délicate surprise offerte par la machine. L’œil humain est incapable de discerner des écarts de quelques millisecondes dans la séquence de boot : cette infime variation temporelle a suffi à maquiller un calcul d’une rigueur absolue en véritable coup du sort.
Le billet de Raymond Chen n’a pas seulement répondu à une énigme d’antan ; il a également figé un instantané de l’ingénierie logicielle d’une époque révolue. En ce temps-là, la mémoire vive était comptée et les disques durs étaient lents. Chaque ligne de code devait justifier son coût, et le moindre cas limite faisait l’objet d’une programmation défensive.
L’avatar distribué il y a 25 ans n’avait rien d’un billet de loterie tiré au chapeau. C’était l’œuvre d’un échantillonnage maîtrisé et de garde-fous stricts : une mécanique de précision offerte à deux générations d’utilisateurs.
Références :
- The Old New Thing
- HN
- Wikipedia
