Je construis des logiciels prêts pour la production en solo, en utilisant VS Code et un développement assisté par IA (Claude Code) comme partie centrale de mon flux de travail — non pas pour passer de côté la compréhension du code, mais pour avancer plus vite dans un processus discipliné et itératif : échafaudage, implémentation, test, débogage, répétition.

**Comment je travaille**
- **Étape par étape, pas en one-shot.** Je divise les projets en phases (Phase 0, Phase 1, Phase 2...) avec un champ d’application clair par phase, plutôt que de demander une application terminée d’un coup.
- **Dépannage piloté par les tests.** Je lance en fait et je clique sur ce qui est construit — en déployant tôt et souvent dans de vrais environnements (Netlify, Supabase) — plutôt que de faire confiance au code en théorie. Quand quelque chose tombe en panne, je le remonte à la cause principale au lieu de patcher les symptômes (par exemple, démêler cinq bugs interconnectés à travers l’environnement dans le lining, les conditions de course, l’analyse des jetons, le middleware et la gestion des cookies dans un seul flux d’authentification).
- **Décisions axées sur l’architecture.** Avant une mise en œuvre intensive, je fixe des choix structurels clés — stratégie de routage, modèle d’authentification, code unique vs. multi-locataire, fourchettes tarifaires — pour que les phases ultérieures reposent sur des bases solides au lieu d’être reconstruites.
- **Pile cohérente et opiniâtre.** JS vanilla + IndexedDB + Service Workers pour les PWA hors ligne (POS, Pet Shop). Next.js 14 + Supabase + Netlify pour les plateformes SaaS multi-locataires (Parish CMS). Je réutilise une architecture éprouvée à travers les projets plutôt que de la réinventer à chaque fois.
- **Développement conscient de l’entreprise.** Je ne me contente pas de livrer des fonctionnalités — je les valide par rapport à un réel ajustement du marché (échelons tarifaires Philippines/SEA, analyse de faisabilité, stratégie de licence) avant de mettre à l’échelle la portée de l’application.

**Ce que j’ai construit**
- **CMS paroissial** — SaaS multi-locataire pour paroisses catholiques (14 Next.js, Supabase, sous-domaine + routage de domaine personnalisé, authentification administrative avec bcrypt + cookies signés)
- **POS System** — PWA de point de vente hors ligne avec RBAC, suivi des sessions/déplacements, inventaire et rapports, désormais dans le cadre de la synchronisation et des licences cloud
- **Pet Shop PWA** — application de gestion des rendez-vous et des dossiers qui étend l’architecture POS
- **Concept de plateforme VA** — exploration d’un modèle de service d’assistant virtuel géré/sélectionné comme ligne métier distincte

Je suis un développeur solo qui propose de vrais produits testés et déployés — pas des démonstrations — en associant la discipline pratique de la QA à une implémentation accélérée par l’IA.
Il y a une inquiétude commune avec le développement assisté par l’IA : le « vibe coding » signifie livrer d’abord ce que l’IA génère, sans test, en espérant que cela tienne. Ce n’est pas comme ça que je fonctionne. J’utilise l’IA (Claude Code) comme un entrepreneur qualifié utilise les outils électriques — cela accélère la construction, mais c’est toujours moi qui vérifie le câblage, teste la charge et déconnecte avant que quelqu’un n’arrive. Chaque long-métrage suit la même discipline, peu importe la façon dont il a été écrit :

Rien n’est livré sans test – Chaque phase est déployée dans un environnement réel et réellement utilisée — cliquée, connectée, testée sous stress — avant que je ne la déclare terminée. Le flux d’auth de mon système POS, par exemple, passait par un débogage réel sur cinq points de défaillance interconnectés (configuration de l’environnement, conditions de course, gestion des jetons, middleware, état des cookies) jusqu’à ce qu’il soit infaillible, et non seulement « ça a l’air correct ».

Les décisions d’architecture m’appartiennent, pas celles de l’IA – avant qu’un code ne soit écrit, je décide de la stratégie de routage, du modèle de données, de l’approche d’authentification et de la structure de location. L’IA met en œuvre un plan que j’ai déjà validé — elle ne fixe pas la direction.

Je comprends chaque système que j’expédie – si quelque chose tombe en panne en production, je peux le retracer, l’expliquer et le réparer — parce que je l’ai construit étape par phase et vérifié chaque couche, plutôt que d’accepter une boîte noire.

La cohérence plutôt que la nouveauté – je réutilise une architecture éprouvée et éprouvée (le même pattern PWA hors ligne entre POS et Pet Shop, la même base Next.js/Supabase sur les projets SaaS) au lieu de laisser l’IA improviser une nouvelle stack à chaque fois. Des fonds de teint familiers signifient moins de surprises pour les clients.

L’IA est un multiplicateur de vitesse, pas un raccourci – elle me permet de livrer des logiciels de production en plusieurs phases en tant que développeur solo, à un rythme qui nécessiterait normalement une petite équipe — sans réduire les étapes de contrôle qualité et d’architecture qui rendent le logiciel fiable.