Le bus factor de votre startup : la dépendance humaine que personne ne mesure et qui fait fuir les investisseurs

Un vendredi soir, votre lead dev vous annonce qu’il part dans un mois. Et là, une sueur froide : c’est lui qui a écrit le système de facturation, le module d’authentification, l’intégration avec votre PSP, et accessoirement le script de déploiement que personne d’autre n’a jamais lancé. Vous ne le saviez pas, mais depuis dix-huit mois, votre startup tenait sur une seule tête.

C’est ce qu’on appelle le bus factor : le nombre de personnes qui devraient « se faire renverser par un bus » pour que votre projet s’arrête net. Quand la réponse est « une seule », vous n’avez pas construit une entreprise, vous avez construit une dépendance. Et c’est l’un des rares risques qu’un investisseur sait détecter en trente minutes de due diligence, alors que la plupart des fondateurs ne le mesurent jamais.

Pourquoi ce risque est invisible tant que tout va bien

Le bus factor de 1 ne fait mal que le jour où il fait mal. Tant que la personne clé est là, motivée et en bonne santé, tout roule — mieux, ça roule vite. Un développeur qui connaît par cœur toute la base de code livre trois fois plus vite qu’une équipe qui doit se coordonner. C’est précisément ce qui rend le piège vicieux : la concentration de connaissance ressemble à de la performance.

En pré-seed, c’est même sain. Vous n’allez pas documenter un MVP que vous réécrirez peut-être dans six mois, ni imposer des revues de code à un fondateur technique qui code seul à 2 heures du matin pour tenir une démo. La sur-ingénierie organisationnelle à ce stade est aussi coûteuse que la sur-ingénierie technique : elle vous fait payer aujourd’hui pour un problème qui n’existe pas encore.

Le basculement se produit au moment du seed, puis devient critique à l’approche de la série A. Vous avez maintenant des clients qui paient, un revenu récurrent, des engagements de disponibilité. Le produit que « seule une personne comprend » n’est plus un prototype : c’est votre chiffre d’affaires. Et le fondateur ou le dev qui détient cette connaissance est devenu, sans que personne l’ait décidé, un point de défaillance unique — au même titre qu’un serveur sans réplication.

Ce que l’investisseur voit et que vous ne voyez pas

Un fonds sérieux ne se contente pas de regarder votre courbe de croissance. En due diligence technique, il pose trois questions apparemment banales : « Combien de personnes peuvent déployer en production ? », « Qui peut modifier le système de paiement en cas d’incident ? », « Que se passe-t-il si votre CTO part demain ? »

Si la réponse aux trois est le même prénom, votre valorisation vient de prendre un coup. Pas parce que le code est mauvais, mais parce que l’actif que le fonds achète — votre produit et sa capacité à évoluer — repose sur un contrat de travail qui peut se rompre. On appelle ça le key person risk, et c’est exactement le genre de ligne qui atterrit dans le mémo d’investissement sous la rubrique « risques ».

Le problème se double d’un enjeu de gouvernance côté français. Un fondateur technique indispensable, non remplaçable, mal encadré par le pacte d’associés, c’est un levier de négociation contre vous : le fonds peut exiger des clauses de vesting renforcées, une période de lock-up, voire subordonner son investissement au recrutement d’un second profil senior. Ce que vous viviez comme une force devient un motif de défiance.

Et ce n’est pas qu’une affaire d’investisseurs. La même dépendance vous coûte tous les jours : les congés de la personne clé deviennent des périodes à haut risque, les incidents en production s’allongent parce qu’une seule personne sait où regarder, et le recrutement d’un nouveau dev prend des mois parce que l’onboarding repose sur la disponibilité — toujours saturée — de l’expert maison.

La vraie cause n’est pas le manque de documentation

La réaction réflexe, c’est de décréter un grand chantier de documentation. C’est presque toujours une erreur. On produit alors des dizaines de pages de wiki que personne ne relit, qui se périment en trois semaines, et qui donnent une fausse impression de sécurité. La documentation exhaustive est un remède de confort, pas de fond.

Le bus factor de 1 est d’abord un problème de flux de travail, pas de stock de savoir. Une connaissance ne se transmet pas parce qu’elle est écrite quelque part ; elle se transmet parce que plusieurs personnes la manipulent régulièrement. Une base de code sur laquelle une seule personne travaille restera opaque aux autres même avec un wiki parfait, tout simplement parce que personne d’autre ne la touche.

Le vrai levier, c’est donc l’exposition croisée : faire en sorte que le savoir critique passe entre les mains, pas seulement dans les têtes. Et ça se joue dans la façon dont vous organisez le travail au quotidien, pas dans un sprint de documentation isolé.

Ce qu’il faut vraiment faire, par ordre de priorité

Commencez par cartographier honnêtement votre exposition, sans y consacrer plus d’une heure. Listez les composants critiques — paiement, authentification, déploiement, base de données, intégrations tierces — et notez en face qui sait les faire évoluer et qui sait les réparer sous pression. Vous verrez immédiatement les zones où le bus factor est de 1. N’essayez pas de tout traiter : concentrez-vous sur ce qui, s’il tombe, arrête l’encaissement ou coupe le service.

Ensuite, attaquez la transmission par le geste, pas par le texte. Le pair programming ciblé sur les zones critiques, deux heures par semaine, transmet plus de savoir réel qu’un mois de rédaction. Instaurez une règle simple : personne ne fusionne un changement sur un composant critique sans qu’une deuxième personne l’ait relu — non pas pour la qualité, mais pour la diffusion de connaissance. Faites tourner les responsabilités : celui qui n’a jamais déployé déploie, sous supervision, une fois. La première fois fait peur ; la deuxième, plus du tout.

Documentez, mais uniquement l’irremplaçable et le contextuel : ce qui ne se déduit pas du code. Pourquoi avoir choisi ce prestataire de paiement, quelles décisions d’architecture ont été prises et pour quelles raisons, quelle est la procédure exacte de reprise après incident. Un document court et à jour vaut mille pages exhaustives et périmées. Un README de vingt lignes par service critique, mis à jour à chaque changement majeur, suffit dans 90 % des cas.

Enfin, adaptez l’effort à votre stade. En seed, l’objectif minimal est de passer de « une personne peut tout faire » à « deux personnes peuvent faire l’essentiel » sur les composants qui touchent au revenu. À l’approche de la série A, l’ambition monte : chaque système critique doit avoir au moins deux personnes capables d’intervenir, et le départ de n’importe quel individu doit être un événement gérable, pas une crise. Ce n’est pas un luxe organisationnel — c’est ce qui transforme votre produit d’une performance individuelle en un actif transférable.

La dépendance qui coûte le plus n’est pas toujours technique

Un dernier angle, souvent oublié : le fondateur lui-même est fréquemment le pire bus factor de la boîte. Celui qui a toutes les relations clients dans sa tête, qui négocie tous les gros contrats, qui connaît les mots de passe des comptes stratégiques. La logique est identique à celle du code, et le remède aussi : documenter les décisions, partager les relations, déléguer avant d’y être contraint.

Réduire son bus factor, ce n’est pas se rendre remplaçable par peur de disparaître. C’est reconnaître qu’une entreprise dont la valeur dépend d’une seule présence n’est pas encore une entreprise — c’est un talent avec une facturation. La question à se poser n’est donc pas « qui est indispensable chez nous ? », mais son inverse, bien plus utile : que se passerait-il, concrètement, lundi matin, si cette personne ne venait plus ? Si vous n’avez pas de réponse rassurante, vous savez par où commencer.