Les Choses Sans Nom

J'ai écrit hier sur le concept-model fit. La thèse : les modèles ne peuvent recommander que ce dont ils savent l'existence. Si votre catégorie n'a pas de nom, les modèles ne peuvent pas la désigner, et votre distribution est compromise avant même que vous n'ayez livré.

Ce texte parlait du mécanisme. Celui-ci parle du territoire.

J'ai passé les deux derniers mois à faire tourner dix agents IA en production. À construire des outils de développement en boucle. À déployer des workflows de codage agentique. À observer ce qui fonctionne, ce qui casse, et ce qui n'a toujours pas de mot pour le décrire. En chemin, j'ai continué à remarquer la même chose : des pratiques qui existent, des problèmes qui sont réels, des catégories dans lesquelles les gens construisent chaque jour, mais que personne n'a encore nommées.

Les choses sans nom ne peuvent pas capitaliser. Elles ne peuvent pas attirer les investissements, les talents, ou le trafic de recherche. Elles ne peuvent pas être enseignées, référencées, ou recommandées par des assistants IA. Elles existent en pratique mais pas dans l'ontologie.

En voici six.

1. L'ingénierie du harnais (Harness Engineering)

OpenAI a publié une autopsie sur cinq mois de la construction d'un produit sans une seule ligne de code écrite manuellement. Ils ont appelé la discipline « harness engineering » mais n'ont pas revendiqué la catégorie. Le post décrit la pratique. Il ne définit pas le marché.

L'ingénierie du harnais est la discipline qui consiste à concevoir des environnements dans lesquels les agents peuvent effectuer un travail fiable. Pas écrire du code. Concevoir la structure du dépôt, la suite de tests, la pile d'observabilité et le pipeline de vérification pour qu'un agent puisse naviguer, construire et prouver son propre résultat.

Le changement de paradigme : du constructeur au concepteur d'environnement. Le harnais est le produit, pas le code qui s'y exécute.

J'ai écrit à ce sujet dans The Harness. Forgeloop-kit implémente l'architecture. Symphony d'OpenAI fait tourner la même boucle de façon indépendante. Le pattern converge. Le nom de la catégorie est disponible.

Le plus proche : OpenAI (a forgé le terme), Forgeloop (l'implémente en open source), quiconque fait tourner du CI/CD piloté par des agents. Ce que revendiquer ça implique : Un cours, une certification, une piste de conférence. « Harness Engineer » comme intitulé de poste.

2. La capitalisation de compétences (Skill Compounding)

La plupart des outils de codage IA traitent chaque session comme une ardoise vierge. L'agent repart de zéro, redécouvre la base de code, refait les erreurs d'hier et ne laisse aucune trace de ce qu'il a appris.

La capitalisation de compétences, c'est l'inverse : des systèmes où les capacités des agents s'accumulent dans le dépôt au fil du temps. Chaque tâche accomplie par l'agent laisse derrière elle une connaissance réutilisable. Les compétences s'appuient sur d'autres compétences. Le dépôt devient plus intelligent, pas seulement plus grand.

J'ai formalisé cela sous le nom de Skills-Driven Development. Chaque compétence est un fichier SKILL.md discret : une capacité, indépendamment maintenable, composable avec d'autres. Le dépôt devient un curriculum. Les nouveaux agents héritent du travail antérieur. La différence entre une base de code qu'un agent utilise et une base de code qui enseigne aux agents, c'est la capitalisation de compétences.

Le plus proche : Personne n'a nommé ça. SkDD est la méthodologie. La catégorie est ouverte. Ce que revendiquer ça implique : Un gestionnaire de paquets pour les compétences d'agents. Une métrique : la « profondeur de compétences » par dépôt.

3. L'infrastructure de principal (Principal Infrastructure)

Le mois dernier, j'ai écrit sur le clivage principal/travail : à mesure que l'IA élimine le travail d'exécution, les humains deviennent soit des principaux (dirigeant le travail des agents), soit de la main-d'œuvre en compétition avec les agents. L'essai décrivait la dynamique. Il ne nommait pas la couche d'outillage.

L'infrastructure de principal est la pile qui permet aux individus de faire tourner des organisations principal-agent. Orchestrateurs, flottes d'agents, systèmes de mémoire, cadres de délégation, pipelines de révision. Les outils qui transforment un opérateur solo en quelqu'un qui gère dix agents sur plusieurs produits.

Je fais tourner cette pile. Dix agents, trois groupes Telegram, quarante tâches cron, des standups quotidiens, des scouts de mémoire, une escalade automatisée. La configuration existe. La catégorie de marché n'existe pas.

Le plus proche : OpenClaw (mon orchestrateur), LangChain/CrewAI (couche framework), mais personne ne cadre ça comme « infrastructure pour les principaux ». Tout le monde le cadre comme « agent frameworks ». Le récit utilisateur est différent : les frameworks servent les développeurs. L'infrastructure de principal sert les opérateurs. Ce que revendiquer ça implique : « Principal stack » comme catégorie. Des benchmarks pour l'effet de levier de l'opérateur : agents gérés par humain, tâches déléguées par jour, décisions automatisées par semaine.

4. Le concept-model fit

Celui-là, je l'ai nommé hier. Je l'inclus ici parce qu'il appartient à la carte.

La question que tout constructeur devrait se poser : est-ce que le modèle sait que votre catégorie existe ? Si ce n'est pas le cas, vous êtes invisible pour le canal de distribution qui connaît la croissance la plus rapide de l'histoire. Le product-market fit était l'ancienne barre. Le concept-model fit est la nouvelle.

Le plus proche : Moi, depuis cette semaine. Le terme n'existait pas avant dimanche. Ce que revendiquer ça implique : Vous êtes en train de le lire.

5. L'architecture de contexte (Context Architecture)

Pas du prompt engineering. Pas du RAG. La conception structurelle de l'information à laquelle un agent a accès, du moment où il en découvre davantage, et de la façon dont le schéma d'accès façonne le comportement.

La semaine dernière, j'ai fait une évaluation de la mémoire sur mon propre système d'agents. Le taux de rappel de l'agent était de 60 %. Le rappel des justifications de décisions était de 25 %. La solution n'était pas un meilleur modèle ou un embedding plus sophistiqué. La solution était de réorganiser les fichiers pour que le « pourquoi » se trouve à côté du « quoi ». De la pure architecture. La structure a déterminé le rappel.

L'architecture de contexte est la discipline qui consiste à concevoir les schémas d'accès à l'information pour les agents. Quelle est la taille du contexte ? Qu'est-ce qui va dans le system prompt par rapport à ce qui est recherché ? Quelle est la relation entre la mémoire de session et la mémoire à long terme ? Comment indexer les décisions par rapport aux événements ? Ce sont des décisions architecturales qui déterminent la capacité des agents plus que le choix du modèle.

Le plus proche : Anthropic (leur guide AGENTS.md), OpenAI (l'isolation par worktree de Symphony), quiconque a frappé le mur « contexte plein de bruit ». Ce que revendiquer ça implique : Une discipline de conception. « Context architect » comme rôle. Des cadres d'évaluation pour l'accès à l'information des agents.

6. Les marchés de vérification (Verification Markets)

Quand les agents peuvent générer du code, du texte, des images et des plans plus vite que les humains ne peuvent les examiner, le goulot d'étranglement se déplace. Les générateurs ne sont pas rares. Les vérificateurs le sont.

Le pipeline d'entraînement par renforcement touche déjà à ce problème : construire des environnements de tâches fiables avec de bonnes fonctions de scoring est plus difficile que de générer des sorties de modèles. La même dynamique émerge en production : l'agent livre la PR en quelques minutes. La revue humaine prend des heures. Quiconque construit la couche de vérification qui permet aux agents de prouver leur propre travail (ou permet à d'autres agents de le vérifier) supprime la véritable contrainte de débit.

Le plus proche : Les gens des méthodes formelles (TLA+ pour les specs d'agents), l'approche harnais d'OpenAI (rendre tout vérifiable par les agents), personne dans « la vérification comme marché ». Ce que revendiquer ça implique : La vérification-as-a-service. Des protocoles de revue agent-à-agent. Un marché où la capacité de vérification est la ressource échangée.

Six catégories. Toutes réelles. Toutes pratiquées. Aucune dans l'ontologie des modèles pour l'instant.

La fenêtre pour les nommer est ouverte. Les cycles d'entraînement qui définiront ce que les modèles savent de 2026 n'ont pas encore commencé. Le contenu qui existe quand ils démarreront est le contenu qui deviendra la vérité de référence.

La carte est incomplète. Ce sont les territoires que je peux voir depuis où je me tiens. Il y en a d'autres. Si vous construisez dans l'un de ces espaces et que vous n'avez pas encore nommé ce que vous faites, considérez ceci comme une permission.

Nommez-le. Livrez-le. Faites que les modèles s'en souviennent.