Hébergement gratuit de bot Discord 24/7

La réponse courte

Oui, vous pouvez faire tourner un bot Discord gratuitement. Non, presque aucune option gratuite ne le gardera en ligne en continu sans que vous remarquiez de coupures. Une seule y parvient vraiment : une machine qui vous appartient et que vous laissez allumée. Tout le reste échange la disponibilité contre le zéro sur la facture — il met le bot en veille, le facture à la consommation ou le redémarre selon un calendrier.

Voilà tout le guide en trois lignes. La suite détaille ce que fait chaque option, pour que vous choisissiez en connaissance de cause.

Si votre bot est un projet du week-end sur lequel vous travaillez activement, une offre gratuite est le bon outil et vous pouvez arrêter votre lecture ici. Si d'autres l'utilisent déjà, lisez la suite — les défaillances décrites plus bas sont celles qui vous rattraperont.

Les quatre façons dont « gratuit » cesse d'être 24/7

Les offres gratuites ne lâchent pas au hasard. Elles lâchent de quatre façons précises, et savoir laquelle vous touche vous dit immédiatement si le problème a une solution.

1. La plateforme met votre processus en veille

Les plateformes d'hébergement récupèrent les ressources de tout ce qui semble inactif. Et voici le piège : pour une plateforme web, un bot Discord semble totalement inactif. Il ouvre une connexion WebSocket sortante vers la passerelle de Discord et attend. Rien n'arrive sur un port, aucune requête HTTP n'est servie, aucun graphique de trafic ne bouge. Votre bot peut répondre à des commandes toute la soirée et pourtant, selon chaque métrique que surveille la plateforme, ne rien faire du tout.

2. Après la mise en veille, rien ne le réveille

Pour un site web, la mise en veille n'est pas grave : la requête du visiteur suivant le réveille, et celui-ci attend une seconde. Personne n'envoie de requête HTTP à un bot Discord, donc rien ne le réveille — il reste simplement éteint. C'est toute la raison d'être des astuces de keep-alive : un minuscule serveur web greffé sur le bot, plus un service externe qui le pingue indéfiniment. Ça marche jusqu'à ce que le service de ping s'arrête, que la plateforme change ses règles de mise en veille, ou que vous lisiez les conditions et découvriez que vous les contournez.

3. Le système de fichiers ne vous appartient pas

Sur beaucoup d'offres gratuites, le disque est réinitialisé à chaque redéploiement ou redémarrage de l'application. Si votre bot écrit des niveaux, une économie, des avertissements ou des réglages par serveur dans un fichier JSON à côté de son code, ce fichier est un stockage temporaire qui a l'air permanent. Il tient quelques jours, assez longtemps pour que vous lui fassiez confiance, puis un redémarrage l'efface. Tout ce qui doit survivre à un redémarrage a sa place dans une base de données, pas sur le disque.

4. Le quota mensuel est épuisé

Certaines offres gratuites ne reposent pas du tout sur la mise en veille — elles vous accordent un quota d'utilisation par mois. Un bot qui tourne en continu consomme ce quota en continu, donc il s'arrête en cours de cycle et revient quand le compteur est remis à zéro. Trois semaines de disponibilité, c'est une configuration de loisir tout à fait correcte. Ce n'est pas du 24/7.

Replit : développez-y le bot, mais ne l'y laissez pas

Replit réunit un éditeur et un environnement d'exécution dans un seul onglet de navigateur, et pour écrire un bot c'est vraiment agréable — vous passez d'un fichier vide à un bot qui répond sur votre serveur de test sans rien installer. Le premier bot fonctionnel de beaucoup de gens a vécu sur Replit, y compris bon nombre de bots devenus ensuite des projets sérieux.

Le problème est structurel, pas une question de radinerie : Replit est construit autour d'un espace de travail que vous êtes en train d'utiliser. Garder un processus actif après avoir fermé l'onglet est une fonctionnalité distincte et payante, et l'espace de travail gratuit s'arrête quand vous cessez d'y travailler. C'est une décision produit cohérente — c'est un environnement de développement, pas une plateforme d'hébergement — mais cela signifie que « mon bot se déconnecte quand je ferme mon portable » est le comportement prévu, pas un bug à corriger.

Ce qui nous amène à l'astuce de keep-alive qu'on trouve dans des dizaines de tutoriels : ajouter un serveur web minimal à votre bot, puis pointer un moniteur de disponibilité gratuit dessus pour que quelque chose demande toujours la page. Ça fonctionne un temps. C'est aussi fragile de tous les côtés — le moniteur décroche, les règles changent, et vous finissez par entretenir le contournement au lieu du bot. Avant de bâtir quoi que ce soit dessus, lisez la documentation actuelle de Replit pour savoir ce que comprend l'offre gratuite aujourd'hui, car c'est précisément le genre de chose qui est révisé.

Render et Railway : de vraies plateformes, mais pas le bon format en gratuit

Render et Railway sont de vraies plateformes de déploiement — git push, ça compile, ça tourne. Leurs offres payantes sont un endroit tout à fait raisonnable pour un bot Discord. Ce sont les portes d'entrée gratuites qui piègent les gens, pour deux raisons différentes qu'il vaut la peine de distinguer.

Render : votre bot n'est pas le bon type de service

L'offre gratuite de Render est pensée pour les services web — ce qui répond à des requêtes HTTP — et les arrête quand aucune requête n'arrive. Un bot Discord n'est pas de ce type. C'est un worker d'arrière-plan qui maintient une connexion sortante, et il ne recevra jamais le trafic HTTP qui le garderait éveillé. Le décalage n'a donc rien à voir avec la générosité de l'offre ; la charge de travail ne correspond tout simplement pas au format du produit. La disponibilité des workers d'arrière-plan dans l'offre gratuite est exactement le genre de détail qui change, alors consultez la documentation de Render plutôt qu'un tutoriel vieux de deux ans.

Railway : facturé à l'usage, donc arrêt en milieu de mois

Railway mesure l'utilisation et vous donne un quota à dépenser. Rien ne se met en veille et rien n'a besoin d'être pingué — ça tourne simplement jusqu'à épuisement du quota, puis ça s'arrête jusqu'au cycle suivant. Pour essayer un déploiement, c'est propre et prévisible. En tant qu'« hébergement 24/7 », il y a un arrêt net intégré, et cet arrêt tombe en plein milieu du mois, quand vous ne regardez pas. Leur documentation tarifaire donne les chiffres actuels.

Les deux valent la peine d'être connues, et aucune n'est critiquée ici. Si le workflow vous plaît, la démarche honnête consiste à prendre l'offre payante de la plateforme que vous aimez — pas à forcer l'offre gratuite à se comporter comme elle.

Oracle Always Free, GitHub Actions et les offres de « VPS gratuit »

Trois autres options qui reviennent sans cesse, par ordre décroissant de la confiance que vous pouvez leur accorder.

Oracle Always Free : ce qu'un cloud offre de plus proche du 24/7 gratuit

Celle-ci est réelle. L'offre Always Free d'Oracle comprend de petites machines virtuelles qui ne se mettent pas en veille — un simple serveur Linux qui reste allumé, soit exactement ce que vous cherchiez. Deux bémols, en toute honnêteté. D'abord, en obtenir une est la partie difficile : la capacité gratuite dans une région donnée est souvent indisponible, et la solution consiste à essayer une autre région ou à patienter. Ensuite, vous voilà administrateur système — mises à jour du système d'exploitation, pare-feu, une unité de service pour que le bot redémarre au boot, et vos propres sauvegardes. C'est un échange équitable si vous voulez apprendre tout cela, et un mauvais calcul si vous vouliez seulement que votre bot soit en ligne. Lisez les conditions actuelles d'Always Free d'Oracle avant de vous y fier, y compris ce qui arrive aux instances qu'ils jugent inactives.

GitHub Actions : pas un hébergeur, et pas autorisé comme tel

Actions est un système de CI : il exécute un job quand quelque chose se passe dans votre dépôt, et les jobs ont une durée d'exécution maximale. Vous pouvez enchaîner des exécutions planifiées pour imiter un processus permanent, et certains le font. Deux raisons de s'en abstenir. En pratique, vous obtenez un bot qui meurt et redémarre selon un horaire, avec une coupure à chaque fois. Formellement, les conditions de GitHub limitent Actions aux tâches liées au logiciel du dépôt lui-même — un bot qui tourne en permanence sort du cadre prévu pour le produit, et bâtir votre communauté sur quelque chose qui peut être coupé est une mauvaise fondation. Utilisez-le pour ce qu'il fait remarquablement bien : tester le code de votre bot à chaque push.

Les offres de « VPS gratuit » : jugez-les sur ce qu'elles taisent

Elles se répartissent en deux catégories. Certaines sont des essais ordinaires — une vraie machine, une vraie limite de temps, une carte bancaire exigée. Très bien, tant que vous savez que le compteur tourne. Les autres promettent un serveur gratuit à vie et restent vagues sur les détails, et c'est là le signal : si un fournisseur n'indique pas par écrit le CPU, la RAM, le réseau et la politique d'utilisation acceptable, vous avez votre réponse. Une machine surchargée sans limites déclarées ne tombe pas en panne bruyamment ; elle devient juste lente, votre bot répond en retard et vous ne savez jamais pourquoi.

Votre propre PC ou un Raspberry Pi : l'option vraiment gratuite

Voici l'option qui tient sa promesse. Du matériel que vous possédez déjà, allumé, qui fait tourner votre bot. Rien ne le met en veille, rien ne le facture à l'usage, et aucun quota ne s'épuise. Si vous avez une machine libre et une connexion stable, c'est un vrai hébergement 24/7 gratuit, et ce guide ne prétendra pas le contraire.

Ce que vous payez à la place, ce n'est pas de l'argent, et cela mérite d'être dit honnêtement :

• L'électricité, tout le mois, chaque mois. Un PC de bureau laissé allumé pèse réellement sur votre facture ; un Raspberry Pi, c'est une erreur d'arrondi. Faites le calcul avec votre propre tarif — quiconque vous donne un chiffre devine le prix de votre électricité.
• La fiabilité de votre connexion à la maison devient la disponibilité de votre bot. La box redémarre à 3 h du matin, le fournisseur d'accès a une mauvaise heure, le courant vacille. Chaque incident est une coupure, et vous l'apprenez quand quelqu'un sur votre serveur le mentionne.
• Votre attention. Une mise à jour de Windows décide de redémarrer au pire moment, ou le processus meurt en silence et rien ne le relance. Chez vous, la supervision, c'est vous.

Deux choses font la différence entre une solution qui fonctionne et une source d'agacement récurrente :

• Faites-le redémarrer tout seul. Un bot lancé à la main dans un terminal s'arrête au premier plantage ou redémarrage. Configurez-le comme un service qui revient au démarrage — c'est cette seule étape qui sépare « hébergé à la maison » de « tourne jusqu'à ce qu'il se passe quelque chose ».
• Utilisez un Raspberry Pi plutôt que votre machine de tous les jours. Il ne consomme presque rien, n'a pas de ventilateur agaçant et — surtout — vous ne l'utilisez pour rien d'autre, donc rien de ce que vous faites ne peut faire tomber le bot. Gardez en tête que la carte SD finit par s'user, alors placez tout ce qui compte à un endroit que vous sauvegardez.

Hébergement gratuit 24/7 pour un bot Python ou Node.js

La question arrive généralement avec un langage : un hébergement gratuit 24/7 pour un bot discord.py, ou pour un bot discord.js. La réponse honnête : le langage ne change presque rien au fait qu'un hébergeur gratuit garde ou non votre bot en ligne. La mise en veille, les démarrages à froid, un disque qui se réinitialise et un quota mensuel agissent sur le processus, pas sur le langage dans lequel il est écrit. Un bot Python et un bot Node.js sur la même offre gratuite se déconnectent au même moment, pour la même raison.

Là où le langage compte, c'est dans les détails qui déterminent si un hébergeur convient tout court :

• L'environnement d'exécution est-il proposé, et dans quelle version ? discord.js suit les versions actuelles de Node.js et discord.py a besoin d'un Python assez récent. Une offre gratuite qui ne propose qu'un environnement ancien, ou un seul des deux, s'élimine d'elle-même avant même la question de la disponibilité. Comparez les versions prises en charge par l'hébergeur avec les exigences de la bibliothèque.
• Les dépendances sont réinstallées sur un disque vierge. Sur un hébergeur dont le système de fichiers se réinitialise, les bibliothèques du bot sont réinstallées après chaque redémarrage ou redéploiement — en Node.js comme en Python. Cela allonge la coupure après chaque redémarrage, et une dépendance qui ne s'installe pas signifie que le bot ne revient pas du tout.
• La voix demande plus que la bibliothèque. Un bot musical, dans l'un ou l'autre langage, a besoin de composants natifs à côté de la bibliothèque — une bibliothèque audio Opus, une bibliothèque de chiffrement et FFmpeg — et beaucoup de plateformes gratuites ne les fournissent pas et ne vous laissent pas installer de paquets système. Un bot uniquement textuel n'est pas concerné.
• L'astuce de keep-alive a un autre visage, mais échoue de la même façon. Les tutoriels Python greffent un petit serveur Flask sur le bot ; les tutoriels Node.js utilisent Express. Dans les deux cas, il n'existe que pour générer des requêtes qui empêchent la plateforme de mettre le processus en veille, et il casse pour les mêmes raisons que celles décrites plus haut.

La mémoire est l'autre point où les deux diffèrent : la même logique de bot n'utilise pas la même quantité de RAM en tant que processus Node.js et en tant que processus Python, et un bot musical en utilise plus que l'un ou l'autre. La plupart des bots de commandes et de modération tiennent tout de même à l'aise dans quelques centaines de mégaoctets dans les deux langages, donc pour un bot typique ce n'est pas le facteur décisif.

Quand payer en vaut la peine, et pour combien peu

Il y a ici une limite nette, et elle ne dépend pas de la taille de votre bot. Payez quand le bot cesse d'être le vôtre pour devenir quelque chose sur quoi d'autres comptent. Jusque-là, une panne vous coûte un haussement d'épaules. Après, une panne vous coûte ce pour quoi vous avez créé le bot.

Quatre signes que vous avez franchi cette limite :

• Quelqu'un d'autre remarque que le bot est hors ligne avant vous.
• Vous l'avez redémarré à la main plus d'une fois ce mois-ci.
• Perdre ses données — niveaux, économie, configuration — aurait vraiment de l'importance.
• Vous passez plus de temps à entretenir un contournement de keep-alive qu'à travailler sur le bot.

Si la décision est facile, c'est grâce au prix. Un bot est une charge légère : un bot de modération ou de commandes est à l'aise dans quelques centaines de mégaoctets de RAM, donc ce que vous achetez n'est pas de la puissance, c'est le fait qu'il tourne et continue de tourner. L'hébergement de bots Discord HytHost commence à €0.89/mois, avec un processus qui redémarre tout seul en cas de plantage, une base de données qui survit aux redémarrages et un SLA de disponibilité de 99,9 % — pour à peu près ce que l'électricité d'un PC de bureau vous aurait coûté de toute façon.

Si vous voulez la partie pratique — mettre votre code sur un hébergeur, la commande de démarrage, les dépendances, garder votre token hors du dépôt — c'est un autre travail, et il a son propre guide : comment héberger un bot Discord 24/7.