1. Introduction
Chez Lonestone, on est une trentaine à se partager trois salles de réunion. Parfois réservées via nos agendas, souvent attribuées au premier arrivé. Pas idéal en temps normal, encore moins depuis qu'une dizaine de colocataires ont rejoint nos bureaux. Il nous fallait un outil simple, partagé et accessible à tous. Plutôt que d'attendre qu'une solution tombe du ciel, j'ai décidé de la construire moi-même, sans savoir coder.
Comment pourrions-nous offrir à une trentaine de personnes un système de réservation de salles simple et partagé, sans passer par un outil tiers surdimensionné ?
Conception produit de l'outil de réservation.
Prototypage et développement assisté par IA, sans compétences dev préalables.
Co-réalisé avec Vincent Ghislain — itérations, corrections et mise en production sur Render.
2. Définition du problème
Les outils de réservation de salles existent, mais ils sont soit trop lourds à déployer, soit trop génériques pour s'adapter à la réalité d'un espace de coworking partagé entre équipes. Dans un environnement à taille humaine, ce qu'il faut c'est un outil que tout le monde comprend en dix secondes, accessible sans friction et suffisamment flexible pour évoluer.
Un problème quotidien, une solution inexistante
Le « premier arrivé, premier servi » fonctionne jusqu'au jour où ça ne fonctionne plus. L'arrivée de nouveaux colocataires a rendu le problème visible et urgent.
Des outils tiers surdimensionnés
Les solutions du marché supposent une infrastructure, une administration et un onboarding que personne n'a le temps de gérer dans une structure comme Lonestone.
Une maquette comme point de départ
Plutôt que de spécifier un besoin dans l'abstrait, j'ai choisi de matérialiser l'intention en une heure avec un écran unique. Pas de wireframes, pas de règles métier, juste une vision de ce que ça pourrait être.
3. Conception de la solution
En une heure, j'ai produit un écran unique pour donner une forme concrète à l'intention. Pas de parcours formalisé ni de spécifications fonctionnelles, juste assez pour communiquer l'idée et démarrer une conversation avec l'IA. Le soir venu, j'ai partagé la maquette à mon LLM préféré en lui exposant mes contraintes et mon intention. L'échange a produit un plan d'action clair pour attaquer le développement.
Je ne sais pas coder. Deux à trois heures plus tard, Rooomies tournait en local, ressemblait à la maquette et les règles fonctionnelles de base étaient en place : réservation d'une salle, annulation, consultation de l'historique. Le code n'est pas parfait et difficilement scalable, mais il est suffisant. J'avais également prévu un back-office pour gérer les utilisateurs et les salles, pensant déjà aux évolutions possibles.
Vincent Ghislain m'a rejoint sur le projet deux jours plus tard. Ensemble, nous avons amélioré l'interface, implémenté la récurrence des réunions, corrigé des bugs sur la persistance des avatars et sécurisé le back-office. Vincent a également géré la mise en production sur Render. C'était mon premier commit. Les émotions.
4. Résultats et apprentissages
Cette expérimentation a duré quelques semaines et a permis à l'équipe Lonestone et à nos colocataires de réserver une salle, annuler une réservation et consulter l'historique, sans formation, sans documentation, sans friction.
Ce projet m'a appris quelque chose que des années de design ne m'avaient pas encore donné : la satisfaction de livrer quelque chose de bout en bout, de la première maquette à la mise en production. Pas de client à convaincre, pas de brief à interpréter, juste un problème réel et l'envie de le résoudre.
Il m'a aussi confirmé que la maquette reste le meilleur langage pour communiquer une intention, y compris avec une IA. Donner à voir avant de décrire, ça marche aussi avec les LLM.