S'associer avec un développeur sur une poignée de mains et une répartition des parts au feeling, c'est l'un des paris les plus risqués qu'on puisse faire au démarrage. Tant que tout va bien, personne ne pense au pacte. Le jour où ça se tend, son absence peut coûter votre entreprise. Je l'ai vu plusieurs fois, et c'est toujours évitable.
Un pacte d'associés avec un cofondateur technique doit au minimum fixer le vesting des parts (acquisition progressive sur quatre ans), un cliff d'un an, des clauses de départ (bad leaver et good leaver), et la propriété du code par la société, pas par le développeur. Ces clauses protègent l'entreprise si l'association tourne court, ce qui arrive plus souvent qu'on ne croit.
Je ne suis pas juriste et un pacte se rédige avec un avocat. Mon rôle ici est de vous dire, du point de vue d'un dirigeant tech, quelles clauses comptent vraiment et pourquoi. Pour le cadre plus large de la construction d'équipe, voyez le guide pour construire son équipe tech et produit.
Les clauses qui comptent vraiment
Un pacte fait parfois trente pages, mais quelques clauses font 90 % de la protection. Voici celles qui vous évitent les pires scénarios, dans l'ordre où je les regarde.
Le vesting : on gagne ses parts dans le temps
Sans vesting, votre cofondateur détient ses parts immédiatement et pour toujours, même s'il part au bout de six mois. Le vesting fait acquérir les parts progressivement, en général sur quatre ans. S'il s'en va en cours de route, il ne garde que ce qu'il a réellement gagné. C'est la clause la plus importante du pacte, et l'absence de vesting est le cauchemar classique du démarrage.
Le cliff : la première année à l'essai
Le cliff est une période, typiquement un an, pendant laquelle aucune part n'est acquise. Si l'association se termine avant le terme du cliff, le cofondateur repart avec zéro. C'est ce qui vous protège du pire cas : quelqu'un qui s'avère ne pas convenir dans les premiers mois et qui, sans cliff, partirait avec une part définitive de votre capital pour quelques semaines de travail.
Bad leaver et good leaver : tous les départs ne se valent pas
Le pacte distingue les conditions de départ. Le good leaver (départ légitime : maladie, accord mutuel) conserve ses parts acquises à des conditions normales. Le bad leaver (faute, départ brutal, concurrence déloyale) peut être obligé de céder ses parts, parfois à un prix décoté. Cette distinction évite qu'un départ conflictuel ne vous laisse avec un associé absent qui bloque vos décisions.
La propriété du code : à la société, jamais à la personne
Point critique souvent oublié. Sans clause explicite de cession de propriété intellectuelle à la société, c'est le développeur qui détient juridiquement le code qu'il a écrit. S'il part fâché, vous pouvez vous retrouver sans droit clair sur votre propre produit. Le pacte doit prévoir que tout ce qui est produit appartient à l'entreprise, sans ambiguïté possible.
Ces quatre clauses ne couvrent pas tout, mais elles traitent les scénarios qui détruisent réellement des startups. Un avocat ajoutera les clauses de sortie, de préemption, d'agrément et de non-concurrence selon votre situation.
Ce que j'ai vu mal tourner faute de pacte
Les histoires se ressemblent toutes. Au début, l'enthousiasme et la confiance rendent le pacte « inutile, on se connaît ». Puis la réalité s'invite : un cofondateur qui décroche, un désaccord de vision, une opportunité ailleurs, et soudain la question des parts devient existentielle.
Il détenait 40 % de la société, il ne codait plus depuis longtemps, et juridiquement je ne pouvais rien faire. J'ai passé un an à racheter mes propres parts au lieu de construire.
Le scénario le plus douloureux : un cofondateur technique qui s'en va tôt, sans vesting ni cliff, et qui garde une part importante du capital. Vous vous retrouvez à porter seul l'entreprise tout en ayant cédé une fraction définitive à quelqu'un qui n'y contribue plus. Cela rend les levées de fonds difficiles, parce qu'aucun investisseur ne veut financer une société dont une grosse part dort entre les mains d'un absent.
L'autre cas fréquent est la propriété du code restée floue. Le développeur part, emporte de fait la connaissance, et la question « à qui appartient ce qui a été écrit ? » n'a jamais été tranchée. Sans clause, c'est une zone grise dangereuse au pire moment.
Le pacte n'est pas un signe de méfiance
Beaucoup de fondateurs repoussent le pacte par peur de froisser leur cofondateur, comme si le proposer revenait à anticiper l'échec. C'est l'inverse. Un pacte bien fait protège les deux parties, pas seulement vous. Il dit clairement ce que chacun gagne en restant et en s'investissant, et il évite que la confiance du début ne se transforme en conflit faute de règles écrites.
Le bon moment pour en parler est avant que les parts ne soient distribuées, quand la relation est saine et que personne n'a d'intérêt à se braquer. Plus tard, chaque clause devient une négociation, parce qu'on touche à quelque chose que l'autre considère déjà comme acquis.
Si vous vous apprêtez à donner des parts à un cofondateur technique, posez le pacte d'abord. Vesting, cliff, clauses de départ et propriété du code se discutent à froid, pas après un conflit. Faites-le rédiger par un avocat, mais arrivez en sachant ce que vous voulez : c'est votre entreprise qui se protège, pas votre confiance qui s'efface.
Ce sujet rejoint directement la question de l'equity quand vous cherchez à attirer un développeur sans gros budget : une part au capital n'a de valeur, pour vous comme pour lui, que si elle est encadrée. Je l'aborde sous l'angle recrutement dans où trouver un bon développeur pour sa startup, et plus largement dans composer sa première équipe tech après le MVP.
J'interviens comme CTO fractional pour vous aider à cadrer la relation avec un cofondateur ou un premier développeur, côté technique et humain. Découvrez la création d'équipe tech et produit, ou réservons 30 minutes pour en parler.
Et maintenant ?
Où en êtes-vous ?
Choisissez la situation qui vous ressemble. Pour chacune : ce que je vous conseille de lire, et ce que je peux faire avec vous.
Personne en interne ne sait arbitrer la technique
Les choix se prennent sans vous, et vous en découvrez les effets après coup.
Mon prestataire est le seul à connaître mon produit
Personne en interne ne sait reprendre le code ni les serveurs.
Je dois recruter mes premiers profils techniques
Le premier recrutement conditionne tous les suivants.
ou appelez-moi au 06 20 52 03 69