Comment créer un logiciel quand vous n’êtes pas le développeur : le framework de décision pour le founder non technique

Quatre décisions dans l’ordre, cinq questions pour choisir la voie, et ce qui change quand le logiciel atteint un client qui paie.

Lors d’une réunion mercredi dernier, une founder est arrivée avec un cahier ouvert, un tableur saturé de couleurs, et une phrase : “j’ai besoin de créer un logiciel”. Elle venait des opérations. Elle avait tenu le tableur avec des automatisations Google Sheets. Le tableur s’était cassé trois fois ce mois-là. Les clients commençaient à le remarquer. Elle maîtrisait le problème métier. Elle était perdue sur comment construire le logiciel.

“Comment créer un logiciel” a une réponse différente selon qui pose la question. Un développeur qui apprend a besoin d’un tutoriel : choisir un langage, monter l’environnement, écrire du code, tester, déployer. Pour le founder non technique, créer un logiciel n’est pas programmer. C’est prendre quatre décisions dans l’ordre avant qu’une seule ligne de code n’existe. Confondre les deux fait commencer du mauvais côté, recruter pour la mauvaise raison, et six mois plus tard se retrouver avec deux mille euros par mois de serveur faisant tourner quelque chose que personne n’utilise.

Cet article est le framework qu’on utilise avec les founders non techniques quand ils arrivent avec le tableur cassé, le contrat signé avec une échéance, ou l’investisseur qui demande le prototype. Quatre décisions. Cinq questions. Un document d’une page.

Les quatre décisions avant de commencer

Il y a une séquence. Elle compte. Prendre la quatrième décision avant la première est la façon la plus courante de cramer trois mois et le budget du tour pre-seed.

Décision 1, périmètre réel. Que faut-il qui fonctionne le premier jour pour le premier client qui paie ? Pas ce qui serait bien d’avoir. Pas ce que l’investisseur a mentionné. L’ensemble minimal d’écrans et d’actions sans lesquels la première vente n’arrive pas. Règle pratique : si vous pouvez décrire le logiciel en trois phrases et cinq écrans, vous êtes proche. Si vous avez 47 user stories dans Notion, vous n’avez pas assez réfléchi.

Décision 2, voie. Build vs buy vs no-code vs hybride. Chacune a un profil de coût, un plafond de fonctionnalité, et un type de personne qui doit être de votre côté pour que ça marche. On y revient à la prochaine section.

Décision 3, partenaire. Qui va construire. Freelance, software house, recrutement interne, ou plateforme no-code avec un implémenteur. Cette décision dépend de la décision 2. Ne commencez pas par là.

Décision 4, contrat et budget. Comment le travail est convenu. Prix fixe, time and materials, equity, sprint payé. Comment l’argent sort et ce qui compte comme livré. Cette décision dépend des trois précédentes.

La plupart des founders non techniques qu’on voit essaient de commencer par la décision 3. “Tu connais un bon développeur ?” est la mauvaise question avant que la décision 1 ne soit réglée. Bon pour quoi.

Comment choisir la voie : build, buy, no-code, ou hybride

La décision 2 est celle qui pèse le plus sur le reste. Elle définit qui vous appelez, quel sera le budget, et quel type de problème vous allez découvrir en chemin.

Buy. Un logiciel existe déjà qui fait 80 % de ce dont vous avez besoin. Salesforce ou HubSpot pour le CRM, Pipefy pour les flux, QuickBooks pour la comptabilité. Buy est la bonne réponse quand votre avantage compétitif n’est pas dans le logiciel lui-même. Vous êtes une opération immobilière qui a besoin d’un CRM, pas une proptech qui construit le CRM du marché. Acheter est plus rapide, moins cher la première année, et libère pour se concentrer sur ce qui différencie réellement le business.

No-code. Bubble, Glide, Softr, Retool avec modules. Fonctionne quand le flux est clair, le volume est faible (jusqu’à quelques milliers de transactions par mois), et le logiciel n’est pas encore le produit que le client paie. Le no-code est la façon la moins chère de valider une idée. C’est aussi la voie d’où le plus de gens sortent en flammes, généralement entre le premier contrat significatif et la Série A. L’article sur le product discovery pour le founder non technique montre comment utiliser le no-code pour valider sans s’enfermer.

Build. Logiciel sur mesure, écrit pour le problème spécifique. Pertinent quand le logiciel fait partie de ce que le client paie, quand le volume a dépassé ce que le no-code tient sans devenir une boîte noire, ou quand la régulation de votre secteur (santé, financier, juridique) exige un niveau de contrôle qu’un outil générique ne donne pas. Build coûte plus cher à démarrer et moins cher à maintenir quand c’est bien fait. L’article sur quand recruter une software house couvre comment évaluer un partenaire sans feindre une profondeur technique.

Hybride. Presque tout logiciel d’entreprise réel est hybride en pratique. CRM acheté, outil interne sur mesure, intégration via Zapier ou API. La bonne question hybride est “quelle partie est notre avantage compétitif et quelle partie est commodity”. L’avantage se construit. Le commodity s’achète. Mal mélanger coûte cher : construire un CRM depuis zéro quand HubSpot le résoudrait, ou acheter un outil de risque quand votre modèle de risque EST le produit.

Règle empirique : si le logiciel sera devant le client qui paie et fait partie du produit qu’il achète, build. S’il est interne, transitoire, ou dans un domaine commoditisé, buy ou no-code avec un plan de sortie.

Est-il possible de créer un logiciel sans programmer ?

Oui, sous deux formes, et la confusion entre les deux coûte cher.

La première est le no-code. Vous n’écrivez pas de code, mais vous écrivez des règles : “quand le client remplit ce formulaire, sauvegarde ici, envoie cet email, affiche cet écran”. Les règles deviennent le logiciel. Ça marche jusqu’à un plafond prévisible : intégration que la plateforme ne supporte pas, volume qui dépasse le forfait, détail de design que le template n’autorise pas. L’article sur vibe coding vs agentic coding couvre comment penser ces choix par étape.

La deuxième forme est de recruter quelqu’un qui programme à votre place. Le “sans programmer” est littéral, mais le founder reste propriétaire de la décision de périmètre, de la revue des livraisons, et de la réponse à “voici ce dont l’utilisateur a besoin, ceci non”. Qui externalise la décision produit au développeur termine avec un logiciel qui satisfait le développeur, pas le client.

La troisième forme, celle qui ne marche pas, est de penser que les outils d’IA générative vont “créer le logiciel” à partir du brief. Ils écrivent du code. Ils ne prennent pas de décisions produit, ne testent pas contre le vrai client, et ne répondent pas des erreurs en production.

Combien coûte créer un logiciel, en pratique

La fourchette varie d’un ordre de grandeur. Buy livre quelque chose qui fonctionne en quelques heures, coûte entre 20 et 200 euros par mois par utilisateur en abonnement, et le travail du founder est de configurer et former l’équipe. No-code livre le premier flux en une à quatre semaines, coûte entre 80 et 800 euros par mois de plateforme plus un implémenteur (entre 1 000 et 3 000 euros pour le premier setup), et exige que quelqu’un (vous ou un opérateur) maintienne les règles vivantes. Build livre la première version en trois à six mois, coûte entre 40 000 et 250 000 euros pour un MVP sur mesure bien cadré, et exige un flux de revue hebdomadaire entre founder et partenaire d’ingénierie. Pour le détail par driver, l’article sur combien coûte développer une app ouvre les six facteurs qui font le plus bouger le chiffre.

La fourchette n’est pas le problème. Le problème est de démarrer un build sans budget de build, ou de démarrer no-code en pensant que ça restera bon marché pour toujours. Le coût total du no-code sur trois ans dépasse souvent le coût d’un build bien fait dès que le volume passe quelques centaines de transactions par jour. Le coût total d’un build mal cadré sur six mois dépasse celui de toute plateforme commerciale disponible.

Comment créer un logiciel étape par étape, depuis zéro

Pour le founder non technique, “créer un logiciel depuis zéro” ne veut pas dire ouvrir un éditeur de code vide. Ça veut dire commencer une séquence de décisions et de livraisons qui se termine par un logiciel qui tourne pour un client qui paie.

Semaine 1. Écrivez sur une page ce que fait le logiciel, pour qui, quelle action fait le client, les cinq écrans minimaux, et ce qui n’est PAS dans la première version. Cette page est votre première version d’un PRD pour founder non technique et changera trois fois dans les deux semaines suivantes.

Semaine 2. Montrez le document à cinq prospects. Ne vendez pas. Demandez ce qui manque, ce qui est en trop, ce qui est confus. Chaque client qui dit “ce serait utile” sans s’engager sur un abonnement ou un acompte est un signal faible. Chaque client qui dit “si ça existe aujourd’hui je paie” est le signal qui fait avancer le projet.

Semaine 3. Décision de voie. Avec la page mise à jour et cinq conversations en poche, prenez la décision 2 avec critère : quelle partie est différenciation compétitive, quelle est commodity, quel est le budget réel, quel est le délai jusqu’au premier client.

Semaine 4. Décision de partenaire. Trois conversations avec des candidats de la voie choisie. Pour build, trois software houses ou un à deux développeurs senior. Pour no-code, deux implémenteurs spécialisés sur la plateforme. Pour buy, deux démos avec des fournisseurs et deux conversations avec leurs clients. Comparez les propositions avec le document d’une page en main.

Semaines 5 à 12. Première version. Le travail du founder est de garder la page vivante, de revoir les livraisons hebdomadaires, et de débloquer les décisions. Couper le périmètre est votre travail. Ajouter du périmètre est l’erreur la plus chère du stade.

La séquence fonctionne pour une entreprise, une startup pre-seed, une opération qui valide une verticale, et une équipe qui modernise un tableur qui a commencé à se casser. Ce qui change est la fourchette de budget et la sophistication du partenaire.

Cinq questions pour choisir la voie

Avant de signer avec n’importe quel partenaire, répondez à chacune en une phrase :

1. Quel problème client résout ce logiciel, et combien paie-t-il aujourd’hui pour l’éviter ? Si la réponse est “je ne sais pas encore”, vous êtes en discovery, pas en build. Reculez d’une case.
2. Dans trois ans, ce logiciel fait-il partie du produit que le client achète, ou est-ce un outil interne ? Si interne, la voie commence par buy ou no-code. Si c’est le produit, build entre dans la conversation immédiatement.
3. Quelle part de l’opération tourne aujourd’hui sur tableur, papier, ou dans la tête d’une seule personne ? Plus la part est haute, plus le risque de tenter de coder un processus pas encore stable est grand. Stabilisez d’abord, codez ensuite.
4. Quel est le budget réel pour les six prochains mois, en comptant la maintenance post-lancement ? Build sans réserve pour les mois sept à douze, c’est emménager dans une maison dont vous ne pouvez payer que la moitié du loyer. Ça va casser dans les détails.
5. Qui dans l’équipe sera propriétaire de ce logiciel une fois en production ? Un logiciel sans propriétaire dans l’entreprise se casse en silence. Si la réponse est “le développeur que je vais recruter”, le système est fragile par construction.

Les cinq réponses, écrites en trois lignes chacune, sont le brief technique qui sépare une conversation sérieuse avec un partenaire d’une réunion qui se termine par “on y réfléchit et on revient”.

Logiciel comme produit vs logiciel comme raccourci

Avant la décision 2, intériorisez la distinction qui sépare le mieux le budget bien dépensé du budget brûlé.

Logiciel comme produit, c’est ce que le client utilise, contracte, paie en abonnement, recommande. C’est le produit de la fintech, de la healthtech, du marketplace vertical, du SaaS de niche. La qualité d’ingénierie ici est avantage compétitif. Le no-code est zone de validation, pas destination. Sous-estimer le build apparaît comme du churn, du support coûteux, et l’impossibilité de facturer le prix qu’un produit bien fait soutient.

Logiciel comme raccourci, c’est ce qui fait gagner du temps à votre équipe : outils internes, dashboards, automatisations back-office. La première version peut être beaucoup plus simple. Le no-code est souvent la bonne réponse plus longtemps. L’erreur la plus courante est de construire depuis zéro ce qui existe déjà tout fait.

Les confondre coûte cher. Construire un CRM interne sur mesure quand un abonnement de 30 euros par mois le résoudrait, et brûler six mois d’équipe sur cette pièce. Ou traiter le produit principal de l’entreprise comme un raccourci, le monter en no-code, et découvrir à 150 clients payants que migrer est un projet de huit mois au pire moment possible.

Le document d’une page, avant la première réunion

La pièce qui sépare le plus un brief sérieux d’une conversation coûteuse est un document simple. Il tient sur une page. Il a six blocs :

Problème. Ce qui fait mal au client, en une phrase.

Utilisateur. Qui utilise le logiciel, quel poste, quel niveau technique.

Cinq écrans minimaux. Le flux essentiel, dans l’ordre.

Hors périmètre. Ce qui n’est PAS dans la première version.

Métrique de succès. Comment vous savez que ça a marché. “Client A fait X en Y minutes” bat “augmenter la conversion”.

Contrainte. Budget, échéance, dépendance réglementaire, intégration obligatoire.

Ce document n’est pas un PRD complet, et n’a pas besoin de l’être. C’est la pièce qui rend trois conversations avec trois partenaires différents comparables. Sans elle, chaque partenaire définit le périmètre dans sa propre proposition, chaque proposition devient incomparable, et le founder choisit selon le charisme du commercial. Avec elle, la comparaison est honnête.

Pourquoi la plupart des premiers logiciels échouent

Trois raisons couvrent presque tous les échecs qu’on voit, par ordre de fréquence.

Mauvais périmètre, c’est la première. Le founder a construit le logiciel qu’il a décrit, pas celui dont le client avait besoin. Correction : la semaine 2 de la séquence, cinq vraies conversations avant la décision de voie.

Mauvais partenaire, c’est la deuxième. Freelance pas cher au mauvais moment, grosse software house au mauvais moment, recrutement de CTO au mauvais moment. Correction : marier la décision 3 avec la 2. Pour le no-code, un implémenteur. Pour un build de produit, une software house compétente ou un développeur senior avec revue de code formelle. Pour buy, un opérateur interne qui dominera l’outil.

Pas de propriétaire interne, c’est la troisième. Le logiciel passe en production, personne dans l’entreprise ne le comprend assez pour le maintenir, et le système se dégrade jusqu’à la prochaine crise. Correction : décider, avant de signer, quelle personne de l’équipe sera propriétaire du logiciel après le lancement. Si la réponse est “personne pour l’instant”, le projet n’est pas prêt à démarrer.

Créer un logiciel, pour le founder non technique, c’est moins monter une équipe d’ingénierie et plus prendre quatre décisions dans l’ordre avec assez d’information. La première version compte moins que la séquence.

Questions fréquentes

Que faut-il pour développer un logiciel ?
Quatre décisions dans l’ordre avant toute ligne de code : périmètre minimal, voie (build, buy, no-code, ou hybride), partenaire, et contrat. La semaine 1 produit la page d’une feuille. Les trois semaines suivantes affinent la page et choisissent voie et partenaire.

Est-il possible de créer un logiciel sans savoir programmer ?
Oui, sous deux formes : outils no-code qui écrivent des règles à la place du code, ou recruter quelqu’un qui code pour vous. Dans les deux cas, le founder reste propriétaire de la décision de périmètre, de la revue de ce qui est livré, et de la réponse à “voici ce dont le client a besoin”.

Combien coûte produire un logiciel ?
La fourchette varie d’un ordre de grandeur. Buy coûte entre 20 et 200 euros par mois par utilisateur en abonnement. No-code coûte entre 80 et 800 euros par mois plus le setup. Build coûte entre 40 000 et 250 000 euros pour un MVP bien cadré. Détail par driver dans l’article sur combien coûte développer une app.

Comment créer un programme de logiciel étape par étape ?
Quatre semaines : semaine 1, écrivez la page avec problème et cinq écrans ; semaine 2, montrez-la à cinq prospects ; semaine 3, décidez de la voie ; semaine 4, parlez à trois candidats de la voie choisie. À partir de la semaine 5, gardez la page vivante et revoyez les livraisons hebdomadaires.

Quelle est la meilleure voie pour créer un logiciel gratuit ?
Gratuit en pratique n’existe presque jamais. Le no-code a des forfaits initiaux sans coût avec des limites étroites. L’open source enlève la licence mais ajoute hébergement et maintenance. Pour une validation sans budget, no-code en forfait gratuit pendant trente à quatre-vingt-dix jours est la voie la plus courante, en assumant que c’est zone de test, pas destination.