Version 2, 30 septembre 2026. Ce manuel remplace le précédent. Il explique d'abord ce qu'il faut comprendre, puis ce qu'il faut faire, avec un outil pensé pour vous : le poste de pilotage, une page dans votre navigateur qui remplace le Terminal. Les détails techniques sont là quand vous en aurez besoin, dans des encadrés « Pour aller plus loin ».

Partie I — Comprendre (dix minutes qui changent tout)

De quoi l'application est faite

Votre application, telle que vos utilisateurs la voient, est un seul fichier, index.html, posé chez un hébergeur (Netlify). Ce fichier contient tout : l'apparence, le comportement, les images, le manuel intégré. Quand quelqu'un ouvre exercices-novi.fr, son navigateur télécharge ce fichier et le fait tourner. C'est pourquoi il n'y a « rien à installer » pour vos utilisateurs.

Ce fichier ne travaille pas seul. Il dialogue avec un serveur (Supabase), qui garde ce qui doit être partagé et protégé : les comptes, les exercices publiés, les séances d'animation, les demandes d'accès. Et quand un courriel doit partir — invitation, réinitialisation, annonce —, c'est un troisième service qui l'expédie (Resend).

Retenez l'image d'une chaîne à trois maillons :

le fichier index.html (chez Netlify)  →  le serveur (Supabase)  →  les courriels (Resend)
   l'application elle-même               comptes, exercices,          invitations, annonces,
   ce que voit l'utilisateur             séances, journaux            réinitialisations

Chaque maillon peut tomber en panne séparément, et chacun se répare à un endroit différent. C'est la première chose à savoir pour dépanner.

Ce qu'est l'atelier

Un fichier de 22 000 lignes ne se relit pas et ne se corrige pas sans se tromper. L'atelier est la version démontée de ce fichier : le code est rangé en cinquante petits fichiers par sujet (le générateur de victimes, la conduite d'exercice, le serveur, l'impression…), les images sont à part, et des outils savent remonter le tout en un seul index.html identique. Ce remontage s'appelle l'assemblage ; le résultat se range dans un dossier nommé dist/ (pour « distribution »).

Deux règles suffisent :

On ne modifie que dans src/ (les sources, le code démonté). Jamais dans dist/ : il est refabriqué à chaque assemblage, et une modification faite là serait perdue.
On ne livre que dist/ — le dossier entier : index.html, _headers, _redirects, version.json et le sous-dossier console/ — et rien d'autre. Tout ce qu'on dépose chez Netlify devient public.

Pourquoi vérifier, et ce que « vérifier » veut dire

Avant l'atelier, on relisait le code des yeux et on espérait. L'atelier fait trois contrôles, dans l'ordre, et s'arrête au premier qui échoue :

La relecture du code (« lint »). Un programme relit les cinquante fichiers et signale ce qui est certainement faux : un nom utilisé sans avoir été défini, ou — la faute qui avait rendu deux fonctions muettes avant la mise en ligne — le même nom défini deux fois, le second effaçant le premier sans bruit. Vingt secondes.
L'assemblage. Le fichier est remonté. Cinq secondes.
Les tests. Un navigateur invisible ouvre le fichier remonté et rejoue dix-neuf scénarios : la vitrine, la démonstration onglet par onglet, la connexion et tous les écrans en mode connecté (avec un faux serveur qui répond comme le vrai), l'assistant de création, la publication, les conditions d'utilisation, l'impression, la conduite, l'animation à plusieurs sur deux navigateurs. Huit à dix minutes.

À la fin : vert ou rouge. Vert, vous pouvez livrer avec une confiance que vous n'aviez pas avant. Rouge, vous ne livrez pas, et la page vous dit en français ce qui a échoué. Ce n'est pas une garantie absolue — un test ne voit que ce qu'on lui a appris à regarder —, mais c'est la différence entre « je crois que ça marche » et « j'ai la preuve que ce que je sais vérifier marche ».

Le vocabulaire qui revient

Mot	Ce que c'est, en clair
Source, `src/`	Le code démonté, celui qu'on modifie.
Assemblage, `dist/`	Le remontage en un seul fichier, et le dossier où il atterrit.
Lint	La relecture automatique du code.
Test	Un scénario rejoué automatiquement dans un navigateur invisible.
Livrer, déployer	Déposer le dossier `dist/` entier chez Netlify.
Netlify	L'hébergeur du fichier. Il garde l'historique de tout ce qu'on a déposé : revenir en arrière se fait en un clic.
Supabase	Le serveur : la base de données, les comptes, les petites fonctions qui envoient les courriels.
Resend	Le service qui expédie les courriels.
Node.js	Le seul logiciel à installer sur votre ordinateur : c'est lui qui fait tourner les outils de l'atelier.
Terminal	La fenêtre où l'on tape des commandes. Vous n'en aurez plus besoin : le poste de pilotage le remplace.
Console du navigateur	Une fenêtre du navigateur (Safari, Chrome) où l'application écrit ses erreurs. Le manuel de dépannage explique comment l'ouvrir et la lire.
Version	Le numéro (1.0, 1.0.1, 1.1…) qui dit aux utilisateurs qu'une mise à jour existe.

Partie II — Le poste de pilotage

C'est l'outil pensé pour vous. Une page qui s'ouvre dans votre navigateur, sur votre ordinateur seulement (personne d'autre n'y accède), avec quatre sections :

Où en est l'atelier — six voyants : Node.js, outils installés, navigateur de test installé, numéro de version dans les sources, dernier fichier assemblé, dernière vérification (vert ou rouge, quand). Et une phrase de conseil : « Le dernier fichier assemblé a été vérifié avec succès : vous pouvez le livrer », ou « lancez Vérifier avant de livrer ».
Vérifier avant de livrer — trois boutons : Vérifier (le contrôle complet), Assembler seulement (trente secondes, pour voir vite un changement), Aperçu dans mon navigateur (l'application, servie depuis votre ordinateur, avec le vrai serveur derrière — vous pouvez vous y connecter). Le résultat s'affiche en français ; le détail brut, ce que le Terminal aurait montré, est replié dessous.
Livrer — le numéro de version, la note pour les utilisateurs, la ligne du journal, un bouton qui archive une copie de ce que vous déposez, et un bouton qui ouvre Netlify.
Raccourcis — le dossier de l'atelier, les livraisons archivées, le site, Supabase, Resend.

Le poste de pilotage

Pour l'ouvrir : double-cliquer sur 0-poste-de-pilotage.command (Mac) ou 0-poste-de-pilotage.cmd (Windows). Une fenêtre noire s'ouvre — c'est le moteur du poste, laissez-la ouverte — puis votre navigateur affiche la page. Pour arrêter : fermer la fenêtre noire.

Ce qu'il ne fait pas : modifier le code (c'est Visual Studio Code, partie III), et déposer chez Netlify (c'est vous, par glisser-déposer : le poste vous ouvre la bonne page et le bon dossier).

Pour aller plus loin. Chaque bouton lance exactement la commande que le Terminal aurait reçue : npm install, npm run verifier, npm run assembler… Le poste n'exécute que ces tâches nommées, jamais une commande venue d'ailleurs, et il n'écoute que votre ordinateur (adresse 127.0.0.1). Si un jour le poste refuse de s'ouvrir, les fichiers 1-installer, 2-verifier, 3-assembler-seulement, 4-apercu-local (.command / .cmd) font la même chose, un par un, et le Terminal reste possible : npm run pilotage, npm run verifier.

Partie III — Faire

1. Installer, une seule fois par ordinateur (dix minutes)

a. Node.js. Ouvrir nodejs.org, cliquer sur le bouton LTS, lancer le fichier téléchargé : Suivant, Suivant, Installer (sur Windows, ne pas cocher « install the necessary tools »). C'est le seul logiciel à installer ; il ne fait rien tout seul.

b. L'archive de l'atelier. Depuis un ordinateur, télécharger exercices-novi-atelier.zip, le décompresser (double-clic sur Mac ; clic droit › Extraire tout sur Windows), ranger le dossier atelier dans Documents et, si vous voulez, le renommer exercices-novi. Pas dans iCloud Drive ni OneDrive : les milliers de petits fichiers des outils rendent la synchronisation interminable.

c. Le poste de pilotage. Double-cliquer 0-poste-de-pilotage. La première fois :

sur Mac, macOS refuse (« provient d'un développeur non identifié ») : clic droit › Ouvrir, puis Ouvrir. Une fois par fichier .command, ou en une fois dans Réglages Système › Confidentialité et sécurité › « Ouvrir quand même » ;
sur Windows, SmartScreen prévient : Informations complémentaires › Exécuter quand même.

d. Les outils. Sur la page, le voyant « Outils de l'atelier » est rouge : cliquer Installer les outils. Une à quatre minutes : les outils (relecture, tests) puis un navigateur de test (150 Mo) se téléchargent. La page dit quand c'est fini.

e. La preuve. Cliquer Vérifier. Dix minutes plus tard, vert. À partir de là, vous savez que la chaîne complète tourne chez vous.

Si l'installation échoue : la page montre la dernière ligne. « network », « ETIMEDOUT » : pas d'Internet, ou un réseau professionnel qui filtre (SDIS, hôpital) — réessayer depuis la maison ou en partage de connexion. « permission denied » (Mac) : le dossier est à un endroit protégé, le déplacer dans Documents. Le téléchargement du navigateur qui s'arrête : recliquer Installer, il reprend.

2. Le cycle, à chaque modification

1. modifier dans src/  →  2. Assembler seulement + Aperçu  →  3. Vérifier (vert)  →  4. Livrer  →  5. noter au journal

Installer Visual Studio Code (code.visualstudio.com, gratuit) pour l'étape 1 : Fichier › Ouvrir le dossier › le dossier de l'atelier. À gauche l'arborescence ; ⇧⌘F (Mac) ou Ctrl+Maj+F (Windows) cherche un mot dans les cinquante fichiers à la fois. TextEdit et le Bloc-notes ne conviennent pas : ils abîment les guillemets.

Trouver où modifier. Vous voyez un texte à l'écran ? Cherchez-le tel quel. Vous connaissez le nom d'une fonction (lu dans la console du navigateur) ? Cherchez function suivi du nom. Sinon, la carte des modules ci-dessous.

Sujet	Fichier(s) dans `src/js/`
Textes de la vitrine, structure des écrans	`../gabarit.html` (le squelette HTML)
Valeurs d'usine : lésions, types d'événement, tri, injects	`10-referentiels-par-defaut`
Enregistrement local, numéro de version	`20-noyau-stockage-utilitaires`
Victimes (tirage, constantes, évolution)	`30-generateur-victimes`
Trame d'injects	`31-trame-injects` (squelette doctrinal), `32-tirage-injects` (moteur de tirage), `33` à `40-reserve-lot-08` (réserve sourcée, un fichier par lot)
La fiche imprimée	`40-fiche-graphisme-svg`, `96-impression`
Connexion, rôles, démonstration	`51-garde-acces`, `74-mode-demonstration`
Serveur, publication, conflits	`60-serveur-supabase`
Console NOVI (administration, ordinateur et téléphone)	`src-console/` : un second produit, assemblé dans `dist/console/` (voir la partie « Le second produit »)
Conditions d'utilisation	`68-confidentialite`
Hôpitaux, orientation	`71-`, `72-`, `91-`
Manuel intégré et FAQ	`75-manuel-et-illustrations`
Assistant de création	`77-etiquetage-et-creation-pas-a-pas`
Séances à plusieurs	`78-filtre-reglages-et-modeles`
Annonces aux utilisateurs	`82-administration-generale-annonces`
Conduite d'exercice	`92-conduite-animation-projection`
Documents (trame, plan de zone, grille)	`93-documents-plan-zone-grille`
Réglages	`97-parametres`
Démarrage, fermeture des fenêtres	`99-initialisation-et-fermetures`

Trois exemples, pas à pas.

Changer une phrase de la vitrine. Chercher le début de la phrase dans src/gabarit.html. La modifier. Enregistrer (⌘S / Ctrl+S). Poste de pilotage › Assembler seulement, puis Aperçu : la vitrine s'affiche avec la nouvelle phrase. Puis Vérifier, puis livrer.

Changer une valeur d'usine (par exemple la durée par défaut d'un exercice). Ouvrir 10-referentiels-par-defaut.js, chercher la valeur, la modifier. Attention : les postes qui ont déjà l'application gardent leurs propres réglages dans leur navigateur ; une valeur d'usine ne les écrase pas. C'est voulu.

Ajouter une question à la FAQ. Ouvrir 75-manuel-et-illustrations.js, chercher const FAQ, copier une entrée existante (elles se ressemblent toutes : un mot-clé de section, une question, une réponse), la coller à la suite, l'adapter. Assembler, Aperçu, Aide : votre question est là.

Ce qu'il ne faut pas faire. Créer une fonction qui porte un nom déjà pris (la relecture le refuse — c'est le but). Renommer un fichier de src/js/ sans réfléchir : le nombre au début du nom fixe l'ordre de remontage, et un module utilisé au démarrage doit venir avant celui qui l'appelle. Modifier dist/.

3. Livrer

Dans le poste, section Livrer : le numéro de version (une correction : 1.0 → 1.0.1 ; une nouveauté : 1.1) et la note qu'afficheront les utilisateurs (une phrase). Ces deux champs écrivent dans les sources ; il faut donc ré-assembler après.
Vérifier. Vert.
Préparer la livraison : une copie de dist/ est rangée dans livraisons/, datée et numérotée, et le dossier s'ouvre. Cette copie compte : quand un utilisateur signalera une erreur « ligne 17942 », c'est dans ce fichier-là qu'on ira lire, pas dans les sources.
Ouvrir Netlify › Deploys : glisser le dossier dist lui-même dans la zone prévue — pas les fichiers un à un : depuis la Console NOVI, il contient un sous-dossier console, qui doit arriver entier. Attendre « Published ».
Ouvrir le site, se connecter, Aide › Vérifier la version : le nouveau numéro s'affiche.
La ligne du journal (section Livrer, avant de préparer) ou à la main dans JOURNAL-DES-MODIFICATIONS.md : date, version, ce qui change, pourquoi. Dans six mois, c'est ce qui vous dira ce que faisait la 1.0.1.

Revenir en arrière : Netlify › Deploys › cliquer sur le déploiement précédent › Publish deploy. Effet immédiat. Une livraison ratée n'est jamais grave : l'ancienne version est à un clic.

4. Le serveur

Le serveur (Supabase) n'a rien à voir avec une livraison : il a été réglé une fois, il tourne. L'atelier garde une copie de ce qui y est installé (supabase/) pour mémoire. Vous y toucherez rarement, et toujours depuis le tableau de bord Supabase (raccourci dans le poste), en suivant le manuel de dépannage. Deux réflexes : ne jamais désactiver « RLS » (c'est le cloisonnement entre services) ; ne jamais copier la « clé de service » ailleurs que dans les réglages secrets des fonctions.

5. Deux ordinateurs

Vous travaillez sur un Mac et un PC. Le danger : corriger sur l'un ce que l'autre a déjà changé. Les deux machines doivent partager la même src/.

La bonne méthode : GitHub Desktop (gratuit, Mac et Windows). Elle demande une heure la première fois et dix secondes par changement ensuite.

Créer un compte sur github.com. Installer GitHub Desktop (desktop.github.com) sur les deux machines, s'y connecter.
Sur la première : File › Add Local Repository › le dossier de l'atelier › « create a repository here ». À gauche, la liste des fichiers ; écrire « Atelier » dans Summary ; Commit to main ; Publish repository en cochant Keep this code private.
Sur la seconde : File › Clone Repository › le dépôt › Documents. Puis le poste de pilotage › Installer les outils (les outils sont propres à chaque machine).
Au quotidien : après avoir modifié, GitHub Desktop liste les changements ; une ligne de résumé, Commit, Push origin. Sur l'autre machine, avant de travailler : Fetch origin, Pull. Si vous avez modifié des deux côtés, il vous montre les deux versions et vous choisissez.

En plus de synchroniser, GitHub garde tout l'historique : chaque version de chaque fichier, avec la date et votre résumé. C'est aussi votre sauvegarde.

Sans GitHub, en dépannage : copier le dossier de l'atelier sur une clé USB sans node_modules/ ni dist/, le coller sur l'autre machine à la place de l'ancien, Installer les outils si ce n'est pas déjà fait là-bas. Et noter sur un papier quelle machine porte la version la plus récente.

6. Quand une nouvelle archive arrive

Dès que vous avez modifié votre atelier, il devient la référence. Une archive reçue — de moi ou de quelqu'un d'autre — ne doit pas l'écraser :

si vous n'avez rien changé depuis la précédente : remplacer le dossier, réinstaller les outils si la page le demande ;
sinon : décompresser à côté et ne reprendre que les fichiers concernés, en comparant (Visual Studio Code : sélectionner deux fichiers, clic droit › Compare Selected) ;
et pour toute évolution que vous me demandez désormais, envoyez-moi d'abord votre dossier src/ (zip, sans node_modules) : je partirai de votre version.

7. Sauvegarder

Irremplaçables : src/ et les documents. Avec GitHub, sauvegardés à chaque Push. Sans, copier le dossier (sans node_modules/) sur un support externe après chaque livraison, en le datant. La base de données, elle, est chez Supabase et ne dépend pas de l'atelier : voir le manuel de dépannage, fiche 18, pour ce que votre plan couvre.

Partie IV — Ce qu'il y a dans le dossier

Élément	Rôle	Y toucher ?
`0-poste-de-pilotage.command` / `.cmd`	Votre outil : la page à boutons	Lancer
`1-installer`, `2-verifier`, `3-assembler-seulement`, `4-apercu-local` (`.command` / `.cmd`)	Les mêmes actions, une par fichier, si le poste ne s'ouvre pas	Lancer au besoin
`src/gabarit.html`	Squelette HTML : écrans, boîtes, textes de la vitrine, fiche	Oui, avec soin
`src/css/` (7 fichiers)	Apparence, impression, thèmes	Oui
`src/js/` (50 fichiers)	Le code, un fichier par sujet, numérotés	C'est là que tout se passe
`src/actifs/`	Images et polices ; `index.json` dit où chacune sert	Pour remplacer une image
`src/NOTE-DE-VERSION.txt`	La note affichée aux utilisateurs (le poste l'écrit pour vous)	Via le poste
`dist/`	Le produit fini : l'application, la Console (`console/`) et leurs réglages Netlify — le dossier à déposer	Jamais à la main
`livraisons/`	Une copie datée de chaque `dist/` déposé	Ne rien supprimer
`outils/`	L'assembleur, la relecture, le poste de pilotage	Non
`tests/`	Les dix-neuf scénarios	Pour en ajouter
`supabase/`	Copie de ce qui est installé sur le serveur, et quinze requêtes de santé	Lecture
`MANUEL-*.md` / `.html`, `GUIDE-MAINTENANCE`, `PLAN-DU-MOIS`, `JOURNAL-DES-MODIFICATIONS`	Documentation	Le journal, à chaque livraison
`POLITIQUE-DE-CONFIDENTIALITE`, `REGISTRE-DES-TRAITEMENTS`, `CORRECTIFS-2026-09-28`	Pièces juridiques et historique	Archives
`package.json`, `eslint.config.mjs`, `playwright.config.js`, `.gitignore`	Réglages des outils	Non
`node_modules/`	Les outils téléchargés	Jamais ; se refait avec Installer

Le second produit : la Console NOVI

Depuis la version 1.0.1, l'atelier fabrique deux produits à partir de deux dossiers de sources : l'application (src/) et la Console NOVI (src-console/), le tableau de bord d'administration. L'assembleur produit les deux d'un seul geste : dist/index.html (l'application) et dist/console/ (la Console, son icône et son petit programme de notifications). On dépose toujours le dossier dist entier : la Console arrive avec l'application, à l'adresse https://exercices-novi.fr/console/.

La Console affiche en pied de ses annonces la version de l'application livrée avec elle : l'assembleur l'y inscrit, rien à faire à la main.

Le contrat avec le serveur

Les tests utilisent un serveur simulé. Pour qu'il ne laisse pas passer ce que le vrai serveur refuserait, il connaît la liste exacte des tables et des colonnes du vrai serveur, avec leur type : c'est le fichier tests/schema-serveur.json. Une requête qui vise une colonne inconnue, ou qui envoie un texte là où le serveur attend un identifiant UUID, fait échouer le test avec un message « contrat serveur : … ». C'est ce contrôle qui a permis de trouver, fin septembre, que la publication d'un exercice n'avait jamais pu fonctionner.

Après toute migration qui ajoute ou change une colonne, il faut rafraîchir ce fichier : dans Supabase › SQL Editor, lancer la requête n° 16 de supabase/requetes-de-sante.sql, copier le contenu de la cellule « schema » et le coller, en entier, à la place du contenu de tests/schema-serveur.json.

Ajouter ou corriger un inject de la réserve

Chaque inject de la réserve est une fiche de texte, rangée dans le fichier de son lot (src/js/33-reserve-lot-01.js pour le lot 1, et ainsi de suite jusqu'au lot 8). Une fiche contient le titre, une ou plusieurs formulations du message, le destinataire et le canal, la réponse attendue, le critère d'évaluation, la fenêtre de temps, la difficulté, les objectifs pédagogiques, les sources, et le fondement : le fait réel qui justifie l'inject, écrit sans nom de lieu ni date.

Modifier la fiche, ou en ajouter une en copiant une fiche voisine.
Si la source est nouvelle, la déclarer en tête du même fichier, avec un identifiant jamais utilisé ailleurs.
Lancer le test de qualité : npx playwright test tests/29-reserve-qualite.spec.js. Il refuse une fiche incomplète, un type d'événement ou une catégorie inconnus, une source absente ou déclarée deux fois, et tout nom de lieu ou toute année dans les textes que voient les joueurs.
Produire le tableau de relecture du lot : node outils/tableau-lot.mjs L03 LOT-03.html (en remplaçant L03 par le lot voulu).
Réassembler l'application (node outils/assembler.js), puis lancer toute la suite de tests.

Les sources ne s'affichent que dans le manuel de l'application, page « Sources de la trame », composée automatiquement à partir de ces fichiers.

Mettre à jour un guide

Chaque guide existe en deux exemplaires : sa source, écrite en Markdown (GUIDE-MAINTENANCE.md, MANUEL-DEPANNAGE.md, etc.), et sa page HTML, lisible par double-clic. La source fait foi : on modifie toujours le fichier .md, puis on produit les pages avec node outils/manuels-html.js.

L'outil refuse de réécrire une page si une phrase de la page actuelle devait disparaître, et il dit laquelle. Il protège ainsi contre l'oubli inverse : une page corrigée directement, sans que sa source suive, et dont la correction serait effacée à la génération suivante. Si la disparition est voulue (une phrase reformulée, un chiffre mis à jour), relancez avec node outils/manuels-html.js --forcer.

Ces guides, comme les dossiers (audit, registres, RGPD) et les pages de livraison, sont aussi dans la Console NOVI, rubrique « Manuels et dossiers » : l'assemblage les y incorpore. Modifier un .md, puis assembler, suffit pour que la Console suive. Pour ajouter un document à la Console : une ligne dans outils/documents-console.js (son identifiant, son fichier, sa famille), puis assembler. La conversion utilise une copie de la bibliothèque « marked » rangée dans outils/vendeur/, avec sa licence : l'assembleur n'a toujours besoin d'aucune installation. Une capture trop lourde pour un téléphone peut être doublée d'une version allégée, de même nom suivi de -console.png : la Console la préfère.