● Parcours guidé · formateurs web

Créer une application AR / VR utile pour apprendre, avec A‑Frame.

Ce laboratoire transforme le code HTML en expériences spatiales intentionnelles : manipulation d’un équipement, observation d’un risque, entraînement à une procédure, débriefing et transfert vers le poste de travail.

A‑Frame 1.7WebXRHTML déclaratifVR casque ou écranAR WebSimulations techniques

1. Situer AR, VR et WebXR

La technologie est un moyen. Commencez par la posture, le geste, l’environnement et la preuve d’apprentissage attendue.

VR — s’immerger

L’apprenant entre dans un environnement simulé. La VR convient bien aux gestes coûteux, dangereux, rares ou difficiles à observer directement.

Exemple : repérer une anomalie dans une armoire électrique avant de toucher un équipement.

AR — enrichir le réel

Le téléphone, une tablette ou un casque ajoute des repères, étapes ou objets virtuels à la situation réelle. Le réel reste le point d’ancrage.

Exemple : afficher une séquence de maintenance près d’une pompe ou d’un tableau.

WebXR — la passerelle navigateur

WebXR est l’API navigateur de l’immersion. A‑Frame fournit une couche HTML et composants qui réduit fortement le volume de code de départ.

Principe : prévoyez toujours une utilisation sur écran classique, pas seulement au casque.

Sélecteur pédagogique : quel dispositif pour votre situation ?

Activez un mode pour voir une visualisation typique et les critères de choix.

Disjoncteur : état anormal
But réalisteDécider + agir sans risque
Interaction centraleRegarder, viser, saisir, valider
Risque de conceptionEffet “waouh” sans tâche
Décision : choisissez la VR lorsque l’environnement lui-même influence les choix de l’apprenant.
Étape 2 : isoler l’énergie
But réalisteGuider le geste réel
Interaction centraleSe déplacer, cadrer, confirmer
Risque de conceptionRepères flottants imprécis
Décision : choisissez l’AR lorsque l’artefact réel est nécessaire à l’apprentissage et que la guidance doit être située.
Cliquez / glissez / observez
But réalisteComprendre une relation spatiale
Interaction centraleSouris, clavier, tactile
Atout majeurDéploiement immédiat
Décision : démarrez souvent ici : c’est le meilleur moyen de tester la valeur pédagogique avant l’achat de matériel XR.

2. La progression qui évite le “gadget XR”

Une simulation efficace organise une décision, une action visible et un retour interprétable. Les objets 3D ne sont que le support.

1

Situation

Décrire un problème professionnel réel, ses contraintes et ce qui peut mal tourner.

2

Objectif observable

Formuler ce que l’apprenant doit faire, pas seulement “comprendre”.

3

Modèle simplifié

Conserver les variables qui modifient la décision. Éliminer le décor inutile.

4

Feedback causal

Montrer la conséquence de l’action et expliquer la règle technique associée.

5

Débriefing / transfert

Faire verbaliser : que feriez-vous au poste réel, avec quelles limites ?

À éviter : reproduire chaque vis, câble et texture alors que l’objectif porte sur un protocole de consignation. La fidélité utile est celle qui change une décision, pas celle qui augmente la taille du modèle 3D.

3. Comprendre la mécanique A‑Frame

A‑Frame décrit une scène par des entités HTML. Une entité reçoit des composants : géométrie, position, lumière, son, interaction, logique métier.

<a-scene>le monde, le rendu, WebXR<a-entity id="machine"><a-camera> + curseurentités + composants <a-assets>modèle .glb, image, son, vidéopréchargement et références Composant JavaScriptrègle métier, état, événementfeedback / score / trace Entréessouris, tactile, regard, mainscontrôleurs WebXR Feedbackvisuel, son, texte, vibrationcause → conséquence Cliquez sur un bloc pour focaliser le rôle et la question à poser.

Point de départ : la scène

Une <a-scene> est le conteneur de l’expérience. Elle orchestre le rendu et la connexion à WebXR. À l’intérieur, utilisez des entités descriptives : <a-entity id="machine"> est plus robuste que « le troisième cube de la page ».

Question de formateur : « Quelle action doit être reconnue, et quelle information minimale doit changer pour que l’apprenant sache pourquoi elle est correcte ou non ? »

4. Atelier : générer votre première scène de simulation

Choisissez un dispositif. Le code produit est volontairement lisible : il démontre la scène, l’interaction et le feedback d’une procédure simple.

index.html — exemple A‑Frame
Chargez A‑Frame depuis un CDN, puis servez le projet en HTTPS lors des essais WebXR sur des dispositifs compatibles.

5. Générer un fichier A‑Frame avec une IA : déléguer le code, garder la conception

ChatGPT, Claude et Gemini peuvent accélérer la production d’un prototype A‑Frame. Ils ne connaissent toutefois ni votre activité réelle, ni vos règles de sécurité, ni votre public : le formateur reste responsable du scénario, du contrôle qualité et de l’essai sur dispositif.

Principe non négociable : ne demandez pas seulement « crée une expérience VR ». Demandez une activité, une logique d’état, des interactions, un mode écran, les limites techniques et un fichier complet. Une IA produit souvent un code plausible ; seul l’essai révèle s’il est réellement exécutable.

ChatGPT

Utile pour partir d’un cahier des charges, itérer sur un fichier HTML, demander des corrections ciblées et confronter le résultat à une capture de la console ou de la scène.

Bonne demande : « Réécris uniquement le fichier complet, sans explication autour du code, puis liste les hypothèses techniques à vérifier. »

Claude

Pratique pour travailler sur des artefacts de code longs, conserver un contrat de projet et demander une revue structurée : dépendances, composants, sélecteurs, logique métier et risques d’accessibilité.

Bonne demande : « Examine ce fichier comme un relecteur A‑Frame : repère les composants non chargés et propose le correctif le plus réduit. »

Gemini

Intéressant pour collaborer dans un espace de code et générer ou réviser une application HTML. Restez exigeant sur l’export : récupérez le code source complet et testez-le hors de l’aperçu.

Bonne demande : « Génère un index.html autonome ; ne remplace pas les parties non réalisées par des commentaires ou des pseudo-fonctions. »

prompt-production.txt — à copier dans l’assistant choisi
Le prompt inclut le contexte pédagogique, le contrat du fichier, les contraintes XR et la méthode de vérification.

Le contrat qui rend la sortie exploitable

  1. Produire un unique fichier index.html, autonome hors assets explicitement listés.
  2. Charger A‑Frame depuis une URL explicite, sans framework ni étape de compilation cachée.
  3. Fournir une scène utilisable à la souris, au clavier et au tactile ; la VR complète l’expérience mais ne doit pas la rendre inutilisable sur écran.
  4. Écrire une logique d’état lisible : préconditions, actions, conséquences et feedback visible.
  5. Émettre le code complet dans un seul bloc, sans « … », sans partie à recopier depuis une réponse antérieure.
  6. Terminer par une liste courte des essais manuels nécessaires : console, HTTPS, casque/téléphone et interaction.

Protocole de revue avant d’accepter le code

  1. Ouvrez le fichier dans un navigateur et inspectez la console : une erreur rouge est un défaut à corriger, pas une option.
  2. Vérifiez que chaque composant déclaré existe réellement dans A‑Frame ou est enregistré dans le fichier.
  3. Testez une erreur volontaire : l’interface explique-t-elle la règle ou affiche-t-elle seulement une animation ?
  4. Testez le parcours sans casque et sur petit écran. Le prototype doit rester observable et pilotable.
  5. Pour l’immersion WebXR, testez en HTTPS sur le matériel cible ; l’aperçu de l’IA ne constitue pas une validation WebXR.
  6. Conservez la version qui fonctionne avant de demander une amélioration esthétique : cela évite de perdre une logique correcte.
Prompt de correction : transformer une erreur observée en demande utile

Après un test, fournissez à l’IA le fichier complet actuel, l’action exacte, le résultat attendu, le résultat observé, le texte intégral de la console et, si possible, une capture. Demandez un correctif minimal, le fichier complet réécrit et une explication de la cause probable. Exemple : « Au clic sur le disjoncteur, le texte de feedback ne change pas ; la console indique Cannot read properties of null. Corrige sans changer le scénario ni ajouter de bibliothèque. »

6. Trois patrons de simulations pédagogiques

Ils sont plus réutilisables que des scénarios purement technologiques. Le pattern doit guider le modèle de données, les interactions et le débriefing.

Décision sous contrainte

Diagnostic d’anomalie

L’apprenant observe des indices, formule une hypothèse, choisit un contrôle puis justifie sa décision. Le système garde une trace de la séquence, pas seulement de la réponse finale.

Geste ordonné

Procédure critique

L’apprenant enchaîne des étapes qui ont des préconditions. Une erreur peut déclencher une conséquence sûre mais parlante ; une bonne action débloque la suivante.

Repérage spatial

Lecture d’un espace

L’apprenant s’oriente, localise des éléments, identifie des zones de risque ou organise une tournée. La présence et l’échelle sont ici pertinentes.

Trame de conception

7. Construire une simulation technique : la logique avant le décor

Une machine simulée n’est pas un modèle 3D : c’est un système d’états, de règles et de conséquences. Décrivez-le avant d’écrire le rendu.

Le modèle d’état minimal

Exemple : une intervention sur un équipement. La variable energieIsolee n’est pas décorative : elle conditionne les actions autorisées.

État initial

energieIsolee = false, zoneSecurisee = false, capotOuvert = false. Le système refuse l’ouverture et explique le danger.

Événements

isoler_energie, verifier_absence_tension, ouvrir_capot, remplacer_piece. Chaque événement vérifie des préconditions.

Feedback et trace

Le feedback immédiat indique l’effet de l’action. La trace retient la séquence, les tentatives, le temps et les erreurs significatives pour alimenter le débriefing.

Ne mesurez pas seulement “réussi / échoué”. En formation, l’ordre des actions, les justifications et les erreurs corrigées sont souvent plus utiles qu’un score brut.

Micro-simulation : procédure de consignation

Essayez cette logique : des étapes hors ordre sont bloquées. L’interface démontre l’intérêt de modéliser les préconditions.

État actuelÉnergie active
Départ : l’ouverture du capot doit être impossible tant que l’énergie n’est pas isolée et vérifiée.

0 / 3 étapes valides

8. Quatre scénarios métiers à transformer en expériences A‑Frame

Ces cas rendent visibles des compétences distinctes : lecture spatiale, respect d’un ordre de sécurité, préparation d’un geste, contrôle final et capacité à s’arrêter lorsque les conditions ne sont pas réunies.

Limite assumée : ces scénarios modélisent des décisions et des préconditions à entraîner. Ils ne remplacent ni une analyse de risques, ni la notice constructeur, ni l’habilitation ou l’encadrement professionnel requis pour l’intervention réelle.
Vision spatiale

Camion + remorque : manœuvre au quai

Lire l’angle, construire des repères, protéger une zone de recul et décider d’un arrêt ou d’un réalignement.

VR cabine / vue orbitaleZones d’exclusion
Geste + diagnostic

PC : RAM et SSD

Préparer le poste, identifier les composants, prévenir le risque électrostatique et vérifier le résultat au redémarrage.

Vue éclatéeÉtat matériel
Préparation sécurisée

Soudure MIG : préparer, souder, contrôler

Mettre en place l’environnement, choisir les protections et effectuer un contrôle visuel avant de valider le cordon.

AR de guidageRisques fumées / incendie
Procédure critique

Voiture : remplacer une roue

Vérifier la stabilité du véhicule, suivre les points prescrits, organiser l’échange puis contrôler le serrage selon le constructeur.

Écran + ARPréconditions

Vision spatiale et contrôle d’une zone

Camion + remorque : manœuvre au quai

Le scénario débute par la préparation de l’aire : la simulation ne transforme pas le recul en jeu d’adresse ; elle fait évaluer l’environnement, les repères et le point d’arrêt.

Objectif observable

Règle bloquante

États à modéliser

Valeur XR / écran

Banc d’essai de la logique : cliquez des actions. Une action hors ordre est volontairement bloquée et expliquée.

Chargement de la règle pédagogique…

0 / 4 préconditions validées

Question de débriefing :

9. Qualité : confort, accessibilité et fiabilité

Une expérience techniquement impressionnante mais inconfortable, inaccessible ou opaque sur les données n’est pas une solution de formation défendable.

Confort XR

  • Évitez de déplacer la caméra de manière automatique : le conflit visuel/vestibulaire peut provoquer de l’inconfort.
  • Préférez la téléportation, la rotation par paliers et une vitesse contrôlable.
  • Préparez une sortie immédiate : bouton « pause », accès au contenu sur écran, durée courte.
  • Ne supposez jamais qu’un casque est adapté à tout le monde ou à toutes les situations de travail.

Accessibilité et équivalence

  • Fournissez une voie clavier/souris/tactile en parallèle des contrôleurs.
  • Doublez les signaux visuels par du texte, du son ou un retour haptique quand c’est possible.
  • Ne fondez pas une consigne critique uniquement sur une couleur.
  • Proposez une version observateur et un débriefing collectif : le casque peut devenir un support de discussion, pas un isolement.

Performance pragmatique

  • Réduisez la taille et le nombre des modèles, textures et lumières dynamiques.
  • Chargez d’abord les éléments nécessaires à la première interaction.
  • Testez sur le dispositif le moins puissant visé ; le bureau haut de gamme masque les problèmes.
  • Mesurez le temps avant la première tâche, pas seulement la beauté du rendu.

Données et évaluation

  • Annoncez les données collectées : score, temps, séquence, audio éventuel, mouvements.
  • Collectez le minimum nécessaire à l’objectif pédagogique.
  • Évitez de transformer la simulation en outil de surveillance implicite.
  • Conservez le contexte : un échec peut venir de l’interface, pas d’une compétence absente.

10. Check-list avant le pilote

Un pilote est un essai de conception : préparez des observations, pas seulement une démonstration.

Préparer le test

0 / 6 éléments validés

Questions à poser pendant le débriefing

1. À quel moment avez-vous su quoi faire — et grâce à quel indice ?
2. Quelle erreur aurait eu une conséquence réelle au poste de travail ?
3. Qu’est-ce que la simulation simplifie trop, ou au contraire montre mieux que la réalité ?
4. Que ferez-vous différemment lors de la prochaine intervention réelle ?

11. Auto-évaluation express

Contrôlez les idées structurantes avant de construire un premier prototype.

Quelle formulation décrit le mieux une simulation pédagogique utile ?

À retenir

Le cœur d’une simulation est le modèle d’état : il définit ce qui est possible, dangereux, correct ou incomplet. A‑Frame rend ensuite cette logique visible et interactive.

Premier incrément conseillé

Une seule décision, deux ou trois actions possibles, une conséquence claire et un débriefing. Construisez la “boucle d’apprentissage” avant le monde 3D complet.

12. Références et prolongements

Appuyez-vous sur la documentation officielle pour les composants, les navigateurs et les exemples, puis adaptez la technique à la tâche de formation.

Positionnement : A‑Frame est un excellent point d’entrée pour des formateurs qui savent déjà lire et modifier du HTML. Lorsqu’un prototype exige une logique 3D très spécialisée, vous pourrez ensuite mobiliser directement Three.js, des services de modèles 3D ou un moteur plus complet — mais seulement après validation de l’activité d’apprentissage.
Copié dans le presse-papiers.