Faire développer son premier logiciel métier quand on n'est pas technique

Vous dirigez une entreprise depuis dix, vingt, parfois trente ans. Vous connaissez votre secteur, vos clients, les mille détails du quotidien que personne ne voit de l'extérieur. Un jour, le tableur qui tenait tout ne suffit plus. Les plannings se compliquent, les remplacements s'improvisent, les clients réclament de la visibilité. Vous décidez de faire développer un logiciel. Et là, vous entrez sur un terrain où trente ans de métier ne vous donnent aucun repère.

C'est une situation qu'on voit souvent : un dirigeant excellent dans son domaine, avec un vrai problème à résoudre, mais aucune référence sur ce que coûte un développement, combien de temps il prend, ni comment il se pilote. Ce n'est pas une faiblesse. C'est simplement un métier que vous n'avez jamais eu à apprendre. Le risque n'est pas de ne pas savoir, c'est de ne pas savoir ce qu'on ne sait pas.

Cet article est écrit pour ce dirigeant. Pas pour vous apprendre à coder, mais pour vous donner les repères qui manquent : ce que vous faites déjà mieux qu'une startup tech, les pièges où tombent presque tous les primo-accédants au logiciel, et comment dérisquer votre projet avant de dépenser le premier euro de développement.

“La technique s'achète. Ce qui ne s'achète pas, c'est de connaître un métier de l'intérieur. Vous avez déjà le plus dur.”

On parle beaucoup des compétences qui vous manquent. On parle rarement de celles que vous avez et qui font défaut à la plupart des projets qui échouent. Vous partez avec un avantage que l'argent n'achète pas : vous vivez le problème tous les jours. Vous n'avez pas à deviner si le besoin existe, vous le subissez depuis des années. C'est exactement ce qui manque à la majorité des produits qui ne trouvent jamais leur marché.

Vous avez aussi une distribution que les startups mettent des années à construire. Un réseau, des clients qui vous font confiance, un bouche-à-oreille. Quand votre logiciel existera, vous avez déjà des gens à qui le montrer. Et vous avez une discipline financière que peu de fondateurs tech possèdent : vous gérez une vraie entreprise, avec une vraie trésorerie, pas une levée de fonds à brûler.

Regardez ce chiffre et mesurez votre avance. La première cause de mortalité des produits, c'est de construire quelque chose que personne ne veut. Vous, vous savez que le besoin existe, parce que c'est le vôtre et celui de gens que vous connaissez. Votre défi n'est pas de trouver un problème à résoudre, c'est de le résoudre proprement sans vous tromper de périmètre ni de partenaire.

Votre avance sur le besoin ne vous dispense pas de la discipline du périmètre. On explique comment cadrer un premier lot utile dans MVP vs V1 : cadrer le bon périmètre. C'est le complément direct de cet article.

Ces pièges n'ont rien à voir avec l'intelligence. Ils viennent tous du même endroit : l'absence de repères sur un métier qu'on découvre. Les connaître à l'avance suffit souvent à les éviter.

“Un logiciel qui marche n'est pas un logiciel qui a toutes les fonctionnalités. C'est un logiciel qui résout le bon problème, proprement.”

Voici le geste qui dérisque le plus un projet, et il ne coûte presque rien comparé au développement : faire réaliser une maquette non codée avant d'écrire la première ligne. Une représentation visuelle des écrans, des parcours, des cas concrets, sur laquelle vous pouvez cliquer et vous projeter.

Son utilité est double. D'abord elle transforme des mots en images. Un cahier des charges écrit laisse chacun imaginer une chose différente : vous voyez un écran, le développeur en voit un autre. La maquette met tout le monde d'accord avant que l'écart ne coûte cher. Ensuite elle sert de base au chiffrage : on estime bien mieux ce qu'on a sous les yeux que ce qu'on décrit en paragraphes.

C'est aussi le moment où un bon partenaire va challenger votre cahier des charges. Pas pour vous contrarier, mais parce que la maquette rend visible ce qui est superflu, ce qui est risqué et ce qui doit venir en premier. Vous en ressortez avec un périmètre plus petit, plus clair et beaucoup moins cher que celui que vous aviez en tête au départ.

Le choix du partenaire pèse plus lourd que le choix de la technologie. Deux prestataires peuvent livrer le même périmètre pour un budget proche et produire des résultats opposés, parce qu'ils n'ont pas le même réflexe face à votre projet. La distinction utile n'est pas agence contre freelance, c'est exécutant contre partenaire.

Comment reconnaître l'un de l'autre en quelques questions, c'est tout le sujet de prestataire ou partenaire : les questions à poser.

Faire développer son premier logiciel quand on n'est pas technique fait peur pour une bonne raison : on avance sans repères sur un terrain inconnu. Mais l'inconnu n'est pas le plus important. Le plus important, la connaissance intime d'un métier et d'un vrai problème, vous l'avez déjà. C'est la partie que personne ne peut vous vendre.

Le reste se pilote avec quelques principes simples : réduire le périmètre, valider par une maquette avant de coder, et choisir un partenaire sur sa capacité à vous dire non. Faites cela, et vous éviterez l'immense majorité des projets qui dérapent, pas parce que vous serez devenu technique, mais parce que vous aurez posé les bonnes questions au bon moment.

“Vous n'avez pas besoin de devenir développeur. Vous avez besoin de savoir reconnaître un bon partenaire et de garder la main sur votre périmètre.”

Étape suivante logique : apprendre à cadrer ce premier lot dans MVP vs V1, cadrer le bon périmètre.