Depuis le 2 juillet 2026, tout serveur Rust démarre par défaut sur un mode de calcul interne appelé Jobs 3. Les administrateurs que ce basculement gênait pouvaient revenir en arrière avec une convar — un réglage tapé en console ou inscrit dans le fichier de démarrage du serveur — nommée UsePlayerUpdateJobs, qu’il suffisait de fixer à 2. Facepunch a prévenu dans le même billet que cette porte de sortie se refermerait en août : la valeur 2 restera acceptée, mais elle exécutera le mode 3 en dessous. Au 3 août 2026, le studio n’a pas encore publié la date de sa mise à jour mensuelle.
Une porte de sortie qui se referme
Le billet « Common Ground », publié le 2 juillet 2026, décrit ce passage en trois temps. Facepunch dit avoir laissé le mode Jobs 3 tourner sur ses propres serveurs pendant la moitié du mois et l’avoir jugé stable, puis l’avoir promu en valeur par défaut afin de pouvoir simplifier le code restant. Le studio ajoute une phrase qui concerne directement les serveurs communautaires : la manière dont l’état des joueurs circule côté serveur a été réécrite, et cette réécriture oblige les mods serveur à mettre leur propre code à jour.
Le travail d’adaptation a donc commencé le 2 juillet, pas en août. Ce que la mise à jour d’août retire, c’est le filet. Jusqu’ici, un administrateur dont les extensions se comportaient mal pouvait repasser en mode 2 le temps que les auteurs de ses plugins publient un correctif. Après la mise à jour d’août, ce réglage ne fera plus rien d’utile.
Ce que « Jobs » désigne dans un serveur Rust
Un serveur Rust recalcule l’état du monde plusieurs fois par seconde : positions des joueurs, tirs, envois réseau, contrôles anti-triche. Historiquement, une grande partie de ce travail s’exécutait sur un seul fil d’exécution, même quand la machine disposait de nombreux cœurs. Le système « Jobs » sert à déplacer une partie de ces tâches vers d’autres fils.
Un fil d’exécution (ou thread) est une file de calcul indépendante. Un processeur à plusieurs cœurs peut en traiter plusieurs en même temps, à condition que le logiciel soit écrit pour cela.
Facepunch détaille ce que le niveau 3 apporte : recours à la bibliothèque UniTask pour éviter des allocations mémoire liées au code multi-fils, envoi accéléré des instantanés de joueurs à chaque image, exécution en parallèle d’une partie des mises à jour d’abonnement réseau, planification plus précoce des tâches EAC et d’analytique pour que le fil principal cesse de les attendre, et parallélisation du reste de la logique anti-triche serveur.
Le studio indique par ailleurs avoir commencé à explorer un niveau « Jobs 4 », dont la première contribution est la parallélisation de la collecte des paires d’occlusion côté serveur. Il prévient que ce niveau demandera vraisemblablement plusieurs mois avant d’avoir assez de substance pour être livré. Aucun chiffre de gain n’est publié : les données disponibles ne permettent pas de dire de combien la charge d’un serveur baisse, ni à partir de quel nombre de joueurs l’écart devient perceptible.
Juillet avait déjà déplacé plusieurs repères
Deux lignes de la section « Removed » du changelog de juillet méritent l’attention d’un administrateur. La première supprime toutes les versions obsolètes et génériques des appels BaseEntity.ClientRPC, ClientRPCEx, ClientRPCPlayer, ServerRPC et ServerRPCList ; Facepunch invite à basculer vers les méthodes existantes ou à écrire les siennes. Une extension qui appelait encore ces méthodes ne se contente pas de mal fonctionner : elle ne trouve plus le code qu’elle appelle.
Un appel RPC (remote procedure call) permet au serveur de déclencher une action chez les clients connectés, ou l’inverse. C’est la brique de base d’une bonne partie des extensions.
La seconde retire le support des démos serveur complètes. L’enregistrement classique des démos côté joueur n’est pas concerné, et le studio a même ajouté le même mois une couche de compatibilité qui tente de faire tourner d’anciennes démos sur une version récente — avec une limite explicite : elle ne fonctionne que pour les démos enregistrées à partir de cette version, pas pour les archives plus anciennes.
Le même billet confie aussi de nouveaux réglages aux propriétaires de serveurs, cette fois dans le mode Softcore : les raids n’y sont autorisés que dans une fenêtre horaire, fixée par défaut de 18 h à 21 h à l’heure locale du serveur, et Facepunch indique avoir livré plusieurs convars pour l’ajuster.
Ce que le journal public de Facepunch laisse voir du contenu d’août
Facepunch publie ses commits en clair. Ce n’est pas une annonce, et rien n’y est définitif : une fonctionnalité visible dans une branche peut être repoussée, remaniée ou retirée avant la livraison. Avec cette réserve, le dépôt rust_reboot montre au 3 août 2026 une branche nommée PlayerMaintainedMonuments, qui donne le ton du mois.
On y trouve un objet appelé heavy fuse, dont le taux d’apparition a été divisé par deux le 2 août et qui a été ajouté aux caisses du laboratoire sous-marin. Un développeur a retravaillé la Power Plant le 3 août — retrait de recycleurs dans une salle, repositionnement d’autres — et un autre a rééclairé un bâtiment du Launch Site en indiquant explicitement que c’était « pour la mise à jour du panneau de contrôle ».
Une deuxième branche, satellite_crash, introduit deux réglages serveur nommés satellite.crate_fire_duration et satellite.wreck_fire_duration. Leurs valeurs ont bougé plusieurs fois en deux jours, ce qui indique un équilibrage en cours plutôt qu’un état figé. Une troisième série de commits ajoute des gares au réseau ferroviaire souterrain ainsi que des prefabs destinés à les faire apparaître plus souvent lors de la génération de carte : s’il est livré, ce changement se verra dès la première carte générée après la remise à zéro.
Un dernier commit, daté du 3 août, arrête d’envoyer à l’application compagnon Rust+ les marqueurs de distributeurs automatiques et d’événements — cargo, hélicoptère, marchand ambulant. Il est, à cette date, le seul de la liste à recevoir plus de votes négatifs que positifs de la part des lecteurs du journal, ce qui en fait le candidat le plus probable à une discussion communautaire au moment de la sortie.
Ce que l’on peut préparer sans attendre le devblog
La date de la mise à jour n’est pas officielle. Le rythme, lui, est constant : les six devblogs mensuels publiés depuis février 2026 le sont tous un premier jeudi — 5 février, 5 mars, 2 avril, 7 mai, 4 juin et 2 juillet. Le premier jeudi d’août 2026 tombe le 6. C’est une déduction, pas une confirmation, mais elle laisse peu de marge de manœuvre.
Un wipe est une remise à zéro : les constructions et les inventaires sont effacés et une nouvelle carte est générée. Les mises à jour mensuelles de Rust s’en accompagnent ; le billet du 1er janvier 2026 s’ouvrait ainsi sur la mention que les serveurs venaient d’être remis à zéro.
Trois vérifications tiennent en peu de temps. Repérer d’abord si UsePlayerUpdateJobs est encore fixé à 2 dans la configuration de démarrage : si oui, la ligne va devenir inopérante, et mieux vaut observer dès maintenant le comportement réel en mode 3 plutôt que le découvrir le jour du wipe. Vérifier ensuite auprès des auteurs des extensions installées qu’elles ont bien intégré la réécriture de juillet ; une extension qui n’a pas été mise à jour depuis juin est le premier suspect en cas d’erreur au démarrage. Sauvegarder enfin la configuration et les données avant la fenêtre de mise à jour, puisque remise à zéro de la carte et mise à jour des plugins tombent le même jour. La méthode de sauvegarde décrite pour Palworld se transpose sans difficulté.
Reste un point qui échappe entièrement aux administrateurs : le contenu final. Tant que le devblog d’août n’est pas publié, la liste ci-dessus décrit un chantier en cours, pas une mise à jour. La seule certitude tient dans la phrase que Facepunch a écrite noir sur blanc le 2 juillet, et elle ne concerne pas un monument mais un réglage.
Pour aller plus loin
- Devblog « Common Ground » (2 juillet 2026) — sa section UsePlayerJobs Changes contient l’annonce du retrait du mode Jobs 2 en août.
- Changelist officiel de juillet 2026 — la liste complète des ajouts, améliorations et suppressions, dont les appels RPC retirés.
- Journal de commits du dépôt rust_reboot — mis à jour en continu, c’est là qu’apparaît le contenu en préparation avant toute annonce.
- Mettre à jour un serveur dédié Satisfactory — un exemple de procédure de mise à jour maîtrisée, applicable à d’autres jeux.
- Ce que la mise à jour Prosperity a changé pour Space Engineers — un autre cas récent de mise à jour qui touche d’abord l’administration du serveur.
