Le "bus factor" est un indice de la robustesse d'un projet face au départ soudain (comme le fait de se faire écraser par un bus) d'un ou plusieurs contributeurs clés du projet.

Ce facteur ne tient compte uniquement que des personnes clés ou irremplaceables dans un projet (ou une entreprise). Est considéré comme tel un contributeur qui :

  • A accès à des informations/fichiers critiques pour le bon déroulé du projet
  • Possède des accès ou des clés de chiffrement globalement non partagés et sans moyens de récupération
  • Est à l'origine de la création d'un composant logiciel clé non-documenté ou obfusqué

Pour chaque personne remplissant au moins un des critères ci-dessus, le bus factor est augmenté de 1, plus ce chiffre est élevé et plus le projet aura de chance de survivre à la "disparition" de l'un des collaborateur. Le facteur le plus critique est de 1 et signifie que le projet pourrait être complêtement arrêté si cette personne venait ne serait-ce qu'à tomber malade, partir en congé subitement ou démissionner.

Le "bus factor" est vu comme un goulot d'étranglement et doit être considéré (et calculé) pour chaque étape d'un projet, exemple :

S'il existe 4 contributeurs clés pour la partie front-end, 3 contributeurs clés pour la partie back-end et 1 seul contributeur clé pour la gestion de la base de données, alors le "bus factor" global du projet est égal à 1, soit le plus petit facteur parmi les étapes vitales du projet.

Comment augmenter son "bus factor" ?

La réduction des risques liés à ce facteur tient en un seul principe majeur : le partage d'informations.

En effet, dans une équipe où tous les membres ont accès à la même source d'informations, lorsque le code est compris par tous, documenté et que les informations sécurisées sont soumises à une stratégie de récupération en cas d'incident, alors le bus factor est exactement égal au nombre de membres de l'équipe.

En formant ses équipes de manières transversales (sur tous les sujets techniques du projet), en tenant une documentation à jour (et des tests), le tout en découplant suffisamment tous les composants logiciels afin d'en faire baisser la complexité pour que l'ensemble du projet soit compréhensible à tous, alors, même si il n'existe pas de risque zéro, il sera très difficile de mettre le projet en péril.

Fun fact : Dans certaines grandes entreprises, lorsque les employés voyagent ensemble, en avion par exemple, ils sont répartis sur plusieurs vols en cas de drame.

J'espère que cet article vous aura plu, et à bientôt sur le blog !


À propos de l'auteur

Hello, je suis Nicolas Brondin-Bernard, ingénieur web indépendant depuis 2015 passionné par le partage de d'expériences et de connaissances.

Aujourd'hui je suis aussi coach pour développeurs web juniors, tu peux me contacter sur nicolas@brondin.com, sur mon site ou devenir membre de ma newsletter pour ne jamais louper le meilleur article de la semaine et être tenu au courant de mes projets !


Photo par Thomas Reaubourg sur Unsplash