Oxide ou Carbon : la question revient à chaque wipe sur les Discord d’administrateurs Rust francophones, et elle n’a plus la réponse évidente qu’elle avait il y a trois ans. Oxide, distribué par uMod, est le framework historique, celui pour lequel la quasi-totalité des plugins ont été écrits. Carbon est le challenger, conçu pour charger ces mêmes plugins plus vite tout en ajoutant ses propres outils. Les deux font tourner des milliers de serveurs communautaires en 2026, et choisir l’un ou l’autre engage votre façon d’administrer pour des mois.
Cet article compare les deux frameworks sur ce qui compte réellement pour un admin : la compatibilité des plugins, le comportement le jour d’une mise à jour Rust, les performances au chargement et en jeu, la configuration, la migration de l’un vers l’autre, et le support. Nous n’avons pas de préférence à vendre dans ce débat Oxide ou Carbon : chez Portallis, les deux s’installent depuis le panel, et nos clients sont à peu près partagés. L’objectif est que vous choisissiez en connaissance de cause.
Oxide ou Carbon : deux approches d’un même problème
Rust n’a pas d’API de modding officielle côté serveur. Tout ce qui ressemble à un plugin (système de kits, téléportation, économie, protection anti-raid hors ligne, gestion des clans avant Common Ground) repose sur un framework tiers qui s’injecte dans le serveur, intercepte les événements du jeu et expose des « hooks » aux plugins écrits en C#. Oxide a défini ce modèle, et la bibliothèque de plugins disponible sur uMod en est la conséquence directe : des milliers de ressources, gratuites ou payantes, écrites contre les hooks d’Oxide.
Carbon est arrivé plus tard avec une ambition claire : reprendre ce modèle de hooks pour rester compatible avec l’écosystème existant, mais reconstruire le moteur en dessous. Compilation des plugins plus rapide, chargement à chaud plus fiable, système de modules intégrés pour des fonctions que les admins installaient auparavant via des plugins séparés, et une organisation des fichiers plus lisible. Carbon ne cherche pas à remplacer les plugins, il cherche à remplacer ce qui les fait tourner. C’est ce qui rend la question Oxide ou Carbon intéressante : vous changez le moteur, pas forcément la carrosserie.
Oxide ou Carbon : la compatibilité des plugins décide le plus souvent
Quand on compare Oxide ou Carbon, la promesse de Carbon est de faire fonctionner la grande majorité des plugins Oxide sans modification, et dans la pratique elle est largement tenue pour les plugins courants. Les plugins populaires d’uMod (kits, téléportation, boutiques, protections de zone, outils d’administration) tournent généralement sur Carbon tels quels. Là où ça se complique, c’est sur les plugins qui s’appuient sur des comportements internes spécifiques d’Oxide, sur des extensions Oxide (certaines bibliothèques partagées) ou sur des plugins payants dont l’auteur n’a testé que sur Oxide et refuse le support ailleurs.
Dans le sens inverse, les plugins écrits spécifiquement pour Carbon, qui exploitent ses modules ou ses hooks propres, ne fonctionnent pas sur Oxide. Cet écosystème spécifique reste plus petit, mais il grandit, et certains développeurs francophones ne publient plus que pour Carbon. La question Oxide ou Carbon se pose donc concrètement en listant vos plugins : si un plugin critique de votre serveur n’existe que pour l’un des deux, le choix est fait.
| Critère | Oxide (uMod) | Carbon |
|---|---|---|
| Ancienneté et maturité | Framework historique, écosystème immense | Plus récent, en développement actif |
| Compatibilité des plugins uMod | Native | Très large, avec exceptions sur les plugins exotiques ou certaines extensions |
| Plugins exclusifs | Quelques extensions historiques | Modules intégrés et plugins Carbon-only |
| Chargement et compilation | Plus lent, surtout avec beaucoup de plugins | Nettement plus rapide |
| Publication après une mise à jour Rust | Peu après la sortie de la mise à jour | Build de production environ une heure avant la mise à jour |
| Support des auteurs de plugins payants | Quasi universel | Variable selon l’auteur |
| Documentation en français | Abondante, parfois datée | Plus rare, communauté active sur Discord |
Le jour d’une mise à jour Rust : Oxide ou Carbon, qui réagit le mieux ?
C’est le moment de vérité du choix Oxide ou Carbon. Chaque premier jeudi du mois, et à chaque mise à jour obligatoire comme celle d’Halloween du 22 octobre, Facepunch publie une nouvelle version du serveur qui écrase les fichiers du framework de plugins. Que vous ayez choisi Oxide ou Carbon, vous devez réinstaller le framework après la mise à jour, puis vérifier que chaque plugin se charge. Sur ce point, Oxide ou Carbon sont à égalité : aucun ne survit à une mise à jour Rust sans réinstallation.
La différence tient au calendrier. Facepunch l’écrit dans son propre guide : après chaque mise à jour serveur, Oxide publie sa version compatible peu de temps après. Carbon, de son côté, publie généralement son build de production une heure avant la sortie de la mise à jour Rust, en travaillant sur la branche de staging. Pour un admin qui veut rouvrir dans les minutes qui suivent le wipe, cette heure d’avance compte. Pour un admin qui rouvre tranquillement en soirée, elle ne change rien. Notre checklist pour préparer son wipe day Rust détaille la séquence complète ; le choix Oxide ou Carbon n’y change que le minutage.
Un conseil valable que vous ayez choisi Oxide ou Carbon : ne faites jamais confiance à un chargement silencieux. Après la réinstallation, lisez la console ligne par ligne. Un plugin qui échoue à compiler sur Oxide affiche une erreur explicite ; sur Carbon, le compilateur est plus rapide mais tout aussi bavard. Un serveur qui « tourne » avec trois plugins en échec est un serveur où les kits ne fonctionnent plus et où les joueurs le découvrent avant vous.
Performances Oxide ou Carbon : ce que Carbon apporte vraiment
L’argument numéro un de Carbon est la vitesse de chargement. Sur un serveur avec 60 à 100 plugins, la différence au démarrage se compte en dizaines de secondes, parfois plus, ce qui est appréciable à chaque redémarrage programmé et crucial le soir d’un wipe où chaque minute de serveur fermé fait fuir des joueurs vers le serveur d’à côté. Le rechargement à chaud d’un plugin modifié est également plus fiable, un avantage réel pour les admins qui développent ou ajustent leurs propres scripts.
Le deuxième argument de Carbon est la qualité des messages d’erreur et des outils de diagnostic : un plugin qui échoue indique plus précisément pourquoi, et les commandes intégrées permettent de recharger, décharger ou inspecter un plugin sans redémarrer le serveur. Pour un admin qui gère un serveur à 200 joueurs avec une centaine de plugins, chaque redémarrage évité pendant les heures de pointe est une victoire. Oxide le permet aussi, mais avec moins de confort.
En jeu, une fois tout chargé, la différence entre Oxide ou Carbon est beaucoup plus ténue. Le coût d’un plugin dépend avant tout de ce que fait le plugin, pas du framework qui l’héberge. Un plugin qui scanne tous les joueurs à chaque tick sera lourd sur les deux. Le thread principal de Rust reste le facteur limitant, et c’est la fréquence single-core du processeur de votre hébergeur qui détermine combien de joueurs et d’entités votre serveur encaisse, comme nous l’expliquons dans notre article sur le lag serveur gaming. Changer de framework pour résoudre un lag en jeu est presque toujours une déception.
Oxide ou Carbon : configuration et organisation des fichiers
Oxide organise tout dans un dossier oxide/ à la racine du serveur : plugins/, config/, data/, lang/, logs/. C’est simple, documenté partout, et des années de tutoriels francophones y font référence. Carbon reprend une structure proche dans son propre dossier carbon/, avec en plus des modules intégrés activables par configuration (par exemple des fonctions d’administration ou de gestion que vous installiez auparavant comme plugins distincts). Sur Portallis, le panel donne accès aux deux arborescences par le gestionnaire de fichiers et le SFTP, et la réinstallation du framework se fait en un clic quelle que soit la réponse à la question Oxide ou Carbon.
Un point souvent négligé dans la comparaison Oxide ou Carbon est la gestion des permissions. Les deux frameworks reposent sur un système de groupes et de permissions attribuées aux plugins, avec des commandes console proches mais pas identiques. Un admin qui a construit pendant deux ans une hiérarchie fine (VIP, modérateurs, administrateurs, permissions par kit) devra la reconstruire à la migration, et c’est souvent l’étape la plus longue, bien plus que la copie des plugins eux-mêmes. Exportez vos groupes et permissions dans un document avant toute migration, et prévoyez une soirée pour les ressaisir proprement.
Pour la configuration de base du serveur lui-même (nom, carte, nombre de joueurs, tickrate), rien ne change : le fichier server.cfg reste le même, et notre guide des convars du server.cfg Rust s’applique à l’identique. Le framework ne touche pas à ces valeurs ; il s’intercale entre le serveur et vos plugins.
Migrer d’Oxide vers Carbon (ou l’inverse) sans casser son serveur
La migration est le moment où la question Oxide ou Carbon devient concrète, et elle se fait de préférence le jour d’un wipe, quand tout est de toute façon réinitialisé et que les joueurs s’attendent à une réouverture tardive. Voici la procédure que nous recommandons, dans un sens comme dans l’autre.
- Lister tous vos plugins avec leur source et vérifier, pour chacun, la compatibilité annoncée avec le framework cible. Isoler ceux qui n’existent que pour le framework actuel.
- Sauvegarder l’intégralité du dossier du framework actuel (plugins, configs, données) hors du serveur, car les données de certains plugins (économie, kits consommés, permissions) devront être réimportées.
- Monter un serveur de test avec le framework cible, y copier les plugins et leurs configurations, et lancer : les plugins qui échouent sont ceux à remplacer ou à retirer.
- Reconstruire les permissions et les groupes, dont la syntaxe de commande est proche mais pas identique entre les deux frameworks.
- Le jour du wipe, désinstaller l’ancien framework, installer le nouveau, copier les plugins validés, redémarrer et lire la console.
- Garder la sauvegarde de l’ancien framework pendant un wipe complet, pour pouvoir revenir en arrière si un problème n’apparaît qu’en charge.
Le serveur de test est la clé d’une migration Oxide ou Carbon réussie. Chez Portallis, un second serveur Rust temporaire avec 8 Go (facturé 1 € par Go et par mois, donc quelques euros pour une semaine de test) suffit à valider la migration sans toucher au serveur de production, et il se supprime ensuite. Les admins qui migrent « à chaud » sur leur serveur principal un soir de semaine finissent presque toujours par rouvrir tard, avec la moitié des plugins en moins.
Oxide ou Carbon : quand choisir l’un, quand choisir l’autre
Oxide reste le choix raisonnable pour un serveur qui dépend de plugins payants dont les auteurs ne supportent que ce framework, pour un admin débutant qui veut s’appuyer sur la masse des tutoriels francophones, et pour une communauté qui privilégie la stabilité éprouvée à la vitesse. La question Oxide ou Carbon n’a pas de bonne réponse universelle, mais si votre liste de plugins contient trois ressources premium testées uniquement sur Oxide, vous avez votre réponse.
Carbon s’impose pour un serveur avec un très grand nombre de plugins où le temps de chargement devient pénible, pour un admin qui développe ses propres scripts et apprécie le rechargement rapide, pour ceux qui veulent profiter des modules intégrés plutôt que d’empiler des plugins, et pour les communautés qui aiment être prêtes une heure avant le wipe. Il convient aussi aux serveurs qui repartent de zéro et peuvent choisir leurs plugins en fonction du framework plutôt que l’inverse.
Et pour ceux qui gèrent plusieurs serveurs, rien n’interdit de ne pas répondre à la question Oxide ou Carbon de façon unique : un serveur modded avec Carbon pour la vitesse, un serveur plus classique avec Oxide pour un plugin payant précis. Les deux coexistent sans problème sur deux instances distinctes, et le panel Portallis les gère de la même manière. Ce qui compte, c’est que chaque serveur ait son framework réinstallé et vérifié après chaque mise à jour, comme nous le rappelions dans notre article sur l’élevage Rust et la mise à jour Halloween.
Oxide ou Carbon, en un clic depuis le panel Portallis
Facturation à la RAM à 1 € par Go et par mois, sans limite de slots ni engagement. Processeur à haute fréquence, stockage NVMe, protection anti-DDoS incluse et support francophone. Votre serveur est en ligne quelques minutes après la commande.
Questions fréquentes
Oxide ou Carbon : Carbon fait-il tourner les plugins Oxide sans modification ?
Pour la grande majorité des plugins courants d’uMod, oui. Les exceptions concernent les plugins qui dépendent de comportements internes spécifiques d’Oxide, de certaines extensions, ou de plugins payants dont l’auteur n’a testé que sur Oxide. Vérifiez chaque plugin critique sur un serveur de test avant de migrer.
Dois-je réinstaller Oxide ou Carbon après chaque mise à jour Rust ?
Oui, dans les deux cas. La mise à jour de Rust écrase les fichiers du framework, quel qu’il soit. Réinstallez la version compatible publiée pour cette mise à jour, redémarrez, puis lisez la console pour vérifier que chaque plugin se charge sans erreur.
Oxide ou Carbon : lequel est le plus rapide en jeu ?
Au chargement, nettement. En jeu, la différence est faible : le coût d’un plugin dépend de ce qu’il fait, pas du framework. Si votre serveur lag pendant la partie, la cause est presque toujours ailleurs (entités, plugin mal écrit, thread principal saturé), et changer de framework ne la résoudra pas.
Peut-on utiliser Oxide et Carbon sur le même serveur ?
Non, un serveur Rust utilise un seul framework de plugins à la fois. En revanche, deux serveurs distincts peuvent très bien utiliser chacun un framework différent, par exemple Carbon sur un serveur très moddé et Oxide sur un serveur qui dépend d’un plugin payant précis.
Quel est le meilleur moment pour migrer d’un framework à l’autre ?
Le jour d’un wipe, après avoir validé la migration sur un serveur de test. Tout est réinitialisé, les joueurs s’attendent à une réouverture tardive, et vous pouvez repartir avec les plugins validés. Conservez la sauvegarde de l’ancien framework pendant un wipe complet pour pouvoir revenir en arrière.
Les plugins payants fonctionnent-ils sur Oxide ou Carbon indifféremment ?
Cela dépend entièrement de l’auteur. Beaucoup de plugins premium sont testés et supportés uniquement sur Oxide ; d’autres annoncent explicitement la compatibilité Carbon. Lisez la page du plugin avant d’acheter, et demandez à l’auteur si le support n’est pas précisé.
Conclusion
Oxide ou Carbon n’est pas un choix entre un bon et un mauvais framework : c’est un choix entre un écosystème universel et un moteur plus rapide, entre la certitude du support des plugins payants et le confort des modules intégrés et du chargement éclair. Pour la plupart des serveurs francophones, la réponse se lit dans la liste des plugins : s’ils tournent tous sur les deux, Carbon vous fera gagner du temps à chaque redémarrage ; s’il en manque un seul sur Carbon, Oxide reste votre base.
Dans les deux cas, le framework ne fait pas de miracle sur une infrastructure inadaptée : Rust a besoin d’un processeur à haute fréquence, de stockage rapide pour ses sauvegardes de carte et d’une protection anti-DDoS sérieuse les soirs de wipe. Choisissez Oxide ou Carbon pour vos plugins, et votre hébergeur pour sa simulation. Pour parcourir la bibliothèque de plugins et les notes de version d’Oxide, la référence reste le site d’uMod : umod.org.