Lancer votre logiciel sans associé technique : ce qu'il faut garder en main

Vous avez le marché, pas l'associé technique : à quoi ressemble la situation ?

Une ancienne responsable d'exploitation d'un transporteur connaît par cœur le problème des quais de chargement : des camions qui attendent faute de créneau, des appels sans fin entre chargeurs et transporteurs. Elle a dessiné l'outil qui manque, trois chargeurs sont prêts à le tester. Il lui manque l'associé technique.

Les propositions arrivent, et elle ne sait pas les comparer :

• un développeur indépendant propose de tout construire contre une part du capital ;
• une agence à l'étranger annonce un forfait bas, hébergement compris, sur ses propres serveurs ;
• un ami conseille un outil sans code pour « tester vite » ;
• un investisseur lui explique qu'il ne finance pas une société sans directeur technique.

Derrière ces offres se cachent trois questions : qui possédera le code, qui pourra le reprendre, et que faudra-t-il refaire le jour du premier recrutement.

Que fait un CTO dans une jeune entreprise, et qui peut tenir ce rôle au début ?

Le CTO (directeur technique) porte les décisions techniques de l'entreprise et en répond sur la durée. Au lancement, ses responsabilités peuvent être réparties, à condition de savoir qui tient chacune :

Un prestataire peut construire, exploiter et documenter. Il ne peut ni trancher vos priorités produit à votre place, ni s'engager dans votre capital sur la durée.

Quel est le coût caché d'un lancement mal verrouillé ?

Le coût d'un lancement sans associé technique ne se voit pas à la signature, mais au premier changement de prestataire. Les pièges les plus fréquents :

• Le code n'est pas à vous. L'INPI rappelle que le logiciel est une œuvre protégée par le droit d'auteur (article L. 112-2 du Code de la propriété intellectuelle). Pour un salarié qui développe dans le cadre de ses fonctions, le guide de l'INPI sur la propriété intellectuelle de l'entrepreneur indique que les droits patrimoniaux reviennent à l'employeur. Pour un prestataire extérieur, il faut une cession : la fiche d'Entreprendre Service Public précise que le contrat de cession de droits d'auteur doit être écrit et énumérer les droits cédés.
• Les comptes sont au nom d'un tiers. Nom de domaine, hébergement, dépôt de code, comptes Apple et Google, compte de paiement : si le prestataire en est titulaire, la moindre opération dépend de sa bonne volonté.
• Des parts données trop tôt. Un développeur payé en capital qui s'en va après quelques mois reste associé, sauf clause prévue dans le pacte d'associés, et laisse un code inachevé.
• Une technologie rare. Un outil de niche ou un générateur propriétaire réduit le nombre de développeurs capables de reprendre le projet.
• Aucune documentation. Le premier développeur recruté passe ses premières semaines à comprendre l'existant au lieu d'avancer.

Ces sujets sont détaillés dans notre guide sur la propriété du code source et la réversibilité.

Quelles options pour construire la première version ?

La bonne réponse dépend de votre stade. Voici les six voies qui s'offrent à un fondateur non technicien :

Pour approfondir : no-code ou développement sur mesure, et le calcul complet du coût d'un recrutement face à une agence.

Les règles à fixer avant la première ligne de code

1. Ouvrir les comptes au nom de la société. Domaine, hébergement, dépôt de code, messagerie, paiement, stores. Pour publier une application au nom d'une organisation, Apple exige une entité juridique dotée d'un numéro D-U-N-S, et le nom du vendeur affiché sera celui de cette entité. Google Play n'ouvre pas non plus de compte d'organisation sans numéro D-U-N-S et indique que la démarche, gratuite, peut prendre jusqu'à 30 jours : lancez-la dès l'immatriculation.
2. Écrire la cession des droits dans le contrat, avec le moment où elle intervient (par exemple au paiement intégral) et la remise du code source.
3. Exiger des technologies répandues, que l'on trouve facilement sur le marché du recrutement, plutôt qu'un outil propriétaire.
4. Recevoir la documentation à chaque version : installation, architecture, configuration, procédure de mise en production.
5. Disposer d'une version de test accessible en permanence, pour juger sur pièce plutôt que sur des comptes rendus.
6. Écrire le périmètre de la première version, et surtout ce qui n'en fait pas partie. Notre guide sur le MVP d'une application aide à trancher.
7. Prévoir la sortie : comment le code, les accès et les données vous sont remis si la collaboration s'arrête.

Ce que YMHB Web prend en charge, et ce qui reste à vous

Avec un fondateur non technicien, YMHB Web tient le rôle d'équipe technique externe pendant la construction, sans prendre la place du dirigeant sur le produit :

• Cadrage avant chiffrage : nous entrons dans votre métier, écrivons avec vous le périmètre de la première version, puis chiffrons un forfait global ferme. Le fondateur de l'agence, Yanis Hamidou-Brochot, reste votre interlocuteur du premier rendez-vous à la mise en service.
• Des choix techniques expliqués : React et Next.js pour le web, Node.js, PostgreSQL avec Supabase, Flutter pour une application iOS et Android sur une seule base de code. Chaque choix est consigné avec sa raison, pour que votre futur recruté comprenne pourquoi.
• Une version testable en permanence, que vous montrez à vos premiers clients pendant la construction.
• Le code et les comptes chez vous : au paiement intégral, le code vous appartient ; il est déposé sur vos comptes, documenté et repris sans difficulté par un autre développeur.

YMHB Web édite aussi son propre logiciel, VISIA, qui analyse la visibilité d'une entreprise dans les assistants IA. Les arbitrages d'éditeur (livrer d'abord, reporter, abandonner) nous sont familiers, ce qui aide à défendre un périmètre de lancement court.

Ce qui reste à vous : la connaissance des clients, l'ordre des fonctions, les décisions commerciales. Aucun prestataire ne doit les prendre à votre place.

Comment préparer l'arrivée de votre premier développeur ou CTO ?

Le jour du recrutement, la qualité de l'existant décide du temps de prise en main. Un dossier de reprise complet comprend :

• un schéma de l'architecture et la liste des services utilisés, avec le titulaire de chaque compte ;
• un guide d'installation qui fait tourner l'application sur un poste neuf ;
• des tests automatiques sur les parcours critiques (inscription, paiement, fonction principale) ;
• le registre des décisions techniques et des compromis assumés ;
• la liste des évolutions envisagées et des faiblesses connues.

Avec ce dossier, un CTO qui arrive évalue rapidement l'existant et décide en connaissance de cause de le garder, de le faire évoluer ou d'en reconstruire une partie. Si un développeur interne part à son tour, la page le développeur qui connaissait le logiciel est parti décrit la marche à suivre.

Quand vaut-il mieux chercher un associé technique ?

• La technologie est le produit : algorithme propriétaire, modèle d'IA entraîné sur vos données, logiciel embarqué dans un équipement. L'avantage concurrentiel se construit dans la durée et doit appartenir à quelqu'un qui partage le risque.
• Vos investisseurs l'exigent : certains fonds ne financent qu'une équipe fondatrice complète. Renseignez-vous avant de bâtir votre plan.
• Le produit changera chaque jour pendant des années : une équipe interne devient alors plus naturelle qu'un prestataire, même bien choisi.
• Vous n'avez pas de temps pour le produit : si personne ne tranche les priorités, ni un associé ni une agence ne sauveront le projet.

Même dans ces cas, une première version propre et transmissible, construite par un prestataire, peut servir de démonstration pour convaincre un associé de vous rejoindre.