Planning Poker : de l’idée au déploiement en neuf heures

Le besoin

Le point de départ était concret : proposer à mon équipe de développeurs un outil de chiffrage simple, adapté à nos sessions de Planning Poker. L’objectif n’était pas de construire une plateforme complète de gestion de projet, mais de disposer rapidement d’un espace commun dans lequel chaque participant peut estimer une tâche et découvrir les votes du groupe.

Cette expérimentation devait donc répondre à trois priorités : être utilisable sans préparation particulière, synchroniser les participants en temps réel et rester suffisamment légère pour être déployée et maintenue facilement.

De l’idée au design en trois heures

La première phase a consisté à transformer l’idée en une expérience cohérente. Le design a été produit avec Claude Design, puis relu et ajusté par mes soins. Trois heures ont suffi pour passer du besoin initial à une interface prête à être implémentée.

Cette étape rapide n’a pas supprimé la conception humaine. J’ai défini le besoin, arbitré les choix proposés et vérifié que le parcours correspondait bien à la manière dont mon équipe mène ses estimations. L’IA a accéléré la production ; la direction du projet et la validation sont restées de ma responsabilité.

Une implémentation temps réel volontairement simple

L’application a ensuite été développée avec Claude Code, toujours sous ma conception et ma vérification. La stack repose sur TypeScript exécuté avec Bun. Les échanges en temps réel utilisent des WebSocket, tandis que les sessions sont conservées en mémoire.

Ce choix rend le prototype particulièrement léger : il n’a besoin ni d’une base de données ni d’un service de stockage supplémentaire. Une session existe tant que l’instance qui l’héberge reste active. Cette simplicité convient à l’usage actuel, mais elle implique aussi une limite assumée : un redémarrage du service efface les sessions en cours et plusieurs instances ne pourraient pas partager leur état sans ajouter un stockage commun.

Une fois le design terminé, l’implémentation et les correctifs ont demandé six heures supplémentaires. Le délai total entre l’idée et une version déployée s’élève donc à neuf heures.

Du prototype au service déployé

Le projet est empaqueté dans une image Docker basée sur Bun. En production, l’application est placée derrière Caddy, qui sert de point d’entrée et prend en charge le HTTPS.

Cette architecture reste en accord avec l’objectif de l’expérimentation : peu de composants, un déploiement reproductible et une exposition sécurisée du service. Elle permet de mettre l’outil à disposition de l’équipe sans transformer un besoin ciblé en chantier d’infrastructure.

Planning Poker est accessible à l’adresse planning-poker.paretolabs.fr.

Ce que l’expérimentation valide

Cette réalisation montre qu’un outil interne ciblé peut passer de l’idée à un service opérationnel en une journée de travail lorsque le périmètre est clairement tenu. Claude Design et Claude Code ont réduit le temps nécessaire pour produire le design et le code, mais leur efficacité a reposé sur un cadre précis, des arbitrages réguliers et une vérification humaine du résultat.

Le principal compromis concerne les sessions en mémoire. Elles évitent toute complexité inutile pour cette première version, au prix de l’absence de persistance et de la difficulté à répartir l’application sur plusieurs instances. Si l’usage de l’outil grandit, l’ajout d’un stockage partagé constituera une évolution naturelle. Pour le besoin initial — chiffrer des tâches en équipe — cette architecture reste volontairement proportionnée.

Conclusion

En neuf heures, l’expérimentation a abouti à un Planning Poker temps réel, conteneurisé et accessible en HTTPS. Au-delà du gain de vitesse apporté par les outils d’IA, le résultat tient surtout à une boucle courte : formuler un besoin précis, produire rapidement, vérifier chaque choix et corriger immédiatement.

Cette approche ne cherche pas à anticiper tous les usages futurs. Elle fournit d’abord à l’équipe l’outil dont elle a besoin aujourd’hui, tout en rendant explicites les limites à traiter si le projet doit évoluer.