Il y a dix ans, j'ai eu une idée toute simple : transformer une ville en terrain de jeu. Un escape game, mais dehors. Pas de salle fermée avec des cadenas et un animateur qui débloque la suite depuis une régie. La rue, les monuments, le patrimoine local comme décor et comme énigme. Tu marches, tu observes, tu avances. La ville devient le jeu.
Je l'ai portée dix ans sans jamais la sortir. Pas par manque d'idée sur le produit, j'avais le concept, les mécaniques, les cas d'usage depuis le début. Par manque de bras. Une plateforme avec carte interactive, géolocalisation temps réel, système d'indices, back-office de création de contenu, authentification, ça représente des mois de développement que je n'ai jamais réussi à m'accorder entre deux missions clients. Le genre de projet perso qui ressort en soirée pour se rassurer qu'on a encore de bonnes idées, avant de retourner dans le tiroir.
Ce qui a débloqué le projet, ce n'est pas un temps libre miraculeusement retrouvé. C'est d'avoir arrêté de traiter Claude Code comme un autocomplete et de m'en servir comme un vrai collaborateur technique, avec un cadre.
Sur ce chantier, chaque fonctionnalité passe par le même cycle avant qu'une ligne de code de production ne soit écrite. Elaborate pour poser le besoin en user stories et critères d'acceptation vérifiables, pas un vague ticket. Plan pour découper le besoin en phases techniques exécutables une par une, avec les fichiers concernés et les risques identifiés. Arch-review pour challenger ce plan avant d'écrire quoi que ce soit, pas après coup une fois le mal fait. Puis l'implémentation phase par phase, et une code-review pour clôturer. Le genre de rigueur qu'on s'impose en équipe pour ne pas partir dans tous les sens, sauf que là, l'équipe c'est moi et l'IA, et c'est elle qui porte la discipline que je n'aurais jamais tenue seul un vendredi soir à 23h.
En deux jours, une vingtaine de fonctionnalités sont sorties avec cette méthode, chacune documentée de bout en bout : le MVP avec la carte interactive et les trois familles d'énigmes, le site vitrine B2C et B2B, l'authentification Google et Facebook, la file de modération admin pour valider les parcours et les réponses aux indices, les indices progressifs avec délai de déblocage, un mode créateur pour proposer des idées d'énigmes géolocalisées, un module d'analytics pour suivre les sessions. Ce que j'aurais mis des mois à sortir seul, morceau par morceau, le soir, en dilettante.
Elaborate - Plan - Arch Review - Implement
Ce n'était pas un enchaînement sans accroc, et c'est justement ça qui rend l'exercice intéressant. Un exemple bête : le timer de déblocage des indices affichait n'importe quoi. 83 723 secondes à attendre au premier chargement, un compteur qui augmentait au lieu de décompter. Ma première hypothèse était fausse, le délai stocké en base était bon. La deuxième aussi, l'horodatage de la tentative n'y était pour rien. La troisième aussi, ce n'était pas un souci de clés JSON. La vraie cause : Carbon 3, la librairie de dates de Laravel, a inversé le sens de diffInSeconds entre deux versions majeures, sans que ça saute aux yeux dans le changelog. Le calcul de temps écoulé se retrouvait négatif, et le compteur gonflait au lieu de décompter à chaque rafraîchissement. Trois fausses pistes avant la bonne, chacune consignée noir sur blanc dans le plan de correction pour ne pas retomber dedans ailleurs dans le code. C'est ça, travailler avec l'IA sur un vrai projet : pas une baguette magique, un collaborateur qui se trompe, qu'on corrige, et qui garde une trace écrite de l'erreur pour la prochaine fois plutôt que de l'oublier le lendemain.
Autre moment révélateur, côté revue d'architecture cette fois. Avant d'implémenter un récapitulatif de fin de partie affichant le nombre de tentatives par session, la revue a détecté que ce compteur n'était incrémenté que pour les énigmes de type question-réponse. Pour les énigmes de géolocalisation, il restait bloqué à zéro, un chiffre faux qui serait passé en prod sans que personne ne le remarque avant les premiers retours joueurs. Repéré en croisant deux fichiers du modèle métier que personne n'aurait pensé à relire ensemble un vendredi sous pression, avant d'avoir écrit la moindre ligne de la fonctionnalité elle-même.
Et un troisième, plus subtil, sur la validation géolocalisée : un joueur qui doit rester dans une zone cinq secondes pour valider une énigme peut forger un faux événement côté client et se téléporter n'importe où. La revue de code a vérifié qu'il existait bien une double validation côté serveur, pas seulement une confiance aveugle dans les coordonnées envoyées par le navigateur. Ce genre de trou de sécurité, personne n'y pense en codant vite un vendredi soir. Une checklist qui le vérifie systématiquement, si.
Le morceau dont je suis le plus fier
Composer un parcours pertinent demande de connaître le patrimoine local, impossible à faire à la main sur des centaines de milliers de lieux. J'ai indexé 277 000 points d'intérêt, les données ouvertes DATAtourisme et la base Mérimée des monuments historiques, dans une base vectorielle Qdrant interrogeable en langage naturel directement depuis Claude Code. Je demande « monuments médiévaux près de la place Saint-Sauveur à Caen », je récupère des lieux réels avec leurs coordonnées GPS et leur historique, prêts à devenir une énigme. Plus besoin de dépouiller des dizaines de milliers de lignes de CSV à la main pour trouver un point de passage crédible.
Et pour boucler la boucle, un mode créateur permet de constituer une base d'idées d'énigmes géolocalisées, chacune avec sa position GPS précise. L'IA pioche ensuite dedans par proximité géographique pour composer ou enrichir un parcours cohérent, sans jamais rattacher une idée à un jeu en particulier tant qu'elle n'a pas été choisie. Ce n'est plus juste l'IA qui écrit du code : c'est l'IA qui fait la recherche documentaire et aide à structurer le contenu du jeu lui-même.
Premier parcours publié
À Ouistreham, un parcours retrace le débarquement à travers dix-sept étapes, du monument aux victimes jusqu'au mémorial Kieffer, chacune avec une photo prise sur place et un vrai travail de recherche historique derrière. Exactement ce que je voulais faire il y a dix ans sans savoir encore comment : donner une raison ludique de s'arrêter devant une plaque commémorative qu'on aurait autrement croisée sans la voir.
Laravel x Livewire x PostgreSQL x Coolify x Qdrant
Techniquement, rien d'exotique, et c'est un choix assumé. Laravel et Livewire pour aller vite sans sacrifier la robustesse, PostgreSQL, le tout hébergé sur mon propre serveur via Coolify plutôt que sur l'infrastructure d'un hyperscaler. Après des années à concevoir des architectures pour des clients qui doivent scaler à des millions d'utilisateurs, ça fait du bien de choisir la stack la plus simple possible pour un projet qui doit d'abord exister avant d'avoir besoin de scaler quoi que ce soit. Et niveau qualité, ça n'a rien d'un prototype jetable : la couverture de tests avoisine les cent pour cent sur le cœur du gameplay, feature après feature.
Du cadrage
Ce qui a changé entre l'idée d'il y a dix ans et sa réalisation aujourd'hui, ce n'est pas la difficulté technique du projet, c'était déjà faisable il y a dix ans. Ce qui a changé, c'est que ce qui aurait pris six mois de nuits et de week-ends a tenu sur deux jours, sans rogner sur la rigueur : chaque brique a eu son cadrage, son plan, sa revue d'archi, sa relecture, ses bugs trouvés avant plutôt qu'après. Le genre de discipline qu'on s'impose en équipe, condensée en solo sur un temps qui n'existait tout simplement pas avant.
What's next ?
La suite, c'est étendre les parcours à d'autres villes, ouvrir la création à plus de monde, et voir Cluengo devenir ce que j'espérais en avoir l'idée : une manière différente de découvrir l'endroit où on vit, ou celui où on est juste de passage pour un week-end.
Si vous connaissez un office de tourisme, une ville, une association qui aimerait avoir son propre parcours, ou si vous voulez juste tester le premier, je suis preneur de retours.