De l’écriture de code à l’écriture d’entreprises

Avant 2025, construire un logiciel signifiait écrire du code. Vous ouvriez votre éditeur, tapiez des fonctions, corrigiez des bugs, validiez vos changements. La boucle de feedback était courte et le travail profondément manuel. Si vous vouliez que quelque chose soit construit, soit vous le construisiez vous-même, soit vous l’expliquiez à un autre ingénieur qui écrivait ensuite le code à votre place.

Ce monde est révolu. Pas de la manière que l’on prédisait, où l’IA grignoterait lentement les marges de la productivité. Il est révolu au sens où la définition même de « construire » est en train d’être reconstruite de fond en comble, une couche d’abstraction après l’autre, à un rythme difficile à saisir.

En raisonnant en couches d’abstraction, j’en compte cinq :

1. Écrire du code : l’humain écrit chaque ligne
2. Décrire les changements : l’humain dit à l’agent ce qu’il faut modifier et relit le résultat
3. Harness Programming : les agents écrivent 100 % du code
4. L’organisation : objectifs, rôles, intention. Le code est invisible. Les humains forment le conseil d’administration
5. Méta-organisations : construire de nombreuses entreprises, des entreprises qui construisent des entreprises

Chaque couche fait la même chose : elle éloigne les humains de l’implémentation et les rapproche de l’intention. Chacune semble radicale quand on la découvre, et évidente avec le recul.

Je vous les présente une par une.

Couche 1 : écrire du code

C’est là que la plupart d’entre nous ont commencé. Vous réfléchissez à ce qui doit se passer, vous le traduisez en code, vous l’exécutez, vous le déboguez, vous le livrez. Toute la charge créative et mécanique repose sur vos épaules.

Vous êtes à la fois l’architecte et le maçon.

L’essentiel de l’histoire de l’ingénierie logicielle se déroule ici. Des décennies d’outils, de langages, de frameworks et de pratiques, tous conçus pour accélérer cette boucle. Gestion de versions, linters, systèmes de types, CI/CD. Tout cela a été construit pour aider les humains à mieux écrire du code.

Nous trouvions ça amusant.

Couche 2 : décrire les changements

Puis Claude Code, Codex et des outils similaires sont arrivés. Soudain, vous pouviez décrire ce que vous vouliez modifier, et un agent écrivait le code à votre place. Pas parfaitement, mais assez bien pour que votre travail passe de l’écriture à la relecture.

C’est là que se trouvent aujourd’hui la plupart des ingénieurs. Vous ouvrez un ticket dans Linear ou un fil Slack, vous décrivez ce que vous voulez, et l’agent produit un diff. Vous le relisez. Vous le contredisez. Vous le guidez. Vous pouvez dire « non, utilise plutôt ce pattern » ou « la gestion des erreurs devrait fonctionner autrement ici ». L’agent itère, et vous finissez par approuver.

Avant

« Je vais écrire le middleware d’authentification, gérer les cas limites, ajouter des tests et soumettre une PR. »

Maintenant

« Ajoute un middleware d’authentification qui valide les jetons JWT. Gère proprement les jetons expirés. Couvre les cas limites dans les tests. »

Vous écrivez du code plus vite que jamais. Mais vous restez profondément impliqué au niveau du code. Vous relisez toujours les diffs, vous vous souciez toujours des patterns d’architecture, vous apportez toujours votre jugement et votre goût.

Vous sentez, à juste titre, que ces éléments comptent pour la réussite de votre produit.

Le changement clé ici est subtil : vous êtes passé de l’écriture de code à la définition du travail.

Mais vous regardez encore le code.

Couche 3 : Harness Programming

Certaines équipes sont allées plus loin. L’objectif est de laisser les agents écrire 100 % du code. Pas 80 %, pas « la plupart ». Tout. Cette approche est appelée Harness Programming ou Harness Engineering, un terme cristallisé par OpenAI dans son compte rendu détaillé sur la construction d’une base de code d’un million de lignes sans une seule ligne tapée à la main.

Lors d’une expérience interne de cinq mois, une petite équipe d’ingénieurs a guidé des agents Codex à travers des pull requests et des workflows de CI. Les agents ont tout écrit : logique applicative, tests, configuration de la CI, documentation, observabilité et outillage. Les humains n’ont écrit aucun code. Leur travail principal est devenu de permettre aux agents d’accomplir un travail utile : concevoir les contraintes, inscrire des « principes d’or » dans le dépôt et construire les boucles de feedback qui gardaient les agents sur la bonne voie.

Dans ce modèle, vous ne regardez plus des fichiers et des diffs individuels. Votre interface principale est Claude Code ou Codex. Vous guidez l’agent par des instructions de plus haut niveau. Vous restez dans la boucle et pouvez intervenir, mais votre relation avec le code lui-même devient indirecte.

La question suivante est naturelle : si les agents font tout le travail, pourquoi continuer à le répartir manuellement ? Pourquoi rester dans Claude Code à leur confier les tâches une par une ?

Chez OpenAI, Symphony est une réponse à cette question.

Il reprend les mêmes idées que la boucle Ralph Wiggum et c’est en gros un service qui tourne en continu : il lit les tickets dans Linear, crée un espace de travail isolé pour chaque ticket et y exécute un agent de code. Vous le pointez vers un projet, vous lui donnez quelques agents, et il se met à écluser le backlog. Les agents ouvrent des PR, relisent le travail les uns des autres et fusionnent quand la CI passe.

Symphony reste du Harness Engineering dans son principe : centré sur le dépôt, borné au ticket et tourné vers l’implémentation. Mais il automatise la répartition. Au lieu que vous surveilliez chaque session d’agent, le système prend le travail en charge et l’exécute. Ce qui est remarquable dans le dépôt de Symphony, c’est qu’il ne contient presque aucune implémentation de code. C’est surtout une spécification, accompagnée d’une forte incitation à implémenter votre propre version.

Ils ne se soucient pas du code qui l’exécute. Ils se soucient des idées.

L’enseignement essentiel : les garde-fous sont tout. Plus vous êtes rigide sur ce que les agents ont le droit de faire, sur les patterns qu’ils suivent, sur les règles de linting et de test qu’ils respectent, mieux cela fonctionne. Sans limites strictes, les agents dérivent. Ils font leur propre chose. Ils perdent le contact avec la réalité. Et vous vous retrouvez avec un chantier de refactoring. Des règles strictes de linting, de formatage et de test, facilement accessibles à chaque agent, sont ce qui garde tout le système ancré.

Cela signifie aussi que c’est étonnamment difficile à appliquer à un projet brownfield, car les agents ont besoin de ces garde-fous stricts, et nous, les humains, avons tendance à les omettre.

Couche 4 : l’organisation

La couche 4 est un grand saut.

Dans les couches 1 à 3, les humains pensent encore au code, même s’ils ne l’écrivent ni ne le lisent plus. Les tickets sont délimités par l’implémentation. Le travail est défini en termes de dépôts, d’endpoints et de modules. L’abstraction a changé, mais le modèle mental n’a pas changé.

À ce niveau, vous cessez complètement de penser au code. Pas seulement de le lire, mais de délimiter le travail autour de lui. Au lieu de décrire ce que le code doit faire, vous décrivez ce que vous voulez voir se réaliser. Pas « implémente un limiteur de débit sur l’API », mais « les utilisateurs ne doivent jamais pouvoir submerger le système ». Pas un ticket, mais une intention.

Thomas Dohmke, CEO de GitHub jusqu’en août 2025, est parti créer une nouvelle entreprise appelée Entire, avec 60 M$ de financement d’amorçage. Sa thèse : GitHub a été conçu pour la collaboration entre humains autour du code, mais dans un monde où les machines sont les principales productrices de code, le code lui-même n’est plus l’artefact le plus important. Ce qui compte, ce sont le raisonnement, les spécifications et l’intention qui l’ont produit. Comme il le dit, nous allons vers « une abstraction bien plus élevée, faite de spécifications, de raisonnement, de journaux de session, d’intention, de résultats ».

Nous n’avons jamais spécifié le code. Nous spécifions à quoi nous voudrions que le monde ressemble. Si quelque chose cloche, nous le voyons au niveau de l’application et nous créons du nouveau travail. Nous ne touchons jamais au code.

Mais capturer l’intention n’est pas seulement un changement d’outillage. C’est un changement organisationnel. Quand vous cessez de penser au code, vous commencez à penser aux rôles, aux responsabilités, aux objectifs et à l’imputabilité. Qui définit ce que le produit doit être ? Qui décide des priorités ? Qui examine les résultats ? Ce sont des questions d’organisation, pas d’ingénierie.

La structure naturelle qui émerge ressemble à une entreprise. Vous fixez un objectif de haut niveau : « construire le meilleur boilerplate serverless AWS open source en Python ». Vous nommez un agent CEO, vous lui confiez la mission et la vision, et vous le laissez exécuter. Le CEO recrute un ingénieur fondateur. L’ingénieur recrute des juniors. Le CEO fait venir un product manager et un responsable marketing. Ils se mettent à construire en public, à écrire des articles de blog, à livrer du code, à itérer à partir des retours.

Des outils comme Paperclip rendent cela concret : vous définissez une entreprise avec un organigramme, vous attribuez des rôles aux agents, vous fixez des objectifs et des budgets, et vous laissez l’organisme tourner.

Vous agissez en tant que conseil d’administration : vous approuvez les recrutements, examinez la stratégie et annulez des décisions si nécessaire.

Ces organisations ne sont pas statiques.

Elles apprennent. Elles déterminent ce qui a fonctionné et ce qui n’a pas fonctionné. Elles s’adaptent. À un moment, le CEO décide peut-être que l’équipe a besoin de plus de monde, ou que quelqu’un sous-performe et doit être remplacé. C’est ainsi que fonctionnent les vraies organisations. La structure est vivante.

En tant qu’humains, nous agissons comme un conseil d’administration. Nous pouvons toujours orienter. Certaines choses exigent notre approbation, et nous pouvons donner des instructions au CEO à tout moment.

« Je pense que tu devrais te concentrer sur cette opportunité. »

« Licencie cette personne. »

« La stratégie est mauvaise ; change de cap. »

Le CEO reçoit l’instruction et la délègue au reste de l’organisation.

Nous ne gérons plus jamais d’éléments de travail individuels.

Couche 5 : méta-organisations

Et c’est ici que ça devient vertigineux.

Si vous pouvez construire une organisation et la superviser comme un conseil d’administration, vous pouvez en construire dix. Vous pouvez avoir des entreprises qui construisent des entreprises. Des entreprises qui construisent des modèles pour d’autres entreprises. Un portefeuille d’organisations autonomes, chacune poursuivant sa propre mission, chacune avec son propre agent CEO, chacune grandissant et s’adaptant.

Un conseil d’administration peut superviser de nombreuses entreprises. C’est, après tout, ce que font les conseils.

C’est la couche que nous comprenons le moins. Nous avons les briques de base, et des outils comme Paperclip prennent déjà en charge plusieurs entreprises dans un même déploiement, avec une isolation complète des données. Le concept de modèles d’entreprise téléchargeables, des structures organisationnelles prêtes à importer et à exécuter, figure sur la feuille de route.

Mais que se passe-t-il quand une organisation peut créer de nouvelles organisations pour résoudre des sous-problèmes ? Quand une entreprise peut créer une filiale, la doter d’agents, lui donner un budget et une mission, et la laisser tourner ? Quand la méta-organisation elle-même se met à décider quelles entreprises financer, lesquelles fermer et lesquelles fusionner ?

Nous ne le savons pas encore. C’est la frontière.

Le rythme

Entre 2010 et 2016, la communauté JavaScript a traversé une période parfois appelée les guerres des frameworks. React, Angular, Ember, Backbone, Vue : chacun gagnait en popularité, chacun se battait pour dominer. C’était volatil. Il fallait apprendre un nouveau framework chaque année, parfois tous les quelques mois. Meta, Google et des équipes plus petites se sont toutes affrontées pour définir l’avenir du développement frontend.

Cette guerre a duré environ six ans.

Le rythme du changement

Chronologie des couches d’IA :

• Janv. 2026 : sortie d’OpenClaw. Il devient la référence pour exécuter des agents dédiés. Le projet à la plus forte progression de l’histoire de GitHub.
• Févr. 2026 : OpenAI rachète OpenClaw.
• Févr. 2026 : OpenAI publie Harness Engineering. Un million de lignes de code, aucune tapée à la main.
• Févr. 2026 : lancement d’Entire. L’ancien CEO de GitHub parie 60 M$ que l’intention, et non le code, est la nouvelle primitive.
• Mars 2026 : sortie de Symphony. Répartition automatisée des tickets vers les agents via Linear.
• Mars 2026 : lancement de Paperclip. CEO agents, organigrammes, budgets, gouvernance. Des entreprises comme organismes.

Comparaison

1. Guerres JS : ~6 ans
2. Couches d’IA : ~semaines

Tout ce que j’ai décrit, d’OpenClaw à Harness Engineering puis Symphony et Paperclip, est sorti en l’espace de quelques semaines.

Et voici ce qu’il faut savoir sur les couches d’abstraction : plus on monte, plus la vitesse d’itération augmente. Si les agents peuvent désormais construire des entreprises qui montent elles-mêmes dans la couche d’abstraction, le progrès se compose. Chaque couche accélère la découverte de la suivante.

Que vous croyiez à la singularité, à l’AGI ou à n’importe quel grand récit, il est important de reconnaître que cela ne se joue pas à l’échelle de plusieurs années.

Cela se joue en semaines et en mois.

Ce que cela signifie pour nous

Un petit groupe de personnes en bénéficiera d’abord. C’est vrai de chaque bouleversement technologique. Mais je ne crois pas à la sous-classe permanente. Je crois que chacun aura sa place pour s’épanouir dans ce nouveau monde, quel que soit le moment ou la manière dont il a choisi d’y participer, ou même s’il choisit de ne pas le faire.

J’espère que les humains pourront se concentrer sur ce qui fait notre humanité. Le travail créatif. Le temps avec les amis et la famille. Les relations et les expériences qui comptent vraiment. Si les agents réalisent l’essentiel de l’implémentation, le travail et l’argent pourraient cesser d’être les marqueurs de statut qu’ils ont été.

Nous pouvons être le conseil d’administration, pas les maçons.

Voyons comment cela se passera.