Le 29 juillet 2026, le studio The Indie Stone a publié Project Zomboid Build 42 en la faisant passer directement sur la branche stable publique, sans étape intermédiaire par la branche instable. Deux correctifs ont suivi le 5 août. Pour les joueurs, c’est l’aboutissement d’un très long cycle de développement. Pour les administrateurs de serveurs multijoueur, c’est d’abord une rupture : aucune sauvegarde Build 41 n’est compatible, la surface de la carte a doublé, et un correctif de sécurité diffusé en amont peut affecter certains mods.
Voici ce que les annonces officielles confirment, ce qu’elles laissent en suspens, et les décisions que cela impose avant de basculer une partie en ligne.
Branche stable, branche bêta : sur Steam, un jeu peut être distribué en plusieurs versions parallèles. La branche stable est celle installée par défaut. Les branches bêta sont des versions alternatives, que l’on active manuellement — pour tester une nouveauté, ou au contraire pour rester sur une ancienne version.
Aucune sauvegarde ne survit au changement de build
C’est l’information la plus immédiatement actionnable, et le studio l’a répétée dans deux billets successifs : les sauvegardes Build 41 ne sont pas compatibles avec Build 42. Une partie en cours ne peut donc pas être « migrée » ; elle s’arrête là où elle en était.
La coupure vaut aussi à l’intérieur même de Build 42. Les sauvegardes de la version instable 42.19 ne sont pas compatibles avec la 42.20, en raison du contenu de carte ajouté au passage en stable. Un serveur qui tournait sur la bêta instable est donc concerné au même titre qu’un serveur resté en Build 41.
Concrètement, pour un serveur en ligne, passer en 42.20 signifie repartir sur un monde neuf. C’est une décision de communauté autant que de technique : elle se prépare avec les joueurs, et elle se prend après avoir mis de côté une copie complète du monde existant, ne serait-ce que pour pouvoir revenir en arrière.
Rester en Build 41 reste possible, et c’est officiel
The Indie Stone a anticipé le problème. Dans son billet du 24 juillet, le studio s’adresse explicitement aux « propriétaires de serveurs » et aux joueurs en ligne qui veulent rester sur l’ancienne version : une branche Steam nommée legacy41 a été mise à disposition en amont de la sortie, et elle reste sélectionnable.
La manipulation est décrite dans l’annonce officielle : clic droit sur le jeu dans la bibliothèque Steam, « Propriétés », puis sélection de legacy41 dans la section des versions et bêtas. Une seconde branche, nommée 42.19, permet par ailleurs de terminer une partie commencée sur l’ancienne version instable.
Un point mérite d’être souligné : le serveur dédié de Project Zomboid est distribué séparément, sous la forme d’un outil Steam gratuit (identifiant d’application 380870), disponible sous Windows, macOS et Linux, et reposant sur Java. Le serveur et les clients doivent se trouver sur la même version — basculer les uns sans les autres empêche simplement la connexion.
Une carte deux fois plus grande qu’en Build 41
Le contenu justifie en grande partie la rupture de compatibilité. Le studio annonce que la surface jouable de Knox Country a doublé entre Build 41 et Build 42. Le département artistique revendique 1 400 nouveaux bâtiments uniques et 20 000 nouvelles tuiles, ce qui porte le total du jeu à 35 000 tuiles.
Sept localités ont été entièrement retravaillées : Riverside, West Point, Rosewood, Fallas Lake, Muldraugh, Ekron et Dixie. S’y ajoutent des lieux inédits — un pénitencier, un orphelinat abandonné, un camp de scouts, un site d’exploitation forestière revu — ainsi que 400 sous-sols générés procéduralement et 75 sous-sols conçus à la main.
L’accueil s’est traduit dans les chiffres de fréquentation : le pic historique de joueurs simultanés relevé par SteamDB s’établit à 121 603 (relevé du 7 août 2026), un record atteint après la sortie de la version stable.
Un correctif de sécurité publié juste avant la sortie
Dans l’annonce du 29 juillet, le studio indique avoir diffusé, en préparation de la version stable, un correctif de sécurité pour les Builds 41 et 42.19. Il fait suite au signalement d’une vulnérabilité par Jorge Escabias, dans le cadre d’une divulgation responsable, avant toute exploitation connue.
Divulgation responsable : pratique par laquelle une personne qui découvre une faille la signale d’abord en privé à l’éditeur, et attend la publication d’un correctif avant d’en parler publiquement.
The Indie Stone précise que ce changement peut, dans une faible proportion, affecter certains mods, et invite leurs auteurs à remonter les incompatibilités. C’est le point de vigilance principal pour un serveur moddé : la mise à jour touche aussi les installations restées en Build 41.
Le second correctif du 5 août, numéroté 42.20.2, va dans le même sens. Il corrige la manière dont le caractère « % » est interprété dans les fichiers, et demande désormais aux auteurs de mods d’écrire « %% » pour afficher un symbole pourcentage. Une compatibilité temporaire accepte les deux écritures, mais le studio annonce son retrait dans une future version instable.
L’impact probable sur la charge d’un serveur
Cette section relève de l’analyse : à ce stade, The Indie Stone ne publie pas de configuration matérielle recommandée pour le serveur dédié en Build 42. Aucun chiffre précis de processeur ou de mémoire ne peut donc être présenté comme officiel.
Ce que l’on peut dire, en s’appuyant sur ce qui est documenté : une carte dont la surface a doublé, et dont les zones sont plus denses en bâtiments et en objets, augmente mécaniquement le volume de monde qu’un serveur doit charger et conserver en mémoire quand les joueurs se dispersent. Le studio mentionne d’ailleurs avoir implémenté des optimisations de performance spécifiques à ces nouvelles zones.
Les facteurs réellement déterminants restent les mêmes qu’auparavant : le nombre de joueurs connectés simultanément, leur dispersion sur la carte, l’étendue déjà explorée du monde, et le nombre de mods chargés. Les données disponibles ne permettent pas encore de chiffrer l’écart entre Build 41 et Build 42 sur un serveur réel.
Les chantiers annoncés pour la suite
Le studio a détaillé sa feuille de route dans le billet du 24 juillet. Après la phase de correctifs vient un patch d’ajustements fondé sur les retours des joueurs, orienté en priorité vers la fin de partie. Suivront la publication des outils de cartographie maison (WorldZed, TileZed), de l’éditeur d’animation AnimZed, et d’un guide de moddage étendu.
Sur le reste de l’année 2026, The Indie Stone annonce une « Build 42 Support Update » centrée sur l’optimisation, le support du moddage et des finitions écartées de la version stable. Le studio indique également que les améliorations du multijoueur se poursuivront tout au long de ce processus de correctifs et de support.
Aucune de ces échéances n’est datée. C’est la principale inconnue pour qui planifie la vie d’un serveur : on sait ce qui est prévu, pas quand cela arrivera, ni si la 42.20 restera longtemps la référence.
Pour aller plus loin
- BUILD 42 STABLE PLANS, blog officiel de Project Zomboid — le billet qui annonce la date de sortie, détaille la branche
legacy41et expose la feuille de route. - 42.20: The Big Glow Up, blog officiel de Project Zomboid — l’inventaire complet des villes retravaillées et les chiffres de la nouvelle carte.
- Annonces Steam de Project Zomboid — la source à consulter pour les notes de version et les correctifs au fil de l’eau.
- Sauvegarder un serveur avant une mise à jour majeure — la méthode décrite pour Palworld s’applique à toute bascule de version qui casse les sauvegardes.
- Palworld 1.0 : trois correctifs pour les serveurs dédiés — un autre exemple récent de gestion de correctifs successifs sur un serveur en ligne.
