Le fichier Rust server.cfg concentre l’ensemble des paramètres qui définissent l’identité et le fonctionnement de votre serveur — de son nom affiché dans la liste jusqu’à la fréquence de mise à jour de la simulation physique. Contrairement à des jeux comme ARK ou Palworld qui utilisent des fichiers .ini structurés avec des sections clairement délimitées, Rust fonctionne par convars, des commandes individuelles qu’on ajoute une par une dans ce fichier de configuration, ce qui peut dérouter les administrateurs habitués à d’autres formats de configuration plus visuellement organisés.
Ce guide couvre les convars du Rust server.cfg qui comptent vraiment pour configurer un serveur communautaire solide, organisées par catégorie, avec pour chacune ce qu’elle change concrètement dans l’expérience de vos joueurs et les valeurs typiquement observées sur les serveurs communautaires bien établis en 2026.
Comprendre la syntaxe des convars avant de commencer
Chaque ligne de votre server.cfg suit une syntaxe simple : le nom de la convar suivi de sa valeur, séparés par un espace, sans guillemets pour les valeurs numériques mais avec guillemets pour les chaînes de texte comme le nom du serveur. Une erreur de syntaxe fréquente chez les administrateurs débutants consiste à oublier ces guillemets sur les valeurs textuelles, ce qui provoque des erreurs de lecture silencieuses où le serveur ignore simplement la ligne mal formatée sans nécessairement afficher d’erreur explicite dans la console au démarrage.
Il est recommandé de tester chaque modification de convar individuellement plutôt que de modifier plusieurs valeurs simultanément avant un redémarrage, une discipline qui permet d’identifier immédiatement la source d’un éventuel problème plutôt que de devoir déboguer un fichier entièrement remanié en une seule fois face à un comportement inattendu du serveur.
Identité et découverte du serveur
server.hostname définit le nom affiché dans la liste des serveurs Rust — soyez descriptif, incluez votre fréquence de wipe et votre orientation (Solo/Duo, Trio, vanilla ou modded). Un nom générique qui ne communique aucune information distinctive se noie parmi les centaines d’autres options disponibles dans la liste publique, tandis qu’un nom qui répond immédiatement aux questions que se posent les joueurs qui parcourent cette liste augmente vos chances d’attirer des joueurs correspondant réellement à votre configuration.
server.description permet une description plus longue visible dans la fiche détaillée de votre serveur, l’occasion de préciser votre règlement, vos horaires de wipe habituels, ou les particularités de votre configuration qui vous distinguent des dizaines d’autres serveurs Rust francophones disponibles. server.url peut pointer vers votre Discord communautaire, et server.headerimage accepte une URL d’image de bannière qui améliore l’attractivité visuelle de votre fiche serveur dans la liste, un détail visuel qui influence réellement le taux de clic des joueurs qui parcourent rapidement de nombreuses options avant de faire leur choix.
La map et sa génération
server.worldsize détermine la taille de la carte en mètres — 3000 à 3500 pour un serveur de 30 à 60 joueurs, 4500 et plus pour un serveur de 100 joueurs ou davantage. Cette valeur doit être calibrée précisément selon votre population cible réelle : une map trop petite pour votre nombre de joueurs crée une densité de combat excessive et des conflits territoriaux permanents, tandis qu’une map trop grande dilue l’activité et donne une impression de vide qui décourage l’exploration.
server.seed fixe la graine de génération — laissez à 0 pour une génération aléatoire, ou notez la valeur utilisée si vous souhaitez pouvoir régénérer une map similaire lors d’un futur wipe. Depuis l’introduction de la Naval Update qui a rendu l’accès maritime stratégiquement important, la recherche d’une seed offrant un littoral riche et bien réparti est devenue une préoccupation supplémentaire pour les administrateurs qui veulent offrir une expérience équilibrée à l’ensemble de leur communauté, indépendamment de la zone géographique où chaque tribu s’installe sur la carte.
| Convar | Rôle | Valeur typique |
|---|---|---|
| server.worldsize | Taille de la map | 3000 à 4500 |
| server.maxplayers | Capacité maximale | Selon population réelle |
| server.tickrate | Fréquence de simulation | 10 à 15 |
| server.globalchat | Chat visible par tous | True ou False selon philosophie |
| server.rconpassword | Sécurité admin | Mot de passe fort obligatoire |
| server.saveinterval | Fréquence de sauvegarde | 300 à 600 secondes |
Joueurs, performance et sécurité
server.maxplayers fixe la capacité maximale — calibrez cette valeur sur votre population réelle plutôt que sur une ambition théorique, un serveur affichant 100 places avec 15 joueurs connectés paraissant vide aux yeux des nouveaux arrivants qui utilisent souvent ce ratio comme indicateur implicite de la vitalité réelle d’une communauté avant même de s’y connecter pour la première fois.
server.tickrate, à 10 par défaut, peut être monté à 15 pour améliorer la précision des combats au prix d’une charge CPU légèrement supérieure — un compromis tout à fait gérable sur un processeur à haute fréquence mono-cœur comme ceux qu’on trouve chez les hébergeurs gaming sérieux en 2026. Cette augmentation du tickrate est particulièrement appréciée sur les serveurs orientés PvP compétitif, où la précision des tirs et des collisions peut faire une différence perceptible dans le ressenti des combats les plus disputés.
server.rconpassword doit impérativement être un mot de passe fort et unique — un accès RCON compromis donne un contrôle total sur votre serveur, permettant potentiellement à un attaquant de modifier n’importe quel paramètre, de bannir des joueurs légitimes, ou même de corrompre délibérément votre configuration. Ne le partagez jamais, même avec des membres de confiance de votre équipe de modération, et envisagez de le changer périodiquement par précaution supplémentaire.
Communication et communauté
server.globalchat active un chat global visible par tous les joueurs, à opposer au chat de proximité uniquement. Sur un serveur qui veut favoriser l’immersion, désactivez le chat global pour ne garder que la communication de proximité — une décision qui change significativement l’ambiance générale de votre serveur, en encourageant des interactions plus localisées et potentiellement plus tendues entre joueurs qui se croisent physiquement plutôt que de dialoguer librement à travers toute la carte sans conséquence sur leur positionnement stratégique.
Cette décision de configuration a des répercussions qui dépassent la simple communication — un serveur sans chat global tend à favoriser des alliances plus locales et géographiquement cohérentes, tandis qu’un chat global facilite les négociations et échanges commerciaux à l’échelle de l’ensemble du serveur, indépendamment de la distance physique entre les joueurs concernés.
Sauvegardes et intégrité des données
server.saveinterval contrôle la fréquence des sauvegardes automatiques du monde, exprimée en secondes. Une valeur trop élevée expose votre serveur à une perte de progression significative en cas de crash imprévu, tandis qu’une valeur trop basse peut créer des micro-interruptions perceptibles par vos joueurs au moment de chaque sauvegarde, particulièrement sur les serveurs avec de nombreuses constructions complexes qui allongent le temps d’écriture sur disque.
Un compromis courant se situe entre 300 et 600 secondes selon la taille de votre communauté et la puissance de votre infrastructure de stockage, le stockage NVMe permettant généralement de réduire cette fenêtre sans impact perceptible sur l’expérience de jeu, contrairement à des solutions de stockage plus anciennes où chaque sauvegarde pouvait provoquer un ralentissement notable pendant plusieurs secondes.
Les convars liées à la construction et au raid
Au-delà de l’identité et des performances générales, plusieurs convars touchent directement à l’équilibre du raid, l’une des mécaniques centrales de l’expérience Rust. decay.scale contrôle la vitesse à laquelle les structures se dégradent lorsqu’elles ne sont pas entretenues, un paramètre qui influence directement combien de temps une base abandonnée reste vulnérable au pillage avant de disparaître naturellement de la carte. Un decay trop rapide peut frustrer les joueurs occasionnels qui ne se connectent pas quotidiennement, tandis qu’un decay trop lent laisse s’accumuler des structures abandonnées qui polluent visuellement et techniquement votre serveur sur la durée d’un cycle de wipe.
server.radiation et les paramètres associés à la zone de largage nucléaire, quand cette fonctionnalité est activée, ajoutent une dimension de risque-récompense supplémentaire qui plaît particulièrement aux communautés qui cherchent à diversifier les sources de contenu endgame au-delà du simple raid entre joueurs. Ces paramètres, bien que moins fréquemment ajustés que ceux évoqués précédemment, méritent d’être vérifiés si votre map inclut ce type de zone spécifique.
Optimiser les performances pour les grandes populations
Sur un serveur qui accueille une population importante, au-delà de 100 joueurs simultanés, certaines convars supplémentaires méritent une attention particulière pour maintenir des performances stables. La gestion de la mémoire allouée aux entités, les limites de spawn des animaux et ressources naturelles, ainsi que les paramètres de rendu à distance peuvent tous être ajustés pour privilégier la stabilité générale du serveur au détriment de certains détails visuels ou de simulation moins critiques pour l’expérience de jeu principale.
Ces ajustements avancés dépassent le cadre des convars les plus couramment modifiées, mais deviennent pertinents à mesure que votre communauté grandit et que les limites de votre infrastructure actuelle commencent à se faire sentir malgré une configuration de base déjà bien optimisée selon les recommandations de cet article.
Pour un accompagnement dans cette phase d’optimisation avancée, n’hésitez pas à solliciter le support technique de votre hébergeur, qui dispose généralement d’une expérience concrète sur des configurations similaires et peut vous orienter vers les ajustements les plus pertinents selon votre situation spécifique.
Cette collaboration étroite entre votre propre expertise de la communauté que vous gérez au quotidien et l’expérience technique accumulée de votre hébergeur constitue souvent la meilleure voie pour affiner progressivement une configuration qui restait jusque-là simplement fonctionnelle vers une configuration réellement optimale et pérenne.
Questions fréquentes
Faut-il redémarrer le serveur après avoir modifié server.cfg ?
Certaines convars peuvent être rechargées à chaud via la commande server.writecfg en console RCON, mais un redémarrage complet reste la méthode la plus sûre pour garantir l’application de tous les changements sans exception.
Quelle taille de map choisir pour son serveur Rust ?
3000 à 3500 pour 30 à 60 joueurs, 4500 et plus pour 100 joueurs ou davantage. Une map trop petite pour votre population crée une densité de combat excessive, une map trop grande donne une impression de vide.
Augmenter le tickrate améliore-t-il vraiment les performances des combats ?
Oui, un tickrate plus élevé (15 au lieu de 10) améliore la précision de la synchronisation des combats, au prix d’une charge CPU légèrement supérieure généralement gérable sur un processeur récent.
Comment sécuriser l’accès RCON de son serveur Rust ?
Utilisez un mot de passe fort et unique dans server.rconpassword, ne le partagez jamais, même avec des membres de confiance, et changez-le régulièrement si vous suspectez une fuite ou un accès non autorisé.
Peut-on modifier server.cfg pendant que le serveur est en ligne ?
Certaines convars s’appliquent en temps réel via RCON, mais les modifications structurelles (taille de map, seed) nécessitent un redémarrage complet pour être prises en compte par le serveur.
Quelle fréquence de sauvegarde choisir pour un serveur Rust communautaire ?
Un compromis entre 300 et 600 secondes convient à la majorité des serveurs communautaires, le stockage NVMe permettant de réduire cette fenêtre sans impact perceptible sur l’expérience de vos joueurs.