Épisode 2 : Le mur de la réalité

Une fois les présentations faites et les premiers retours positifs reçus, on se dit : “Ça y est, on tient la fameuse idée” !

Puis arrive rapidement une question toute simple : mais comment on fait ça maintenant ?

Marty étant mon premier projet entrepreneurial, je me suis pris un sacré mur à ce moment-là. Pour passer d’un beau catalogue d’idées ambitieuses à une société qui fonctionne, il y a un gap énorme.

C’est valable sur l’ensemble des activités : développement commercial, marketing, SEO, technique…

Dans cet article, on se focalise sur ce dernier point, le volet produit/tech !

Comment transformer un paquet d’idées en SaaS ?

En tant que fondateur technique, on se rend vite compte de ses propres limites lors de cette phase.

Mais une réalité simple nous oblige à les dépasser : si on n’y arrive pas, ça ne sera pas fait… et ça peut faire capoter tout le projet.

Cet article est un retour d’expérience sur cette phase cruciale et ce rôle complexe.

Du produit rêvé au produit faisable

Le projet a débuté par une erreur classique !

Sur les slides, Marty répondait à toutes les problématiques du secteur : mise en relation, visibilité, administratif, gain de temps… pour du B2B et du B2C.

J’ai compris à ce moment-là qu’en pratique ça serait impossible à construire en quelques mois seul.

Il a donc fallu se demander qu’est-ce qui est vraiment essentiel ? … et qu’est-ce qui est faisable ?

Pour Marty, la demande identifiée était claire :

Donner de la visibilité de qualité aux artisans

Une phrase simple qui implique beaucoup de sujets techniques !

Si comme moi vous n’aviez jamais bossé dans une société lors du fameux “0 to 1”, il faut TOUT mettre en place :

• ✅ Interfaces
• ✅ Système d’authentification
• ✅ Stockage des données (applicatives, sécurité, images, …)
• ✅ Systèmes d’IA
• ✅ Paiement
• ✅ Mise en relation
• ✅ Tracking
• ✅ Infra
• ✅ Blog pour le SEO
• ✅ Schéma des tables
• ✅ …

👉 Point clé : L’ensemble de ces tâches sont classiques en software, vous y arriverez très bien ! Attention toutefois à bien les avoir en tête dans votre idée du produit faisable.

L’objectif : Livrer un MVP en 2-3 mois pour avoir de réels retours ASAP.

Le choix de la stack et des fondations

Une situation classique dans la Tech est de “faire rapidement un prototype pour répondre au business” en se disant qu’il sera refait plus tard.

L’ayant vécu plusieurs fois, je gardais en tête qu’une fois livré, un produit est considéré comme fonctionnel, même si on a clairement exprimé qu’il devrait être retravaillé !

C’est un équilibre que chaque Tech connaît :

• Aller vite → Car un produit n’a de valeur que s’il est utilisé
• Poser des bases solides → Maintenables et évolutives par 1 seule personne dans le cadre de Marty

Une autre responsabilité du fondateur technique est le choix de l’architecture et des outils. Ce choix impactera le produit pendant des années (capacités, performances, dette technique, recrutement, …).

Dans le cadre de Marty j’ai décidé de faire au plus simple, avec des outils éprouvés.

La stack technique

Frontend :

• TypeScript, React & Next.js → Stack moderne et maîtrisée

Backend :

• Python avec FastAPI → Classique + expertise existante

Base de données :

• PostgreSQL (PostGIS et PgVector) → Fiable + support vectoriel

Infrastructure :

• Docker + Cloud Run → Simple, portable vers K8s
• GCP → Simplicité + expertise
• Vercel → Simplifie le déploiement front

👉 Conseil : Simplifiez les outils, votre solution métier sera suffisamment compliquée à développer !

La création d’un produit Tech

Une phase très cool a ensuite été de réfléchir à un produit qui donne envie, qui n’est pas seulement fonctionnel.

Il a donc fallu ajouter des casquettes supplémentaires :

Les multiples rôles du fondateur technique

• Product Manager : prioriser les features, définir les specs
• Designer UX/UI & Dev front : créer des parcours utilisateur cohérents et adaptés au monde de l’artisanat
• Dev backend : implémenter le comportement produit (pas uniquement les API Data/ML comme je faisais jusqu’à présent)
• DevOps : déployer, monitorer, sécuriser
• QA : tester, débugger, valider

Passer d’un rôle de Data Eng / MLOps à un vrai rôle full stack demande beaucoup d’énergie !

Un jour tu optimises un algorithme, le lendemain tu réfléchis à quelle interface mettre en place, le surlendemain tu configures un serveur de prod.

C’est difficile à faire au début, on se sent perdu et c’est normal.

👉 À retenir : Il faut garder en tête l’objectif du produit et ne pas se perdre sur des problématiques techniques. Oui ça fait beaucoup mais si c’est fait dans la bonne direction ça marchera.

Ce que j’ai retenu de cette 2ᵉ phase

✅ Les points forts

• Passer du concept à la réalité
• Penser long terme dès le départ
• Avoir une vue globale

❌ Ce que j’aurais fait autrement

• Mieux cadrer la problématique business/réponse produit
• Être moins perfectionniste
• Livrer plus vite (5 mois !) pour avoir rapidement des retours terrain

🎯 Conseils si vous en êtes à cette étape

1. Clarifier LA problématique phare : acceptez de renoncer à une partie des idées pour en implémenter une parfaitement

2. Pensez long terme : évitez de devoir faire un refactoring dans l’année

3. Codez uniquement le cœur de votre valeur ajoutée : votre valeur n’est pas dans l’auth ou les paiements

4. Livrez vite : mettez tout en œuvre pour avoir de vrais retours rapidement

La suite de cette série

Dans les prochains articles, je vous détaillerai :

• “L’impact technique du business model” - Comment j’ai implémenté le moteur de recherche des artisans de sorte à satisfaire le modèle SaaS.

• “IA et produit : comment aligner expérience utilisateur avec qualité des réponses” - Un article sur ma démarche dans le choix puis l’intégration d’une solution IA dans le produit.

📩 Si ces sujets vous intéressent, contactez-moi par mail ou suivez-moi sur LinkedIn pour ne rien rater !

L’objectif de cette série ? Partager mes apprentissages concrets pour aider d’autres créateurs et leur éviter les mêmes erreurs. Chaque article sera actionnable !