De l'idée jusqu'à la production.

Mon rôle : tout : vision produit, modélisation du domaine métier, architecture, développement full stack, sécurité et déploiement.

Parti pris d'architecture : le domaine métier reste indépendant des bibliothèques. Auth0, Stripe ou MongoDB doivent pouvoir être remplacés sans toucher aux règles métier.

Défis techniques : garder la création d'une résolution assez simple pour qu'un commerçant la termine, sans jamais sacrifier la crédibilité qui fait la valeur de la plateforme. Les résolutions contenant des captures d'écran passent par une modération avant publication, et l'authentification Auth0 à double facteur distingue quatre rôles : visiteur, utilisateur, commerce et administrateur.

État : en production et utilisé, sur prouvex.com. Gratuit et sans engagement.

Mon rôle : conception et développement de bout en bout : électronique, code embarqué, backend, application Angular et gestion des comptes.

Défis techniques : transmettre chaque but sans latence perceptible et garder table, serveur et spectateurs parfaitement synchronisés.

Genèse : tout est parti de la V1, un prototype à deux Arduino, matrices LED 8×8 et capteurs infrarouges. Voir la vidéo.

État : en production, neurokicker.com.

Mon rôle : conception produit et développement complet : application Flutter, modèle de données, Security Rules, Cloud Functions de paiement et facturation des commissions.

Parti pris d'architecture : les Security Rules Firestore sont la seule couche d'autorisation, et le code serveur est strictement borné au paiement. Le critère d'admission est explicite : impossible sans serveur, jamais seulement plus pratique. Une clé secrète Stripe ne peut pas vivre dans un APK — c'est l'unique raison pour laquelle des Cloud Functions existent ici.

Défis techniques : les charges « destination » de Stripe Connect font du vendeur le commerçant de la transaction, ce qui garde la plateforme dans son rôle d'intermédiaire et hors du statut d'établissement de paiement. Le webhook, lui, doit rester juste quand les évènements arrivent dans le désordre ou qu'une annonce disparaît entre la carte et la confirmation : un échec périmé ne doit jamais écraser un paiement encaissé.

État : bêta. Le parcours complet a été vérifié sur téléphone, de la publication de l'annonce jusqu'au paiement par carte encaissé en mode test, commission prélevée à la source.

Mon rôle : tout : conception produit, application Flutter, modèle de données, Security Rules, intégration continue et publication sur Google Play.

Parti pris d'architecture : aucune base locale ajoutée par-dessus Firestore. Sa persistance hors ligne garde déjà sur le téléphone les cartes et la file des écritures pas encore confirmées ; une seconde base aurait créé deux sources de vérité à réconcilier, exactement le genre de mécanisme qui fait perdre des cartes. Pas de backend non plus : les Security Rules sont la seule frontière d'autorisation.

Défis techniques : une écriture faite hors ligne n'est confrontée aux Security Rules qu'au moment où elle est rejouée, parfois des heures plus tard ; si une règle la refuse alors, la carte disparaît sans erreur visible. Les règles ne vérifient donc que des faits stables, le propriétaire et le type des champs, et un test garantit qu'une carte créée il y a longtemps passe encore. À l'écran caisse, le code est dessiné en vectoriel : un bitmap agrandi donne des barres floues que les lecteurs laser refusent.

État : bêta, en test fermé sur Google Play ; l'application n'est pas encore ouverte au public. Gratuite jusqu'à douze cartes, financée par un bandeau publicitaire — jamais à l'écran caisse, où le pouce se trouve juste là — et par une option payante qui lève la limite. La sauvegarde et le mode hors ligne restent gratuits, quoi qu'il arrive.

Mon rôle : tout : conception produit, architecture, développement full stack Angular et Node.js, intégration des paiements et sécurité.

Parti pris d'architecture : le formateur est le vendeur. Avec Stripe Connect, chaque place est vendue pour son compte et la plateforme ne perçoit que sa commission, au lieu de faire transiter le prix entier par son propre chiffre d'affaires.

Défis techniques : le lien de réunion ne quitte jamais le serveur avec la conférence : il n'est servi qu'aux inscrits, de quinze minutes avant le début à quatre heures après. Le montant est toujours calculé par l'API, coupon compris, et c'est le webhook Stripe, signé et idempotent, qui fait foi du paiement. Une place est prise dès l'ouverture du paiement et rendue par un seul chemin, pour que la jauge ne dérive jamais.

État : bêta, pas encore en ligne. Le produit est complet et le parcours d'achat a été mené de bout en bout contre Stripe en mode test ; restent le déploiement sur son nom de domaine et le passage de Stripe en mode réel.

Mon rôle : tout : cadrage, application Flutter pour Android, modèle de données, Security Rules et Cloud Functions.

Parti pris d'architecture : l'IA rédige des gabarits, jamais des messages. Une Cloud Function demande à l'API Anthropic un modèle de texte par ton, sans aucune donnée personnelle ; le prénom, le jour et l'heure ne sont insérés qu'ensuite. Une réponse qui contient autre chose que ces trois champs, ou qui dépasse la longueur d'un SMS, est refusée, et l'application retombe sur des gabarits écrits à la main.

Défis techniques : les personnes à protéger ne sont pas l'utilisateur de l'application mais ses clients, et un rendez-vous chez un logopède est une donnée de santé par déduction. D'où des durées de conservation courtes, appliquées par une purge nocturne, un export et une suppression complète des données, et un numéro qui a demandé à ne plus être contacté conservé sous forme d'empreinte, jamais en clair.

État : prototype. Le MVP est complet et couvert par 254 tests automatisés, mais il n'a pas encore été installé sur un téléphone : le premier essai en conditions réelles reste à faire.

Mon rôle : conception produit et développement complet : application mobile Flutter et backend Firebase Cloud Functions.

Défis techniques : orchestrer un dialogue IA cohérent avec Gemini et transformer une conversation libre en recommandation structurée et exploitable.

État : archivé. Le développement a été arrêté avant publication ; la monétisation prévue reposait sur Google AdMob.

Mon rôle : conception et développement complets : interface, backend et modélisation de la base de données.

Défis techniques : modéliser une base adaptée au suivi pédagogique et sécuriser distinctement les accès professeurs et étudiants.

État : archivé. La plateforme n'est plus accessible en ligne.

Mon rôle : conception électronique, développement du code embarqué et coordination avec l'imprimeur 3D pour le boîtier sur mesure.

État : produit finalisé, projet archivé.