Auteur
Louis L.
Rédigé avec l'aide de l'IA
En bref
Si la technologie est un vrai risque et le cœur de ton avantage, il te faut un cofondateur technique, pas un prestataire. Tu peux l’évaluer sans savoir coder, à condition de savoir quoi regarder, et de faire vérifier le reste par un développeur de confiance.
Et un point qui règle beaucoup de mauvaises associations avant qu’elles commencent : un cofondateur technique qui construit tout le produit, à temps plein, depuis presque rien, se rémunère en parts proches de la parité, pas en 10 %.
Prestataire ou cofondateur ?
Un prestataire ou un freelance suffit quand tu peux spécifier ce qu’il faut construire, que la techno est standard, que tu as le budget, et que le code n’est pas ce qui te différencie. Un MVP bien cadré, un site vitrine, une intégration : ça s’achète.
Un cofondateur technique devient nécessaire quand le risque technique est réel, que la feuille de route est longue et va bouger en permanence, que la technologie est la barrière à l’entrée, et que tu veux quelqu’un qui prenne les décisions d’architecture avec toi plutôt que de te livrer un devis. Il porte le même risque que toi (pas de salaire garanti, un pari sur la réussite) et c’est ça que rémunèrent les parts.
Où sont les développeurs qui veulent construire
Un bon développeur peut trouver un poste bien payé demain. Tu n’es donc pas en train de filtrer une pile de candidats : tu recrutes quelqu’un qui a d’autres options. Ce qui se joue, c’est ta capacité à vendre le problème, le « pourquoi toi », le « pourquoi maintenant » et l’histoire du capital.
Les viviers les plus productifs :
- Les ingénieurs d’anciennes startups : ils connaissent le rythme, ont souvent vécu un échec ou une revente, et beaucoup ont l’envie de faire le leur.
- Les contributeurs et mainteneurs open source de ton domaine : visibles, évaluables sur pièces, et déjà investis dans un sujet proche du tien.
- Les communautés « build in public » et indie hackers : des gens qui veulent déjà construire des produits, souvent en solo, et à qui un bon binôme manque.
- Ceux qui animent les meetups techniques, pas seulement ceux qui y assistent, les intervenants et organisateurs sont plus seniors et plus faciles à approcher.
- Les hackathons : le seul endroit où tu vois quelqu’un livrer sous contrainte en 48 h avant tout engagement.
Évaluer un profil technique sans savoir coder
Ce que tu peux juger toi-même
- La communication. Est-ce qu’il t’explique un compromis technique simplement, ou est-ce qu’il empile le jargon ? Un bon signe : « on peut faire vite et sale maintenant, ou propre et lent : voilà ce que je choisirais et pourquoi ».
- L’historique de livraison. A-t-il fini et mis en ligne des choses : un side-project, une app, une contribution utilisée par d’autres ? Le volume compte moins que le fait d’avoir bouclé.
- Le jugement sur le périmètre. Veut-il tout reconstruire proprement, ou livrer la plus petite version qui apprend quelque chose ?
- L’intérêt pour les utilisateurs. Pose-t-il des questions sur les clients, le problème, le marché, ou seulement sur la stack ?
Ce qu’un développeur de confiance vérifie pour toi
Fais appel à un développeur senior de ton réseau, avec un script précis : revue d’un bout de code existant, questions sur des choix d’architecture passés, estimation d’une fonctionnalité, et la question finale : « est-ce que tu embaucherais cette personne ? ». Trente minutes suffisent à lever la plupart des doutes que tu ne peux pas lever seul.
Signaux verts, signaux rouges
Verts : livre vite et itère, tient ses opinions fermement mais les lâche devant un bon argument, sait dessiner le système au tableau en dix minutes, accepte le « suffisant pour l’instant ».
Rouges : sur-ingénierie et stack à la mode « parce que c’est intéressant », incapable d’estimer, méprisant envers les sujets non techniques, aucune curiosité pour les clients, « il me faut six mois avant de pouvoir montrer quoi que ce soit ».
Le test : une fonctionnalité de bout en bout
Avant tout engagement, une à deux semaines sur une vraie fonctionnalité du produit, livrée de bout en bout. Tu observes : est-ce qu’il livre ? est-ce qu’il te prévient quand il est bloqué, ou tu le découvres à la fin ? le résultat est-il à peu près maintenable, ou bricolé au point d’être jetable ? Le détail du protocole est dans Comment trouver un cofondateur.
Combien de parts pour un cofondateur technique
Le titre de CTO ne se paie pas en parts : le risque pris et le travail à venir, si. Deux cas nets :
- Vrai cofondateur : à temps plein, à partir de presque rien, il porte tout le produit et la feuille de route technique pour des années. La bonne fourchette est proche de la parité. Donner 10-15 % à la personne qui construit l’intégralité du produit est l’erreur classique du fondateur non technique, et elle explose en moins d’un an. Y Combinator recommande d’ailleurs d’être généreux, pas économe, avec l’equity des cofondateurs.
- Il rejoint après le lancement, avec un produit qui tourne déjà et un début de revenus : c’est un arrivant plus tardif : souvent 5 à 15 %, en parts ou en BSPCE , avec un vesting de quatre ans qui démarre à son entrée.
La méthode pour poser le chiffre exact : Répartition des parts entre cofondateurs.
Et si tu construisais la v1 toi-même ?
Parfois, la bonne première étape n’est pas de chercher un cofondateur technique mais de retirer le risque avant de chercher. Un prototype no-code (ou juste assez de code pour une démo qui tient), mis entre les mains de quelques utilisateurs, transforme la conversation : tu ne proposes plus « une idée et un fondateur non technique » mais « un problème validé, des premiers usages, et une place de cofondateur ». Le nombre de développeurs sérieux qui répondent oui n’est pas le même.
Ça ne remplace pas un cofondateur technique si la technologie est ton avantage, ça te met en meilleure position pour en attirer un bon.
Ce qu’un bon associé technique évalue chez toi
L’évaluation n’est pas à sens unique. De son côté, il regarde :
- Ta capacité à vendre et à distribuer. Son cauchemar, c’est construire pour un fondateur qui n’arrive pas à trouver de clients.
- Ta culture technique. Assez pour ne pas le micro-manager et pour trancher les compromis ensemble, pas plus.
- L’équité de l’offre de parts. Une proposition à 10 % lui dit que tu n’as pas compris ce que tu lui demandes.
- Ton engagement réel. Temps plein, économies en jeu, pas un side-project que tu gardes « au cas où ».
- Le problème. Est-ce qu’il est réel, et est-ce que tu y tiens au-delà de « monter une boîte, c’est cool » ?