Kinésithérapeute le jour, développeur le soir : comment j'ai créé PoupiEats
Le dev dans les veines
Je n'ai pas commencé à coder en 2022. En réalité, ça fait bien plus longtemps.
Comme beaucoup de curieux, j'ai touché au HTML et au PHP sur des projets perso il y a des années. Des sites web bricolés, des petites idées testées le soir depuis le lycée. Le développement, je l'avais déjà dans les veines. Mais je partais dans tous les sens — un bout de PHP par-ci, un framework JavaScript par-là, sans jamais aller au bout.
Un jour, j'ai pris une décision : me concentrer sur une seule chose. Un seul langage. Une seule stack. J'ai choisi Python et Django. Pourquoi ? Parce que c'est lisible, puissant, et que la communauté est immense. Et parce que je savais déjà ce que je voulais construire avec. C'était donc la meilleure solution accessible, avec une courbe d'apprentissage rapide.
4 ans de Django — et une première version ratée
Ma première version de PoupiEats date de 2022. Elle n'est jamais sortie. Et c'est tant mieux.
Elle n'était pas fonctionnelle, pas utilisable, et surtout elle ne répondait pas vraiment au besoin. J'avais codé avant de réfléchir. Erreur classique. En plus, j'avais l'impression d'avoir un outil qui datait des premières années d'internet. Pas terrible.
Mais chaque projet raté m'a appris quelque chose. Après PoupiEats v1, j'ai créé d'autres outils — pour mon cabinet de kiné cette fois :
- Une liste d'attente automatisée — les patients s'inscrivent, le système gère les priorités, les notifications partent toutes seules
- Retrolib — un outil de gestion des rétrocessions pour les remplaçants, avec calcul automatique et suivi des paiements
- D'autres petits projets, chacun me faisant progresser sur Django, les bases de données, le déploiement et une méthodologie de l'idée à la solution.
Chaque projet était un pas de plus vers PoupiEats. J'attendais le moment d'avoir toutes les armes pour combler mes objectifs.
Des centaines de vidéos et un second cerveau
YouTube a été mon université gratuite. J'ai regardé des centaines et des centaines de vidéos — sur Django, Python, Docker, le déploiement, les API, le design de bases de données, la sécurité. Des tutoriels de 10 minutes comme des formations de 4 heures. Je suis tombé sur des pépites qui m'ont permis de progresser vite et bien. Pas toujours facile à trouver parmi les millions de vidéos.
Mais, le problème, c'est que regarder des vidéos ne sert à rien si on ne retient rien. Et ça c'est un grand problème pour moi, une vraie mémoire de poisson rouge. J'ai vite compris qu'il fallait structurer tout ce que j'apprenais. C'est là que Jarvis est né — mon "second cerveau".
Jarvis, c'est un serveur Mac M4 chez moi qui centralise tout : mes notes, mes références techniques, mes idées de fonctionnalités, ma roadmap, mes contacts, mes projets, mes todo list. Chaque vidéo intéressante, chaque article, chaque solution à un problème technique — tout atterrit dans Jarvis.
Collecter des informations, c'est facile. Les organiser pour les retrouver au bon moment, c'est ce qui fait la différence entre quelqu'un qui apprend et quelqu'un qui avance. Et j'ai maintenant ce qu'il me faut pour ne plus partir dans tous les sens.
Kiné et développeur : même logique
Ce que peu de gens réalisent, c'est que la kinésithérapie et le développement web suivent exactement la même logique :
- Diagnostic → Identifier le problème (douleur du patient / besoin de l'utilisateur)
- Plan de traitement → Concevoir la solution (protocole de soins / architecture technique)
- Traitement → Implémenter (séances / code)
- Suivi → Itérer avec les retours (le patient revient, on ajuste / l'utilisateur teste, on corrige)
En kiné, je ne propose jamais un traitement sans comprendre d'abord ce qui fait mal. En développement, je ne code jamais une fonctionnalité sans comprendre d'abord pourquoi elle est nécessaire.
Cette approche m'a évité beaucoup d'erreurs et m'a permis de prioriser les fonctionnalités à mettre en place. Quand on est développeur ET utilisateur du problème qu'on résout, on ne perd pas de temps sur des fonctionnalités inutiles.
L'IA aide, mais ne remplace pas le travail en amont
Oui, j'utilise l'intelligence artificielle. Claude Code m'accompagne au quotidien et me permet d'aller beaucoup plus vite sur le code.
Mais — et c'est important — l'IA ne fait pas le travail en amont. La réflexion fonctionnelle, c'est moi. La structure de la base de données, c'est moi. La roadmap, les personas, l'étude de marché, le business plan, les choix d'UX, la prospection terrain — tout ça, c'est des heures de réflexion humaine que l'IA ne peut pas remplacer.
L'IA accélère le code. Elle ne remplace pas la vision et la bonne conception.
Un développeur qui utilise l'IA sans comprendre ce qu'il construit, c'est comme un kiné qui effectuerait un traitement sans avoir examiné son patient. Ça ne marche pas.
Février 2026 : cette fois c'est la bonne
Pourquoi cette version est différente des précédentes ?
Parce que cette fois, j'ai fait le travail en amont. Étude de marché. Personas. Business plan. Roadmap structurée. Et surtout : des retours terrain dès le premier jour.
J'ai contacté des restaurateurs avant même que l'application soit finie. J'ai écouté leurs problèmes. J'ai compris que le tableau d'allergènes n'était pas un sujet technique pour eux — c'était un sujet de temps, de peur juridique et de complexité ressentie.
Aujourd'hui, PoupiEats est en bêta, fonctionnel, utilisé par plusieurs établissements. J'ai commencé à construire une carte publique des allergènes — établissement par établissement, en parcourant les sites internet, en contactant les restaurants un par un. C'est long, mais chaque point sur la carte rapproche une famille allergique d'un repas serein. Pour cette mission, toutes les bonnes volontés sont bonnes à prendre.
Construire soi-même, c'est tout comprendre
Je n'ai pas de CTO. Pas de prestataire. Pas d'équipe technique. C'est moi qui code, qui déploie, qui corrige les bugs à 23h, qui répond aux emails à 7h et entre les patients.
Le prix : des nuits courtes et un agenda de kiné le matin suivi d'un agenda de développeur le soir.
La récompense : un outil qui colle exactement au besoin. Chaque décision technique est prise par quelqu'un qui vit le problème au quotidien — quelqu'un qui a vu sa fille pleurer devant un buffet de petit-déjeuner parce que le tableau d'allergènes était faux.
Aucun cahier des charges n'aurait pu exprimer ça.
Pour aller plus loin :