Pterodactyl ou Pelican : sur quel panneau de jeu construire la suite ?

Si vous vendez de l’hébergement de jeu, voici la décision qui façonnera les prochaines années de votre activité. Pterodactyl est la référence depuis 2015. Pelican est un fork, lancé en mars 2024 par des personnes qui avaient travaillé sur Pterodactyl, et il a emmené avec lui une part importante de cette communauté.

Nous n’avons aucun intérêt dans l’issue. Provibr prend en charge les deux panneaux en production, et un client sur Pterodactyl nous paie exactement la même chose qu’un client sur Pelican. C’est pour cela que nous pouvons écrire ce texte : cPanel ne publie pas de comparaison honnête avec DirectAdmin, et Pterodactyl n’en publie pas avec Pelican. Nous avons construit les deux intégrations, contre les deux API, et rencontré les deux séries d’angles vifs.

Le chiffre qui raconte vraiment l’histoire

Ces valeurs proviennent de l’API GitHub et ont été mesurées le 21 août 2026. Dans un an elles seront fausses, et c’est précisément pour cela que la date figure ici.

Les étoiles et les forks mesurent combien de personnes ont trouvé un projet. Les contributeurs mesurent combien y travaillent encore. Pelican a rassemblé en deux ans et demi plus de contributeurs que Pterodactyl en dix. Toute l’histoire tient dans cette ligne, et c’est pour cela que la question se pose.

Le contrepoids est dans la dernière ligne, et il n’est pas mince. Pelican porte toujours la mention 1.0.0-beta, ses mainteneurs le disent eux-mêmes, et son API change d’une version bêta à l’autre. Provibr est testé sur la 1.0.0 et n’épingle rien d’autre, car le panneau n’offre aucun moyen de demander quelle version il exécute : une mise à niveau qui modifie une réponse se manifeste donc comme une erreur, et non comme un avertissement préalable.

Ce que les deux partagent

Pelican est un fork, la forme est donc la même. Un serveur est construit à partir d’un egg : une image Docker, une commande de démarrage et un ensemble de variables que l’egg définit lui-même. Un nœud exécutant le démon Wings porte le conteneur. Une allocation donne au serveur son adresse et son port. Les deux panneaux coupent leur API en deux : une moitié de gestion qui crée et supprime les serveurs, et une moitié client qui porte les commandes d’alimentation, les mesures d’utilisation et la console.

Cette forme commune est ce qui rend une migration entre les deux réaliste. C’est aussi le piège : la même forme ne signifie pas les mêmes réponses.

Là où ils divergent, mesuré contre les deux panneaux

Voici la partie qu’aucune page marketing ne vous donnera. Chaque ligne ci-dessous est quelque chose que nous avons rencontré en construisant et en déployant les deux intégrations.

Quelques-unes méritent une phrase, car elles déterminent le travail réel que représente un changement.

Le format des règles d’egg est l’angle le plus vif. Un analyseur écrit pour les chaînes de règles de Pterodactyl n’échoue pas sur une variable lorsqu’on le pointe vers Pelican : il échoue sur la désérialisation de la liste entière des eggs, parce que le type a changé. Tout ce qui lit des eggs doit être réécrit, et non ajusté.

La différence sur les variables obligatoires est une différence en tickets de support. Sur Pterodactyl, un champ manquant est refusé d’emblée. Sur Pelican, le panneau construit le serveur, et le jeu de votre client plante au premier démarrage. C’est pourquoi Provibr impose cette obligation de son côté pour Pelican : un champ qui devient rouge est une bien meilleure réponse qu’un conteneur qui meurt en silence.

Le champ CPU d’un nœud est un véritable écart de capacité, en faveur de Pelican. Un nœud Pterodactyl indique la mémoire libre ; un nœud Pelican indique en plus la CPU dont il dispose et la part déjà distribuée. Le placement entre nœuds peut donc tenir compte des cœurs autant que de la mémoire. À savoir sur ce chiffre : sur les deux panneaux, il s’agit de la comptabilité propre du panneau (la somme des limites des serveurs présents sur un nœud, y compris ceux encore en installation), et non d’une mesure de ce qui tourne réellement.

Les deux paires de clés peuvent être interverties sans erreur visible. Les deux panneaux acceptent une clé client sur l’API de gestion. Le préfixe est la seule chose qui les distingue, et c’est pourquoi tout outillage sérieux le vérifie des deux côtés. Pelican ajoute une subtilité : il n’affiche la clé client qu’une seule fois, et la liste ne conserve ensuite qu’un identifiant court, lui-même accepté comme une clé. Collez-le et vous obtenez un échec d’authentification sec, sans le moindre indice que vous avez copié la mauvaise chose.

Alors, lequel choisir ?

Il n’y a pas de vainqueur général. Il y a un vainqueur par situation.

Choisissez Pterodactyl si vous vendez aujourd’hui à des clients payants, si vos contrats évoquent la stabilité logicielle, ou si votre activité ne peut pas absorber une rupture dans une version mineure. La v1.15.1 est sortie le 14 août 2026 : le projet n’est pas à l’arrêt, il avance au rythme d’une base de code de dix ans portée par 191 contributeurs.

Choisissez Pelican si vous construisez quelque chose de neuf qui sera en ligne en 2027, si vous voulez un placement qui comprend la CPU, ou si vous voulez être là où se trouve aujourd’hui l’énergie de développement. Acceptez en échange de lire les notes de version avant chaque mise à niveau, et que « bêta » est le mot du projet lui-même, pas celui d’un concurrent.

Restez sur Pterodactyl pour l’instant si vous l’exploitez déjà en production et que rien ne fait mal. Qu’un fork soit plus actif est une raison de planifier, pas une raison de migrer ce trimestre.

Passez à Pelican si vous le faites déjà tourner en préproduction, si vous avez reconstruit tout ce qui lit des eggs, et si vous disposez d’un retour arrière que vous avez réellement essayé.

Ce qu’on oublie : vous n’avez pas à choisir en une seule étape

Le plus difficile dans une migration de panneau n’est pas le logiciel. Ce sont les mois du milieu, où les anciens clients restent sur l’ancien panneau et les nouveaux arrivent sur le nouveau, et où vous exploitez deux plans de contrôle, avec deux connexions et deux façons de compter ce que vous avez vendu.

C’est là que se place Provibr. Les deux panneaux se connectent au même compte Provibr, apparaissent dans la même liste de serveurs, et comptent tous deux dans la même capacité et sur la même facture mensuelle. L’agent appelle vers l’extérieur depuis votre propre réseau : aucun des deux panneaux n’a besoin d’ouvrir un port, et rien n’est installé sur l’un ni sur l’autre. Les serveurs que vous n’avez pas créés via Provibr sont laissés tranquilles jusqu’à ce que vous les importiez : c’est ce qui transforme le déplacement d’un panneau existant en une reprise plutôt qu’en une reconstruction.

Le choix du panneau sur lequel vous misez reste le vôtre. Vous n’avez simplement pas à le faire en un week-end.

À lire ensuite

• Configurer Pterodactyl : deux clés, les eggs, les plans de jeu, la console et l’import de serveurs.
• Configurer Pelican : les deux clés d’API, le placement entre nœuds et ce qui change entre versions bêta.

Les étoiles, forks, contributeurs et versions ont été mesurés via l’API GitHub le 21 août 2026. Tout ce qui est décrit ici au sujet des deux API a été mesuré contre des panneaux en fonctionnement pendant la construction des intégrations Provibr.