À retenir
- La force vient du nombre de relecteurs (les « yeux »).
- La transparence logicielle réduit le temps de correction des failles.
- C'est le fondement philosophique et pratique de l'Open Source.
La loi de Linus est un principe qui suggère que lorsqu'une grande communauté de personnes examine un code informatique, les erreurs et les failles de sécurité sont détectées et corrigées beaucoup plus rapidement. C'est l'idée que la collaboration massive rend les problèmes complexes plus faciles à résoudre, un peu comme une erreur dans un texte devient évidente dès que des dizaines de lecteurs le relisent attentivement.
Étymologie
Ce terme a été inventé par Eric S. Raymond dans son essai La Cathédrale et le Bazar (1997). Il l'a nommé en hommage à Linus Torvalds, le créateur du noyau Linux, qui a prouvé l'efficacité du développement collaboratif à grande échelle. La phrase originale est : « Given enough eyeballs, all bugs are shallow » (Avec assez de regards, tous les bugs sont superficiels).
Exemples d'usage
- Le développement du noyau Linux, où des milliers de contributeurs corrigent des failles en permanence.
- Les projets Open Source sur des plateformes comme GitHub, où un bug signalé par un utilisateur est souvent corrigé en quelques heures par un autre développeur anonyme.
- Les audits de sécurité publics de logiciels de chiffrement, où la transparence du code permet à des experts du monde entier de vérifier qu'il n'y a pas de porte dérobée.
Cas d'usage
Ce concept est le pilier du mouvement Logiciel Libre (Open Source). Il intervient dans la cybersécurité (pour justifier que le code ouvert est potentiellement plus sûr) et dans la gestion de projets communautaires pour encourager la relecture de code (code review) systématique.
Bonnes pratiques
Pour que cette loi fonctionne, il ne suffit pas de rendre le code public ; il faut aussi qu'il soit lisible et bien documenté pour attirer les contributeurs. Publier un code incompréhensible empêche les autres de trouver les bugs, rendant la loi de Linus inopérante.
Synonymes
Antonymes
Conseil
Si vous lancez un projet, n'ayez pas peur de montrer votre code même s'il n'est pas parfait. C'est en l'exposant aux autres que vous bénéficierez de l'effet de groupe pour l'améliorer. Plus on cache son code par peur du jugement, plus on risque de laisser passer des erreurs graves.
Questions fréquentes
Est-ce que cela signifie qu'un logiciel libre n'a jamais de bugs ?
Non, cela signifie simplement que les bugs ont plus de chances d'être trouvés et corrigés rapidement s'il y a une communauté active autour du projet.
La loi s'applique-t-elle aux logiciels privés (propriétaires) ?
Moins bien, car le nombre de personnes autorisées à voir le code est limité aux employés de l'entreprise, contrairement à l'Open Source qui est ouvert au monde entier.
Un projet avec peu de contributeurs bénéficie-t-il de cette loi ?
Très peu. Si le code est public mais que personne ne le regarde, les bugs restent cachés. C'est la présence réelle de relecteurs qui compte, pas juste la publicité du code.