Bus factor : ce que tout fondateur non technique doit savoir quand un seul développeur tient le code

Carla était partie depuis trois heures pour un déplacement client à Austin quand le WhatsApp est tombé. Son unique développeur, Vinicius, était aux urgences avec une appendicite perforée. Il allait s’en sortir. La release de mardi, non. Il y avait un bug de paiement en production qu’il était en train de corriger dans son coin, une pull request ouverte sur une feature qu’elle avait promise à un client pour la semaine suivante, et une migration de base de données qu’il avait écrite et que personne d’autre dans l’entreprise n’avait jamais regardée. Carla, COO et cofondatrice d’une legaltech de 14 personnes, s’est assise à l’arrière d’un Lyft et a essayé de penser à qui, dans son équipe, pouvait au moins ouvrir le dépôt.

Personne ne pouvait. La réponse était personne.

C’est ce que le bus factor mesure. Le bus factor d’un logiciel est le nombre de personnes de l’équipe qui devraient disparaître, en même temps, pour que le projet s’arrête. La version classique de la question est morbide (le bus). La version honnête est banale : le développeur accepte un poste chez Anthropic, part en congé paternité, attrape une appendicite, ou tourne simplement vers un autre client et répond désormais sur Slack avec trois heures de retard. Dans tous ces cas le bus factor de votre produit est le même nombre, et pour la plupart des startups en phase initiale construites autour d’un seul ingénieur, ce nombre est un.

Cet article s’adresse au fondateur non technique qui a lu le paragraphe précédent avec ce sentiment précis d’angoisse qui vient de s’y reconnaître. Il fait trois choses. Il vous dit ce que le bus factor mesure réellement à l’intérieur de votre entreprise, indépendamment de ce qu’un blog d’ingénierie vous dira que cela signifie. Il explique pourquoi la solution évidente (recruter un deuxième développeur) aggrave souvent la dépendance avant de l’arranger. Et il vous donne un plan en quatre étapes que vous pouvez mener ce trimestre sans doubler votre effectif.

Ce que le bus factor signifie vraiment, en un paragraphe

Le bus factor est le nombre minimum de personnes sur un projet qui, si elles arrêtaient soudainement de contribuer, laisseraient le travail incapable de continuer. Le terme est apparu dans les communautés de programmation dans les années 1990 comme un humour noir sur le risque de personne clé. Un projet avec un bus factor de un est un projet où exactement une personne peut faire avancer le code. Un projet avec un bus factor de trois est un projet où trois personnes devraient disparaître en même temps avant que le travail ne s’arrête. Plus haut, c’est plus sûr. Plus bas, c’est plus fragile. Pour un fondateur non technique, la définition pratique est encore plus simple : le bus factor est la question de savoir combien de personnes dans votre entreprise peuvent déployer un correctif sur le logiciel en production demain matin, sans préavis, sans casser le reste. Pour la plupart des startups avec un seul développeur, la réponse est un. Que la réponse soit un n’est pas inhabituel. Que la réponse soit un et que vous ne le sachiez pas, voilà le vrai problème.

Trois problèmes cachés dans une seule question

Quand un fondateur dit “je m’inquiète de ce qui se passerait si mon développeur démissionnait,” il s’inquiète en réalité de trois choses différentes qui se mélangent. Les séparer est le premier mouvement, parce que chacune se résout par une intervention différente.

Concentration des connaissances

Le premier problème est que le logiciel en production est un système qui fonctionne, mais l’explication de pourquoi il fonctionne ainsi vit dans la tête d’une seule personne. Pourquoi la table des paiements est-elle dénormalisée ? Pourquoi le flux d’authentification a-t-il un timeout de 90 secondes ? Pourquoi y a-t-il un Cloudflare worker qui réécrit l’URL les mardis soir ? Le code vous montre ce qui se passe. Il ne vous montre pas pourquoi. Le raisonnement, les compromis et le long catalogue des “on a essayé ça et ça a cassé la prod” sont des connaissances tacites. Elles n’entrent jamais dans le dépôt. Quand votre unique développeur part, le code reste. Les raisons de sa forme actuelle, non.

Le signe que c’est votre problème : vous pouvez voir qui a écrit quel fichier, mais vous ne trouvez pas un seul document, commentaire ou réunion enregistrée qui explique les choix d’architecture que vous avez déjà payés.

Continuité opérationnelle

Le deuxième problème est que même si le système continuait de tourner en pilote automatique, vous n’avez personne capable de le modifier. Un petit correctif en production un mardi matin est une bête différente de reconstruire le système à partir de zéro. Le premier pose la question : quelqu’un en qui vous avez confiance peut-il ouvrir le projet, trouver le bug, déployer un patch, et ne pas casser le reste ? Si la réponse est non, alors un désagrément de routine (un développeur en vacances, une grippe, un retour de congé décalé) devient une indisponibilité visible pour les clients. C’est le problème du bus factor dans son sens le plus étroit et le plus immédiat, et c’est celui que la plupart des fondateurs ressentent en premier.

Le signe que c’est votre problème : une feature est “presque prête” depuis deux mois et personne d’autre que le développeur original ne peut dire où elle en est.

Propriété stratégique

Le troisième problème est plus abstrait et c’est celui que les fondateurs voient rarement avant d’être profondément dedans. Qui décide de ce que devient la base de code ensuite ? Quand la seule personne qui comprend complètement le système actuel est aussi la seule capable de vous dire de façon crédible ce qui est ou n’est pas constructible dans les six mois à venir, votre roadmap produit est implicitement co-écrite par cette personne. Ses incitations et les vôtres peuvent se recouper parfaitement. Elles peuvent ne pas se recouper. Dans tous les cas, une roadmap avec un point unique de défaillance stratégique est une roadmap fragile.

Le signe que c’est votre problème : quand vous apportez des idées produit à votre développeur, chaque réponse prend la forme “il faudrait reconstruire X” ou “on a déjà essayé Y” et vous ne pouvez pas évaluer de façon indépendante si ces cadrages sont exacts.

Ces trois problèmes répondent à la même question de surface. Ils ne se résolvent pas par la même intervention. Une erreur fréquente du fondateur est d’essayer de résoudre les trois en recrutant un deuxième développeur d’un coup, et ce mouvement tend à échouer en n’adressant aucun en particulier.

Pourquoi votre bus factor est probablement 1 et que vous l’ignorez

La plupart des fondateurs non techniques, quand on leur pose la question, disent qu’ils pensent que leur bus factor est probablement 1, mais ils ne le savent pas vraiment. Trois confusions en sont généralement responsables.

La première est de compter ceux qui ont touché au dépôt. Un fondateur avec un développeur et un contractor à temps partiel va compter le contractor. Le contractor a poussé quatre pull requests cette année, toutes petites, toutes dans des parties du système que le contractor connaissait déjà. Le bus factor n’est pas le nombre de personnes qui ont touché au dépôt. C’est le nombre de personnes capables d’ouvrir le portable demain et de corriger le bug en production que le fondateur ne peut pas décrire. Ce nombre est presque toujours un.

La deuxième est de confondre “avoir des sauvegardes” avec “avoir de la redondance”. Les sauvegardes protègent les données. La redondance protège la continuité. Le code est sur GitHub. L’infrastructure tourne sur AWS. Chaque secret est dans 1Password. C’est de la redondance de données, et c’est bien. Cela ne dit rien sur la capacité d’une autre personne de l’entreprise à faire monter le bus factor de un à deux. Une sauvegarde est une photo figée du système. La redondance est une deuxième personne capable de conduire la voiture.

La troisième est de confondre “on a de la documentation” avec “on a un savoir transférable”. Une page de wiki qui dit “le flux d’auth est dans /src/auth” est techniquement de la documentation. Elle ne transfère pas la connaissance de pourquoi le flux d’auth fait timeout au bout de 90 secondes. Le test de la documentation n’est pas de savoir si elle existe. Le test est de savoir si un développeur compétent et nouveau, avec la documentation et le code en main, peut déployer un correctif de routine dans sa première semaine sans l’auteur original présent. Ce niveau est beaucoup plus élevé que la plupart des fondateurs ne le réalisent.

La solution courante qui aggrave le problème

La réaction la plus courante d’un fondateur en découvrant un bus factor de 1 est de recruter un deuxième développeur. C’est parfois le bon mouvement et presque toujours exécuté de travers. Vous recrutez le Développeur Deux. Vous l’embarquez, lui donnez accès à tout, le pointez vers le code et lui demandez de “monter en compétence”. Pendant les deux mois suivants, le Développeur Deux écrit du code, apprend le système et demande du contexte au Développeur Un en permanence. Le Développeur Un, déjà à 110% d’utilisation, devient le goulot d’étranglement de la courbe d’apprentissage du Développeur Deux, et l’entreprise passe donc d’un développeur productif à un peu moins d’un développeur productif plus une masse salariale plus lourde.

Au mois trois, l’une de deux choses se produit. Le Développeur Deux a intériorisé suffisamment le système pour être utile et votre bus factor est maintenant 2. Ou le Développeur Deux a intériorisé la surface du système mais pas les raisons, et donc votre bus factor reste 1, simplement caché par l’existence d’une deuxième personne capable de répondre de façon plausible “je vais regarder”. Ce second cas est plus fréquent et plus difficile à détecter parce que l’effectif a doublé.

Le problème plus profond est que “recruter un deuxième développeur” confond masse salariale et redondance. Deux développeurs qui dépendent tous les deux de la même personne pour leur expliquer le code sont un bus factor de 1, quel que soit le nombre de personnes dans l’équipe. La redondance que vous voulez n’est pas dans l’effectif. Elle est dans le savoir transférable. L’effectif ne devient utile qu’une fois que le savoir a été externalisé.

La séquence correcte est d’externaliser d’abord, recruter ensuite. Le reste de cet article est le playbook pour le faire dans cet ordre.

Cinq questions à se poser si vous avez un seul développeur

Avant de faire le moindre mouvement, lancez le diagnostic en cinq questions. Chaque réponse est un paragraphe, pas un oui ou un non. Le but est d’avoir une image lucide de votre exposition réelle.

1. Un nouveau développeur, avec le dépôt et la documentation en main, pourrait-il déployer un correctif de routine dans sa première semaine sans votre développeur actuel présent ? C’est le test pratique de combien de savoir est capturé par écrit par rapport à combien vit dans une tête. Si la réponse honnête est “non”, vous avez un problème de concentration des connaissances, pas un problème de recrutement.

2. Votre développeur actuel peut-il partir dix jours en vacances sans que votre activité s’arrête ? C’est le test de continuité opérationnelle. Si des vacances normales semblent risquées, vous avez un problème de continuité. La solution n’est peut-être pas une deuxième personne. Cela peut être du processus : une procédure de release documentée, un playbook de support pour les bugs connus, une règle claire de ce qui se reporte par rapport à ce qui s’escalade.

3. Quand vous apportez des idées produit à votre développeur, pouvez-vous évaluer de façon indépendante la réponse technique qu’il vous donne ? C’est le test de propriété stratégique. Si tout “on ne peut pas construire ça parce que…” est impossible à contester pour vous, vous n’avez pas un problème de roadmap avec votre développeur. Vous avez un problème de roadmap avec vous-même, et la réponse est un avis technique indépendant, pas un deuxième recrutement.

4. Si votre développeur actuel partait demain avec deux semaines de préavis, que devrait contenir le document de passation pour que l’entreprise continue de fonctionner ? C’est l’exercice le plus utile de cet article. La plupart des fondateurs, en se le posant, réalisent que le document n’existe pas et n’est pas facile à écrire. L’exercice d’écrire le document, c’est l’externalisation.

5. Financez-vous du logiciel parce qu’il est central à votre activité, ou parce que vous ne pouvez plus vous permettre de ne pas le financer ? C’est la question que personne ne pose. Certaines entreprises ont un seul développeur parce que c’est genuinement la bonne forme pour le stade. D’autres entreprises ont un seul développeur parce qu’elles se sont retrouvées dans du logiciel sur mesure et se sentent maintenant coincées. Le second cas se résout parfois non pas en augmentant le bus factor mais en réduisant la surface de code sur mesure (voir comment créer un logiciel quand vous n’êtes pas le développeur pour le diagnostic qui distingue les deux).

Les réponses à ces cinq questions vous disent lequel des trois problèmes ci-dessus est le vôtre, et cela détermine ce que vous faites ensuite.

Quatre étapes pour faire monter votre bus factor sans doubler l’effectif

Si le diagnostic confirme que vous avez un problème de bus factor et non un problème de roadmap ou un problème de processus, voici la séquence qui fonctionne vraiment.

Étape 1 : Externaliser d’abord le savoir le plus à risque

Le premier mouvement n’est pas un recrutement. C’est un exercice d’écriture. Asseyez-vous avec votre développeur deux heures par semaine, toutes les semaines, pendant quatre semaines, et produisez un petit ensemble de documents écrits pour un nouveau développeur qui ne connaît pas encore le code. Pas de documentation autogénérée. De la vraie prose. L’ensemble est court.

Une carte du système d’une page : quels sont les composants principaux, ce que chacun fait, ce qui appelle quoi. Un runbook opérationnel d’une page : comment se passent les releases, où vont les alertes, quoi faire à 3h du matin quand la passerelle de paiement tombe. Un journal de décisions d’architecture d’une page : les quatre ou cinq décisions qui contraignent le système aujourd’hui, pourquoi chacune a été prise, et ce qui a été envisagé puis rejeté. Un document “si je devais partir demain”, écrit par le développeur dans sa propre voix, listant les bouts en suspens, les features à moitié finies, les parties du code qu’il ne laisserait pas un ingénieur junior toucher sans accompagnement, et la liste explicite des choses qu’il voulait corriger et n’a pas corrigées.

Si votre développeur résiste à cet exercice, c’est en soi une découverte. Certains développeurs résistent à la documentation parce que le contrat implicite a été “vous n’avez pas besoin de savoir ce que je sais”. Ce n’est pas toujours conscient et ce n’est pas toujours malveillant, mais c’est un signal à noter. Soulevez-le directement : ce travail est pour l’entreprise, pas pour vous, et il aidera aussi quand lui partira en vacances.

Étape 2 : Racheter la dépendance en commits, pas en effectif

Le mouvement le moins coûteux et le plus à effet de levier disponible pour un fondateur non technique avec un seul développeur est d’amener une seconde paire de mains à temps partiel, pas comme un recrutement pair à pair, mais comme un mécanisme de transfert de connaissances. Trois options fonctionnent en pratique. Un ingénieur senior fractional qui fait du code review et du pair programming quatre heures par semaine. Une petite équipe partenaire (une software house focalisée ou un binôme de contractors de confiance) qui prend un chantier délimité et le livre seule en faisant remonter ses questions à votre développeur actuel. Ou un seul ingénieur senior recruté spécifiquement pour observer et absorber, avec le mandat explicite que ses six premières semaines soient consacrées à l’apprentissage, pas à la livraison.

La raison pour laquelle cela fonctionne mieux qu’un recrutement pair à pair est que l’objectif explicite est le transfert de connaissances, pas la croissance de l’effectif. Le contrat est court. Le coût est faible. Le bus factor passe de 1 à 2 en commits, lentement, et ce que vous achetez, c’est une deuxième personne qui a effectivement touché au code de production. Pour une comparaison plus poussée de ces structures, la décision entre équipe interne et externalisation couvre le même terrain depuis l’autre côté.

Étape 3 : Convertir le savoir tacite en specs explicites, un chantier à la fois

Pendant que l’Étape 1 produit les documents fondateurs et que l’Étape 2 amène une seconde paire de mains dans le code, la troisième étape consiste à commencer à convertir le flux de travail entrant de “piloté par le développeur” à “piloté par la spec”. Chaque nouvelle feature reçoit une spec d’une page avant d’être construite. La spec s’écrit en collaboration. Elle explique le problème métier, la solution proposée, les compromis considérés, les alternatives rejetées et les critères d’acceptation. Le but n’est pas la bureaucratie. Le but est que le raisonnement derrière chaque nouvelle addition au code entre dans la mémoire de l’entreprise au moment où il est construit, plutôt que de devoir être déterré ensuite.

Cela fonctionne le mieux quand le fondateur écrit la première version de la spec et que le développeur l’annote. La friction de cet échange est exactement la friction que vous voulez. Elle force le fondateur à demander pourquoi et le développeur à écrire la réponse. Après trois ou quatre cycles, vous serez tous les deux plus rapides à cela que vous ne l’étiez le premier jour.

Étape 4 : Lancer le test de la “semaine de vacances”

Le diagnostic le plus puissant pour savoir si les trois étapes précédentes ont fonctionné consiste à mettre votre développeur en vacances pendant une semaine de travail complète, sans ordinateur portable et sans Slack. Pas comme un test punitif, comme de vraies vacances payées qu’il avait gagnées. Pendant qu’il est dehors, votre seconde paire de mains (de l’Étape 2) est votre première ligne pour tout incident de production. Votre équipe de support a le runbook documenté de l’Étape 1. Le backlog de specs de l’Étape 3 est là pour que la deuxième personne y pioche.

Si une semaine normale se passe sans un incident que votre équipe ne sait pas gérer, votre bus factor a bougé. Si la semaine s’effondre, vous avez appris exactement lequel des trois sous-problèmes (concentration des connaissances, continuité, propriété) est encore vivant. La version honnête du test de vacances est aussi une décision de bien-être pour votre développeur, qui porte probablement une astreinte invisible depuis longtemps. Le coût caché d’un bus factor de 1, souvent oublié, est le coût payé par le développeur qui n’a aucune façon de se déconnecter pour de vrai.

À quoi ressemble “le bon niveau”

Un bus factor raisonnable pour une startup en phase initiale est deux ou trois. Pas dix. Le coût de le pousser au-dessus de trois avant que l’entreprise ne soit assez grande pour le justifier est gaspillé en contexte dupliqué que personne ne lit. La plupart des entreprises de moins de trente personnes sont bien servies par un bus factor de deux, la deuxième personne étant soit une équipe partenaire, soit un ingénieur senior fractional, soit un cofondateur qui a choisi de garder les mains assez près du code pour être utile en cas d’urgence.

Un bus factor de un n’est pas toujours mauvais. Cela peut être un choix délibéré et limité dans le temps. Le fondateur d’une entreprise de cinq personnes avec un développeur et neuf mois de runway peut genuinement faire le bon choix. L’erreur est de traiter cette condition comme permanente. Le bon cadrage est que le bus factor de un est un état avec une date de péremption connue, et chaque trimestre vous devriez vous demander s’il devrait encore l’être.

Le point plus profond est que le bus factor n’est pas vraiment un nombre. C’est une question sur qui d’autre, dans l’entreprise, détient les clés du système, dans la tête et sur le papier. Une fois que vous avez construit les documents, amené une seconde paire de mains et envoyé votre développeur en vacances sans que le monde s’écroule, vous avez cessé d’être un point unique de défaillance dans votre propre entreprise. C’est ce que la question demande vraiment.

FAQ

Qu’est-ce qu’un bus factor de 1 ? Un bus factor de un signifie qu’une seule personne sur le projet détient le savoir nécessaire pour le maintenir en marche. Si cette personne arrête de contribuer pour n’importe quelle raison (maladie, vacances, nouveau poste, urgence familiale), le travail ne peut pas continuer sans perturbation significative. Pour la plupart des startups en phase initiale avec un seul développeur, le bus factor est un, même quand l’équipe compte plusieurs personnes.

Comment calcule-t-on le bus factor ? Le calcul honnête n’est pas une formule. C’est une expérience de pensée. Prenez un morceau critique de votre logiciel en production (le flux de paiement, le système d’authentification, le modèle de données dont tout le reste dépend) et demandez-vous : combien de personnes dans l’équipe pourraient ouvrir le code demain matin et déployer un correctif de routine sur ce morceau sans casser le reste ? La réponse est le bus factor de cette partie du système. Le bus factor du projet entier est la plus petite de ces réponses sur l’ensemble des chemins critiques. Plusieurs groupes de recherche ont proposé des métriques automatisées basées sur l’historique des commits, mais pour un fondateur, l’expérience de pensée est plus utile que la formule.

Qu’est-ce que le bus factor en pratique ? En pratique le bus factor apparaît non pas comme une catastrophe mais comme une série de petites frictions : un développeur en vacances et un correctif que vous ne pouvez pas déployer, une feature que personne d’autre que l’auteur ne peut expliquer, une roadmap implicitement co-écrite par la seule personne capable d’évaluer la réponse technique. Ces frictions quotidiennes sont l’expérience vécue d’un bus factor bas, longtemps avant que quelqu’un ne soit vraiment renversé par un bus.

Quel est un exemple de bus factor ? Un exemple réel : une legaltech de 14 personnes avec un développeur senior et un contractor à temps partiel. Le développeur senior a écrit la base de code originale, possède le pipeline de déploiement, détient les clés de production et est la seule personne qui ait jamais touché à l’intégration de paiement. Le contractor a poussé quatre correctifs, tous dans des zones que le contractor connaissait déjà. L’entreprise a tout le code sur GitHub, les secrets dans 1Password et l’infrastructure sur AWS. Le bus factor est un. La CEO n’a pas tort de se sentir exposée, et ce qui aiderait vraiment, c’est le plan en quatre étapes ci-dessus, pas un deuxième recrutement pair à pair.

Comment augmenter le bus factor ? En externalisant les connaissances avant d’ajouter de l’effectif. D’abord les documents, ensuite une seconde paire de mains, puis un flux piloté par spec, et une vraie semaine de vacances comme test. Ajouter des personnes sans avoir d’abord externalisé les connaissances qu’elles auraient à absorber ne fait pas monter le bus factor ; cela répartit juste la dépendance sur plus de salaires. La façon la moins chère de passer de un à deux est presque toujours de commencer par un exercice d’écriture, pas par un recrutement. La même logique apparaît dans le coût à long terme de maintenir du logiciel sur mesure : les lignes de budget qui semblent devoir augmenter avec l’effectif augmentent en réalité avec le savoir documenté.

Une fois qu’un fondateur non technique a fait ce travail, l’angoisse d’origine change de forme. La question cesse d’être “qu’est-ce qui se passe si mon développeur démissionne” et devient “quelle partie du système est le prochain point unique de défaillance à démonter”. C’est une bien meilleure question à se poser.