Choisir un panneau de jeu d’après l’API que vous automatisez

La plupart des comparatifs de panneaux de serveurs de jeu sont écrits pour la personne qui va cliquer dedans. Si vous vendez des serveurs de jeu, cette personne n’est pas vous. Vous verrez le panneau à peu près deux fois par an, et votre système de facturation le verra toutes les quelques minutes, indéfiniment.

La comparaison utile est donc autre : que vous permet de faire l’API, que refuse-t-elle de vous dire, et laquelle des promesses affichées dans l’interface le panneau impose-t-il réellement quand un client cesse de payer.

Tout ce qui suit a été mesuré en construisant des intégrations contre Pterodactyl 1.11, Pelican 1.0.0-beta38, WISP 3.7.5, PufferPanel 3.0.9, GameAP 4.4.2 et MCSManager 10.18.2, en août 2026.

Un panneau est délibérément absent du tableau. AMP n’y figure pas parce que nous ne l’avons pas mesuré. C’est un produit sérieux, doté d’une vraie API, et écrire une ligne de comparatif d’après sa documentation plutôt que d’après ses réponses serait exactement le genre de remplissage à l’air assuré contre lequel ce texte s’élève.

Entrer : six panneaux, cinq modèles d’identifiants

Trois d’entre eux appellent un avertissement.

Pterodactyl et Pelican ont besoin des deux clés, et la raison est structurelle : il n’existe aucun point d’accès d’alimentation sur l’API de gestion. Une intégration configurée avec la seule clé de gestion peut créer des serveurs que son propriétaire ne peut pas démarrer.

Pelican accepte une clé client sur l’API de gestion. GET /api/application/servers, /nodes et /users renvoient tous 200 avec la mauvaise clé, et l’erreur ne se manifeste qu’à l’écriture, sous la forme d’une erreur de validation portant sur un champ utilisateur manquant. Pterodactyl répond 403 à la même requête. Sur Pelican, vérifier le préfixe de la clé est le seul moyen d’attraper une paire intervertie avant qu’elle ne devienne un échec incompréhensible au moment du provisionnement. Sur WISP, qui n’a aucun préfixe, il n’y a aucun moyen de l’attraper.

MCSManager est livré avec son API désactivée. Une installation neuve a enableApiKey à false, et tant que personne ne l’active, chaque appel renvoie 403 « Insufficient Permissions », y compris les appels faits avec une clé valide appartenant à un administrateur valide. C’est un ticket de support dès le premier jour pour quiconque ne sait pas où regarder. Tant que vous y êtes : MCSManager limite aussi le débit à huit requêtes par seconde par cookie de session, si bien qu’un client qui conserve ses cookies se fait brider là où un client qui les jette ne l’est pas.

La question qui tranche : la suspension est-elle réelle ?

On peut demander à chacun de ces panneaux de suspendre un serveur. Ce n’est pas la question. La question est de savoir si un client qui détient encore ses identifiants de panneau peut défaire cette suspension.

Les trois panneaux de la famille Pterodactyl disposent d’une véritable primitive et il n’y a rien à débattre.

MCSManager est la surprise. Lui non plus n’a pas de point d’accès de suspension, mais il a une expiration : placez la date de fin d’une instance dans le passé et le démon refuse de la démarrer. Nous l’avons vérifié contre le panneau et non contre notre propre garde-fou, avec une requête brute, et nous avons obtenu 500 Instance expired. Unable to start the instance. Cela s’appelle imposer une règle. Deux réserves : il faut aussi tuer l’instance, sinon un serveur en fonctionnement continue de tourner jusqu’à ce que la vérification horaire d’expiration le rattrape, jusqu’à soixante minutes plus tard. Et si un client avait fixé sa propre date d’expiration, c’est à vous de la remettre à la réactivation ; la nôtre ne le fait pas encore.

PufferPanel n’a rien. Il n’existe ni point d’accès de suspension ni colonne « suspendu » dans son modèle de données ; le vocabulaire d’état se réduit à running et installing. La meilleure action disponible consiste à arrêter le serveur, puis à le tuer s’il ne s’arrête pas. Un client ayant accès au panneau peut appuyer sur démarrer.

GameAP a un indicateur qui ne fait rien. Il existe un champ blocked, et le positionner est purement administratif. Nous l’avons activé sur un serveur SA-MP en fonctionnement : le serveur est resté en ligne, répondant aux requêtes de jeu en direct, et il a pu être redémarré depuis le panneau par la suite.

Cette distinction mérite d’être inscrite dans votre propre modèle de données plutôt que gommée. Sur les deux panneaux qui n’imposent rien, la description honnête de ce qui s’est passé est « le serveur a été arrêté et bloqué dans le panneau, mais une connexion directe peut le redémarrer », et cela a sa place dans l’enregistrement d’audit de l’action. Consigner six panneaux comme « suspendu » alors que deux d’entre eux ne font qu’en rêver, c’est ainsi qu’un système de facturation cesse discrètement d’encaisser.

Créer un serveur : quatre formes différentes

Il n’y a ici aucun terrain commun. Quatre de ces panneaux modélisent un serveur de jeu d’une manière fondamentalement différente, et la forme de l’appel de création en découle.

Pterodactyl et Pelican veulent tout d’un coup. Nom, propriétaire, egg, image Docker, commande de démarrage, l’ensemble complet des variables d’environnement y compris celles que le client ne voit jamais, limits, feature_limits et une allocation. Il n’existe pas de création partielle ; un champ manquant est un refus, champ par champ. Une valeur à connaître : limits.io est validé between:10,1000, donc envoyer 0 pour « illimité » donne un 422 sur un champ dont aucun client n’entendra jamais parler. Pelican a inversé cette règle : chez lui 0 passe, et c’est l’omission du champ qui est une erreur.

PufferPanel fonctionne à l’envers. Vous forgez vous-même l’identifiant du serveur, huit caractères, puis vous envoyez en PUT toute la définition du modèle en ligne, car la liste des modèles ne transporte pas les variables. Créer n’installe pas : c’est un second appel. Et supprimer exige d’arrêter d’abord, faute de quoi vous récoltez un 500.

GameAP crée une ligne en base de données et rien d’autre. POST /api/servers vous donne un serveur avec installed: 0 ; l’installation est un second appel dont le résultat atterrit dans une tâche du démon plutôt que dans la réponse HTTP, il faut donc interroger. Il n’y a ni identifiant externe ni clé d’idempotence, et les noms ne sont pas uniques, ce qui, mis bout à bout, signifie qu’une création rejouée produit silencieusement un doublon. L’identifiant renvoyé est la seule identité que vous obtenez : stockez-le avant que quoi que ce soit d’autre puisse mal tourner.

MCSManager n’a aucune notion de modèle. Une instance est une commande de démarrage, et c’est là toute l’abstraction. Il existe une liste de préréglages d’installation rapide, soixante-trois au total, mais aucun ne porte d’identifiant : le panneau fait correspondre sur le titre plus la description, cinquante des soixante-trois titres ne sont pas uniques, et les valeurs dépendent de la langue. Tout ce qui s’appuie dessus casse quand le client change la langue du panneau.

Ce que vous pouvez voir ensuite

Deux entrées y sont pires qu’elles n’en ont l’air. GameAP renvoie 403 sur /api/nodes pour un jeton d’API, si bien qu’un moteur de placement ne peut pas voir la capacité du tout et doit se faire dicter où poser les choses. Et le chiffre de disque de MCSManager n’est pas seulement peu fiable : le champ est déclaré à zéro dans le démon et ne se voit jamais affecter de valeur, il vaut donc toujours zéro, sur chaque instance, pour toujours.

Le point d’accès /resources de Pterodactyl met en cache pendant vingt secondes, ce qui compte plus qu’il n’y paraît : interrogez plus vite et vous récupérez les mêmes octets, et un calcul naïf de débit réseau transforme des compteurs identiques en un creux qui n’a jamais eu lieu. Pelican a hérité du même comportement. WISP ne met pas cela en cache, mais WISP n’a pas de champ uptime, qui est justement le champ dont vous vous serviriez pour distinguer une lecture fraîche d’une lecture répétée.

Comment choisir réellement

• Vous avez besoin d’une suspension applicable et d’une vraie API. Pterodactyl, ou Pelican si vous voulez le fork activement développé. C’est la réponse correcte et ennuyeuse pour la plupart de ceux qui vendent de l’hébergement de jeu.
• Vous voulez de l’hébergement sans Docker sur de petites machines. MCSManager, et il convient mieux que sa réputation ne le laisse croire, car l’expiration vous donne une application réelle de la règle. Acceptez de n’obtenir que deux mesures d’utilisation et aucune intégration de console.
• Vous exploitez déjà PufferPanel ou GameAP. Très bien, mais construisez votre suspension par-dessus : c’est à la plateforme de bloquer l’accès au panneau, car le panneau ne le fera pas.
• Vous choisissez aujourd’hui, sans existant. L’API du panneau sera la contrainte de votre automatisation pendant des années, et deux de ces six-là sont incapables d’imposer la seule opération dont votre système de facturation dépend le plus.

Ce qui n’est pas mesuré ici

AMP, comme indiqué plus haut. Les versions de Pterodactyl antérieures à la 1.11, sur un panneau où c’est exactement le genre de comportement qui bouge d’une version corrective à l’autre. Les limites de débit de Pterodactyl et de Pelican, qui demanderaient des centaines de requêtes contre un panneau en fonctionnement pour être établies honnêtement. MCSManager avec Docker activé, où davantage de mesures devraient exister mais où nous n’avons jamais vu un champ rempli. Et le GameAP classique en PHP, puisque le panneau que nous avons mesuré est la réécriture en Go, qui diffère au moins par sa couche d’authentification.

Pterodactyl face à Pelican traite du fork. Provibr intègre ces six panneaux à travers un agent qui tourne dans votre propre réseau ; les notes d’installation se trouvent sous Pterodactyl, Pelican, PufferPanel, GameAP et MCSManager.