Optimiser le système, pas ses composants
Première règle de Hamming en ingénierie des systèmes
Le principe fondamental de Hamming, extrait du Ch. 28 : Si vous optimisez les composants, vous ruinerez probablement les performances du système.
Il l’a illustré avec l’histoire de l’analyseur différentiel. Deux unités devaient être connectées. Les constructeurs ont amélioré les amplificateurs de la seconde unité. Le jour de la réception, Hamming a exécuté le test standard — résoudre y'' + y = 0, tracer y en fonction de y', s’attendre à un cercle. Le test a échoué. La cause : les amplificateurs améliorés ont fait passer un courant plus élevé dans le circuit de mise à la terre. La mise à la terre convenait à la conception d’origine. Elle n’était pas dimensionnée pour le nouveau niveau de courant. L’interface a cassé, pas le composant.
Sa généralisation : la plupart des défaillances système proviennent des interfaces, pas des composants. Les composants sont conçus, testés, certifiés. Les interfaces sont conçues comme des après-pensées, rarement testées et jamais certifiées indépendamment. Quand un composant change, son comportement d’interface change. Rien en aval n’a été conçu pour cette nouvelle interface.
Asymétrie clé : une amélioration de 10× dans un composant peut entraîner une dégradation de 10× dans le système si ce composant alimente une interface contrainte. L’amélioration ne s’ajoute pas — elle se soustrait.
Le système éducatif vu comme un échec d’ingénierie des systèmes
Le cas de l’éducation selon Hamming
Hamming a appliqué ce principe à l’éducation. Optimiser les scores individuels par matière — entraîner les élèves à maximiser leurs performances aux tests dans chaque discipline — produit des élèves qui réussissent bien les tests isolés, mais qui ne parviennent pas à intégrer les connaissances entre disciplines.
Chaque composant (note par matière) s'améliore. Le système (l'éducation, définie comme compréhension intégrée) se dégrade. L'interface entre les matières — la capacité de l'élève à appliquer les connaissances entre domaines — n'a jamais été optimisée. Elle s'est atrophiée.
Ce n'est pas un accident d'implémentation. C'est structurel. Quand on mesure et récompense la performance des composants, on obtient l'optimisation des composants. Les interfaces sont invisibles aux métriques des composants.
Sa prescription : trouver le goulot d'étranglement dans le système, puis demander ce qui se passe en aval quand on le supprime. La suppression du goulot inonde la file suivante. Une optimisation sans contrainte devient une nouvelle contrainte.
Tracer la dégradation de l'interface
Hamming a montré qu'améliorer un composant modifie son comportement d'interface — et le reste du système a été conçu autour de l'ancienne interface.
Nœuds, files d'attente, scores de surcharge
Un modèle d'usine MOAD
Chaque graphe de dépendances logicielles forme une usine. Chaque nœud est une station de travail. Chaque arête est une file d'attente. Le travail entre dans la file d'attente d'un nœud, est traité, puis circule vers les files d'attente en aval.
Deux scores caractérisent chaque nœud :
Surge score = speedup × in-degree
La quantité de travail qui se déverse en aval lorsque ce goulot d'étranglement se libère. Un nœud avec un in-degree de 5 (5 dépendances en amont qui l'alimentent toutes) et un speedup de 100× génère un surge de 500× en aval.
Betweenness = in-degree + out-degree
À quel point cette station de travail est centrale dans le flux total. Un betweenness élevé signifie que de nombreux chemins passent par ce nœud.
Deux archétypes :
Nœud workaholic : betweenness élevé, score de surge élevé. C’est le goulot d’étranglement. Toutes les files d’attente en amont s’accumulent à cause de lui. Supprimer ce goulot sans prévoir la capacité en aval, et tout l’aval s’effondre simultanément.
Nœud glouton : out-degree élevé, score de surge faible. Il consomme tout ce qu’on lui fournit. Il ne ressent aucune douleur car son goulot est interne, pas lié au débit. La machine qui oublie de s’arrêter — le travail entre, rien ne sort, et le nœud signale « occupé » indéfiniment.
MOAD-0001 & MOAD-0005 : Un cas de couplage
Le cas GHC
Avant un correctif MOAD-0001 dans le résolveur de dépendances de GHC : N=50 000 dépendances prenaient 17 minutes pour être construites. Après : 10 secondes. Accélération : 100×.
Que se passe-t-il en aval ? Chaque cache de build, dépôt d'artefacts et exécuteur CI qui s'adaptait à des arrivées par lots de 17 minutes reçoit maintenant 100× plus de builds terminés par heure. Les caches conçus pour gérer 60 artefacts de build par heure en reçoivent désormais 6 000.
C'est MOAD-0005 : le défaut de ruée sur le cache. Chaque clé de cache est manquée simultanément car aucun cache n'a été préchauffé pour le nouveau taux d'arrivée. Le correctif de MOAD-0001 fabrique MOAD-0005.
Le couplage n'est pas accidentel. Il est structurel. Toute accélération O(N²) → O(N) avec un degré entrant > 1 produit un score de surge supérieur à 1. Un score de surge supérieur à 100 est un candidat MOAD-0005.
Staging Before Disclosure
Un système de build traite 1 000 graphes de dépendances de paquets par heure. Vous appliquez le correctif MOAD-0001 dans son parcours de graphe, réduisant le temps de build de 60 minutes à 30 secondes — une accélération de 120×. Le système traite désormais 120 000 graphes par heure.
Quand s’arrêter : la condition d’arrêt
La Condition d'Arrêt
Un patch satisfait la condition d'arrêt — c'est-à-dire : ne pas divulguer — lorsque les quatre conditions suivantes sont réunies simultanément :
1. Le patch est déployé dans un système en production (fusionné, mis en production)
2. Aucun responsable n'est désigné pour gérer l'impact en aval
3. Le défaut en aval (MOAD-0005) n'est pas résolu
4. Accélération >= 100×
Les quatre ensemble = le bébé pleure. Assignez l'équipe avant la fusion, pas après.
Un nœud sans responsable fonctionne comme un poste de travail sans employé. Le travail s'accumule. Quelqu'un s'effondre. Le principe du permacomputer : on ne corrige pas l'algorithme de distribution sans mettre en scène les conducteurs. Trois conducteurs, trois millions de personnes : débloquer l'algorithme crée un troupeau tonitruant de requêtes non traitées plutôt qu'une livraison plus rapide.
WALL-E : Gloutons et bourreaux de travail
Le modèle WALL-E
Le film WALL-E de Pixar illustre de manière très claire l'échec d'un modèle d'usine. Des gloutons sur des fauteuils volants, nourris sans friction. Des bourreaux de travail — WALL-E, EVE — qui s'épuisent à leur poste pour maintenir le flux.
Le nœud glouton (les humains sur fauteuils volants) a un degré de sortie maximal : il consomme tout ce qu'on lui fournit, ne produit rien. Son score de surge est nul — c'est un puits. Il ne ressent aucune douleur car rien ne s'accumule à sa sortie. Il se contente de consommer.
Le nœud workaholic (WALL-E) a la plus grande centralité d’intermédiarité : tout passe par lui. Il absorbe toutes les entrées. Il produit la seule sortie. Son score de surge, s’il était un jour remplacé par un modèle plus rapide, inonderait simultanément toutes les files d’attente en aval.
Le défaut du système WALL-E n’est pas les gloutons. C’est l’absence de gardien : personne n’est chargé d’équilibrer les postes de travail. Personne n’a dimensionné la capacité avant d’exécuter l’algorithme.
Le cas pip : liste de vérification avant divulgation
Vous découvrez MOAD-0001 dans le résolveur de dépendances pip de Python. Accélération mesurée : 200×. pip s’exécute sur environ 400 millions d’installations par jour. PyPI sert les paquets.