Un jeu HTML5 qui reste sur un disque dur n’existe pas vraiment. Tant qu’il n’a pas d’adresse, personne ne peut y jouer en un clic, l’ajouter à un portfolio ou le soumettre à une jam. La bonne nouvelle, c’est qu’un build web ne réclame presque rien pour vivre en ligne : pas de base de données, pas de PHP, pas de serveur applicatif. Des fichiers statiques, une URL, du HTTPS.
La mauvaise nouvelle, c’est que « presque rien » n’est pas « rien ». Selon le moteur utilisé, le poids du build et l’usage visé, les trois hébergements gratuits les plus courants – itch.io, GitHub Pages et Netlify – ne se valent pas du tout. Nous utilisons les trois au studio, sur des projets différents, et voici ce qui les sépare vraiment.
Ce qu’un jeu HTML5 demande à son hébergeur
Un export web, c’est un dossier : un index.html, un ou deux fichiers JavaScript, souvent un .wasm, et un ensemble d’assets. N’importe quel serveur de fichiers statiques sait le distribuer, à trois conditions. Le HTTPS d’abord, parce que le plein écran, le verrouillage du pointeur, l’API Gamepad et le démarrage audio y sont conditionnés sur les navigateurs récents. Les types MIME ensuite : un fichier .wasm servi en text/plain empêche l’instanciation en streaming et allonge le temps de chargement. La compression enfin, gzip ou Brotli, parce qu’un export Godot ou Unity pèse facilement plusieurs dizaines de mégaoctets une fois décompressé.
Le cas particulier des builds multithread
Si le moteur utilise des threads – c’est le cas des exports Godot 4 avec rendu threadé et de nombreux builds Unity WebGL – le navigateur exige que la page soit isolée entre origines. Concrètement, le serveur doit renvoyer deux en-têtes, Cross-Origin-Opener-Policy: same-origin et Cross-Origin-Embedder-Policy: require-corp, sans lesquels SharedArrayBuffer reste indisponible et le jeu refuse de démarrer. Cette seule contrainte élimine un des trois hébergements de la liste, et nous y revenons plus bas.
itch.io, la vitrine avant l’hébergement
Sur itch.io, on téléverse une archive ZIP contenant un index.html à la racine, on coche l’option indiquant que le fichier se joue dans le navigateur, et la plateforme s’occupe du reste. C’est le chemin le plus court entre un build et un lien jouable. C’est aussi le seul des trois qui apporte un public : page produit, devlogs, commentaires, statistiques de vues, inscription à une jam et collecte de dons sont intégrés.
Les limites annoncées pour un build jouable dans le navigateur sont de 1 000 fichiers, 200 Mo par fichier et 500 Mo une fois décompressé. C’est confortable pour un jeu 2D, nettement plus serré pour un projet 3D. Au-delà, l’outil en ligne de commande butler permet de pousser des versions bien plus lourdes.
La contrepartie, c’est que la page ne vous appartient pas. L’URL reste en pseudo.itch.io, la mise en page suit un gabarit, et le référencement profite d’abord à la plateforme. Pour montrer un travail à un client ou alimenter un site professionnel, ce n’est pas le bon support.
GitHub Pages, quand le dépôt devient le site
Si le projet est déjà versionné, GitHub Pages ne coûte presque aucun effort supplémentaire : on pousse le dossier de build, on active Pages dans les réglages du dépôt, et le jeu est en ligne quelques secondes plus tard, en HTTPS, avec la possibilité de brancher un nom de domaine personnalisé sans frais.
Les limites documentées sont généreuses pour un jeu : 1 Go pour le site publié, 100 Go de bande passante par mois et une dizaine de constructions par heure. Ce sont des limites souples : GitHub prévient ou ralentit plutôt qu’il ne facture.
Le vrai obstacle est ailleurs. GitHub Pages ne permet pas de définir d’en-têtes HTTP personnalisés. Pas de COOP, pas de COEP, donc pas d’isolation entre origines et pas de SharedArrayBuffer : un export Godot 4 multithread ou un build Unity WebGL avec threads ne démarrera tout simplement pas. La demande revient régulièrement dans les discussions de la communauté GitHub depuis plusieurs années, sans réponse. Pour un jeu en JavaScript pur, avec Phaser par exemple, la question ne se pose pas et Pages fait très bien le travail.
Netlify, le déploiement continu et son nouveau tarif
Netlify accepte aussi bien le glisser-déposer d’un dossier de build que le branchement direct d’un dépôt Git, avec redéploiement automatique à chaque commit. Surtout, il laisse écrire les en-têtes que l’on veut, via un fichier _headers déposé dans le dossier publié ou via netlify.toml. C’est la solution la plus simple pour servir un build multithread correctement isolé.
Attention toutefois au changement de modèle. Les comptes créés depuis septembre 2025 sont passés à un système de crédits : 300 crédits par mois sur l’offre gratuite, un déploiement en production coûtant 15 crédits et la bande passante 20 crédits par gigaoctet. En pratique, cela représente une quinzaine de gigaoctets de trafic ou une vingtaine de déploiements, en plafond strict. Les comptes plus anciens conservent l’ancienne formule, 100 Go de bande passante et 300 minutes de construction. Pour un jeu web de plusieurs dizaines de mégaoctets, le calcul mérite d’être fait avant de communiquer largement sur le lien.
Lequel choisir selon le projet
Pour une jam ou une première mise en ligne, itch.io reste le choix évident : la page existe en dix minutes, le public est déjà là, et personne n’attend une URL de marque. Pour un portfolio, un prototype montré à un client ou un jeu que l’on veut voir référencé sous son propre nom de domaine, GitHub Pages est difficile à battre, à condition que le build ne réclame pas d’isolation entre origines. Dès que le moteur exige COOP et COEP, ou qu’on veut un déploiement continu propre, Netlify devient la seule option confortable des trois – en surveillant la consommation.
Rien n’oblige d’ailleurs à trancher. Nous publions régulièrement la même version à deux endroits : sur itch.io pour la visibilité et les retours, sur notre propre domaine pour le portfolio. Le build est identique, seul le contexte change. Et si vous vous demandez ce que l’automatisation peut réellement prendre en charge dans ce pipeline, nous en avons fait le tour dans IA et jeu indé : ce qu’on peut vraiment automatiser en 2026.
Les erreurs qui reviennent le plus souvent
La première est l’archive mal formée : l’index.html se retrouve dans un sous-dossier au lieu de la racine du ZIP, et la plateforme affiche une page blanche. La deuxième vient des chemins absolus. Un GitHub Pages de projet sert le site depuis /nom-du-depot/, si bien qu’un asset appelé en /assets/sprite.png est cherché à la racine du domaine et échoue silencieusement. Il faut des chemins relatifs, ou une base configurée à l’export.
Viennent ensuite le contenu mixte – une police ou un son appelés en http:// depuis une page en https:// sont bloqués sans avertissement visible –, l’oubli de la compression, qui transforme un chargement de trois secondes en attente de trente, et l’absence de test sur mobile, où le tactile et la mémoire disponible ne pardonnent pas les hypothèses prises au clavier.
Pour aller plus loin
Mettre un jeu HTML5 en ligne prend dix minutes une fois qu’on a compris ce que le navigateur attend du serveur. L’essentiel se joue en amont, dans la préparation du build : chemins relatifs, assets compressés, en-têtes cohérents avec le moteur. Si vous partez de zéro, notre guide créer un jeu 2D avec Phaser 4 couvre la partie développement, et HTML5 et game development revient sur les bases du format. Côté lecture, les manuels de développement de jeux en JavaScript restent une bonne porte d’entrée, et l’actualité des sorties indépendantes se suit sur Subway Press.
0 commentaire