path: root/translations/fr.md

# 💻📖 hacker-laws

Lois, théories, principes et modèles que les développeurs trouveront utiles.

[Traductions](#translations): [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](./translations/de.md) [🇫🇷](./translationis/fr.md) [🇬🇷](./translations/el.md) [🇮🇹](https://github.com/csparpa/hacker-laws-it) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](https://github.com/umutphp/hacker-laws-tr)

Vous aimez ce projet ? N'hésitez pas à [me sponsoriser](https://github.com/sponsors/dwmkerr) ainsi que [les traducteurs](#traductions).

---

<!-- vim-markdown-toc GFM -->

- [Introduction](#introduction)
- [Lois](#lois)
    - [Loi d'Amdahl](#loi-damdahl)
    - [Théorie de la vitre brisée](#theorie-de-la-vitre-brisee)
    - [Loi de Brooks](#loi-de-brooks)
    - [Loi de Conway](#loi-de-conway)
    - [Loi de Cunningham](#loi-de-cunningham)
    - [Nombre de Dunbar](#nombre-de-dunbar)
    - [Loi de Gall](#loi-de-gall)
    - [Loi de Goodhart](#loi-de-goodhart)
    - [Rasoir de Hanlon](#rasoir-de-hanlon)
    - [Loi de Hofstadter](#loi-de-hofstadter)
    - [Loi de Hutber](#loi-de-hutber)
    - [Cycle du hype & Loi d'Amara](#cycle-de-hype--loi-damara)
    - [Loi d'Hyrum (loi des interfaces implicites)](#loi-dhyrum)
    - [Loi de Kernighan](#loi-de-kernighan)
    - [Loi de Metcalfe](#loi-de-metcalfe)
    - [Loi de Moore](#loi-de-moore)
    - [Loi de Murphy / Loi de Sod](#loi-de-murphy--loi-de-sod)
    - [Rasoir d'Occam](#rasoir-doccam)
    - [Loi de Parkinson](#loi-de-parkinson)
    - [Effet d'optimisation prématurée](#effet-doptimisation-prematuree)
    - [Loi de Putt](#loi-de-putt)
    - [Loi de Reed](#loi-de-reed)
    - [Loi de la conservation de la complexité (Loi de Tesler)](#loi-de-tesler)
    - [Loi des abstractions qui fuient](#loi-des-abstractions-qui-fuient)
    - [Loi de futilité](#loi-de-futilite)
    - [Philosophie d'Unix](#philosophie-dunix)
    - [Modèle de Spotify](#modele-de-spotify)
    - [Loi de Wadler](#loi-de-wadler)
    - [Loi de Wheaton](#loi-de-wheaton)
- [Principes](#principes)
    - [Principe de Dilbert](#principe-de-dilbert)
    - [Principe de Pareto (Regle des 80/20)](#principe-de-pareto-regle-des-8020)
    - [Principe de Peter](#principe-de-peter)
    - [Principe de robustesse (loi de Postel)](#principe-de-robustesse-loi-de-postel)
    - [SOLID](#solid)
    - [Principe de responsabilité unique](#principe-de-responsabilite-unique)
    - [Principe ouvert/fermé](#principe-ouvertferme)
    - [Principe de substitution de Liskov](#principe-de-substitution-de-liskov)
    - [Principe de ségrégation des interfaces](#principe-de-segregation-des-interfaces)
    - [Principe d'inversion des dépendances](#principe-dinversion-des-dependances)
    - [Principe DRY](#principe-dry)
    - [Principe KISS](#principe-kiss)
    - [YAGNI](#yagni)
    - [Illusions de l'informatique distribuée](#illusions-de-linformatique-distribuee)
- [À lire](#a-lire)
- [Traductions](#traductions)
- [Projets liés](#projets-lies)
- [Contribuer](#contribuer)
- [TODO](#todo)

<!-- vim-markdown-toc -->

## Introduction

Il y a beaucoup de "lois" dont les gens parlent quand on discute de développement. Ce repository offre une vue d'ensemble et une référence des plus communes. N'hésitez pas à partager et à proposer vos PRs !

❗: Ce repo ne *préconise* aucune des lois, principes ou modèles qui y sont expliqués. Leur application devrait toujours être le sujet d'un débat, et dépend grandement de ce sur quoi vous travaillez.

## Lois

Nous y voila !

### Loi d'Amdahl

[Loi d'Amdahl sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_d%27Amdahl)

> La loi d'Amdahl est une formule qui montre le *gain de vitesse potentiel* sur un calcul, obtenu en augmentant les ressources d'un système. Habituellement utilisé en calcul parallèle, elle peut prédire les bénéfices réels de l'accroissement du nombre de processeurs. Bénéfices qui sont limités par le potentiel du programme à être parallélisé.

Prenons un exemple: si un programme est composé de 2 parties, la partie A devant être exécuté par un seul processeur et la partie B pouvant être parallélisée, alors on peut constater qu'ajouter plusieurs processeurs au système executant le programme ne peut avoir qu'un bénéfice limité. Cela peut potentiellement améliorer grandement la vitesse de la partie B, mais la vitesse de la partie A restera inchangée.

Le diagramme ci-dessous montre quelques exemples de gain de vitesse potentiels :

<img width="480px" alt="Diagram: Amdahl's Law" src="../images/amdahls_law.png">

*(Reference: par Daniels220 sur English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)*

Comme il est visible, un programme qui est parallélisable à 50% ne bénéficiera que très peu au delà des 10 processeurs, tandis qu'un programme parallélisable à 95% peut encore gagner en vitesse avec plus d'un millier de processeurs.

À mesure que la [loi de Moore](#loi-de-moore) ralenti et que l'accélération de la vitesse de calcul des processeurs diminue, la parallélisation est la clef de l'amélioration des performances. Prenons par exemple la programmation graphique avec les calculs de Shader: chaque pixel ou fragment peut être rendu en parallèle. Ce qui explique que les cartes graphiques récentes ont souvent plusieurs milliers de coeurs de calcul (GPUs ou Shader Units).

Voir aussi:

- [Loi de Brooks](#loi-de-brooks)
- [Loi de Moore](#loi-de-moore)

### Théorie de la vitre brisée

[Théorie de la vitre brisée sur Wikipedia](https://fr.wikipedia.org/wiki/Hypoth%C3%A8se_de_la_vitre_bris%C3%A9e)

La théorie de la vitre brisée suggère que des signes visibles de criminalité (ou de manque de soin d'un environnement) amène à des crimes plus nombreux et plus sérieux (ou une plus grande détérioration de l'environnement).

Cette théorie est aussi appliqué au développement logiciel pour suggérer que du code de mauvaise qualité (ou de la [dette technique](#TODO)) peut amener à penser que les efforts fait pour améliorer le code ne sont pas valorisés, voir complètement ignorés. Menant ainsi à une plus grande détérioration de la qualité du code au fil du temps.

Voir aussi:

- [Dette technique](#TODO)

Exemples:

- [The Pragmatic Programming: Software Entropy](https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy)
- [Coding Horror: The Broken Window Theory](https://blog.codinghorror.com/the-broken-window-theory/)
- [OpenSource: Joy of Programming - The Broken Window Theory](https://opensourceforu.com/2011/05/joy-of-programming-broken-window-theory/)

### Loi de Brooks

[Loi de Brooks sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_Brooks)

> Ajouter des personnes à un projet en retard accroît son retard.

Cette loi suggère que dans beaucoup de cas, tenter d'accélérer le bouclage d'un projet qui est en retard en ajoutant plus de personnes dessus rendra le projet encore plus en retard. Brooks est clair sur le fait qu'il s'agit d'une grande simplification, mais le raisonnement général est que la vitesse d'avancement du projet sur le court terme diminue à cause du temps nécessaire à l'intégration des nouveaux arrivants et du surplus de communication nécessaire. De plus, de nombreuses tâches peuvent ne pas être divisibles, comprendre réparties entre plusieurs personnes. Ce qui abaisse encore le potentiel d'augmentation de la vitesse d'avancement du projet.

La phrase bien connue "Neuf femmes ne peuvent pas faire un bébé en un mois" illustre la loi de Brooks, en particulier le fait que certaines tâches ne sont pas divisibles ou parallélisables.

C'est un thème central du livre '[The Mythical Man Month](#reading-list)'.

Voir aussi:

- [Death March](#todo)
- [Reading List: The Mythical Man Month](#reading-list)

### Loi de Conway

[Loi de Conway sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_Conway)

Cette loi suggère que les contours techniques d'un système reflètent la structure de l'organisation qui a produit le système. Cette loi est souvent évoquée quand on cherche à améliorer l'organisation en question. Si une organisation est structurée en plusieurs unités déconnectées, le logiciel qui est produit le sera aussi. Si une organisation est composée de silos verticaux orientés autour de fonctionnalités ou services, le logiciel le reflètera aussi.

Voir aussi:

- [Modèle de Spotify](#modele-de-spotify)

### Loi de Cunningham

[Loi de Cunningham sur Wikipedia](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law)

> Le meilleur moyen d'obtenir une bonne réponse sur Internet n'est pas de poser la question, mais de poster la mauvaise réponse.

Selon Steven McGeady, Ward Cunningham lui aurait conseillé au début des années 1980: "le meilleur moyen d'obtenir une bonne réponse sur Internet n'est pas de poser la question, mais de poster la mauvaise réponse." McGeady baptisa cette phrase la loi de Cunningham, bien que Cunningham lui même en réfute la parenté. Faisant initialement référence aux interactions sur Usenet, cette loi a été utilisé pour décrire le fonctionnement d'autres communautés en ligne (Wikipedia, Reddit, Twitter, Facebook).

Voir aussi:

- [XKCD 386: "Duty Calls"](https://xkcd.com/386/)

### Nombre de Dunbar

[Nombre de Dunbar sur Wikipedia](https://fr.wikipedia.org/wiki/Nombre_de_Dunbar)

"Le nombre de Dunbar est le nombre maximum d'individus avec lesquels une personne peut entretenir simultanément une relation humaine stable." À savoir une relation dans laquelle un individu sait qui est chaque personne et comment elle est liée aux autres personnes. Il n'y a pas de véritable consensus sur le nombre exact. "... [Dunbar] avance que les êtres humains peuvent maintenir confortablement seulement 150 relations stables". Il place le nombre dans un contexte social: "le nombre de personnes envers lesquelles vous ne vous sentiriez pas embarrassé de partager un verre si vous les croisiez par hasard dans un bar". Les estimations du nombre tombent généralement entre 100 et 250.

De même que les relations stables entre individus, la relation entre un développeur et une codebase requiert des efforts pour être maintenu. Lorsque nous faisons face à de larges projets compliqués ou nombreux, nous pouvons nous aider de conventions, de procédures ou de modèles. Le nombre de Dunbar est important à garder à l'esprit non seulement lorsque la taille d'une entreprise augmente mais aussi lorsqu'on décide de la portée des efforts à réaliser pour une équipe. Pris dans un contexte d'ingénierie, il représente le nombre de projets sur lesquels on pourrait sereinement faire du support si on y était amené.

Voir aussi :

- [Loi de Conway](#loi-de-conway)

### Loi de Gall

[Loi de Gall sur Wikipedia](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law)

> Un système complexe qui fonctionne est une évolution d'un système simple qui fonctionne. Un système complexe entièrement conçu depuis zero ne fonctionne jamais et ne peut pas être modifié pour le faire fonctionner. Il faut recommencer avec un système simple qui fonctionne.
> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author)))

La loi de Gall implique que les tentatives de *concevoir* un système fortement complexe ont de grandes chances d'échouer. Les systèmes fortement complexes sont rarement construits d'un seul coup, mais évoluent plutôt depuis des systèmes plus simples.

Un exemple classique est le world-wide-web. Dans son état actuel, il s'agit d'un système fortement complexe. Cependant, il était initialement définit comme un simple moyen d'échanger du contenu entre établissements universitaires. Ayant atteint cet objectif avec un grand succès, le système a évolué pour devenir de plus en plus complexe au fil du temps.

Voir aussi :

- [KISS (Keep It Simple, Stupid)](#principe-kiss)

### Loi de Goodhart

[Loi de Goodhart sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_Goodhart)

> Toute régularité statistique observée a tendance à perdre de sa fiabilité lorsque on tente de la contrôler.
> *Charles Goodhart*

Souvent aussi énoncée de cette manière :

> Lorsqu'une mesure devient un objectif, elle cesse d'être une bonne mesure.
> *Marilyn Strathern*

Cette loi indique que les optimisations basées sur une mesure peuvent amener à une perte de valeur de la mesure elle même. Un ensemble de mesures ([KPIs](https://en.wikipedia.org/wiki/Performance_indicator)) trop restraint appliqué aveuglément à un process déforme le résultat. Les gens tendent à "tricher" localement pour satisfaire une mesure en particulier sans faire attention aux effets globaux de leurs actions sur le système.

Exemples concrets :

- Il est possible d'atteindre un taux de couverture du code arbitraire en rédigeant des tests qui ne vérifient rien. Alors que le but initial de la mesure était d'avoir du code correctement testé.
- Mesurer les performances des développeurs avec le nombre de lignes de code rédigées amène à des codebases inutilement grosses.

Voir aussi :

- [Goodhart’s Law: How Measuring The Wrong Things Drive Immoral Behaviour](https://coffeeandjunk.com/goodharts-campbells-law/)
- [Dilbert on bug-free software](https://dilbert.com/strip/1995-11-13)

### Rasoir de Hanlon

[Rasoir de Hanlon sur Wikipedia](https://fr.wikipedia.org/wiki/Rasoir_de_Hanlon)

> Ne jamais attribuer à la malveillance ce que la bêtise suffit à expliquer.
> Robert J. Hanlon

Ce principe suggère que des actions produisant un mauvais résultat ne sont pas toujours motivées par de mauvaises intentions. Il est au contraire plus probable que le problème se situe dans la compréhension de ces actions et de leurs impacts.

### Loi de Hofstadter

[Loi de Hofstadter sur Wikipedia](https://fr.wikipedia.org/wiki/Loi_de_Hofstadter)

> Il faut toujours plus de temps que prévu, même en tenant compte de la loi de Hofstadter.
> (Douglas Hofstadter)

Vous pourrez entendre parler de cette loi lorsqu'on cherche à estimer le temps nécessaire pour faire quelque chose. C'est un lieu commun de dire que nous ne sommes pas très bon pour estimer le temps nécessaire à boucler un projet en développement logiciel.

c'est un extrait du livre '[Gödel, Escher, Bach: An Eternal Golden Braid](#a-lire)'.

Voir aussi :

- [À lire: Gödel, Escher, Bach: An Eternal Golden Braid](#a-lire)

### Loi de Hutber

[Loi de Hutber sur Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law)

> Amélioration veut dire détérioration.
> ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))

Cette loi suggère que les améliorations apportées à un système vont mener à la détérioration d'autres choses. Ou qu'elles vont cacher d'autres détériorations, amenant globalement à une dégradation de l'état du système.

Par exemple, un abaissement de la latence de réponse sur une route (end-point) peut causer des problèmes de débit et de capacité plus loin, affectant un sous-système entièrement différent.

### Cycle du hype & Loi d'Amara

[Cycle du hype sur Wikipedia](https://fr.wikipedia.org/wiki/Cycle_du_hype)

> On a tendance à surestimer l'effet d'une technologie sur le court terme et à le sous-estimer sur le long terme.
> (Roy Amara)

Le cycle du hype est une représentation visuelle de l'attrait et du développement d'une technologie au fil du temps. Initialement réalisé par Gartner, le concept est plus clair avec un diagramme :

![The Hype Cycle](../images/gartner_hype_cycle.png)

*(Reference: par Jeremykemp sur English Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*

En clair, ce cycle montre qu'il y a généralement un pic d'excitation concernant les nouvelles technologies et leur potentiel impact. Les équipes adoptent ces technologies rapidement et se retrouvent parfois déçues des résultats. Cela peut être à cause d'un manque de maturité de la technologie, ou parce que les applications concrètes de cette technologie ne sont pas encore totalement maitrisées. Après un certain temps, les opportunités d'utiliser cette technologie ainsi que ses capacités augmentent suffisamment pour que les équipes deviennent vraiment productives. La citation de Roy Amara le résume de manière plus succincte: "On a tendance à surestimer l'effet d'une technologie sur le court terme et à le surestimer sur le long terme".

### Loi d'Hyrum (loi des interfaces implicites)

[Loi d'Hyrum en ligne](http://www.hyrumslaw.com/)

> Passé un certain nombre d'utilisateur d'une API, peu importe ce qui est promis par l'interface, tous les comportements possibles du système seront utilisés.
> (Hyrum Wright)

La loi d'Hyrum décris le fait que lorsqu'une API a un *nombre suffisamment élevé d'utilisateurs*, tous les comportements de l'API (y compris ceux qui ne sont pas définis publiquement) seront utilisés par quelqu'un. Un exemple trivial peut concerner les éléments non fonctionnels de l'API comme le temps de réponse. Un exemple plus subtil peut être l'utilisation d'une regex sur les messages d'erreurs pour en déterminer le *type*. Même si la spécification de l'API ne mentionne rien quant au contenu des messages, *certains* utilisateurs peuvent utiliser ces messages. Un changement au niveau de ces messages reviendrait à casser l'API pour ces utilisateurs.

Voir aussi :

- [Loi des abstractions qui fuient](#loi-des-abstractions-qui-fuient)
- [XKCD 1172](https://xkcd.com/1172/)

### Loi de Kernighan

> Debugger est deux fois plus difficile que de rédiger le code initial. Par conséquent si vous rédiger le code de manière aussi maligne que possible, vous n'êtes, par définition, pas assez intelligent pour le debugger.
> (Brian Kernighan)

La loi de Kernighan est nommée d'après [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan) et est b