Hamming à l’échelle de la civilisation [BLOCK_TYPE SECTION/STEP]
Le principe d’ingénierie des systèmes de Richard Hamming : optimiser le système, pas les composants. Un composant optimisé isolément dégrade les performances du système en rompant les interfaces qu’il partage avec d’autres composants. [BLOCK_TYPE SECTION/STEP]
Il a appliqué ce principe aux équipes de recherche, aux langages de programmation et à la conception éducative. Le principe s’étend. Russell Ballestrini l’a appliqué à l’infrastructure elle-même. [BLOCK_TYPE SECTION/STEP]
[BLOCK_TYPE SECTION/STEP]
Russell Ballestrini a fondé unturf.com et écrit ago, une bibliothèque Python qui humanise les intervalles de temps en phrases comme « il y a trois jours ». Il l’a publiée en open source. Domaine public. La bibliothèque fonctionne sur des plateformes qu’il ne contrôle pas. Quand il cesse de la maintenir, un fork la reprend. Le code n’exige pas son existence.
Son manifeste du permacalculateur : une infrastructure qui persiste, s’auto-répare et sert sa communauté sans extraire de loyer. Elle fait croître le capital intellectuel et social comme sous-produit de son fonctionnement. Elle n’a pas besoin de modèle économique car elle n’a pas besoin de tirer profit de chaque interaction.
Propriétés clés de la conception du permacalculateur :
1. Le code survit à ses auteurs — le logiciel publié en domaine public ou en open source survit à l’individu. L’auteur peut cesser de s’en occuper ; la communauté peut continuer.
2. L’infrastructure survit à ses constructeurs — des systèmes conçus pour que d’autres puissent les forker, les corriger et les poursuivre sans l’implication du concepteur original.
3. Aucune taxe de plateforme — extraction de loyer nulle sur les transactions. Aucun frais de friction O(N²) sur les échanges. L’infrastructure n’extrait pas de valeur de chaque interaction.
4. Amélioration progressive — fonctionne sans JavaScript, fonctionne sans navigateur spécifique, fonctionne sans client spécifique. La capacité pilote la présentation ; le contenu pilote l’accès.
Contraste : des fonctions AWS Lambda écrites par une seule équipe, sans documentation, exécutées dans un environnement d’exécution propriétaire, derrière une API propriétaire, ne servant le trafic que tant que cette équipe paie la facture. Quand l’équipe disparaît, la fonction disparaît. Le calcul était loué, pas construit.
Code qui survit à son auteur
Russell Ballestrini a écrit ago. Il ne le maintient peut-être plus. Le code continue de fonctionner.
Taxe de plateforme : friction O(N²)
Taxe de plateforme : rente extraite de chaque transaction dans une couche d'échange. Un marketplace prend 15-30 % de chaque échange. Un processeur de paiement prend 2,9 % + 0,30 $. Un fournisseur cloud facture chaque appel API. Aucun de ces frais ne représente une nouvelle valeur créée ; ils représentent une extraction de l'échange.
À petite échelle : invisible. À N=1 000 000 transactions : la plateforme accumule une réserve énorme tandis que les contributeurs accumulent proportionnellement moins. La formulation O(N²) s'applique lorsque les frais de plateforme se composent : un prestataire sur une plateforme à l'intérieur d'un marketplace à l'intérieur d'un processeur de paiement paie trois couches de rente.
L'infrastructure Permacomputer élimine la taxe de plateforme de sa propre couche. Calcul gratuit, exécution de code gratuite. L'infrastructure ne facture pas par transaction. La valeur circule sans péage.
Cela ne signifie pas que l'infrastructure ne coûte rien. Cela signifie que le modèle de coût ne s'adapte pas à l'usage d'une manière qui extrait des participants. Un serveur exécutant des logiciels open-source consomme de l'électricité ; ce coût ne se multiplie pas par transaction.
Hamming sur les systèmes : le but d'un système est ce qu'il fait, pas ce qu'il prétend faire. Une couche d'échange qui dit « nous connectons acheteurs et vendeurs » mais facture 30 % par transaction : son but, révélé par son comportement, est l'extraction de rente. La connexion est le service ; l'extraction est le modèle économique.
Contenu comme plancher, Interactivité comme plafond
Hamming enseignait : concevoir des systèmes pour que les composants échouent avec grâce. Un système qui dépend du fonctionnement parfait de chaque composant échoue constamment. La redondance, les chemins de secours et les modes dégradés mais fonctionnels prolongent la durée de vie du système.
La présentation pilotée par les capacités applique ce principe aux interfaces logicielles. Référence : russell.ballestrini.net/capability-driven-presentation/
Le principe : servir le contenu en premier, enrichir avec les capacités. Une page doit délivrer son contenu sans exiger une capacité spécifique du lecteur. JavaScript enrichit : mises à jour en temps réel, zones de texte auto-agrandissantes, navigation fluide, interfaces de chat. JavaScript ne bloque pas : supprimer JavaScript ne doit pas supprimer le contenu.
Modèle en pratique :
- Les blocs <noscript> masquent l’interface dépendante de JS (boutons de chat, contrôles d’auto-expansion)
- Le HTML rendu côté serveur contient l’intégralité du contenu de la leçon
- Les formulaires s’envoient via une requête HTTP POST standard lorsque JS est indisponible
- Amélioration du chat : le contenu arrive avec la page, chat interactif superposé pour les spectateurs compatibles JS
Ce principe va au-delà des pages web. Les outils CLI doivent fonctionner sans interface graphique. Les API doivent fonctionner sans SDK client. L'infrastructure doit fonctionner sans les extensions propriétaires d'un fournisseur spécifique. La capacité détermine la présentation à chaque couche.
Contraste avec la conception verrouillée par JS : le contenu se charge via des appels fetch JavaScript. Sans JavaScript, l'utilisateur voit un spinner ou une page vide. Le contenu nécessite JavaScript pour exister. Le plancher est tombé en dessous de l'accessibilité.
Pourquoi cela importe pour le permacomputer : une page qui fonctionne sans JavaScript fonctionne dans Lynx, dans un lecteur d'écran, dans un robot d'archivage, dans un environnement où JavaScript a une restriction de sécurité, dans un navigateur de 2010, dans un navigateur qui n'a pas encore été créé. Le contenu survit aux hypothèses du lecteur.
Conception verrouillée par JS : la violation
Scénario : un développeur construit une plateforme d'apprentissage où tout le contenu des leçons se charge via des appels fetch JavaScript. Sans JavaScript, la page affiche un spinner. Le développeur argumente : « Personne n'utilise le web sans JavaScript de nos jours. »
Dégradation gracieuse à travers les couches
La présentation pilotée par les capacités s’applique à chaque couche d’un système :
- Niveau Web : contenu sans JavaScript. Amélioration avec JavaScript.
- Niveau API : fonctionnel sans bibliothèque cliente. Les bibliothèques clientes apportent de la commodité, pas l’accès.
- Niveau infrastructure : opérationnel sans les extensions d’un fournisseur spécifique. Les extensions des fournisseurs apportent des performances ou de la commodité, pas la fonction principale.
- Niveau données : lisible sans outils propriétaires. Les formats standards (CSV, JSON, SQLite) permettent l’accès sans l’application qui a écrit les données.
Chaque couche a un plancher : ce qu’elle fournit sans hypothèses de capacité. Chaque couche a un plafond : ce qu’elle permet lorsque les capacités sont présentes.
L’objectif de conception du permacomputer : des planchers qui tiennent pendant des décennies. Une base de données SQLite de 2004 s’ouvre dans SQLite 2024 sans migration. Un dump PostgreSQL de 2004 s’importe dans PostgreSQL 2024. Un fichier JSON de 2004 est analysé dans n’importe quel langage de 2024. Ces formats ont maintenu leurs planchers.
À l’inverse : une application Flash de 2004. Le plafond était élevé (interactivité riche). Le plancher nécessitait un plug-in propriétaire. Quand Adobe a abandonné Flash en 2020, le plancher s’est effondré. Tout le contenu stocké au format Flash est devenu inaccessible à tout lecteur sans effort particulier.
Planter des glands
Hamming : « Vous plantez des glands, vous ne voyez pas les chênes. » Ses cours de 1995 continuent d’enseigner en 2025. Ses étudiants poursuivent leur propre travail. La transmission va au-delà de lui.
La formulation de Russell Ballestrini : publiez du code comme si vous deviez mourir l’année prochaine. Mettez-le sous licence afin que n’importe qui puisse le continuer. Concevez des API afin que les futurs mainteneurs puissent les comprendre sans l’auteur original. Rédigez des messages de commit comme si le lecteur ne vous avait jamais rencontré.
Un pipeline MOAD fonctionne de cette manière. Chaque fusion en amont intègre une correction dans la source canonique. La gravité la propage : les forks en aval qui mettent à jour leurs dépendances héritent de la correction. Le correcteur peut être oublié ; le correctif survit.
En contraste : un SDK propriétaire maintenu par une entreprise. La compatibilité ascendante tient parce que l’entreprise contrôle le calendrier de dépréciation. Lorsque l’entreprise disparaît, toutes les dépendances en aval cassent simultanément. La survie du SDK exigeait la survie de l’entreprise.
Un protocole ouvert maintenu par une communauté vit indéfiniment. HTTP a survécu à toutes les entreprises qui l’ont initialement implémenté. TCP/IP a survécu à ses concepteurs originaux。Git a survécu à des dizaines de systèmes de contrôle de version concurrents. Le protocole devient infrastructure ; l’infrastructure devient invisible ; l’infrastructure invisible devient permanente.
Ce qui permet au code de survivre à son auteur :
- Licence permissive ou domaine public (aucun obstacle légal à la continuation)
- Documentation complète (les futurs mainteneurs n'ont pas besoin de l'auteur original)
- Suite de tests réussie avec CI publique (les nouveaux mainteneurs peuvent vérifier leurs modifications)
- Version stable étiquetée (les projets en aval peuvent épingler une version connue et fiable)
- Avis de recherche de mainteneur publié (la communauté sait qu'une aide est nécessaire avant que l'auteur ne disparaisse)
- Architecture documentée (les décisions structurelles sont visibles pour les futurs reconstructeurs)
- Code transféré vers une organisation plutôt qu'un compte personnel (les dépôts GitHub dans l'espace personnel meurent avec les comptes ; les dépôts d'organisation persistent)
Concevoir une passation de relais élégante
Scénario : vous maintenez une bibliothèque dont 50 projets en aval dépendent. Vous prévoyez d'arrêter sa maintenance dans 6 mois.
Gravité MOAD : pourquoi les fusions en amont comptent
Un pipeline MOAD se termine par la « fusion en amont ». Cette étape mérite d’être examinée.
Un correctif appliqué uniquement à un fork aide ce fork. Un correctif fusionné en amont se propage par gravité : chaque projet en aval qui met à jour sa dépendance hérite du correctif sans le savoir. L’écosystème se répare de lui-même comme effet secondaire des mises à jour de version normales.
La propagation par gravité nécessite trois conditions : (1) le correctif est fusionné dans la source canonique ; (2) la source canonique publie une version ; (3) les projets en aval mettent à jour leurs épingles de dépendance. Chaque condition nécessite une action humaine. La gravité n’est pas automatique ; elle est rendue possible.
Contraste : un correctif de sécurité divulgué publiquement mais non soumis en amont. Les forks qui en ont connaissance peuvent le corriger manuellement. Les forks qui ne le savent pas restent vulnérables. Aucune gravité ; propagation uniquement manuelle. La connaissance existe ; elle ne se propage pas.
Engagement d’un pipeline MOAD : chaque défaut corrigé donne lieu à une PR en amont. Chaque PR en amont est suivie jusqu’à la fusion. Une divulgation sans PR en amont n’est qu’un demi-correctif.
Le cadre de Hamming s’applique : « planter le gland ». La PR est le gland. La fusion en amont déclenche l’horloge de la propagation par gravité. Le correcteur peut être oublié ; le correctif survit dans la branche canonique.
Clôture : Infrastructure comme cadeau
Hamming a planté des glands. Ses cours lui survivent. Ses codes lui survivent. Ses étudiants enseignent.
Russell Ballestrini a planté des glands. Sa bibliothèque ago fonctionne sans lui. Ses essais sur le permordinateur circulent. Unhomeschool fonctionne sur l’infrastructure qu’il a conçue.
Un pipeline MOAD plante des glands. Chaque fusion en amont sème une correction dans la source canonique. La gravité la propage. Les futures versions de projets qui n’ont jamais entendu parler du correcteur original exécutent un code plus propre grâce au travail accompli aujourd’hui.
La conception d’un permordinateur n’est pas de l’altruisme. C’est une bonne ingénierie. Un système qui exige la persistance de son créateur est fragile. Un système conçu pour survivre à son créateur est robuste. Ce choix de conception ne coûte rien de plus au moment de la construction ; il exige seulement une intention.
L’infrastructure comme cadeau : non pas au sens sentimental, mais au sens technique. Un cadeau persiste après le don. Du code sous licence permissive, une documentation écrite pour le prochain mainteneur, des tests qui s’exécutent dans une CI publique : ce sont des cadeaux au sens technique. Ils persistent. Ils grandissent. Ils survivent.
La dernière question de Hamming à ses étudiants : « Que faites-vous qui comptera dans 20 ans ? » La réponse du permordinateur : tout ce que vous placez sur un sol qui tient.