La plupart des pilotes de formation VR suivent la même trajectoire. Une équipe obtient un budget pour un proof of concept, un studio construit un scénario soigné, tout le monde enfile le casque le jour de la démo, et la salle est impressionnée. Six mois plus tard, les casques sont dans un tiroir et le projet est « en cours d'évaluation ».
J'ai construit des simulateurs de formation pour la défense et la santé, et les pilotes ratés que j'ai vus de près n'ont jamais échoué sur la partie VR. Le tracking fonctionnait. Le scénario était réussi. Les gens appréciaient. Le pilote a stagné quand même, pour des raisons toutes décidées avant la première ligne de code.
La démo était le livrable
Un pilote construit pour impressionner en démo optimise la mauvaise chose. Il mise tout sur le rendu visuel et scénarise un parcours parfait, parce que c'est ce qui fonctionne dans une session de dix minutes sous le regard d'un directeur.
Mais un déploiement n'a pas besoin d'un parcours parfait. Il a besoin de vingt stagiaires moyens qui font des choses inattendues, d'un moyen d'ajouter des variantes de scénario sans rappeler le studio, et de quelqu'un au service formation capable de lancer une session sans technicien dans la pièce. Rien de tout cela ne figure sur la checklist d'une démo, donc rien de tout cela n'est construit.
Personne ne portait les chiffres
Demandez ce que le pilote devait prouver et vous entendrez généralement « que la formation VR fonctionne ». Ce n'est pas une affirmation vérifiable avec un casque et de la bonne volonté.
Les pilotes qui ont atteint le déploiement avaient une métrique ennuyeuse attachée dès le premier jour : temps d'acquisition des compétences comparé à la salle de classe, taux d'erreur sur une procédure précise, heures d'instructeur économisées par cohorte. Le pipeline de données qui capture ces chiffres (logs de session, scores, états de complétion, exportés là où un responsable formation regarde vraiment) est du travail backend sans prestige. C'est aussi la seule chose qui fait approuver un deuxième budget.
Le pipeline de contenu était une réflexion tardive
Un scénario, c'est une démo. Un programme de formation, c'est une bibliothèque de scénarios qui évolue avec les procédures. Si chaque mise à jour exige un nouveau contrat avec le studio d'origine, le coût par scénario reste bloqué au niveau « projet logiciel sur mesure », et le programme meurt discrètement à la deuxième facture.
La solution est architecturale, pas artistique : construire la logique de scénario comme de la donnée, pas comme du code. De la configuration pour les plans de salle, les étapes de procédure, les déclencheurs d'échec, les règles de scoring. Le deuxième scénario coûte alors une fraction du premier, et le dixième presque rien.
Ce que je vérifie avant de construire quoi que ce soit
- Un responsable nommé côté client, dont le travail s'améliore si le déploiement a lieu.
- Une affirmation mesurable que le pilote doit prouver, actée par écrit, avec la capture de données correspondante intégrée au build.
- Un plan pour le deuxième scénario : qui l'écrit, avec quel outil, à quel coût.
- Un test sans technicien : un formateur peut-il mener une session complète seul dès la deuxième semaine ?
Si un pilote ne peut pas répondre à ces questions, le contenu du casque n'a pas encore d'importance. Cette conversation est inconfortable au kickoff, et beaucoup moins chère qu'au post-mortem.