- Projet
- Case study
Digitaliser des parcours de jeu urbain : du PDF papier à la web app en deux mois
![Digitaliser des [[parcours de jeu urbain]] : du PDF papier à la web app en deux mois](/_next/image?url=https%3A%2F%2Fsupabase.clementmenczynski.fr%2Fstorage%2Fv1%2Fobject%2Fpublic%2Fimages%2Fprojets%2Fjeux-urbain.webp&w=3840&q=75)
Un client qui organise des escape games et des chasses au trésor en plein Paris nous contacte avec un brief limpide : il imprime des parcours de jeu en PDF pour chaque session, et il veut arrêter. Coûts d'impression, gaspillage de papier, logistique pénible. Nous étions deux développeurs freelance, et le projet semblait droit au but. Il l'était, à un détail près : le plus gros défi n'avait rien de technique.
Le brief : "J'imprime des PDF, je veux arrêter"
Des parcours papier, une logistique lourde
Le concept du client est simple et malin. Il propose des parcours de jeu urbain : des groupes de joueurs explorent un quartier de Paris en passant par des monuments et lieux remarquables, répondent à des questions d'observation sur chaque lieu, et reconstituent un code secret avant la fin du chronomètre. Une sorte d'escape game grandeur nature, en plein air.
Le problème, c'est que chaque session nécessitait d'imprimer un paquet de PDF. Les parcours, les questions, les indices, tout était sur papier. Multipliez ça par le nombre de sessions hebdomadaires, ajoutez les versions en français et en anglais pour les touristes, et vous obtenez une logistique lourde pour un business qui devrait être léger.
Un besoin simple, un scope maîtrisé
Le brief tenait en une phrase : "J'ai des PDF de parcours en deux langues, je veux les digitaliser pour ne plus imprimer." Pas d'écran de fumée, pas de specs de 40 pages. Le client savait exactement ce qu'il voulait, et c'est le genre de clarté qui fait gagner un temps fou en début de projet.
Nous étions deux développeurs, en freelance. Le scope était défini, le brief clair, on co-construisait tout. Sur le papier, un projet idéal. En tout, de la conception des maquettes à la livraison, le projet nous a pris environ deux mois.
Repenser l'expérience de jeu pour le digital
Du papier à l'écran : ce qui change vraiment
Digitaliser un PDF, ce n'est pas juste mettre du texte dans une page web. C'est repenser le flux d'utilisation. Sur papier, le joueur a tout sous les yeux en même temps. Sur écran, il faut guider, structurer, rythmer.
Nous avons conçu un déroulement de partie fluide. Un game master, présent physiquement, lance une session depuis le back-office et génère un code d'accès. Ce code est lié à un parcours précis, valable pour une durée limitée et un nombre de joueurs défini. Les joueurs entrent le code dans la web app, et c'est parti : le chronomètre tourne.
Chaque étape du parcours contient trois éléments. D'abord une indication pour se rendre au lieu suivant. Ensuite une question à choix multiples liée au lieu, le genre de question qui oblige à lever les yeux et observer. Enfin un petit contexte historique sur le monument ou l'endroit visité. C'est ce mélange jeu et culture qui fait le charme du concept.
La mécanique centrale, c'est le code secret. Chaque bonne réponse donne un indice pour le reconstituer, par exemple "la 2e lettre de la réponse est en 5e position dans le code". Une mauvaise réponse ne pénalise pas directement, mais elle prive le joueur d'un indice, ce qui complique la reconstitution finale. Et si un joueur bloque sur une étape, il peut la passer et y revenir plus tard. On voulait éviter la frustration.
Le passage du papier au digital n'est jamais une simple transposition. C'est l'occasion de repenser l'expérience, et souvent de l'améliorer.
Le casse-tête du bilingue qui n'en est pas un
Celui-là, on ne l'a pas vu venir. Au départ, nous avions un premier parcours pour construire l'application. Par chance, ce parcours était identique en français et en anglais : même nombre d'étapes, même structure, même code secret. On a donc naturellement conçu le système de gestion bilingue comme une couche de traduction classique au-dessus d'un parcours unique.
Et puis les autres parcours sont arrivés. Et là, on a déchanté. Un parcours français n'était pas la traduction directe du parcours anglais. Le nombre d'étapes pouvait différer, le code secret changeait, le contenu variait. Ce n'étaient pas deux langues pour un même parcours, c'étaient des parcours structurellement distincts par langue.
Il a fallu pivoter rapidement. Nous avons revu l'architecture pour que chaque langue corresponde à sa propre configuration de parcours, tout en maintenant un lien entre les deux : on sait quelle configuration française correspond à quelle configuration anglaise. Deux configurations distinctes, mais liées. Ce pivot a demandé de la réactivité, mais on a réussi à l'intégrer sans faire exploser le planning.
La moralité est simple : toujours demander l'ensemble des documents et valider la structure des données en amont, pas sur un seul exemple. Si on avait eu le cas complexe dès le départ, on serait partis dans la bonne direction tout de suite. Au lieu de ça, le premier parcours nous a donné une fausse impression de simplicité, et on a construit sur cette base.
Ne construisez jamais une architecture sur un échantillon unique. Demandez tous les cas de figure dès le départ, surtout les plus tordus. C'est ceux-là qui définissent votre modèle de données.
Le vrai défi : l'intégration de contenu
Quand la saisie manuelle mange le planning
Parlons du défi principal de ce projet. Et non, ce n'était pas le chronomètre, ni l'architecture, ni la gestion des sessions. C'était l'intégration manuelle de tous les parcours existants.
Le client avait des PDF. Beaucoup de PDF. Chaque parcours, dans chaque langue, avec ses étapes, ses questions, ses indices, son code secret. Tout ça devait être saisi dans le système. Étape par étape, question par question, indice par indice. En français et en anglais, sachant que ce sont des contenus différents à chaque fois.
On a évidemment essayé d'automatiser. Mais le format des PDF ne nous permettait pas de récupérer la donnée proprement. Certains fichiers étaient des scans, ce qui rendait l'extraction des images et du texte encore plus hasardeuse. Quant à l'IA, on était encore aux débuts, les outils n'étaient pas assez performants pour ce type d'extraction avec la fiabilité qu'on attendait. Résultat : saisie manuelle, parcours par parcours.
Ce travail a pris un temps considérable. Bien plus que ce qu'on avait estimé.
Ce qu'on sous-estime (presque) toujours
C'est la leçon la plus importante de ce projet, et probablement la plus universelle. On est développeurs, on estime bien le temps de développement. Mais le travail non-technique, l'intégration de contenu, la saisie de données, la vérification des traductions, tout ça passe systématiquement sous le radar.
Sur ce projet, la saisie manuelle des jeux et des traductions a représenté une part significative du temps total. Et c'est le genre de tâche ingrate qu'on ne voit pas venir parce qu'elle ne figure dans aucun ticket Jira glamour. Personne n'écrit "data entry" sur un post-it en sprint planning avec enthousiasme.
Si c'était à refaire aujourd'hui ? L'IA a suffisamment progressé pour qu'on puisse probablement automatiser une bonne partie de cette extraction. Mais à l'époque, on n'avait pas ce luxe.
La prochaine fois que vous estimez un projet, posez-vous cette question : combien de temps va prendre le travail que personne n'a envie de faire ? Multipliez par deux. Vous serez plus proche de la réalité.
Sous le capot : stack et architecture
Pourquoi Laravel, React et Inertia
Le choix de la stack a été rapide et pragmatique. Nous maîtrisions Laravel et React, et le projet ne justifiait pas d'apprendre quelque chose de nouveau sur ce délai. Le critère numéro un, c'était la vélocité de développement.
Inertia.js a été la pièce centrale de ce choix. Ce qu'Inertia apporte, c'est la possibilité de construire un monolithe avec Laravel côté backend et React côté frontend, sans avoir à gérer une API séparée. Pas de REST, pas de GraphQL, pas de double déploiement. On code comme dans un monolithe classique, mais avec la réactivité d'une SPA. Pour un projet de cette taille, c'était le sweet spot parfait.
Notre retour d'expérience sur la combinaison Laravel / React / Inertia.js est franchement positif. Inertia simplifie considérablement le développement quand on n'a pas besoin d'une API publique. Si vous hésitez entre un monolithe classique et une architecture découplée pour un projet de taille modeste, testez Inertia. Vous pourriez être surpris.
La base de données PostgreSQL gère tout ce qui est dynamique : les sessions de jeu, les utilisateurs, et les droits d'accès aux parcours via les codes générés par le game master.
Un back-office pensé pour l'autonomie client
Pour le panel d'administration, nous avons utilisé Filament. Le gain de temps a été considérable. Filament fournit une interface d'administration complète et intuitive avec un effort de développement minimal. Et comme le design du back-office n'était pas une priorité pour le client, c'était le choix idéal.
Le back-office permet au client de modifier les traductions des jeux existants de façon autonome. C'était un point important : une fois le projet livré, il ne devait pas dépendre de nous pour chaque ajustement de contenu. Le game master peut aussi y gérer ses sessions, générer les codes d'accès et configurer les paramètres de chaque partie.
Un bon back-office, c'est celui qui rend le client autonome dès la livraison. Si le client doit vous rappeler pour chaque modification, c'est que vous n'avez pas fini le travail.
Ce que je retiens de ce projet
Ce projet m'a rappelé quelques vérités simples. Un brief clair fait gagner des semaines. Une stack maîtrisée vaut mieux qu'une stack à la mode qu'on découvre en chemin. Et le travail invisible, celui qui n'est pas du code, est souvent celui qui fait déraper un planning.
La digitalisation de parcours de jeu urbain n'était pas un défi technique insurmontable. Mais c'était un projet complet, avec sa dose de subtilités (la gestion bilingue, l'intégration de contenu) et ses enseignements. Le genre de mission freelance qui se passe bien quand le cadre est posé dès le départ.
Si vous bossez sur un projet similaire, ou si vous avez des questions sur la combinaison Laravel / React / Inertia.js, n'hésitez pas à me contacter. Et si vous êtes curieux de voir d'autres retours d'expérience, jetez un œil à mes autres projets.
Ce projet a été réalisé en marque blanche. Le nom du client et de la plateforme ne sont volontairement pas mentionnés, par respect des engagements de confidentialité. Les choix techniques et l'architecture décrits dans cet article sont fidèles au projet réel.
![2 ans et demi comme [[développeur en startup]] : retour d'expérience chez ncScale](/_next/image?url=https%3A%2F%2Fsupabase.clementmenczynski.fr%2Fstorage%2Fv1%2Fobject%2Fpublic%2Fimages%2Fprojets%2Fncscale.webp&w=2048&q=75)