Bus factor: le risque que les investisseurs sous-estiment le plus

Demandez à un investisseur ce qui l’inquiète dans une startup tech, il répondra marché, traction, équipe. Demandez à un auditeur technique ce qui fait réellement dérailler les sociétés qu’il a vues de près, la réponse tient en une question : que se passe-t-il si le développeur principal part demain ? Ce risque a un nom, une mesure, et une particularité qui le distingue de tous les autres : il ne se répare pas après coup.

Qu’est-ce que le bus factor, exactement ?

Le bus factor, ou facteur d’autobus, est une mesure du risque dû à l’absence de partage d’informations et de compétences au sein d’une équipe : concrètement, le nombre de membres dont la disparition soudaine (l’autobus de la métaphore, mais un préavis de démission produit le même effet) suffirait à bloquer le projet (facteur d’autobus, Wikipédia). Le concept prolonge une idée bien plus ancienne du monde de l’assurance, l’homme clé, en l’appliquant à ce qui fait la valeur d’une société de logiciel : la connaissance de son propre système.

Dans les startups early stage, la mesure donne presque toujours le même résultat : 1. Un fondateur technique ou un premier développeur a construit l’essentiel seul, dans l’urgence légitime des débuts, et personne d’autre ne sait déployer, ne comprend le cœur métier, ne connaît les pièges. Ce n’est la faute de personne : c’est la trajectoire naturelle de tout projet qui va vite. C’est aussi, à partir d’un certain enjeu, une bombe à retardement posée sur la table de la levée de fonds.

Pourquoi ce risque pèse-t-il plus qu’un code imparfait ?

Parce que tous les autres défauts techniques s’achètent, et pas celui-là. Une architecture datée se modernise, une dette technique se rembourse, des tests manquants s’écrivent : autant de problèmes qui se convertissent en budget et en délai, désagréables mais solubles. Nous avons d’ailleurs détaillé comment mesurer la dette technique précisément parce qu’elle se gère. La connaissance concentrée dans une seule tête, elle, disparaît avec la tête : aucun budget ne rachète la mémoire d’un développeur parti fâché, et la reconstruire depuis le code seul coûte des mois, quand c’est possible.

C’est ce qui devrait en faire un point central de toute due diligence technique, et c’est pourtant l’axe le moins outillé des grilles d’audit : la dette se voit dans le code, le bus factor ne se voit que dans l’organisation. Un auditeur pressé peut le manquer ; les conséquences, elles, ne manquent jamais. Le scénario classique que ce risque recouvre : une jeune société en discussion avancée avec un fonds, un développeur unique qui annonce son départ entre deux tours de table, et une valorisation qui se renégocie brutalement, non parce que le produit a changé, mais parce que sa transférabilité vient de s’effondrer. Le même mécanisme, un cran plus loin, produit les logiciels orphelins que nous décrivons dans que faire d’un logiciel sans développeur.

Comment mesurer le bus factor sans lire une ligne de code ?

C’est la bonne nouvelle : ce risque, invisible dans le code, est le plus facile à mesurer en entretien. La mesure vaut d’ailleurs d’être répétée : un bus factor sain à la levée peut retomber à 1 dix-huit mois plus tard, après deux départs et une croissance rapide, et personne ne s’en aperçoit tant que personne ne repose les questions. Un point semestriel suffit. Cinq questions suffisent, et elles sont posables par un investisseur, un dirigeant ou un acquéreur sans aucune compétence technique :

1. « Si votre développeur principal partait demain, combien de temps avant de livrer à nouveau ? » La seule réponse rassurante est un délai chiffré et argumenté. Un silence, un rire ou un « ça n’arrivera pas » sont la réponse.
2. « Qui d’autre a déjà déployé en production, seul ? » Pas « qui saurait » : qui l’a fait. La différence entre les deux est exactement l’épaisseur du risque.
3. « Montrez-moi ce qu’utiliserait son remplaçant pour prendre le relais. » Une documentation d’architecture datée du mois dernier et un dépôt de code commenté racontent une histoire ; « tout est dans sa tête, mais il est très disponible » en raconte une autre.
4. « Quand quelqu’un modifie le code, qui relit ? » La revue systématique par un second regard est le mécanisme le moins cher jamais inventé pour diffuser la connaissance. Son absence signifie que chaque ligne n’existe que pour son auteur.
5. « Quelles zones du système une seule personne comprend-elle ? » L’équipe honnête répond en listant ; l’équipe en danger répond « aucune » sans réfléchir.

Que faire, côté investisseur, face à un bus factor de 1 ?

Le transformer en conditions, pas en veto : un bus factor de 1 est la norme en early stage, et le sanctionner aveuglément reviendrait à ne financer personne. La réponse mature tient en quatre leviers, à calibrer selon le stade. D’abord le nommer dans l’audit, noir sur blanc, avec la liste des zones concernées : c’est le même réflexe que pour tout constat d’audit d’acquisition, faire ressortir la faiblesse pour la traiter, pas pour l’agiter. Ensuite financer explicitement sa résorption : une ligne du plan post-investissement dédiée à la documentation, à l’automatisation des déploiements et, le moment venu, au recrutement, avec un jalon à 6 ou 12 mois. Puis sécuriser la personne clé pendant la transition : un package de rétention honnête et, pour les cas les plus concentrés, une assurance homme clé qui couvre au moins le coût de la reconstruction. Enfin vérifier la réversibilité de l’externalisation quand la tech est portée par un prestataire : contrat, documentation et propriété du code font alors office de bus factor contractuel.

Ce que l’investisseur ne devrait jamais accepter, en revanche : un bus factor de 1 nié par l’équipe. Le risque assumé se gère ; le risque invisible aux yeux de ceux qui le portent est celui qui se matérialise.

Comment faire remonter un bus factor de 1 ?

Par des pratiques, pas par un recrutement de panique. Recruter un second développeur ne partage rien par magie : sans les mécanismes ci-dessous, on obtient deux silos au lieu d’un. Les quatre leviers, par ordre de rendement : la revue de code systématique (chaque modification lue par un autre cerveau avant d’entrer en production : la connaissance se diffuse au fil de l’eau, sans réunion) ; la documentation vivante (pas un roman : l’architecture, les décisions structurantes et leurs raisons, les procédures d’urgence, tenues à jour comme le code) ; l’automatisation des déploiements (un déploiement en un clic, reproductible, que n’importe qui peut déclencher, transforme un rituel personnel en outil d’équipe) ; et les standards éprouvés (chaque choix exotique crée de la connaissance non transférable ; chaque brique standard rend le remplaçant productif plus vite).

En pratique, un plan de 90 jours suffit à changer la donne quand le sujet est pris au sérieux :

1. Semaines 1 à 2 : cartographier. Lister les zones du système et, pour chacune, qui la comprend. Le simple exercice révèle des surprises, y compris à l’équipe elle-même.
2. Semaines 3 à 6 : documenter les trois zones les plus critiques. Pas tout, pas parfaitement : l’architecture, les procédures de déploiement et d’urgence, les décisions structurantes avec leurs raisons.
3. Semaines 7 à 10 : automatiser le déploiement. C’est l’investissement au meilleur rendement du plan : il transforme le geste le plus risqué du projet en bouton que tout le monde peut presser.
4. Semaines 11 à 13 : instaurer la revue croisée et tourner les sujets. À partir de là, la diffusion de la connaissance devient un sous-produit du travail quotidien, plus un chantier.

Le cas de l’équipe d’une seule personne mérite un mot, parce qu’il concerne la moitié des projets early stage : un fondateur-développeur solo ne fera jamais relire son code par un jumeau. Son bus factor de 1 se compense autrement, par la transférabilité : un socle technique standard plutôt qu’exotique, une documentation tenue comme si le remplaçant arrivait lundi, des déploiements scriptés, et un dépôt propre. La question de l’investisseur change alors de forme : non pas « qui d’autre sait ? » mais « en combien de temps une équipe compétente reprendrait-elle ? ». Deux semaines est une bonne réponse ; « aucune idée » n’en est pas une.

Un angle mort complète le tableau : le bus factor des accès. Au-delà du savoir, qui peut techniquement agir ? Si les accès à l’hébergeur, au nom de domaine, aux sauvegardes et aux services critiques vivent sur le compte personnel d’une seule personne, le départ bloque même une équipe qui saurait quoi faire. L’inventaire des accès, avec un coffre partagé et une procédure de révocation, fait partie du même chantier que la documentation, pour un après-midi de travail.

Ces pratiques ont un point commun : elles transforment un savoir individuel en actif de l’entreprise, c’est-à-dire, du point de vue d’un investisseur, en valeur qui reste après les départs. Elles rejoignent la propriété du code, l’autre pilier de la transférabilité, que nous traitons dans un article dédié de cette série : un actif logiciel vaut ce qu’il reste quand les personnes changent.

Une transparence pour finir, parce que le sujet nous concerne directement : un studio structuré atteint un bus factor sain par construction, revue croisée entre fondateurs, documentation systématique, déploiements automatisés, socle standard, et c’est notre méthode sur chaque projet comme sur nos propres produits. Mais l’honnêteté oblige à retourner l’argument : confier son produit à un prestataire sans réversibilité organisée, c’est déplacer le bus factor, pas le supprimer. La vraie protection est contractuelle et technique à la fois : code au nom du client, documentation livrée en continu, et un produit qu’une autre équipe pourrait reprendre demain. C’est le standard que nous appliquons, y compris en dev for equity, et c’est celui que vous devriez exiger de quiconque touche à votre logiciel.

Si vous évaluez une société, la vôtre ou une cible, et que la question « que se passe-t-il si le dev principal part demain ? » n’a pas de réponse écrite, parlons-en : quelques jours d’audit suffisent à transformer ce point aveugle en plan d’action, et c’est toujours moins cher avant la signature qu’après le préavis.