Lorsque l'on vise le long terme pour un projet technique, on se confronte à tous les sujets autour de la pérennité du projet telle que la dette technique, la qualité et la robustesse du code, mais également d'un facteur trop souvent négligé : le "bus factor".

Ce "facteur" est en réalité un indice de la robustesse d'un projet, non pas technique, mais en termes de ressources humaines et de partage de connaissances.

Ce facteur rentre en jeu par exemple lors de la démission ou le décès soudain (comme se faire écraser par un bus) d'un ou plusieurs contributeurs clés du projet.

Le "bus factor" tient compte des personnes clés ou irremplaçables 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 rendu illisible (obfusaction)

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 collaborateurs. 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 améliorer 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 total 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 s'il n'existe pas de risque zéro, il sera très difficile de mettre le projet en péril.

Dans d'autres contextes

Ce facteur de pérennité est également valable dans des contextes d'entreprise hors-numérique, tant que des connaissances métier importantes sont requises pour le bon fonctionnement du projet ou de l'entreprise.

Il existe même, au sein de certaines grosses entreprises industrielles mondiales, des règles concernant le déplacement d'un grand nombre d'employés. Lorsque ces derniers doivent prendre l'avion vers une même destination par exemple, ils sont répartis sur plusieurs vols différents en cas de drame.

J'espère que cet article vous aura été utile, 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 d'expériences et de connaissances.

Aujourd'hui je suis aussi formateur/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