Connexion
Abonnez-vous

Windows 11 24H2 : des mises à jour incrémentielles, plus petites et rapides à installer

Des mises à jour « durables »

Windows 11 24H2 : des mises à jour incrémentielles, plus petites et rapides à installer

Microsoft a présenté il y a deux jours une amélioration importante à venir pour son processus de mise à jour sous Windows 11. À partir de la fin de l’année, le différentiel appliqué à certains correctifs mensuels sera plus fin. Avec à la clé, une réduction du temps d’installation et du poids des mises à jour.

Le 17 juillet à 16h16

Pour comprendre l’intérêt du changement annoncé le 15 juillet, revenons sur le fonctionnement des mises à jour mensuelles sur Windows 10 et 11.

Actuellement, Microsoft en déploie deux types. Les plus importantes, les correctifs de sécurité, sont publiées le deuxième mardi de chaque mois. Cette fréquence est la même depuis de nombreuses années. Elle a été mise en place pour donner aux entreprises un rythme clair et prévisible. Ces correctifs sont téléchargés et installés automatiquement, la machine devant après coup redémarrer. En entreprise, ils sont souvent gérés par un processus spécifique, permettant de planifier l’installation.

Viennent ensuite les mises à jour de « qualité ». Celles-ci ne sont plus liées directement à la sécurité, mais viennent corriger des bugs plus généraux. Ces mises à jour peuvent également contenir de nouvelles fonctionnalités. Bien qu’il y en ait pratiquement tous les mois, leur installation ne devient obligatoire qu’au bout de quelque temps.

Il faut ajouter un troisième type de mise à jour, nettement plus rare : les évolutions majeures. Elles sont annuelles ou semestrielles selon le système et les années. Pour Windows 11, la prochaine est la 24H2, dont le nom signifie « deuxième semestre 2024 ». Ces mises à jour modifient de larges pans du système et proposent de nombreuses nouveautés. Leur installation est optionnelle pendant un an, après quoi elles deviennent obligatoires. Elles se téléchargent et s’installent alors automatiquement. Sur une machine un peu ancienne, l’immobilisation de la machine peut prendre 10 à 20 min.

Le statut RTM et le calcul du différentiel

Depuis des années, les mises à jour de sécurité de Windows fonctionnent sur un mode cumulatif. Là où il fallait avant installer les correctifs mensuels comme autant de mises à jour séparées, Windows Update propose aujourd’hui une seule mise à jour contenant tout.

Ce « tout » est une accumulation de toutes les mises à jour rendues disponibles depuis la RTM de la dernière révision majeure du système. RTM, pour Release To Manufacture, est le statut d’une version signifiant qu’elle est prête pour distribution. C’est en général un équivalent à « version finale ». Il y a quelques subtilités, mais elles ne sont pas importantes dans le cas présent.

Pour donner un exemple simple, la version majeure en cours de Windows 11 est la 23H2. Quand des mises à jour mensuelles sont préparées, elles incluent tout ce qui est sorti depuis la RTM de cette version. Les téléchargements ont donc tendance à gonfler avec le temps. En revanche, le temps d’installation reste à peu près le même, car seule la partie effectivement absente de la machine est installée. Le reste est « inerte » et disparait après installation.

Vers des mises à jour « checkpoint »

On savait que Microsoft préparait depuis un certain temps un système plus souple. Le 15 juillet, l’entreprise a donc annoncé une importante modification qui arrivera avec la version majeure 24H2 et entrera en piste vers la fin de l’année.

L’éditeur y présente les points de contrôle, ou mises à jour « checkpoint ». L’objectif est simple : plutôt que d’attendre la RTM d’une version majeure pour établir une base de calcul, ces mises à jour établiront un nouveau point de contrôle. Il n’est manifestement pas prévu qu’elles soient présentes tous les mois, mais chacune consistera la base d’un nouveau calcul incrémentiel.

Le gros avantage est qu’elles viendront « casser » l’accumulation faite au fil des mois. Si vous recevez l’une de ces mises à jour, la mise à jour mensuelle suivant ne téléchargera et n’installera que le différentiel (delta) strictement nécessaire.

Les entreprises également concernées

Le delta étant calculé depuis le dernier point de contrôle et non plus depuis la dernière RTM, ce sont toutes les mises à jour qui seront plus légères à télécharger. Microsoft met donc en avant trois avantages : de plus petits téléchargements, une installation plus rapide et une charge moins importante pour les serveurs, qui n’auront plus à fusionner de trop grandes masses de données. Microsoft se permet d'indiquer au passage que ce fonctionnement est plus « durable ».

C’est également valable en entreprise, puisque le changement sera aussi présent dans Windows Server 2025. La prise en charge dans des services comme Windows Update for Business, Windows Autopatch et Windows Server Update Services (WSUS) sera automatique. Les administrateurs n’auront pas à modifier leurs réglages.

Pour les personnes testant les préversions de Windows 11, ces changements sont présents dans la dernière build (26120.1252) du canal Dev du programme Windows Insiders.

Commentaires (40)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar
Ils n'ont toujours pas compris que le calcul de ce qu'il faut télécharger doit être fait sur la machine à mettre à jour et pas sur le serveur. C'est comme cela que l'on ne charge que ce qui est nécessaire depuis la mise à jour précédente. Les gestionnaires de paquet des distribution Linux (que je connais) font comme cela depuis toujours.
votre avatar
tu ne voudrais tout de même pas demander a Microsoft de mettre en place une solution simple comme un apt-get ou un git :roule:

Pourquoi faire simple quand on peut faire compliqué ! (et faire payé plein pot cette complexité inutile)
votre avatar
Je rajouterais, tu veux quand même pas demander à MS de faire un vrai OS par hasard. Un truc qui marche correctement (par rapport à un Linux) et pas une daube sans nom.
votre avatar
Windows est un vrai OS qui tient a route ... Et bien mieux documenté pour une entreprise que Linux, et plus stable dans le temps sur bien des points.
Si tu veux un vrai conccurent à Windows dans l'entreprise, ce serait FreeBSD, ou Readhat, ou Oracle ou Debian, pas "Linux"
votre avatar
Je ne souhaite pas lancer un débat Linux/Windows, qu'importe les saveurs que l'on met derrière mais je veux pas non plus me laisser sans défense.

Pour moi, Windows n'a pas sa place. Il n'est pas stable (je connais pas un PC Windows qui ne doit pas rebooter au bout 3 semaines, ni qui maintient des perfs constantes dans le temps d'utilisation...). Sa seule stabilité, c'est sa rétro-compatibilité et son ABI & API. Mais c'est une force comme une faiblesse. Celà dit je concède que je me suis déjà écharpé avec Linux sur ce point.

La documentation est inférieure à celle de Linux. Exemple, tu cherches la doc pour mmap. J'ai besoin de parcourir plusieurs sous-liens pour trouver l'information de savoir si c'est du COW ou pas. Linux, un simple Ctrl-F et j'ai mon info. Et mieux, j'ai le code source pour répondre à mes interrogations.
En revanche, elle est accessible. Le ticket d'entrée pour la doc de Windows est nettement inférieure à celle de Linux.

Windows n'est pas sécure. Désolé mais le principe de kerckhoffs est pour moi strictement requis pour avoir confiance sinon c'est de la sécurité par obscurantisme. Et nous savons que c'est un échec.

Je pourrais aussi te parler des faibles performances du NTFS et du scheduler I/O du kernel. Pour un OS 2024 d'entreprise c'est assez risible. Ce qui le sauve, c'est la latance des SSD.
La question se pose également pour les autres schedulers et la capacité de Windows à gérer correctement du multiprocessing.

Je termine sur ceci. Windows sera un vrai OS quand il pourra gérer un supercalculateur du top-500. A defaut, pouvoir être aussi rapide qu'un Linux sur un benchmark du LINPACK. Même à code équivalent en asm, Windows reste significativement derrière (sur nos benchmark, ~10-15 % derrière du Linux [Fedora Workstation]).
votre avatar
"Je ne souhaite pas lancer un débat Linux/Windows, par contre faire un gros troll, ca je veux bien" :kimouss:
votre avatar
Je ne comprends pas trop ce que tu veux dire. Je n'ai vu nul part que le calcul se faisait sur le serveur. Et le système actuel (le futur ancien système donc), il n'y a pas de calcul, puisque le téléchargement est le même pour tous.

Et le téléchargement "unique" n'a pas que des inconvénients :
- les téléchargements étant les mêmes pour tous, il est plus facile de mettre en place un cache / proxy / partage par peer / téléchargement offline
- le gestionnaire de paquets c'est bien pour gérer l'installation d'applications et leurs dépendances. Ici, ce n'est pas le cas, car les dépendances vont dépendre de la machine et énormément de sa configuration hardware (type de processeurs, cartes graphiques, bus, réseau, RAM, disque dur, etc.) avec une complexité, certes peut être pas insurmontable, mais plus grande que la gestion "statique" de dépendance des systèmes de gestion de paquets actuels.
- L'installation de la mise à jour se fait offline entre le moment où elle débute, et le moment où elle se termine. Avec un gestionnaire de paquets, ce n'est pas toujours le cas. On peut certes télécharger en amont les paquets à installer, mais un paquet peut ensuite avoir besoin de ressources complémentaires nécessitant une connexion internet que le gestionnaire de paquets ne pourra pas télécharger lui-même (c'est rare, mais ça arrive).

Je ne dis pas qu'un système différentiel ne présente pas d'avantages et que le système complet est exempts de défauts. Je dis juste que le système "complet" n'a pas que des défauts, et à aussi des avantages ;)
votre avatar
mais un paquet peut ensuite avoir besoin de ressources complémentaires nécessitant une connexion internet que le gestionnaire de paquets ne pourra pas télécharger lui-même (c'est rare, mais ça arrive).
Non, je ne connais pas gestionnaire de paquet Linux qui impose. En tout par Debian, Fedora, Ubuntu, Redhat entreprise / Centos, ArchLinux ce n'est pas le cas.
votre avatar
Le problème n'est pas le gestionnaire de paquet, mais le paquet lui-même. Quand tu as des téléchargements dans des hook post-install, tu es bien coincé si tu n'as pas la connexion internet à ce moment là.

Je ne pense pas que ce soit courant dans les paquets des dépôts officiels, mais dans les paquets d'applications hors dépôt, fait par des personnes qui ne sont pas des packagers, oui, ça arrive.
votre avatar
Concernant ce point :

*[...] le téléchargement "unique" n'a pas que des inconvénients :
- les téléchargements étant les mêmes pour tous, il est plus facile de mettre en place un cache / proxy / partage par peer / téléchargement offline [...]*

Le téléchargement incrémental ou différentiel n'est pas non plus incompatible avec le caching et le peering : au lieu d'héberger un gros fichier monolithique KB1234.msu, tu héberge son contenu. Il suffit d'héberger les fichiers à l'intérieur de l'archive, et tu héberge aussi le manifest qui contient les métadonnées requises (checksum, conditions d'installation ou pas, etc.)

En procédant comme ça, c'est facile de conserver du cache tout en augmentant la finesse de l'incrémental : toutes les machines téléchargent le manifest, puis ensuite seulement les fichiers unitaires requis.

Et rien n'empêche de concevoir un fetcher dédié pour demander à télécharger la mise à jour hors ligne (genre avec Microsoft Catalog.
votre avatar
On peut certes télécharger en amont les paquets à installer, mais un paquet peut ensuite avoir besoin de ressources complémentaires nécessitant une connexion internet que le gestionnaire de paquets ne pourra pas télécharger lui-même (c'est rare, mais ça arrive).
C'est totalement faux, tous les gestionnaires de paquets connaissent et chargent à l'avance le contenu (éventuellement en // d'un autre install pour gagner du temps). C'est comme ça que les distrib linux ont toujours fonctionné, et c'était absolument impératif à l'époque où les distrib arrivaient en DVD / CD. Sous windows c'est pas du tout le cas, pour beaucoup de soft tu charges en fait un installeur coquille vide qui à son tour va télécharger réellement le logiciel.
votre avatar
Crois ce que tu veux.

Quand le téléchargement est dans un script en hook post-install, ton gestionnaire de paquet ne peut rien faire. Je suis d'accord pour dire que le paquet était mal foutu, mais c'est le paquet fourni par l'éditeur. Donc au bout d'un moment...

Par contre, je n'ai pas souvenir d'avoir eu le problème avec des dépôts officiels. C'était toujours des dépôts tiers.
votre avatar
Clair qu'on voit sacrément la différence de gestion des maj entre une Debian et un Windows, pour avoir un parc mixte...

Et aussi pourquoi Windows n'a pas de netinstall pour le déploiement ? Bien plus pratique pour déployer rapidement des masters sans avoir à télécharger un iso régulièrement...

Après ce n'est pas tant le téléchargement qui pose souci (avec une connexion fibre c'est assez rapide) que le temps de l'installation lui-même qui est vraiment fou avec une machine récente.

un reboot (obligatoire...) met un temps de dingue à déployer les maj sur l'OS...
votre avatar
Winget? On en parle rarement mais c'est un gestionnaire de paquet sous Windows qui fonctionne très bien.
votre avatar
Tu n'as pas dû t'en servir pour écrire ça :D
Le truc n'est même pas capable de découvrir ce qui est installé sur la machine,
winget ne connait que quelques softs, aucun pilote, pas même les màj de windows,
ça propose presque systématiquement des paquets obsolètes,
un grand nombre de paquets proposent ad vitam la même mise à jour parce qu'il est incapable de déterminer la version installée.

100% inutilisable ! (d'ailleurs MS ne communique plus trop sur cette daube depuis un moment)
votre avatar
Tu ne dois pas trop savoir de quoi je parle pour dire ça.:mrgreen: et au vu de ta réponse c'est même pire.

Si tu compares à 100% de features avec Apt pour Linux oui, c'est moins complet mais est-ce une bouse pour autant, non et comme d'hab', ce qui est excessif est insignifiant.

J'ai aucun des problèmes que tu cites dans la limite de l'utilisation de l'outil mais peut être que je sais comment et dans quel périmètre utiliser Winget et c'est je crois la même chose avec Apt.

Je te laisse te documenter.
votre avatar
Acrobat Reader, LibreOffice, Firefox, Gimp: 4 packages significatifs qui ne sont pas ou mal gérés par winget.

Tous étaient en retard de version dans winget, une fois installé au premier lancement chacun de ces softs proposaient leur propre mise à jour à l'exécution. Une fois la mise à jour faite depuis l'appli, winget oublie le soft et ne le propose plus du tout à l'upgrade.

winget ne gère même pas le propre store de Microsoft
winget upgrade --all
tu ouvres le store Microsoft, il trouve pleins de màj que winget n'avait pas vu.

J'ai suivi tes conseils et me suis documenté :
- 991 bugs ouverts
- les 80 bugs uniquement sur la commande upgrade semblent confirmés mon ressenti
votre avatar
En effet, je ne l'utilise pour la mise à jour des logiciels que tu cites qui ont souvent leur propre outil de mise à jour (je n'ai pas vérifié, je ne les utilises pas tous).

Encore une fois Winget n'est pas parfait mais de là à le qualifier de bouse, c'est TON jugement de valeur mais c'est pas le mien dans MON périmètre d'utilisation.

Et en effet, plein de bug ouverts, ça signifie aussi qu'il est utilisé et que ses utilisateurs souhaitent leur faire évoluer. Est-ce que MS met l'emphase nécessaire? MS ne met jamais assez d'effort sur un tas de choses qui mériterait d'évoluer ( coucou Console)

Si tu penses que cet outil serait utile un peu à la manière d'Apt pour Linux, et qu'à ce titre le faire évoluer serait une bonne idée, pourquoi ne pas contribuer au Git de Winget?

Sinon, j'utilise aussi Chocolatey dans certains cas (ie: machines Windows clientes).
votre avatar
winget est le truc qui m'a fait convertir mon dernier laptop sous windows (au cas où): un vieux Dell qui traine dans le salon ou la cuisine pour les recettes. Du coup il est passé sous Linux comme tout le reste, et au moins je ne passe plus mon temps à le rebooter à chaque usage.
votre avatar
Ok. C'est noté Linux c'est bien et Windows le mal. Bon JO.
votre avatar
Je réagis juste sur la métrique utilisée (le nombre de bogues).

Le nombre de bogue a un instant T ne donne absolument aucune information sur la (non) qualité d'un logiciel. Plus le nombre de bogues est grand, plus le logiciel est utilisé. C'est éventuellement la seule chose que l'on pourrait en déduire.

De plus, bogue dans ce contexte est inapproprié, c'est plutôt ticket qu'il faudrait employer. En effet, des demandes d'évolutions apparaissent aussi en tant que bogue. Et s'il y a des demandes d'évolutions, c'est que le logiciel est aussi utilisé.

Enfin, si le nombre de bogues ouvert reflétait la (non)qualité d'un logiciel, alors aptitude ne fait guère mieux que winget. Faut-il en conclure pour autant que c'est une daube ?
votre avatar
Effectivement ma réflexion n'est pas sur le nombre mais le libellé des tickets, qui est assez alarmant : "détecte pas la version installée", "ne gère pas le type d'installeur". ça rejoint entièrement mon ressenti.

Ce sont des problèmes majeurs qui rendent l'outil inutile, et ça fait 1an et demi que ces tickets sont ouverts sans prise en compte. (ça s'est plutôt un bon indicateur je trouve ;-)

Je pense que le qualitatif de daube est assez mérité.

Ce n'est pas un simple problème de métadata mal renseigné par les éditeurs tiers, Notepad (le nouveau), paint 3d produit Microsoft ne sont pas dispo !
votre avatar
votre avatar
Encore un truc à la c*n qui va plomber les admin SCCM, et conduire à des packages de 4TO, ou j'ai pas bien compris.
Ce qu'il se passe avec SCCM, on fait une règle "package les dernières updates du mois pour w11 23h2", il met la dernière cumul et vire ce qui est obsolète depuis > 3 mois dans un package SCCM et les pc téléchargent tous le même package

là vu qu'on ne sait pas l'état des xxxxxpc (dont certains fraichement réinstallés donc RTM, d'autres éteints depuis 4 mois etc), s'il faut garder tous les KB différentiels, dans le même package SCCM "delta 1 mois, delta 3 mois, delta 3ans..." :eeek2:

Faire 1 package new par mois c'est ingérable en distribution sur une grosse infra, sans compter que certains sont superseed, mais si c'est plus du cumulatif, comment je reviens à l'état full patch depuis un RTM avec les updates qui sont purgées par SCCM :pleure:
votre avatar
J'ai compris autre chose (mais aussi sur la base d'autres articles précédents): Microsoft veut casser les "paquets": dans les différents paquets, souvent des fichiers sont identiques aux précédents, l'idée est de ne plus les envoyer mais d'envoyer uniquement les fichiers différents.
Ca ne change pas le repository des paquets.

Ce qui va exploser ton SCCM, ce sera la montée des paquets ARM en plus de X64 et x86 s'il t'en reste.

Pour les linuxiens, c'est comme si on ne récupérait pas tout un deb mais uniquement les fichiers différents. Ou si pour mettre à jour un snap on ne retéléchargeait que des morceaux.
votre avatar
j'ai vu les résultats dans sccm avec leur dernière invention il y a env 1 an
un kb de 725Mo dans le catalogue c'est 9.9 go dans sccm car ces boulets y ont intégré les features on demand (env 5.7+2.5go) dans tous les kb cumul intégrés dans sccm

extract de sccm sur le KB5040442
| fichier | taille |
|http://../.../public/featureondemand_3294af9937b733783476da837b21943dc160faaa.wim | 5747,73 |
| http://../.../public/edition_b7d4cae381a5971e5bf48a1246488c4e7861a0b0.wim | 2506,84 |
votre avatar
Je suis bien content de ne plus m'occuper de cela :)
votre avatar
Moi non plus, j'ai délégué... mais ça me reste en travers car la sécu ME pète des plombs tous les mois avec l'augmentation du trafic sur les FW :D
votre avatar
Petite et rapide chez Microsoft on connaît pas... C'était déjà une promesse d'il y a quelques années et les mises a jours mettent un temps de dingue a s'installer... J'attends de constater mais la marge est immense....
votre avatar
C'est déjà mieux que sur Android où le système des Google Pixel fait qu'il faut parfois 1H pour une mise à jour mensuelle de 20 Mo.
votre avatar
Et des mise a jours stable?
votre avatar
Dès qu'ils auront mis un émulateur windows sur un noyau linux.
votre avatar
les mises à jour sont stables pour la grande majorité des utilisateurs. tout le monde n'est pas concerné par les problèmes loin de là.
le problème c'est que Windows, c'est plusieurs centaines de millions d'utilisateurs voire milliards. donc les problèmes ont plus de visibilité que Linux ou Mac qui sont loin derrière en terme de part de marché.
votre avatar
"le problème c'est que Windows, c'est plusieurs centaines de millions d'utilisateurs voire milliards. donc les problèmes ont plus de visibilité que Linux ou Mac qui sont loin derrière en terme de part de marché."

Ça dépend comment tu comptes. Les estimations du nombre de machines Windows tournent autour de 1.4 milliard. Rien que chez Docker, on estime à 700 millions le nombre de déploiements, et Datadog estime le nombre de containers à 2.4 milliards dans le monde. Si on ajoute tous les serveurs hors containers, les OS embarqués de la plupart des box et routeurs (il y a aussi du *BSD dedans, certes), et les 3 milliards d'android qui, après tout, sont des Linux, la conclusion n'est pas si évidente que Windows est devant.
votre avatar
Ton calcul est biaisé. On voudrait avoir la part de marché de tel ou tel OS (ou noyau), je ne dis pas. Là, on parle de processus de mise à jour :
- Un docker, tu n'utilises pas le gestionnaire de paquets pour le mettre à jour, tu mets à jour le conteneur via docker (autrement dit, tu télécharges une nouvelle image au lieu de mettre à jour celle déjà existante).
- l'embarqué a des spécificités propres. Idem, on ne fait pas de "apt update" (ou équivalent), mais en mettant à jour le firmware
- Android a un processus de mise à jour particulier qui n'a rien à voir avec ce que font les distributions linux classiques via leur gestionnaire de paquets.

Ensuite, les usages desktop / serveur sont très différents également, et n'ont pas les mêmes contraintes. Quand j'avais du Linux en desktop, les problèmes de mise à jour que je rencontrais était à 80% liés au système graphique (serveur graphique qui ne se lance pas, ouverture de session impossible ou qui plante, etc.), le reste du temps à du matériel qui se mettait à ne plus fonctionner correctement (souvent imprimante et/ou scanner). Problème qui ne se pose généralement pas pour le serveur ^^

Sur un serveur, tu as rarement une couche graphique (c'est possible, mais peu fréquent au final) et rarement des problèmes de compatibilités matériels (déjà, parce que le matériel connecté y est rare, et ensuite, les contrôleurs de disques durs, cartes réseaux, etc. sont choisis avec plus ou moins de soin par les hébergeurs pour fonctionner correctement sous du Linux).
votre avatar
Pour Docker, j'ai le raisonnement absolument inverse du tien : il y a un nombre incalculable de Dockerfiles qui commencent par apt-get update et une série de apt-get install. En CI, ça me semble affolant la charge que ça doit mettre sur les serveurs de paquets, beaucoup plus élevée que pour un OS desktop.
votre avatar
Attention : tu confonds la création de l'image de la mise à jour d'une image déployée. Ce sont 2 processus différents réalisés par 2 acteurs différents : la création de l'image se fait par le publieur, pas par l'utilisateur.

Et même si les deux peuvent être fait par la même personne, cela n'empêche pas d'être deux processus complètement distincts avec des workflows normalement distincts. Un utilisateur (j'insiste bien sur le terme utilisateur) ne doit pas (ou en tout cas, ne devrait pas) mettre à jour son image docker en se connectant à celle-ci et en effectuant un apt-get update ou assimilé. C'est une très mauvaise utilisation qui va à l'encontre même de ce qu'est docker.
votre avatar
En CI, tu crées des images Docker à la volée.
votre avatar
Oui, bien sur que tu peux créer des images à la volée en CI. Heureusement d'ailleurs. Mais ce sont des nouvelles images. Une image, une fois créée est immuable et donc toutes nouvelles versions est simplement une nouvelle image.

Avec Docker, on ne met pas à jour une image, on télécharge/crée une nouvelle image de la version à jour.
votre avatar
Sauf qu'on ne met toujours à jour les Linux (Android, voiture, vidéo proj) ou partiellement (docker, VM fournies par les éditeurs qui ont 3 ans de retard...)

Et si on compare, des windows server qui tombent c'est très très rare (et encore plus rare sur du windows server core).

Windows 11 24H2 : des mises à jour incrémentielles, plus petites et rapides à installer

  • Le statut RTM et le calcul du différentiel

  • Vers des mises à jour « checkpoint »

  • Les entreprises également concernées

Fermer