Fil rouge — Mettre le mini-jeu en ligne

Votre mini-jeu existe depuis le module 1.2, mais il ne vit que sur votre disque dur : aucun de vos étudiants ne peut y jouer. Cette séance franchit la dernière frontière de la partie 1 — celle qui sépare « ça marche chez moi » de « c'est en ligne ». À la fin, vous aurez une adresse à distribuer.

1. Ce que vous allez publier

Reprenez le dossier minijeu/ produit au module 1.2. Il contient normalement ceci :

minijeu/
├── references/          les PDF de travail
├── programme.md         vos consignes de production
├── index.html           la page du jeu
├── styles.css
└── game.js

Tout n'a pas vocation à partir. C'est précisément le premier travail de cette séance — et une question qu'on se pose trop rarement avant de transférer.

2. Étape 1 — Trier avant de transférer

Le réflexe naturel est de tout envoyer, « au cas où ». C'est justement ce qu'il ne faut pas faire. Sur les cinq éléments de minijeu/, deux n'ont aucune raison de partir : ils sont inutiles au fonctionnement du jeu, et les publier vous exposerait.

Le jeu tourne très bien sans eux

Ouvrez index.html et regardez ce qu'il appelle : styles.css et game.js, rien d'autre. Ni les PDF de references/ ni programme.md n'apparaissent nulle part dans le code. C'est logique — ils ont servi à fabriquer le jeu, ils ne servent pas à le faire tourner. Une fois le jeu produit, ils n'ont plus aucun rôle : les transférer n'apporterait rigoureusement rien à vos étudiants.

Et les transférer vous exposerait

Concrètement, pour ces deux éléments :

• references/ — des documents qui ne vous appartiennent pas

  Ce sont des articles scientifiques, protégés par le droit d'auteur. Les mettre à disposition sur un site public n'est pas la même chose que les distribuer à vos étudiants en classe : c'est de la rediffusion, et elle n'est pas couverte par l'usage pédagogique.

• programme.md — vos consignes de travail

  Il décrit votre méthode, vos exigences, parfois vos tâtonnements. Rien de secret, mais rien qui ait sa place en ligne non plus. Et si vous y avez noté un code enseignant ou une solution, vous le publiez avec.

Passez donc chaque élément en revue avant de le mettre dans le camion :

Trois fichiers, donc. C'est peu, et c'est normal : le dossier de travail n'est pas le site. La règle vaudra pour tous vos projets à venir — on ne transfère que ce dont la page a besoin pour fonctionner, jamais « le dossier entier, on verra bien ».

3. Étape 2 — Relire les noms de fichiers

Deux minutes ici vous éviteront un quart d'heure de perplexité tout à l'heure. Ouvrez index.html et comparez chaque référence au nom réel du fichier :

• La casse, caractère par caractère

  href="Styles.css" pour un fichier nommé styles.css fonctionne chez vous et échoue en ligne. Idem pour src="Game.js". C'est la panne numéro un des premières mises en ligne.

• Les accents et les espaces

  Un fichier jeu ammoniac.html ou références.pdf pose toujours problème dans une adresse. Renommez avant de transférer, pas après.

• Les chemins absolus

  Cherchez C:/ ou file:/// dans le code. Ces chemins désignent votre disque : en ligne, ils ne mènent nulle part. Tout doit être relatif.

Si vous trouvez un doute, faites contrôler avant d'envoyer :

Vérifie que tous les fichiers référencés dans index.html existent bien, avec exactement la même casse. Signale-moi aussi tout chemin absolu ou toute ressource externe qui ne fonctionnerait pas hors de mon ordinateur. Ne modifie rien avant que j'aie validé.

4. Étape 3 — Transférer

Le geste a été détaillé à la microressource 2 : Cyberduck, connexion FTP-SSL, racine du sous-domaine. Une seule décision vous revient ici — où déposer le jeu.

1. Créer un sous-dossier

   À la racine du sous-domaine, créez un dossier jeu (clic droit → Nouveau dossier dans Cyberduck). Le jeu vivra à l'adresse https://votre-site/jeu/, sans écraser la page d'accueil de votre hébergement.

2. Déposer les trois fichiers

   Glissez index.html, styles.css et game.js dans ce dossier. Les trois côte à côte, sans sous-dossier : c'est l'arborescence qu'attendent les liens de votre page.

3. Vérifier ce qui est parti

   Relisez la liste affichée par Cyberduck. Trois fichiers, ni plus, ni moins. Si references/ s'est glissé dans le transfert, supprimez-le du serveur maintenant.

5. Étape 4 — Tester comme un étudiant

Le test qui compte n'est pas « est-ce que ça s'affiche ? » mais « est-ce qu'un étudiant peut y jouer ? ». Ce n'est pas la même chose, et votre ordinateur est le pire endroit pour le vérifier — il a tout en cache.

1. Ouvrir l'adresse, rechargement forcé

   Ctrl+F5 sur https://votre-site/jeu/. Sans nom de fichier : le serveur doit servir index.html tout seul. Si vous obtenez à la place une liste de fichiers, le fichier est mal nommé.

2. Jouer une partie entière

   Du premier écran jusqu'au débrief. Un jeu qui s'affiche mais dont le bouton « valider » ne répond pas est un jeu cassé : c'est presque toujours game.js qui n'a pas été trouvé.

3. Tester depuis un téléphone

   En données mobiles, pas en Wi-Fi domestique. C'est la seule preuve que la page est réellement publique — et l'occasion de voir si elle est lisible sur petit écran.

4. Ouvrir la console

   F12, onglet Console. Une ligne rouge signale un fichier introuvable ; le nom qui y figure vous dit exactement lequel.