hyper.dev
well come

2026-04-19 · L’enclosure du code - fin - Le prélude et l’après

Ce que le crépuscule a à dire que l’aube a besoin d’entendre

Prologue et épilogue de la trilogie — La chaîne d’approvisionnement logicielle

← L’enclosure du code — Série complète

---

0. Pourquoi ce texte existe

Les trois sessions précédentes ont tracé un arc : de la liberté recadrée (ère 1), aux communs encapsulés (ère 2), aux communs moissonnés (ère 3). Mais cet arc a un avant et un après.

L’avant, c’est le prélude — les pionniers d’avant GNU, ceux pour qui le logiciel n’était pas encore un bien à posséder ni un commun à défendre, parce que la question ne se posait pas. Le temps où le code était un geste partagé comme on partage une recette de cuisine.

L’après, c’est la question que l’arc pose sans y répondre : maintenant qu’on sait, qu’est-ce qu’on fait ?

Ce texte n’est pas une recherche. C’est une conversation entre deux voix : le crépuscule (celui qui a traversé les trois ères, qui a des cicatrices et des outils) et l’aube (celui qui arrive dans un paysage dont il n’a pas choisi la forme). Le crépuscule n’a pas raison. L’aube n’est pas naïve. Ils ont besoin l’un de l’autre.

---

I. Le prélude : avant que la question ne se pose

Le crépuscule

Avant GNU, avant la FSF, avant que quiconque ait besoin de défendre le droit de lire le code source, il y avait une époque où la question n’existait pas. Dans les laboratoires du MIT, de Bell Labs, de Xerox PARC dans les années 1960-1970, le logiciel circulait comme les articles scientifiques circulaient : on le donnait parce que c’est ce qu’on faisait. Le code était un sous-produit du matériel, pas une marchandise. Personne ne vendait du logiciel parce que personne n’imaginait que c’était vendable.

Ce qui circulait dans ces laboratoires, c’était quelque chose de plus précis que du « code ». C’étaient des idées incarnées — des façons de penser rendues exécutables. Quand les gens de Xerox PARC ont inventé Smalltalk, ils n’inventaient pas un langage de programmation. Ils inventaient une philosophie : que la complexité doit être compréhensible, qu’un système doit être entièrement saisissable par un seul esprit humain, que l’interface est le système. Quand les gens du MIT ont créé Lisp, ils ne créaient pas un outil — ils formalisaient une manière de raisonner où le programme et les données sont la même chose, où la structure est transparente, où rien n’est caché.

L’aube

Mais je n’ai pas accès à ça. Quand je démarre, je reçois un framework de 41 000 fichiers, un tutoriel de 20 minutes, et un Copilot qui m’autocomplète les lignes. Je n’ai jamais vu la question se poser parce qu’elle a été résolue avant moi — résolue dans un sens qui m’est défavorable. Le code circule, oui, mais sur les conditions de quelqu’un d’autre. La philosophie du PARC, je la lis dans des livres. Le laboratoire n’existe plus.

Le crépuscule

C’est vrai. Et c’est le point. Le prélude n’est pas un âge d’or. Les laboratoires du PARC et du MIT étaient des espaces de privilège extrême — presque exclusivement blancs, masculins, anglophones, financés par le département de la Défense ou par des entreprises qui pouvaient se permettre de la recherche pure. La communauté hacker des années 1970 était une communauté de quelques centaines de personnes dans quelques institutions américaines. Le partage était réel — mais il existait dans un contexte si restreint que la question de la propriété ne se posait pas, non pas parce qu’il y avait une éthique universelle du partage, mais parce qu’il n’y avait pas assez de monde pour que le conflit émerge.

Le moment où le logiciel est devenu une marchandise — la lettre de Bill Gates aux hobbyistes en 1976, la fermeture du code source par AT&T pour Unix, la montée de Microsoft dans les années 1980 — n’était pas une corruption d’un état naturel. C’était le résultat prévisible de l’industrialisation. Quand le marché arrive, la question de la propriété arrive avec lui.

Ce que Stallman a fait en 1983, en lançant GNU, c’était de refuser de traiter cette industrialisation comme naturelle. Il a dit : non, nous pouvons organiser le logiciel autrement. Il avait raison. Mais l’arc que nous avons tracé montre ce qui arrive quand une alternative existe mais que le système l’absorbe.

L’aube

Alors le prélude n’est pas un modèle à restaurer ?

Le crépuscule

Non. C’est un rappel que les choses n’ont pas toujours été ainsi. Ce qui veut dire qu’elles n’ont pas à rester ainsi. Le prélude montre que la possession du code est un choix civilisationnel, pas une loi de la physique. Un autre choix a été fait — et peut être refait.

---

II. Ce que le crépuscule voit en 2026

Le crépuscule

Voici ce que je vois après trente ans dans le métier, dit honnêtement.

Le tenure ne protège plus. Il y a cinq ans, vingt ans d’expérience étaient un bouclier. Aujourd’hui, vingt ans d’expérience signifient vingt ans de dette technique que tu portes dans ta tête — des frameworks disparus, des patterns obsolètes, des intuitions formées dans un monde qui n’existe plus. L’expérience qui compte est celle qui se reconfigure. L’expérience qui ne se reconfigure pas est un passif.

Le CV-driven development est un piège mortel. J’ai vu des collègues empiler Kubernetes, des ORM, React, TypeScript, GraphQL, Terraform — non pas parce que le problème l’exigeait, mais parce que leur prochain entretien d’embauche l’exigeait. Ils ont optimisé leur employabilité au prix de leur compréhension. Quand le modèle de langage sait configurer Kubernetes aussi bien qu’eux, il ne leur reste rien. Ils ont appris les commandes, pas les principes. La surface, pas la structure.

La simplification est le vrai luxe. Dans un monde noyé sous la complexité, la capacité à supprimer du code, à réduire les dépendances, à dire « nous n’avons pas besoin de ça » — cette capacité vaut plus que toute la pile technique du monde. Mais elle n’est pas valorisée. Personne n’a jamais été promu pour avoir supprimé un microservice. Personne n’a jamais été embauché parce que son système n’avait que trois dépendances. L’industrie récompense la complexité parce que la complexité justifie des effectifs, des budgets, et des consultants. La simplicité menace tout ça.

Mais attention : il y a deux figures derrière « je comprends en profondeur », et elles sont opposées. La première regarde un système de 47 microservices et dit : « ceci est un monolithe déguisé, remplaçons-le par un service et une base de données ». Cette personne crée de la valeur en réduisant la complexité. La seconde est le rentier du brownfield — celui dont le pouvoir vient exclusivement du fait qu’il est le seul à comprendre pourquoi l’ORM fait ce truc bizarre le mardi, pourquoi le pipeline CI a ce hack que personne ne touche, pourquoi le déploiement nécessite trois scripts shell non documentés dans un ordre précis. Cette personne extrait de la rente d’une complexité qu’elle a contribué à créer ou qu’elle a laissé s’accumuler. Son « expertise profonde » n’est pas de la maîtrise — c’est du lock-in personnel.

Le test est simple : est-ce que ta contribution rend le système plus compréhensible par quelqu’un d’autre que toi, ou moins ? Si la réponse est « moins », tu n’es pas un artisan. Tu es un péage.

L’aube

Mais comment je survis, concrètement ? Les offres d’emploi demandent Kubernetes. Les bootcamps enseignent React. Les managers veulent du « full-stack » avec 47 technologies dans la pile. Si je simplifie, je ne suis pas embauché.

Le crépuscule

Tu as raison sur le marché tel qu’il est. Mais le marché tel qu’il est — celui qui embauche 70% de moins qu’en 2022, qui licencie 244 000 personnes en 2025, qui remplace les juniors par des outils IA — ce marché ne te veut pas non plus avec 47 technologies. Ce marché est en train de se réorganiser. Et quand il aura fini, il aura besoin de personnes qui comprennent les problèmes, pas les outils.

Voici ma prédiction, aussi réaliste que je peux la faire.

---

III. Prédictions honnêtes

Ce qui va probablement arriver

1. Le SaaS actuel va s’effondrer partiellement. Le modèle SaaS de la dernière décennie — des applications identiques vendues à des milliers d’entreprises avec une personnalisation minimale — est menacé des deux côtés. Par le haut : l’IA permet de générer des applications « suffisamment bonnes » sur mesure, rendant les SaaS génériques moins nécessaires. Par le bas : les coûts d’infrastructure cloud deviennent insoutenables pour les entreprises moyennes. Ce qui survivra, c’est le SaaS qui résout un problème de domaine si précis qu’aucun outil général ne peut le remplacer. Le SaaS générique — le énième outil de gestion de projet, le énième CRM — sera le premier à tomber.

2. Le « logiciel situé » va revenir. Clay Shirky l’avait nommé en 2004 : le logiciel construit pour un petit groupe de personnes spécifiques, résolvant leur problème spécifique, sans ambition de scalabilité universelle. L’ère de l’assemblage avait tué cette idée en rendant les frameworks universels si dominants que personne n’imaginait construire autrement. L’IA générative, paradoxalement, la fait renaître : si un modèle peut générer un outil sur mesure pour un besoin précis, pourquoi acheter un SaaS qui résout 80% de ton problème et te force à contourner les 20% restants ?

Le danger ici est le « vibe coding » — du logiciel situé généré par IA que personne ne comprend et que personne ne peut maintenir. La promesse est le logiciel situé construit avec rigueur — des outils compréhensibles, pour des personnes spécifiques, résolvant des problèmes spécifiques.

3. Les seniors simplificateurs vaudront plus qu’avant. Les seniors gardiens de la dette vaudront moins. Le marché aura besoin de personnes capables de trois choses que l’IA ne fait pas : comprendre un domaine métier assez profondément pour formuler le bon problème, évaluer si une solution (générée ou non) résout réellement le problème, et maintenir un système sur la durée — c’est-à-dire le comprendre assez pour le faire évoluer sans tout casser. Ce sont des compétences de seniors. Mais de seniors qui simplifient — qui regardent un graphe de dépendances et enlèvent des nœuds, qui remplacent un microservice par une fonction, qui rendent le système compréhensible par la prochaine personne.

Le senior dont le pouvoir vient de l’opacité — le seul à savoir pourquoi le script de déploiement échoue silencieusement le troisième mardi du mois — est menacé de deux côtés. Par l’IA, qui peut éventuellement naviguer dans le marécage de son code legacy. Et par les juniors, qui avec des outils IA et de la pratique délibérée peuvent atteindre en deux ans un niveau de compréhension structurelle que le rentier n’a jamais cherché à construire, trop occupé à défendre son périmètre. L’IA ne distingue pas l’artisan du péage. Mais le marché, à terme, le fera — parce que le système simplifié par l’artisan coûte moins cher à maintenir que le système rendu opaque par le péage. Le calcul est cruel mais arithmétique.

4. Les juniors qui pratiquent délibérément survivront — les autres seront broyés. Le chemin pour un développeur débutant en 2026 n’est pas « apprendre React et espérer ». C’est : maîtriser un langage au point de pouvoir écrire un left-pad les yeux fermés. Comprendre comment une requête traverse un réseau. Lire du code avant d’en écrire. Construire un projet complet de bout en bout sans framework, puis comprendre pourquoi les frameworks existent. L’IA peut remplacer un assembleur. Elle ne peut pas remplacer quelqu’un qui comprend ce que l’assemblage fait.

5. Le revenu universel deviendra un sujet technique, pas seulement politique. Si 40% des tâches d’externalisation technologique en Afrique sont affectées par l’IA d’ici 2030, et si l’emploi des développeurs juniors continue de chuter, la question du revenu universel de base n’est plus une utopie — c’est un calcul. Les gains de productivité IA vont quelque part. La question est si ce « quelque part » est uniquement les actionnaires, ou si une partie revient aux commoners dont le travail a nourri le modèle. Ce n’est pas une question de générosité. C’est une question de soutenabilité : si vous détruisez la filière de formation (les postes juniors) tout en moissonnant le travail passé (les communs open source), vous n’avez plus de pipeline. La machine mange ses propres graines.

Ce qui ne va probablement pas arriver

Le « tout-IA » ne va pas arriver. L’étude METR montre que l’IA ralentit les développeurs expérimentés sur des tâches complexes dans leur propre code. Le code IA contient des vulnérabilités, augmente la dette technique, et crée du « churn » — du code jetable. Les entreprises qui ont massivement adopté le vibe coding vont frapper des murs de maintenance. La correction viendra — douloureusement, comme toujours dans les cycles technologiques — mais elle viendra.

L’open source ne va pas mourir. Les communs survivent aux enclosures — pas intacts, pas indemnes, mais ils survivent. Les communautés du logiciel libre en Afrique francophone, les fondations Apache et Linux, les développeurs qui mettent « no AI training » dans leurs licences — ces gestes ne renverseront pas l’arc, mais ils maintiennent l’espace du possible.

---

IV. Möbius comme miroir

L’aube

Tu m’as parlé de Möbius. Qu’est-ce que c’est ?

Le crépuscule

Möbius, c’est un langage de programmation à adressage par contenu — chaque morceau de code a une identité dérivée de ce qu’il est, pas de là où il est stocké. Avec un horodatage Bitcoin pour prouver quand il a existé. C’est technique, mais l’idée est simple : un miroir mathématique.

Imagine un système qui te montre trois choses :

Ce que tu as fait. Chaque fonction que tu as écrite a une identité stable et un horodatage. L’historique est incorruptible. Ce n’est pas un CV — c’est une preuve. Tu ne peux pas le gonfler, et personne ne peut te l’enlever.

Ce que tu dois améliorer. Si ton code est dans le graphe, les comparaisons sont possibles. Pas « ton code est meilleur ou pire que celui de X » — mais « voici les patterns que tu utilises, voici les patterns que d’autres utilisent pour le même problème, voici ce qui pourrait être plus simple ». Le miroir ne juge pas. Il reflète.

Ce que nous devons faire pour que tu restes lisible. C’est la partie la plus subversive. Si chaque morceau de code a une identité de contenu, alors le code qui change son nom mais pas sa structure est reconnu comme le même code. Le code qui change sa structure mais pas son nom est reconnu comme différent. La lisibilité — la capacité pour un humain de comprendre ce que fait un système — devient une propriété traçable, pas une aspiration.

L’aube

Et le lien avec l’IA ?

Le crépuscule

L’IA générative produit du code qui fonctionne sans être lisible. Möbius est une réponse possible : un système qui rend la lisibilité traçable. Si le code est adressé par contenu, alors le code généré par IA peut être inspecté de la même manière que le code écrit par un humain — par ce qu’il est, pas par qui l’a produit. Le miroir ne se soucie pas de la source. Il se soucie de la structure.

C’est aussi une réponse au problème de l’entraînement. Si chaque morceau de code a une identité et un horodatage, alors la question « ce code a-t-il été utilisé pour entraîner un modèle ? » devient traçable. Pas parfaitement. Pas aujourd’hui. Mais la structure est là.

Et c’est une réponse au problème de l’agentivité. Le principe de Smalltalk dit

« si un système doit servir l’esprit créatif, il doit être entièrement compréhensible par un seul individu ». Möbius est un système qui rend chaque pièce de code individuellement compréhensible — par son identité de contenu, par sa trace temporelle, par sa place dans le graphe. C’est le contraire exact du vibe coding : non pas « ça marche et je ne sais pas pourquoi », mais « voici exactement ce que c’est, quand ça a existé, et comment ça se relie au reste ».

Et c’est, enfin, une réponse au problème du rentier brownfield. Le miroir ne se soucie pas de qui comprend le code — il rend la structure visible indépendamment des personnes. Le rentier perd son pouvoir quand la complexité qu’il gardait opaque devient traçable, mesurable, comparable. Quand le miroir dit « cette fonction a 47 dépendances et pourrait en avoir 3 », le péage n’a plus d’ombre où se cacher. L’artisan, lui, est validé — ses réductions de complexité sont visibles dans le graphe. Möbius rend le simplificateur mesurable et le gardien de dette visible. Ce n’est pas un jugement moral — c’est une propriété structurelle du système.

---

V. Pratique délibérée : ce que le junior a besoin d’entendre

Le crépuscule

Voici ce que je dirais au junior de 2026, sans condescendance et sans mensonge.

Commence par le domaine, pas par l’outil. Si tu construis un système de facturation, comprends d’abord la facturation. Quels sont les cas limites ? Quelles sont les contraintes légales ? Qu’est-ce qui rend une facture valide dans la juridiction de ton client ? L’outil vient après — et souvent, le bon outil est plus simple que ce que l’industrie te vend. Une base de données relationnelle et un script bien écrit résolvent 80% des problèmes métier. Le reste, c’est de l’ingénierie de la complexité — et l’ingénierie de la complexité a un coût que personne ne t’apprend à calculer.

Apprends un langage au point d’en toucher le fond. Je ne dis pas Scheme parce que je suis partial (je le suis). Je dis : choisis un langage et apprends-le jusqu’à comprendre comment il fonctionne, pas seulement comment l’utiliser. Un langage où tu peux lire l’implémentation. Un langage qui ne te cache pas ses mécanismes. Un langage qui te rend plus intelligent, pas plus productif. La productivité suit la compréhension. Jamais l’inverse.

Construis un système complet sans dépendances externes, une fois. Un serveur web qui écoute sur un port, parse des requêtes HTTP, retourne des réponses. Pas avec Express — à la main. Pas parce que tu vas le faire dans la vraie vie, mais parce que tu ne comprendras jamais ce que fait Express si tu ne sais pas ce qu’il remplace. L’IA peut assembler des appels d’API. Elle ne peut pas te donner la compréhension de ce que ces API font. Cette compréhension est ton avantage concurrentiel — le seul qui résiste à l’automatisation.

Lis du code avant d’en écrire. Le meilleur tutoriel pour apprendre un langage n’est pas un tutoriel — c’est un petit projet bien écrit dans ce langage. Lis-le ligne par ligne. Comprends les décisions. Demande-toi pourquoi l’auteur a fait ce choix plutôt qu’un autre. C’est le même geste qu’un musicien qui transcrit un solo : tu n’apprends pas le solo, tu apprends la pensée derrière le solo.

Résiste à la panique du framework. Quand l’industrie te dit que tu dois apprendre le framework du mois, pose la question : est-ce que ce framework résout un problème que j’ai, ou est-ce qu’il résout le problème de quelqu’un d’autre en créant un nouveau problème pour moi ? Le développeur qui connaît cinq frameworks superficiellement est remplaçable par un modèle de langage. Le développeur qui connaît un domaine en profondeur ne l’est pas.

Et pose-toi cette question chaque jour : est-ce que mon prochain commit rend le système plus lisible ou moins lisible ? Pas plus lisible pour moi — plus lisible pour la prochaine personne. C’est le test qui distingue l’artisan du rentier. L’artisan simplifie pour que d’autres puissent comprendre. Le rentier complexifie pour que personne d’autre ne puisse comprendre. Les deux peuvent se raconter l’histoire de l’expertise profonde. Mais le code ne ment pas : si ton départ rendrait le système ingouvernable, tu n’as pas construit de l’expertise — tu as construit une dépendance à toi-même. Et l’IA viendra te chercher là aussi, parce que naviguer dans l’opacité, c’est exactement ce que les modèles de langage font de mieux. La seule chose qu’ils ne font pas bien, c’est décider qu’un système est trop complexe et le simplifier. C’est ça, ton travail.

L’aube

Et si je fais tout ça et que le marché ne me veut quand même pas ?

Le crépuscule

Alors construis le tien. Le logiciel situé — un outil pour un groupe de personnes spécifiques, résolvant leur problème spécifique — est la chose que l’IA rend plus facile à faire et que le marché ne peut pas te prendre. Pas un SaaS à l’échelle mondiale. Un outil qui résout le problème de la coopérative agricole en face de chez toi, de l’association culturelle de ton quartier, du cabinet médical de ta rue. L’IA peut t’aider à le construire. Mais le domaine — la compréhension de ce dont ces personnes ont réellement besoin — c’est toi qui l’as. C’est le geste qu’aucun modèle ne peut faire à ta place : aller parler à quelqu’un, comprendre son problème, et construire la chose la plus simple qui le résout.

C’est ça, le travail qui vient. Pas l’assemblage de composants sur les conditions de quelqu’un d’autre. La résolution de problèmes réels pour des personnes réelles, avec des outils que tu comprends de bout en bout.

---

VI. Ce qui vient après l’arc

L’arc que nous avons tracé — de la liberté recadrée à l’enclosure générative — n’est pas une fatalité. C’est une trajectoire. Les trajectoires peuvent être infléchies.

Voici ce qui existe déjà et qui pointe dans une autre direction :

Le logiciel compréhensible. Des langages comme Scheme, des systèmes comme Smalltalk, des architectures comme celle que Möbius explore — des outils où la compréhension n’est pas sacrifiée à la productivité. Ce sont des niches aujourd’hui. Ils pourraient être des refuges demain.

Le logiciel situé. Des outils construits pour des communautés spécifiques, pas pour un marché mondial. Les communautés du logiciel libre en Afrique francophone — les RAFLL, Ovillage, les JerryMarathons — construisent déjà dans cette direction : des solutions locales, avec des outils libres, pour des problèmes locaux. C’est le contraire exact de la monoculture npm.

La traçabilité comme infrastructure. Le CRA européen exige des SBOM. Möbius propose l’adressage par contenu. Les licences « no AI training » émergent. Ce sont des premiers pas vers un monde où la question « d’où vient ce code, qui l’a écrit, sous quelles conditions ? » a une réponse vérifiable. C’est l’inverse exact de l’invisibilité qui a permis l’arc d’extraction.

La pratique délibérée comme acte politique. Mais attention : la pratique délibérée vers la simplification est l’acte politique. La pratique délibérée de la complexité est la rente. Le premier geste rend le système compréhensible par d’autres — c’est un bien public. Le second rend le système dépendant de soi — c’est une capture privée déguisée en expertise. Le développeur qui refuse le vibe coding comme mode par défaut et qui simplifie ce qu’il touche maintient une capacité collective : la capacité de la société à comprendre les systèmes dont elle dépend. Le développeur qui empile les abstractions pour sécuriser son poste fait le contraire — il produit de la dette technique qui, un jour, sera soit absorbée par un modèle de langage, soit abandonnée. Ni l’un ni l’autre ne le sauvera. Drucker avait raison : les plans ne sont que de bonnes intentions tant qu’ils ne dégénèrent pas en travail concret. Le travail concret ici, c’est chaque commit, chaque revue de code, chaque décision d’architecture. Le test tient en une question : est-ce que quelqu’un d’autre que moi peut comprendre ce que je viens de faire ?

---

VII. La dernière conversation

L’aube

Si tu devais résumer tout l’arc en une phrase, pour quelqu’un qui n’a jamais écrit une ligne de code ?

Le crépuscule

Les gens qui ont construit les fondations numériques du monde l’ont fait en partageant leur travail. D’autres ont clôturé ce travail et l’ont vendu. Puis ils ont utilisé le travail lui-même pour fabriquer des machines qui remplacent les personnes qui l’avaient fait. Maintenant, la question est : est-ce qu’on accepte ça comme le prix du progrès, ou est-ce qu’on construit autrement ?

L’aube

Et la réponse ?

Le crépuscule

La réponse n’est pas une technologie. C’est une pratique. Construire des choses que tu comprends, pour des personnes que tu connais, avec des outils que tu peux inspecter. Et laisser une trace — pas une trace dans un modèle statistique, mais une trace lisible, versionnable, adressée par contenu, ancrée dans le temps.

Pas que tout le monde pense la même chose. Mais que la pensée de chacun laisse une trace.

L’aube

C’est ambitieux.

Le crépuscule

Non. C’est simple. C’est pour ça que c’est difficile.

---

Ce texte est le prologue et l’épilogue d’une trilogie : « Avant les plateformes » (ère 1), « L’ère de l’assemblage » (ère 2), « L’ère générative » (ère 3). Les quatre documents ensemble — le prélude, les trois ères — composent un arc complet, du laboratoire du MIT aux prompts de 2026. Ils peuvent être lus dans l’ordre ou dans le désordre; chacun se tient seul, mais les quatre ensemble racontent une histoire que les parties séparées ne racontent pas.

← L’enclosure du code — Série complète