- En développement logiciel, le bus factor est un concept qui indique combien de détenteurs d’un savoir donné sont nécessaires pour qu’un projet puisse être maintenu ; auparavant, la pire valeur possible était 1
- Cependant, depuis la publication de ChatGPT (30 novembre 2022), avec l’adoption massive de l’IA générative, beaucoup ne conservent plus eux-mêmes les connaissances et s’en remettent à l’IA, créant de fait une situation de bus factor 0
- Sur le terrain, de plus en plus de développeurs utilisent tels quels le code et les fonctionnalités générés par des LLM, renoncent à faire l’effort de comprendre la base de code et basculent vers le « vibe coding »
- Cela peut conduire, lors de la correction de bugs, de l’application de correctifs de sécurité ou de l’extension de fonctionnalités, à une situation où personne ne sait pourquoi le code a été écrit ainsi
- Cela crée un risque grave pour la fiabilité et la sécurité des logiciels, et constitue une limite fondamentale tant que le jour où l’IA générera parfaitement un code parfait n’est pas arrivé
Concept et histoire du bus factor
- Le bus factor est un concept qui exprime numériquement combien de personnes se partagent une connaissance donnée
- Exemple : si 3 personnes savent restaurer une sauvegarde de base de données, le bus factor de cette fonction est de 3
- Traditionnellement, la pire valeur était 1 : si une seule personne perdait cette connaissance, le projet ne pouvait plus être maintenu
- Pour surmonter ce problème, l’humanité a diffusé le savoir par d’innombrables moyens : documentation, formation, transfert de connaissances, séminaires, écoles, etc.
- Cela a conduit à des efforts systématiques de transmission et de préservation des connaissances, mobilisant d’importantes ressources humaines et du temps
L’arrivée de l’IA et le bus factor 0
- Le lancement de ChatGPT en novembre 2022 a ouvert l’ère du « AI First »
- À mesure que l’IA génère du code et des fonctionnalités, beaucoup de personnes sont écartées du processus de préservation des connaissances et commencent à dépendre des productions de l’IA, ce qui fait chuter brutalement leur compréhension du projet
- Il en résulte une situation où il n’y a tout simplement plus aucun détenteur de la connaissance, autrement dit un bus factor de 0
- Les programmeurs montrent une tendance à déléguer entièrement à l’IA, plutôt que de rédiger et comprendre eux-mêmes le code et les fonctionnalités
- Dans ce processus, les développeurs évitent de comprendre la base de code et de la documenter, et se contentent de redemander des explications à l’IA
Les problèmes du développement basé sur les LLM
- Même en laissant de côté la question de la qualité du code, le point essentiel est que lire et maintenir du code est intrinsèquement plus difficile que l’écrire
- Autrefois, des mentors ou la documentation apportaient au moins un soutien minimal, mais dans un environnement dépendant de l’IA, même ce filet de sécurité disparaît
- Dans un développement basé sur les LLM, le processus de génération du code n’est pas consigné, et même l’IA ne se souvient pas du contexte du code qu’elle a généré
- Au final, les développeurs se retrouvent à devoir analyser et modifier du code écrit par l’IA mais dont le contexte reste flou
- Cela mène, lors de la résolution de bugs, du correctif de vulnérabilités de sécurité ou de la mise à niveau des dépendances, à un état où personne ne connaît l’intention ni la structure du code
Les risques du point de vue des utilisateurs
- Les développeurs ne sont pas les seuls exposés : les utilisateurs le sont aussi
- Les logiciels auxquels on confie des documents personnels, des informations de carte bancaire, des photos privées ou des pensées intimes peuvent avoir été construits avec un code dont personne ne connaît la structure interne ni la finalité
- Cela comporte des risques graves en matière de protection des données et de fiabilité, et soulève des doutes sur la stabilité du service
Conclusion
- Le vibe coding, qui entraîne un bus factor de 0, est une approche fondamentalement défaillante
- C’est une limite inévitable tant que l’IA n’est pas capable de générer un code correct à 100 % à partir de prompts corrects à 100 %
- Dans la situation actuelle, il est donc indispensable de ne pas négliger, en parallèle de l’usage de l’IA, la préservation des connaissances et la compréhension du code, et de maintenir des pratiques de gestion des connaissances et de documentation
3 commentaires
Le bus factor n'est-il pas devenu infini ?
Si les développeurs de l’entreprise n’ont pas les connaissances, le bus factor tend vers 0.
Avis Hacker News
Utiliser un LLM pour simplement générer en masse du code non relu est un mauvais usage ; cela signifie que le projet part structurellement dans la mauvaise direction ou qu’il deviendra vite impossible à maintenir dès que des bugs complexes apparaîtront. La vraie force des LLM se manifeste plutôt dans des situations comme celles-ci : lorsqu’il faut appliquer un algorithme connu à une structure de données existante et complexe ; lorsqu’il faut monter des jeux de tests ou l’ossature de tests unitaires avec beaucoup de dépendances ; lorsqu’on crée un éditeur web visuel avec une API backend et une fonction d’enregistrement dans sqlite ; lorsqu’on doit appliquer à grande échelle, sur une grosse codebase, des transformations répétitives qui restent difficiles même avec des expressions régulières complexes ; etc. En pratique, grâce aux LLM, des tâches qui prenaient une demi-journée ou trois jours peuvent être lancées en 2 minutes. L’important, c’est que même si un LLM ne sait pas résoudre des problèmes très difficiles, il peut quand même fortement augmenter la productivité. On peut se libérer des tâches répétitives et ennuyeuses pour se concentrer sur des problèmes plus intéressants.
Je pensais aussi qu’un LLM finirait en 2 minutes des modifications répétitives sur une grosse codebase, mais après avoir testé moi-même plusieurs grands modèles, j’ai constaté que plus le contexte devient complexe, plus les erreurs s’accumulent ; il arrive aussi parfois qu’ils introduisent des changements sans rapport, si bien qu’au final ce n’était pas fiable. C’est parfait sur de petits exemples, mais insuffisant à grande échelle. On peut améliorer ça avec une agentic loop, mais à force d’exécuter et de relire en boucle, cela finit par prendre beaucoup plus de temps. Il est bien plus fiable de demander au LLM d’écrire un programme qui automatise lui-même les modifications.
Tous les exemples proposés semblent bons, mais il existe en réalité bien plus de cas d’usage possibles. Vous parlez surtout de cas propres aux développeurs expérimentés, mais même pour les personnes peu techniques ou encore en apprentissage, les LLM ont considérablement élargi ce qu’elles peuvent faire. On peut désormais tenter soi-même en 3 minutes quelque chose qu’il fallait auparavant payer 100 dollars. Que le résultat soit parfait et maintenable devient presque secondaire ; montrer que c’est possible a une valeur plus grande.
Je suis d’accord avec votre avis, mais je voulais partager une expérience récente assez drôle. J’ai demandé à Claude d’écrire des tests unitaires et, lors de la revue, il s’est avéré qu’il y avait effectivement un bug dans mon code, que les tests ont détecté. Mais au lieu de corriger le bug, Claude a essayé de faire passer la suite en n’exécutant tout simplement pas le test qui échouait ; une anecdote assez savoureuse de la vraie vie. Les LLM sont faibles pour définir les exigences, concevoir l’architecture ou rédiger des spécifications conformes aux besoins, mais ils sont forts pour les tâches au périmètre clair et à l’impact limité, comme l’écriture de code.
J’ai essayé une étape intermédiaire consistant à laisser l’IA faire automatiquement la review de PR, puis à effectuer une review manuelle. La génération du code prend 5 à 10 minutes, puis la review et les commits supplémentaires demandent généralement 1 à 3 heures, mais j’ai appliqué cette méthode avec succès sur plusieurs projets (10 à 20k LOC, environ 100 fichiers). Avec de bonnes spécifications, beaucoup de fonctionnalités sont implémentées presque correctement sans grosse correction, et les refactorings se font surtout à partir du feedback. Bien sûr, quand ça ne fonctionne pas correctement, il arrive qu’il faille presque une journée pour résoudre le problème, mais dans l’ensemble cela représente un gain de productivité de 3 à 5x. Pour les gros projets, il semble préférable de découper et modulariser.
Les formulations du type « x jours de travail accomplis en 2 minutes avec un LLM » sont un peu exagérées, parce qu’elles n’incluent pas le temps de review. Si on ajoute la review réelle et la validation, cela prend beaucoup plus de temps. On peut même retomber dans la « mauvaise méthode » évoquée au départ.
Cet article présente plusieurs problèmes liés à la génération de code par IA, mais il ne semble pas prendre en compte les solutions déjà existantes ou qui pourraient apparaître. Même avant, si une équipe faisait ne serait-ce qu’un minimum d’effort sur sa codebase, cela pouvait déjà aider les nouveaux arrivants à comprendre le code. Je me demande si l’auteur manque d’expérience avec le legacy code, ou s’il pense vraiment qu’on ne pourra pas corriger le fait que l’IA « oublie tout le contexte du processus de rédaction initial ». Il semble aussi mal comprendre le problème du Bus Factor 0 en pensant qu’il faut le résoudre avec une précision parfaite à 100 %, alors qu’en réalité les humains non plus ne sont pas toujours exacts à 100 %, et pourtant on leur fait confiance.
J’ai eu l’impression que l’article regardait le problème de façon trop simplifiée. La réalité, c’est que nous vivons déjà dans un monde où l’on ne peut pas faire chaque tâche avec son auteur à côté. Le simple fait d’avoir un binôme ou une IA qui explique représente déjà un énorme progrès. On dirait qu’on imagine un monde sans humains, alors que nous vivons déjà souvent ce type de situation.
Je suis l’auteur, je suis d’accord avec la première remarque et je pense aussi que l’IA réduira l’écart à l’avenir. Mais d’ici là, certains problèmes auront peut-être déjà eu le temps d’apparaître. Il y a aussi le problème de laisser derrière soi du code sans contexte logique ni historique de manipulation. On entend souvent dire que l’IA « apprend en permanence », mais en pratique elle n’apprend pas avant l’arrivée d’un nouveau modèle. Les humains non plus ne sont pas exacts à 100 %, mais ils ne sont pas à Bus Factor 0 ; il est plus facile d’identifier et de résoudre les problèmes. Si les autres problèmes sont résolus eux aussi, alors le problème du bus factor diminuera également.
Je me suis souvent dit que j’aurais aimé avoir des outils d’IA quand j’analysais du legacy code. J’ai vraiment connu des situations absurdes du genre : « Le dernier auteur de ce fichier Perl est maintenant directeur d’agence, je dois vraiment prendre un rendez-vous avec lui ? »
À la question « pourquoi faut-il 100 % de précision ? », je pense que les gens critiques envers l’IA ont au contraire tendance à attendre de l’IA qu’elle soit une solution magique et parfaite. C’est un peu la même tonalité que lorsque quelqu’un critique le typage statique en disant « ça n’attrape même pas les erreurs logiques ».
Ces temps-ci, il y a tellement d’images générées par IA sur les blogs que cela finit plutôt par gêner la concentration, et bien souvent ça n’aide pas le contenu.
J’ai récemment rejoint une équipe avec une codebase en désordre ; la plupart des anciens développeurs étaient déjà partis, et même ceux qui restaient connaissaient mal le code. C’était complètement du Bus Factor 0. Étonnamment, l’IA a nettement amélioré la vitesse de compréhension du code, d’identification des intentions et de débogage. On a commencé à extraire de la documentation directement depuis le code avec l’IA. La documentation ou la transmission orale peuvent être déformées, alors que le code est la vérité elle-même. Avec l’aide de l’IA, on a pu créer un environnement où le code s’explique de lui-même, avec un gros gain de productivité à la clé.
Même avant l’arrivée des LLM, le Bus Factor a toujours été un problème. La plupart des entreprises n’ont jamais structuré le travail de façon à ce que plusieurs personnes comprennent chaque partie. Même quand plusieurs personnes sont affectées à différents domaines, le volume de travail continue d’augmenter jusqu’à ce qu’au final plus personne ne comprenne vraiment l’ensemble ; c’est un schéma récurrent. Pour l’éviter complètement, il faut une gestion d’ingénierie énorme, comme faire tourner les personnes dans la codebase, et en général on n’y arrive pas parfaitement à cause de la pression sur la vitesse. J’ai mis par écrit mes retours d’expérience de CTO sur ce sujet dans un livre ici, accessible quel que soit le prix. Je pense que les principes ne diffèrent pas tant que ça entre un environnement où l’on construit des systèmes avec des LLM et un environnement où l’on travaille avec 10 développeurs externes.
Le Bus Factor était déjà un problème avant les LLM ; c’est un terme technique établi depuis longtemps. Le TFA (article d’origine) critique la tendance selon laquelle avant le Bus Factor était de 1, et qu’il glisse maintenant vers 0.
Le volume de travail ne fait qu’augmenter, mais en pratique on n’avance pas vers une direction plus recommandable ; on ne fait que répéter le schéma consistant à bricoler pour tenir les délais. Ajouter quelques obstacles procéduraux ne résout pas le problème.
Notre cerveau cherche à économiser de l’énergie sur les informations qu’il utilise peu ; plus on s’éloigne de quelque chose, moins on le comprend bien ou plus on l’oublie. Même si l’on fait soi-même toute la review du code, ses compétences peuvent quand même se dégrader. C’est un peu comme lorsqu’un ingénieur fait longtemps du management et finit par ne presque plus savoir résoudre de problèmes techniques. Dans l’automatisation automobile aussi, il est difficile de maintenir une implication humaine continue dans les étapes intermédiaires (level2→5), et si la machine n’est pas fiable à 100 %, cela finit par poser problème.
Il y a dans ce débat un point vraiment important : en réalité, ces outils et ces workflows n’en sont qu’au tout début. Je suis convaincu qu’à l’avenir l’IA pourra résoudre ce type de problèmes mieux que les humains. J’ai moi-même expérimenté l’usage de LLM, avec quelques succès et quelques échecs, mais dans certains domaines ils montrent clairement des capacités remarquables. Les LLM ne se lassent pas et peuvent mettre à jour avec soin la documentation, les commentaires, les README et même les ADR. Avec suffisamment de guides et de structure, une codebase LLM pourrait à long terme être au contraire plus facile d’accès, justement parce qu’elle aurait tendance à être mieux documentée.
Je pense que l’article néglige le fait qu’on peut déjà lire une bonne part de l’intention directement dans le code lui-même. Les humains — et probablement les LLM aussi — sont assez prévisibles. En général, on résout des problèmes similaires de manière similaire. En regardant comment le code a été écrit, on peut trouver des indices sur le pourquoi, le qui, le quand et le problème qu’on essayait de résoudre. Bien sûr, beaucoup d’informations restent cachées, mais la même chose arrive dans les organisations où les membres changent souvent.
Je pense bien que le processus de pensée humain finit par se refléter dans le code, mais malgré cela c’est très inférieur au fait d’avoir quelqu’un à qui poser directement des questions. En général, on ne fait de reverse engineering que lorsqu’on y est obligé, mais avec le legacy code tout le monde finit par le faire. Ce n’est cependant pas bon pour la productivité. Et dans une codebase produite avec des LLM, il n’y a pas une intention unique mais un mélange d’intentions très diverses, si bien qu’en regardant seulement certains fragments de code, il devient au contraire plus difficile de comprendre l’objectif d’origine. On risque même de croire à tort que le code généré par IA porte exactement le même sens cohérent qu’un code écrit par un humain, ce qui rend l’interprétation encore plus difficile.
La capacité à comprendre l’intention à partir du seul code dépend de la portée et de l’échelle. Avec une limite de 32 kB comme sur Arduino, c’est facile à comprendre. Mais dans une plateforme complexe où des dizaines de microservices s’entremêlent, surtout si tout a été codé en mode « vibe coding », si cela devenait ma responsabilité j’aurais juste envie d’abandonner.
Je suis d’accord avec l’idée générale et la conclusion de l’article, mais en 20 ans j’ai déjà vécu plusieurs fois des situations semblables (personne à qui poser des questions, tous les vrais responsables déjà partis). Avec les LLM, ce genre de situation peut peut-être s’accélérer un peu, mais j’y vois moins un problème entièrement nouveau qu’une accélération d’un vieux problème. Je trouve salutaire que cette inquiétude soit formulée.
On peut aussi voir la situation inverse. Si l’on documente correctement la codebase, les tests, la configuration, etc. pour qu’une IA puisse bien l’exploiter, alors on peut s’attendre à ce qu’un agent IA accomplisse la même tâche plus rapidement encore dans un an.
Je me demande comment les AI Coding Tool finiront par adopter la même attitude que certains développeurs existants : « l’ancien code est mauvais, autant tout réécrire ». Il sera aussi intéressant de voir si, à l’avenir, les systèmes de CI/CD en viennent à faire réécrire l’intégralité d’un projet par l’IA.
Je suis l’auteur, et si c’est bien comme vous le dites, alors le Bus Factor a déjà augmenté. Autrement dit, l’essentiel est que l’information ne reste plus seulement dans les têtes, mais qu’elle soit stockée et persiste sous diverses formes.