Should I Buy It?
Garde-le simple. La simplicité est un objectif de conception, pas une contrainte. Un système doit pouvoir fonctionner — et être réparé — même dans des conditions dégradées.
Origine
Kelly Johnson (1910–1990) était l’ingénieur en chef de la division Skunk Works chez Lockheed, responsable de certains des avions les plus avancés de l’histoire : le U-2, le SR-71 Blackbird, le F-117.
Le paradoxe de sa position : concevoir des appareils de pointe qui devaient aussi être réparables sur le terrain, par un mécanicien ordinaire, avec une poignée d’outils basiques. C’est de cette contrainte concrète qu’est né le principe KISS.
Johnson donnait littéralement une poignée d’outils à ses ingénieurs et leur disait : l’avion que vous concevez doit être réparable avec ça, dans des conditions de combat. Le “stupid” ne visait pas les ingénieurs — il désignait le décalage entre la sophistication du système et les moyens disponibles pour le réparer.
La U.S. Navy a formalisé le principe en 1960, mais Johnson l’appliquait bien avant.
La théorie
Le principe KISS repose sur une observation simple : la complexité inutile est un risque. Plus un système a de composants, plus il a de points de défaillance potentiels. Plus il est difficile à comprendre, plus il est difficile à maintenir, réparer, adapter.
La simplicité n’est pas un défaut de conception — c’est un objectif actif à atteindre. Un système simple qui remplit sa fonction vaut mieux qu’un système sophistiqué qui la remplit aussi bien mais qui casse au mauvais moment.
Les variantes du principe sont nombreuses :
- “Keep it short and simple”
- “Keep it simple and straightforward”
- En Unix : “Do one thing and do it well”
Toutes convergent vers la même intuition : la valeur d’un système se mesure à ce qu’il accomplit, pas à la complexité de son mécanisme interne.
En pratique
En ingénierie logicielle : Moins de code signifie moins de bugs. La philosophie Unix (un outil = une fonction) a produit des systèmes d’une longévité remarquable précisément parce que chaque composant est compréhensible isolément.
En design d’interface : La complexité visuelle nuit à l’utilisabilité. Les interfaces qui demandent le moins d’effort mental au départ sont celles que les utilisateurs adoptent et maintiennent.
En communication : Un message court et clair passe mieux qu’un message exhaustif. L’exhaustivité est souvent une forme de protection intellectuelle — “j’ai tout couvert” — qui nuit à la transmission réelle.
En automatisation : Un workflow de 5 étapes qui tombe rarement en panne vaut mieux qu’un workflow de 30 étapes qui fait la même chose mais requiert une maintenance permanente. Chaque bloc supplémentaire est un point de défaillance potentiel.
Nuances et limites
KISS ne dit pas que tout doit être trivial. Certains problèmes sont intrinsèquement complexes et exigent des solutions complexes. La question est : cette complexité est-elle nécessaire, ou est-elle le résultat d’une mauvaise conception ?
Il y a une différence entre la simplicité apparente (cacher la complexité derrière une interface simple) et la simplicité réelle (un système qui n’est pas plus complexe qu’il ne le doit). Les deux ont leur place, mais la seconde est plus robuste.
KISS et la loi de Gall se complètent : KISS dit “vise la simplicité”, Gall dit “même si tu voulais faire complexe d’emblée, ça ne marcherait pas”. Ensemble, ils forment un argument cohérent pour commencer simple, valider, et complexifier prudemment.
Sources : Wikipedia — KISS principle · Wikipedia — Kelly Johnson