Note de la rédaction : Alors que les agents d'IA évoluent du simple prompt ponctuel et du 'vibe coding' vers des workflows plus complexes, la question cruciale n'est plus « le modèle peut-il accomplir la tâche ? », mais « peut-on capitaliser les capacités de l'IA en actifs de processus réutilisables et cumulatifs ? ».
À partir du GBrain de Garry Tan, cet article résume cinq formes essentielles vers lesquelles convergent de nombreux utilisateurs d'outils d'agents comme Codex, Claude Code, Hermes, etc. : les Compétences paramétrables, les Cadres d'exécution légers (Thin Harness), les Routeurs (Resolvers), la couche d'exécution séparant le jugement du modèle du code déterministe, et la Mémoire pour l'accumulation de contexte à long terme.
La combinaison de ces modules pointe vers une nouvelle « capacité de processus » : encoder l'expérience en flux, abstraire les tâches en paramètres, confier les règles stables au code, déléguer le jugement et la synthèse au modèle, et capitaliser en continu via la couche mémoire. Contrairement aux applications ou prompts générés ponctuellement, ce type de système est plus difficile à reproduire et plus susceptible de constituer la base d'un avantage compétitif durable à l'ère de l'IA, que ce soit pour un individu, une petite équipe ou une entreprise.
Texte original ci-dessous :
J'ai passé un certain temps à étudier le GBrain de Garry Tan. En tant que personne sans formation technique et ne travaillant pas dans le capital-risque, je souhaitais extraire les structures génériques que j'y vois et ce qui le rend vraiment intéressant.
Je pense que beaucoup de gens convergent progressivement vers le même ensemble de structures fondamentales. Elles peuvent être résumées en 5 formes, qui représentent également la direction naturelle de l'évolution des outils d'IA de type agent comme Codex, Claude Code, Hermes, OpenClaw, etc.
Lecture connexe : « Harness léger, Skills robustes : la véritable source d'une productivité IA multipliée par 100 »
Skills : Des SOP aux « appels de méthode »
Les Skills sont le point de départ le plus naturel pour presque tout le monde. Même sans qu'on le leur rappelle, les utilisateurs les construisent instinctivement, car leur forme est très familière. Au début, je les ai compris comme des SOP (Procédures Opérationnelles Standard), c'est-à-dire des flux pour accomplir quelque chose. L'utilisateur fournit le « quoi faire », le Skill fournit le « comment faire ».
La compréhension de Tan est qu'un Skill ressemble plus à un « appel de méthode ». En programmation, un appel de méthode utilise des paramètres pour invoquer un flux de programme. Le même code s'exécute à chaque fois, ce qui change, ce sont les paramètres : quelles données, quel problème, quel objectif. Par exemple, la même fonction process_invoice peut traiter chaque facture du système, pas seulement celle pour laquelle elle a été initialement écrite.
Le Skill a une structure similaire. Un Skill nommé /investigate peut contenir sept étapes fixes qui ne changent pas. Ce qui change, ce sont les paramètres : TARGET (qui ou quoi enquêter), QUESTION (ce que vous voulez comprendre), DATASET (où chercher l'information). Pointez-le vers un cas de lanceur d'alerte dans la santé, il agit comme un analyste de recherche ; pointez-le vers des dépôts SEC, il agit comme un enquêteur juridique. Le même fichier, les mêmes sept étapes, la différence est fournie par le monde extérieur.
Cela diffère d'un SOP traditionnel. La plupart des SOP sont écrits pour un poste ou une tâche spécifique, comme « traiter les comptes fournisseurs ». Chaque cas d'utilisation a son propre flux. Le Skill est plus abstrait, le même flux peut traiter une classe de problèmes. Un Skill bien conçu peut faire le travail de dizaines de SOP, car les informations des cas concrets sont extraites du document et transférées vers les paramètres. En pratique, certains Skills sont plus proches d'un SOP, d'autres plus d'un appel de méthode.
Thin Harness : Le modèle est l'intelligence, le Harness est le bras armé
Les modèles, comme Opus, GPT-5.5, etc., sont l'intelligence brute ; les Harness, comme Claude Code, Codex CLI, Hermes, OpenClaw, sont les cadres d'exécution qui donnent au modèle de vrais « bras ». Ils gèrent l'exécution en boucle, la lecture/écriture de fichiers, la gestion du contexte, l'application des contraintes de sécurité. Leur code cœur fait environ 200 lignes.
Garry mentionne une erreur que beaucoup commettent : entasser constamment plus de choses dans le Harness. C'est mon cas aussi. J'ai fini par accumuler 100 définitions d'outils et une pile de serveurs MCP. Résultat : la fenêtre de contexte était saturée par des descriptions d'outils inutiles pour la tâche en cours. Le modèle commençait à confondre quel outil utiliser, la latence augmentait, la précision baissait, conduisant finalement à une « corruption du contexte ».
Resolvers : Utiliser des tables de routage pour résoudre la corruption du contexte
La solution à la corruption du contexte est d'établir une table de routage. Le rôle d'un Resolver est de mapper explicitement « la tâche de type X qui vient d'arriver » vers « le Skill Y qui doit être appelé ». Quand vous n'avez que 5 Skills, vous n'avez pas besoin de Resolver ; mais quand vous en avez 100, les descriptions deviennent floues, le modèle a du mal à appeler le bon Skill au bon moment. Le Resolver remplace la correspondance de motifs floue par des règles explicites.
Tan a également mis en place un mécanisme similaire pour les fichiers : une table de routage indépendante pour décider où la sortie d'un Skill doit être placée dans le système de fichiers. C'est la même structure « audit → routage » appliquée à un autre problème. Ainsi, les sorties vont de manière stable dans le bon dossier, et non à un emplacement deviné temporairement par le modèle.
Skillify est une autre idée complémentaire : c'est une boucle qualité pour transformer un Skill ponctuel en infrastructure réutilisable à long terme. Le processus en 10 étapes décrit par Tan comprend : la définition d'un contrat, l'utilisation de code déterministe là où c'est approprié, les tests unitaires, les tests d'intégration, l'évaluation LLM-as-judge, l'entrée dans le Resolver, les scripts d'audit, la vérification des Skills sans chemin d'appel, et les tests de fumée de bout en bout. Le critère est simple : si vous devez poser deux fois la même question au modèle, c'est un échec.
Latent vs. Déterministe : Confier le jugement au modèle, les tâches déterminées au code
Il est crucial de distinguer quels travaux doivent être confiés au LLM et lesquels à un système déterministe. Les LLM sont bons pour le jugement, la synthèse, la reconnaissance de motifs et la lecture entre les lignes ; mais ils ne sont pas bons pour le calcul arithmétique, l'optimisation combinatoire, ni pour toute tâche nécessitant la même réponse à chaque fois. Le LLM est fondamentalement probabiliste ; quand une solution déterministe peut résoudre le problème, il ne faut pas utiliser le LLM.
La plupart des personnes sans formation technique sous-estiment souvent la valeur de la couche déterministe. La réaction par défaut est de tout jeter au modèle. Mais si quelque chose peut être fait de manière déterministe, cela devrait presque toujours être fait. Et vous n'avez pas besoin d'être programmeur, car le modèle peut écrire le code pour vous. Ce qu'il faut vraiment cultiver, c'est une discipline : se demander à chaque fois, cette tâche peut-elle être accomplie de manière stable et peu coûteuse par du code ? Si la réponse est oui, faites écrire ce code par le modèle.
Memory : Rendre le système vraiment cumulatif
Pour qu'un système soit utile, il doit posséder une forme de mémoire. Je ne suis pas encore certain de la forme la plus correcte, beaucoup l'expérimentent de différentes manières : embeddings vectoriels, similarité sémantique, graphes de connaissances, stockage hybride, etc. L'approche de Tan est la même que la mienne : un simple dossier markdown.
Sa structure est : une page par personne, une page par entreprise, une page par concept. Le haut de chaque page contient la « conclusion fiable actuelle », une synthèse qui est constamment réécrite et mise à jour avec de nouvelles preuves ; le bas est une timeline en ajout uniquement, jamais écrasée.
Choisir le markdown a plusieurs conséquences. Premièrement, les fichiers eux-mêmes sont l'enregistrement principal du système, pas un résultat exporté. Vous pouvez les ouvrir dans VS Code, les éditer manuellement, l'Agent lira automatiquement ces changements. Deuxièmement, les relations typées, comme works_at, invested_in, founded, attended, advises, sont extraites automatiquement par regex à chaque écriture, permettant au graphe de connaissances de se connecter sans consommer de tokens. Ce schéma spécifique est adapté à son travail, mais d'autres devront probablement le personnaliser selon leur domaine professionnel.
De plus, un détecteur de signaux tourne en arrière-plan. Si une personne est mentionnée une fois, une page ébauche est créée ; si elle est mentionnée trois fois dans différentes sources, cela déclenche un complément d'information web ; après une réunion, un processus complet est exécuté. Un cycle « dream cycle » nocturne scanne les conversations, complète les informations d'entités obsolètes et répare les références rompues. La couche de base est du texte, tout ce qui est construit dessus est peu coûteux et composable.
Bien sûr, il y a plus de détails en profondeur, mais je pense que ce sont les contours les plus importants, et ils sont en grande partie universels.
Personnellement, j'ai déjà construit environ la moitié d'une telle architecture. Je n'avais pas encore atteint une échelle nécessitant l'introduction d'un vrai Resolver, mais c'est le cas maintenant, donc je viens de faire une petite refactorisation pour rendre mon système indépendant du modèle et intégrer un Resolver. La partie clé que je n'ai pas encore construite est le détecteur de signaux et le cycle « dream cycle » nocturne, c'est-à-dire le mécanisme d'enrichissement et d'organisation automatique des informations, que je souhaite essayer d'ajouter ensuite.
Je soupçonne que la convergence vers une structure similaire par différents constructeurs est en soi un signal : cette forme, même si elle ne convient pas à tout le monde, a de grandes chances d'être globalement utile. Même si les détails d'implémentation varieront, cette structure générale est de plus en plus découverte indépendamment par de nombreuses personnes.
Une question que je me pose récemment est : comment construire un avantage compétitif durable avec l'IA ?
Les applications « vibe-coded » et les prompts ponctuels suscitent beaucoup d'excitation, c'est bien sûr très cool. C'est comme ça que j'ai commencé aussi. Mais tout ce qui peut être construit avec un prompt ponctuel aura à l'équilibre un prix qui tendra vers son coût en tokens, soit quelques centimes.
Par exemple, quelqu'un qui clone MyFitnessPal, le vend à moitié prix et gagne 1 million de dollars, c'est impressionnant. Mais bientôt, quelqu'un d'autre le clonera et le vendra encore moins cher. Ce cycle continuera jusqu'à ce que la marge soit entièrement compressée.
Ce qui est vraiment durable, c'est une « capacité de processus ». Dans le cadre du livre 7 Powers de Hamilton Helmer, l'architecture décrite ci-dessus implique précisément le « process power ».
7 Powers propose qu'une entreprise puisse maintenir des marges supérieures à la moyenne du marché à long terme parce qu'elle possède l'une de sept forces structurelles. Tout avantage non ancré dans ces forces sera finalement érodé par la concurrence.
Pour les PME et les jeunes entreprises, cinq des sept forces d'Helmer sont quasiment fermées. Les économies d'échelle nécessitent de l'échelle ; les effets de réseau et les coûts de changement peuvent être construits, mais nécessitent d'abord une large base d'utilisateurs ; les ressources exclusives impliquent généralement des brevets ou des actifs similaires, que la plupart des entreprises n'ont pas ; la marque nécessite généralement une décennie pour être construite, sans raccourci possible.
Les deux restantes sont le contre-positionnement et la capacité de processus.
Le contre-positionnement fait référence à un modèle d'affaires qu'un géant existant ne peut imiter car cela nuirait à ses activités actuelles. Cette opportunité existe parfois, mais n'est pas toujours disponible.
Ainsi, le chemin le plus réaliste reste la capacité de processus. Et un système d'IA bien conçu est précisément l'outil qui peut générer une capacité de processus.
C'est essentiellement le même travail que créer des SOP de haute qualité ou un logiciel propriétaire interne : le processus est encodé, les cas sont paramétrisés, le système déterministe sous-jacent est rapide et fiable, la couche mémoire capture continuellement ce qui a été appris. Cela amplifie encore la « servicisation du produit » : vous pouvez offrir un service ou un produit à un coût inférieur ou une qualité supérieure, car tout le travail a été structuré.
Imaginez un comptable qui construit un tel système. La couche mémoire est un dossier, chaque client a un fichier markdown avec la conclusion fiable actuelle, par exemple la structure de l'entité, la position fiscale annuelle, les audits en cours, et une timeline des réunions, décisions et changements.
Elle a des Skills, comme /year-end-review, /quarterly-estimate, /audit-prep. Le même flux peut être exécuté de manière paramétrique pour différents clients.
Elle a aussi une couche déterministe, incluant les formulaires fiscaux, les tableaux d'amortissement, les documents IRS, les déclarations fiscales historiques des clients, etc.
Ajoutez un mécanisme de consolidation ou de type « dream cycle ». Par exemple, le système détecte automatiquement la nuit qu'une allocation K-1 d'un associé a baissé de 40% sans changement stratégique ; ou remarque qu'une structure de déduction pour bureau à domicile d'un client peut être migrée vers un autre, la structure est réutilisable, mais l'identité et la confidentialité restent en place.
Ainsi, elle peut facturer une légère prime, servir plus de clients par an, et les concurrents auront du mal à reproduire cela, car cette structure n'apparaît pas magiquement après son succès, elle s'accumule depuis le début.
En surface, l'outil n'est qu'un dossier markdown. Mais chaque ligne dans chaque fichier est le résultat d'un travail conscient de test, de construction et d'itération. Ce qui forme la barrière concurrentielle, ce ne sont pas les fichiers eux-mêmes, mais la capacité de processus qu'ils portent.
