Should I Buy It?
Un système complexe qui fonctionne a toujours évolué depuis un système simple qui fonctionnait. Un système complexe conçu de zéro ne fonctionne pas — et on ne peut pas le réparer pour le faire fonctionner. Il faut repartir d’un système simple.
Origine
John Gall (1925–2014) était pédiatre américain et passionné de théorie des systèmes. Dans General Systemantics: How Systems Work and Especially How They Fail (1975), il compile des décennies d’observations sur les systèmes qui échouent dans tous les domaines — médecine, technologie, bureaucratie, ingénierie.
Sa conclusion centrale, reformulée dans The Systems Bible (2002) :
“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”
Le livre est écrit avec humour et cynisme, mais l’observation empirique est solide.
La théorie
La loi de Gall pose une asymétrie fondamentale entre l’évolution et la conception : les systèmes évolutifs accumulent de la complexité par couches successives, chacune ayant été validée. Les systèmes conçus d’emblée comme complexes n’ont pas traversé ce filtre de réalité.
Un système simple qui marche possède quelque chose d’irremplaçable : la preuve qu’il fonctionne. Il peut ensuite s’enrichir d’une couche supplémentaire, testée à son tour, et ainsi de suite. Chaque étape reste ancrée dans quelque chose qui a prouvé sa valeur.
À l’inverse, un système conçu d’un coup dans toute sa complexité cumule des hypothèses non testées. Quand il échoue — et il échoue — on ne sait pas quelle couche est défaillante. Patcher ne sert à rien : les problèmes sont structurels, pas superficiels.
La loi s’applique universellement : systèmes informatiques, organisations, processus de travail, workflows d’automatisation.
En pratique
Les succès évolutifs : Le World Wide Web a démarré comme un système de liens hypertextes entre documents académiques. Les blogs ont émergé de simples pages HTML. Unix a commencé comme un projet d’un seul chercheur. Chacun a grandi par couches successives.
Les échecs de conception : CORBA — spécification technique complexe dès le départ, jamais vraiment adoptée. Les grands programmes informatiques d’État conçus sur des cahiers des charges de 500 pages, livrés 5 ans plus tard dans un monde différent.
Application personnelle : Construire la V1 d’un outil simple qui résout un problème précis. Valider que ça marche. Ajouter une couche. Valider. Répéter. Ne jamais sauter l’étape “valider que ça marche”.
La loi de Gall est un argument en faveur du développement agile, du MVP, et de la méthode itérative — pas par idéologie, mais parce que c’est empiriquement la seule façon de construire des systèmes qui fonctionnent.
Nuances et limites
La loi est descriptive, pas normative. Elle dit comment les systèmes fonctionnants sont construits, pas comment on devrait idéalement les concevoir.
Elle ne dit pas qu’il faut rester simple pour toujours — elle dit que la complexité doit être acquise progressivement, en partant d’une base qui marche.
La loi de Gall se complète avec le principe KISS (Keep It Simple, Stupid) de Kelly Johnson : KISS prescrit la simplicité comme objectif de conception, Gall l’observe comme condition empirique du succès. Les deux convergent vers la même recommandation pratique : commencer simple, valider, puis complexifier prudemment.
Elle ne s’applique pas dans tous les contextes — certains systèmes doivent être conçus en entier avant de fonctionner (un avion, un pont). Mais dans les systèmes organisationnels, logiciels, et de processus, l’observation de Gall tient remarquablement bien.
Sources : Wikipedia — John Gall · Systemantics