Je suis avocat de formation. Sciences Po, école du barreau, collaboration en cabinet. Rien dans mon parcours ne me destinait à construire un produit technologique. Et pourtant, DAIRIA IA existe, fonctionne, et a des utilisateurs qui paient.
Si vous êtes expert dans un domaine non-tech et que vous avez une idée de produit SaaS, cet article est pour vous. Voici ce que j’ai appris en passant de l’autre côté de la barrière.
L’avantage inattendu du fondateur non-technique
Contre-intuitivement, ne pas être développeur peut être un avantage pour construire un produit B2B. Pourquoi ? Parce que vous pensez en termes de problème client, pas en termes de solution technique. Un développeur qui a une idée commence souvent par la technologie : « Je vais construire un moteur de NLP avec du machine learning. » Un non-dev commence par le besoin : « Les DRH ont besoin de savoir en 30 secondes si un licenciement est risqué. »
Cette différence de perspective est fondamentale. Les meilleurs produits B2B ne sont pas les plus sophistiqués techniquement. Ce sont ceux qui résolvent le mieux le problème de l’utilisateur. Et pour comprendre le problème de l’utilisateur, mieux vaut être un utilisateur soi-même qu’un développeur qui imagine des cas d’usage.
J’ai construit DAIRIA IA parce que j’étais frustré par les outils juridiques existants. Pas parce que je voulais faire de la tech. La frustration d’un utilisateur est le meilleur cahier des charges possible.
« Le meilleur fondateur de SaaS n’est pas celui qui code le mieux. C’est celui qui comprend le mieux le problème qu’il résout. »
Apprendre à coder (un peu) est indispensable
On peut construire un SaaS sans être développeur, mais pas sans comprendre le développement. J’ai appris les bases du code — HTML, CSS, JavaScript, Python — non pas pour développer le produit moi-même, mais pour pouvoir dialoguer avec ceux qui le développent.
Quand un développeur me dit « c’est impossible », je veux être capable de distinguer le « c’est vraiment impossible » du « c’est juste compliqué et j’ai la flemme ». Quand il me propose une architecture, je veux comprendre les implications en termes de coût, de performance et de maintenance.
Le minimum vital, à mon sens : comprendre ce qu’est une API, une base de données, un frontend vs backend, un déploiement. Savoir lire du code même si on ne sait pas l’écrire. Comprendre les ordres de grandeur de coût et de délai. Six mois d’apprentissage en autodidacte suffisent pour ça.
Les trois options pour le développement
Option 1 : trouver un CTO associé. C’est le scénario idéal mais le plus dur à réaliser. Un bon CTO qui accepte de s’associer avec un non-tech sur un projet early-stage, c’est une licorne. Si vous le trouvez, ne le lâchez pas.
Option 2 : sous-traiter à une agence ou des freelances. C’est ce que j’ai fait au début. L’avantage : vous gardez le contrôle et la propriété. L’inconvénient : le coût et la dépendance. Choisissez un prestataire qui comprend votre domaine, pas le moins cher.
Option 3 : l’IA comme co-développeur. C’est de plus en plus viable. Avec Claude Code et les outils d’IA actuels, un non-développeur peut construire des prototypes fonctionnels et même des produits complets pour des cas d’usage bien définis. C’est l’approche que j’utilise de plus en plus.
Les erreurs qui coûtent cher
L’erreur la plus commune du fondateur non-tech : construire trop avant de vendre. J’ai passé trois mois à développer une fonctionnalité que personne n’a utilisée. Trois mois et plusieurs milliers d’euros perdus. Depuis, je vends d’abord (ou au moins je valide l’intérêt), je construis ensuite.
Autre erreur : sous-estimer la maintenance. Construire un produit, c’est 30% du travail. Le maintenir, le corriger, le faire évoluer, c’est 70%. Avant de lancer un développement, demandez-vous : « Qui va maintenir ça dans six mois ? »
Dernière erreur : vouloir tout faire soi-même. Le bootstrap a ses limites. Il y a un moment où il faut investir dans les compétences techniques, que ce soit un recrutement, un prestataire ou une formation sérieuse. Accepter ses limites n’est pas un aveu de faiblesse, c’est un acte de maturité entrepreneuriale.
