Mon jeu web marchait sur mon PC, mais pas sur certains téléphones : le piège du déploiement

J’ai mis un jeu web en ligne.

Sur mon ordinateur, tout fonctionnait. Le correctif était bien sur GitHub. Le déploiement s’était terminé avec succès.

Et pourtant, sur certains téléphones, le jeu ne marchait toujours pas.

Dans Analytics, j’ai trouvé cette erreur :

SyntaxError: Unexpected token '<'

Je travaillais en JavaScript. Alors pourquoi ce signe « < » apparaissait-il soudain comme problème ?

C’est arrivé pendant le développement de mon jeu web ORA Quest. La leçon la plus utile n’a pas été une ligne de code miracle, mais le fait de comprendre ce que ce message essaie souvent de nous dire.

Le vrai problème n’est peut-être pas le « < »

Mon premier réflexe a été de chercher une erreur de syntaxe JavaScript. Un caractère bizarre ? Un JSON cassé ? Une virgule oubliée ?

Mais avec Unexpected token '<', il faut rapidement vérifier autre chose : le navigateur demandait-il du JavaScript ou du JSON alors que le serveur lui a renvoyé du HTML ?

Imaginons que le navigateur demande game.js. Il s’attend à recevoir du JavaScript. Mais le serveur renvoie en réalité une page d’erreur commençant par <!DOCTYPE html>.

Le navigateur essaie de lire cette page comme du JavaScript et bloque dès le premier <.

Autrement dit, ce signe n’est pas forcément le coupable. Le navigateur a peut-être simplement reçu le mauvais type de contenu.

Les bugs les plus pénibles ne cassent pas chez tout le monde

C’est ce qui a rendu le problème particulièrement trompeur.

Le jeu pouvait fonctionner sur PC, fonctionner sur un téléphone, puis échouer sur un autre ou dans le navigateur intégré d’une application sociale.

On tombe alors très facilement dans ce cycle :

corriger → déployer → ouvrir sur son propre PC → constater que ça marche → considérer le problème comme réglé.

Je faisais exactement cela.

Mais si la panne dépend du cache, du navigateur, d’une ancienne ressource ou d’un chemin de requête particulier, votre propre machine peut vous donner une fausse impression de sécurité.

Les 5 vérifications que je ferais en premier aujourd’hui

1. Ouvrir directement l’URL du fichier JavaScript ou JSON en erreur.
2. Vérifier que la réponse est bien du JavaScript ou du JSON.
3. Regarder si une page 404, une page de connexion, WordPress ou un autre HTML est renvoyé à la place.
4. Confirmer que le serveur de production sert bien le fichier attendu depuis GitHub.
5. Tester sur un autre appareil ou navigateur sans dépendre du même cache.

La première vérification est particulièrement rentable.

Au lieu de modifier du code parce que « l’erreur ressemble à du JavaScript », mieux vaut poser une question beaucoup plus simple :

Qu’est-ce que cette URL renvoie réellement ?

Elle peut éviter beaucoup de corrections inutiles.

Un GitHub correct ne garantit pas une production correcte

Je l’ai appris à mes dépens.

Le bon code peut être présent sur GitHub sans être exactement ce que l’utilisateur reçoit.

Entre le dépôt et le joueur, il peut y avoir une automatisation de déploiement, un serveur, WordPress, un cache serveur ou CDN, le cache du navigateur et un navigateur intégré à une application.

Une seule couche qui renvoie une ancienne version ou une réponse inattendue suffit pour obtenir : « Mais je l’ai déjà corrigé… »

Depuis, ma définition de « corrigé » a changé.

Une correction n’est pas terminée quand le commit est juste. Elle l’est quand l’URL de production fonctionne dans des conditions proches de celles du vrai utilisateur.

Ne pas seulement supprimer l’erreur : préparer la prochaine enquête

Avant, mon objectif était simple : faire disparaître l’erreur.

Aujourd’hui, j’essaie aussi de garder assez d’informations pour la comprendre si elle revient.

Quel fichier a échoué ? Quelle URL a été demandée ? Dans quel environnement ? Quel build était en cours ?

Avec ces éléments, la prochaine fois la question n’est plus « le même bug mystérieux est revenu », mais « est-ce la même cause que la dernière fois ? »

Ce n’est pas spectaculaire. Pour un développeur solo, c’est pourtant parfois plus précieux qu’une fonctionnalité supplémentaire.

Développer seul, c’est souvent passer plus de temps à comprendre la réalité qu’à écrire du code

Avant de créer des jeux web, j’imaginais surtout les personnages, l’histoire et la programmation.

En réalité, beaucoup de temps part dans des questions comme : pourquoi seulement cet appareil ? Pourquoi le JavaScript d’hier apparaît-il encore ? Pourquoi une URL JSON renvoie-t-elle du HTML ?

Chaque problème compris élargit un peu ce que je peux construire ensuite.

La grande leçon de Unexpected token '<' est simple :

le code que vous avez écrit et le fichier que l’utilisateur reçoit réellement ne sont pas toujours la même chose.

Si vous voyez cette erreur, avant de réécrire votre JavaScript, ouvrez directement l’URL du JS ou du JSON concerné. Si vous voyez du HTML, vous tenez déjà une piste importante.

J’apprends tout cela en construisant ORA Quest. Si vous voulez voir ce que deviennent ces heures de debugging, vous pouvez essayer gratuitement la démo d’ORA Quest.