Construire GritGateway de l'idée au MVP en 3 mois

Edouard m'a contacté en novembre 2025 avec un concept, pas une spécification. Il avait une vision claire du problème qu'il voulait résoudre et un modèle mental approximatif de l'utilisateur, mais aucune fondation technique, aucune décision de stack, et personne pour lui dire si ses hypothèses survivraient au contact avec une vraie infrastructure. C'est exactement le moment où je trouve le plus intéressant d'entrer dans un projet. Le brief était simple : construire GritGateway de zéro, atteindre un MVP fonctionnel, et ne pas gaspiller les six premiers mois sur des choses qui n'importent pas.

La première chose que nous avons faite, ce n'était pas écrire du code

Avant qu'aucun repository n'existe, nous avons passé trois semaines dans ce que j'appelle un sprint de découverte. J'ai demandé à Edouard de me décrire à haute voix le parcours utilisateur qu'il imaginait, étape par étape. J'ai pris des notes et j'ai remis en question chaque hypothèse qui nécessiterait une décision technique non triviale plus tard. Quelles données la plateforme possède-t-elle ? Qu'est-ce qu'elle lit à partir de sources externes ? Où l'argent circule-t-il, le cas échéant ? Que se passe-t-il quand un utilisateur revient après trente jours d'inactivité ?

Ce n'est pas une formalité. Chaque heure passée ici a économisé environ quatre heures de refonte plus tard. À la fin de ces trois semaines, j'avais une image suffisamment claire pour prendre le premier vrai appel architectural : le produit avait besoin d'une séparation nette entre sa couche publique et son modèle de données central, car les deux évolueraient à des vitesses très différentes. Cette décision a façonné chaque sprint qui a suivi.

Comment j'ai structuré l'architecture technique

J'ai choisi une approche full-stack moderne avec une limite d'API claire. Le frontend est une application basée sur React avec un accent fort sur la cohérence des composants, car une UI fragmentée au stade du MVP se transforme très rapidement en problème de maintenance. Le backend expose une couche API typée, ce qui signifie que l'équipe d'Edouard peut étendre le produit sans avoir besoin de rétro-ingénierie mes intentions. J'ai documenté le modèle de données avant d'écrire une seule migration, pas après.

Pour le workflow de développement lui-même, j'ai intégré des outils natifs à l'IA dès le départ. Fin 2025, utiliser des outils comme Cursor aux côtés de Claude pour la génération et l'examen de code était devenu un vrai multiplicateur de productivité, pas une nouveauté. Les praticiens du secteur signalaient des réductions de plus de 30 % dans les délais de scaffolding et d'intégration, et mon expérience sur GritGateway a confirmé cette fourchette. Le boilerplate qui aurait pris une journée en a pris une matinée. Ce temps a été consacré aux parties qui nécessitaient vraiment du jugement, le flux d'authentification, les modèles d'accès aux données, les cas limites du cycle de vie utilisateur.

L'authentification et la gestion des sessions ont reçu plus d'attention qu'elles ne le font habituellement au stade du MVP. C'est un choix délibéré. Rétrofiter un modèle d'authentification sécurisé sur un produit qui a déjà des utilisateurs est douloureux et risqué. Le faire correctement dès le départ ne coûte presque rien en comparaison.

Où se situait le vrai point de friction

La partie la plus difficile de cet engagement n'était pas technique. C'était l'écart entre ce qu'Edouard voulait que le produit soit et ce que le MVP devait être. Il avait de vrais instincts produit, ce qui est un atout, mais ces instincts généraient constamment du scope. Mon travail, autant que de construire la chose, était de tenir la ligne sur ce qui entre dans la version un.

Nous avons eu un désaccord spécifique sur une fonctionnalité qui aurait nécessité une intégration tierce avec des implications de conformité significatives. J'ai recommandé de la reporter. Edouard a poussé des objections, à juste titre, car il la voyait comme centrale à la proposition de valeur. Nous l'avons résolu en construisant un placeholder léger qui signale la fonctionnalité aux utilisateurs sans activer l'intégration. Ce placeholder est devenu un signal utile : il nous a dit, avant que nous construisions quelque chose de coûteux, combien d'utilisateurs se souciaient vraiment de cette fonctionnalité. La réponse a informé la roadmap.

C'est le genre d'appel qui n'apparaît pas dans une spécification technique. Il se situe à l'intersection de la réflexion produit et du jugement d'ingénierie, et c'est l'une des raisons pour lesquelles je considère ce travail comme plus proche d'un engagement de CTO fractionnaire qu'un pur contrat de construction.

Ce que le MVP a réellement livré

Mi-2026, GritGateway était en ligne sur gritgateway.com. Le produit livré incluait :

• —L'authentification utilisateur et la gestion de profil, construites pour être extensibles
• —Le flux de plateforme central qu'Edouard avait décrit en novembre, maintenant validé auprès d'utilisateurs réels
• —Une couche admin qui permet à l'équipe de gérer le contenu et les données utilisateur sans toucher au codebase
• —Une structure de composants qui rend l'ajout de nouveaux écrans rapide et cohérent
• —L'instrumentation, afin que l'équipe puisse voir ce que les utilisateurs font réellement, pas ce qu'ils disent faire

Rien sur cette liste n'est glamour. Tout est nécessaire. Un MVP qui se lance sans instrumentation est un MVP qui ne peut pas apprendre.

Ce que j'ai appris de cet engagement

Construire un produit pour un fondateur profondément investi dans l'idée est différent de construire des outils internes pour un client d'entreprise. Les enjeux émotionnels sont plus élevés. Les boucles de feedback sont plus serrées. Et l'énergie du fondateur, quand elle est canalisée correctement, est un vrai atout pour la construction.

La volonté d'Edouard d'engager sérieusement avec le raisonnement architectural, plutôt que simplement d'examiner des écrans, a rendu le produit meilleur. Nous avons été en désaccord sur le scope plusieurs fois. Nous l'avons toujours résolu avec des preuves ou de la logique, pas de la séniorité. C'est la dynamique que j'essaie d'établir dès le début de chaque engagement.

J'ai construit dans des contextes très différents, de la plateforme de gestion de quarts Workbud à la plateforme de services financiers qui nécessitait des normes de sécurité strictes, et le modèle qui tient dans tous les cas est celui-ci : les décisions techniques qui importent le plus sont prises dans les trois premières semaines, quand la plupart des gens écrivent encore des decks. Bien prendre ces décisions est ce qui rend le reste de la construction traitable.

Si vous êtes au stade où Edouard était en novembre 2025, la chose la plus utile que vous puissiez faire maintenant est d'avoir une conversation directe sur vos hypothèses avant qu'elles ne deviennent votre architecture. Commencez cette conversation ici.