La nouvelle pile technologique de l'IA : modèles, harnais, boucles et agents à auto-amélioration

Tout le monde parle des modèles d'IA.

Personne ne parle de la couche qui les rend réellement utiles.

Claude Code. Codex. Cursor.

Ce ne sont pas que des modèles.

Ce sont des modèles enveloppés dans un système.

Ce système s'appelle un harnais.

Et les meilleurs harnais s'améliorent désormais eux-mêmes.

Voici tout ce que vous devez comprendre sur la nouvelle pile IA.

Le mensonge que tout le monde croit à propos des produits IA

La plupart des gens pensent que le progrès en IA = des modèles plus intelligents.

Ce n'est pas le cas.

Le modèle n'est qu'une partie de la pile.

L'architecture est publique. Tout le monde copie le même transformeur. Chaque laboratoire utilise les mêmes blocs de construction.

Ce qui distingue réellement Claude Code d'un projet de week-end, ce n'est pas le modèle.

C'est ce qui entoure le modèle.

Le harnais.

En 2017, le progrès de l'IA portait sur les mécanismes d'attention. En 2020, c'était l'échelle. En 2026, c'est l'ingénierie des harnais.

Et les harnais sont désormais conçus par l'IA, pas par les humains.

Qu'est-ce qu'un harnais ?

Un harnais est le système qui entoure un modèle.

Il décide :

→ Comment le modèle pense et planifie

→ Quand il appelle des outils et ce qu'il fait avec les résultats

→ Ce dont il se souvient entre les étapes

→ Comment il stocke les artefacts et gère l'état

→ Comment il évalue sa propre sortie

→ Quand il revient en arrière et réessaie

Considérez-le comme un système d'exploitation.

Le modèle est le CPU. Le harnais est l'OS.

Vous pouvez avoir un CPU puissant et un logiciel terrible et ne rien livrer d'utile. Vous pouvez avoir un CPU modeste et un excellent logiciel et livrer quelque chose de génial.

Les agents de codage les plus performants — Claude Code, Codex, Cursor — partagent tous la même idée :

La boucle compte autant que le modèle.

Les 3 motifs de harnais que tout développeur IA doit connaître

Chaque système IA de production utilise au moins l'un d'entre eux.

Motif 1 : La boucle

Le modèle ne répond pas une fois et s'arrête.

Il boucle.

Planifier → Exécuter → Observer → Améliorer → Répéter

C'est le cœur de tout agent de codage.

Une boucle Claude Code simplifiée :

1. Lire la tâche
2. Planifier l'approche
3. Écrire le code → l'exécuter
4. Voir ce qui a échoué
5. Corriger
6. Exécuter à nouveau
7. Répéter jusqu'à ce que les tests réussissent

Le modèle n'est pas plus intelligent à la boucle 3 qu'à la boucle 1.

Mais le système, lui, l'est.

Chaque boucle donne au modèle un nouveau contexte — messages d'erreur, résultats de test, traces d'exécution.

La sortie de la boucle 1 devient l'entrée de la boucle 2.

Ce contexte composé est la raison pour laquelle les systèmes agentiques surpassent le prompting unique sur des tâches complexes.

L'idée clé : Le modèle reste fixe. Le contexte devient plus intelligent.

Motif 2 : Le système de fichiers comme mémoire

La plupart des développeurs fourrent tout dans la fenêtre de contexte.

C'est un piège.

Les tâches à long terme génèrent :

→ Journaux d'expériences

→ Diffs de code → Traces d'erreurs

→ Historiques de déploiement passés → Résumés d'articles → Artefacts intermédiaires

Tout cela dépasse largement n'importe quelle fenêtre de contexte.

La solution : écrire dans des fichiers, pas dans le contexte.

1# Mauvais : tout dans le contexte
2contexte = sortie_précédente + résultat_outil + journal_erreurs + historique...
3# Explose à l'étape 47
4
5# Bon : utiliser le système de fichiers
6agent.ecrire("experiences/run_3/journal_erreurs.txt", trace_erreur)
7agent.ecrire("experiences/run_3/resultats.json", métriques)
8
9# Plus tard, l'agent ne lit que ce dont il a besoin
10pertinent = agent.lire("experiences/run_3/resultats.json")

Cela change tout pour les tâches à long terme.

→ L'agent peut reprendre après un crash

→ L'agent peut raisonner sur son propre historique d'exécution

→ Le contexte reste propre même à l'étape 200

→ Plusieurs sous-agents peuvent partager l'état via des fichiers

Les meilleurs agents traitent le système de fichiers comme un deuxième cerveau.

Pas un dépotoir. Une mémoire structurée.

Motif 3 : Les sous-agents

Un seul agent ne peut pas tout faire.

Les meilleurs systèmes engendrent des sous-agents parallèles.

L'agent parent :

→ Divise la tâche en sous-tâches indépendantes

→ Lance des sous-agents pour les exécuter en parallèle

→ Surveille leur statut → Fusionne leurs résultats

Exemple pour un harnais de recherche :

1L'agent parent reçoit : "Rédigez un rapport d'analyse concurrentielle complet"
2
3Engendre 4 sous-agents simultanément :
4→ Sous-agent 1 : Rechercher les prix et fonctionnalités du concurrent A
5→ Sous-agent 2 : Rechercher les prix et fonctionnalités du concurrent B
6→ Sous-agent 3 : Rechercher les actualités récentes sur les deux concurrents
7→ Sous-agent 4 : Extraire les avis utilisateurs de Reddit et de l'App Store
8
9Le parent attend, puis fusionne les 4 sorties dans le rapport final
10
11Temps total : identique au sous-agent le plus lent (pas 4 fois plus long)

La règle de conception clé : les sorties des sous-agents doivent aller dans des fichiers.

Pas dans un contexte transitoire. Des fichiers.

S'ils ne vivent que dans le contexte, ils disparaissent lorsque la session du sous-agent se termine.

S'ils vivent dans des fichiers, l'agent parent peut les inspecter, le système peut récupérer après des crashs, et tout est vérifiable.

Outils utilisés par chaque agent de codage

Si vous construisez un agent, voici la boîte à outils sur laquelle tous les grands agents de codage se standardisent.

1Outils du système de fichiers :
2→ glob, grep, ls          # trouver des fichiers
3→ read, read_many         # lire le contenu
4→ write                   # créer un nouveau fichier
5→ edit                    # modification par remplacement de chaîne
6→ apply_patch             # diff structuré
7
8Outils Shell :
9→ bash                    # exécuter n'importe quelle commande
10→ PowerShell              # équivalent Windows
11
12Contrôle de version :
13→ git_status, git_diff    # inspecter les modifications
14→ git_commit              # sauvegarder la progression
15
16Gestion des agents :
17→ spawn_agent             # lancer un sous-agent
18→ wait_agent              # attendre le résultat
19→ list_agents             # voir ce qui s'exécute
20→ interrupt_agent         # annuler si nécessaire
21
22Contexte externe :
23→ web_search, web_fetch   # obtenir des informations actuelles
24→ outils MCP              # se connecter à des services externes

Vous n'avez pas besoin de tous ces outils pour chaque agent.

Mais chaque agent de production finit par avoir besoin de la plupart d'entre eux.

Ceux qui comptent le plus au début : bash, read, write, edit.

Maîtrisez ces quatre-là et vous pouvez construire presque n'importe quoi.

L'ingénierie du contexte : la compétence dont personne ne parle

Le modèle est fixe.

Vous ne pouvez pas modifier ses poids à l'exécution.

Mais vous pouvez changer ce qu'il voit.

C'est l'ingénierie du contexte.

Et c'est désormais l'une des compétences les plus stratégiques dans l'ingénierie de l'IA.

Mauvais contexte :

→ Tout déverser → espérer le meilleur

→ Le contexte gonfle → le modèle perd le focus → les sorties se dégradent

Bon contexte :

→ Structuré. Concis. Évolutif.

→ Bonne information à la bonne étape.

→ Les échecs précédents informent la tentative actuelle.

L'approche de pointe (ACE — Agentic Context Engineering) :

13 composants :
2
3Générateur :   exécute la tâche, référence un manuel de contexte structuré
4Réflecteur :   analyse les succès et les échecs, distille les informations
5Conservateur : met à jour le manuel avec de nouveaux apprentissages — ajoute, supprime, déduplique
6
7Le manuel n'est PAS un bloc de prompt.
8C'est une liste structurée de paires (identifiant, information).
9
10Exemple :
11{
12  "id": "001",
13  "information": "Toujours écrire les traces d'erreur dans un fichier avant de réessayer."
14},
15{
16  "id": "002",
17  "information": "Le sous-agent pour la recherche web donne de meilleurs résultats avec des requêtes spécifiques au site."
18},
19{
20  "id": "003",
21  "information": "Exécuter les tests avant de valider détecte 80 % des régressions."
22}

Le manuel se met à jour après chaque exécution.

L'agent qui exécute la tâche 50 travaille avec 49 exécutions d'apprentissages distillés.

L'agent qui exécute la tâche 1 n'avait rien.

C'est ainsi qu'un système devient plus intelligent sans toucher aux poids du modèle.

Le harnais qui s'améliore lui-même

C'est là que ça devient fou.

Et si le harnais lui-même était ce qui était optimisé ?

Pas le prompt. Pas le modèle.

Le code qui exécute l'agent.

C'est exactement ce que fait Self-Harness.

Boucle en 3 étapes :

Étape 1 — Identifier les faiblesses

Exécuter le harnais actuel sur un ensemble de tâches. Collecter les traces d'échec. Regrouper les échecs par cause racine.

Pas "ça a échoué." Mais pourquoi ça a échoué.

Types d'échecs découverts :

→ "L'agent expire lors de longues lectures de fichiers"

→ "Les sorties des sous-agents sont perdues lorsque le parent plante"

→ "Les messages d'erreur ne sont pas assez informatifs pour s'auto-corriger"

→ "Le contexte devient trop volumineux après l'étape 30, le modèle perd le focus"

Étape 2 — Proposer des correctifs

Le même modèle examine les schémas d'échec. Propose des modifications spécifiques et ciblées du code du harnais.

Pas de réécritures. Des modifications ciblées.

Modification proposée du harnais :

→ Ajouter un gestionnaire de délai d'attente aux opérations de lecture de fichier

→ Vider automatiquement la sortie du sous-agent sur le disque à chaque étape (pas seulement à la fin)

→ Normaliser le format des messages d'erreur pour inclure : étape, outil, entrée, sortie, raison de l'échec

→ Ajouter une étape de compression du contexte tous les 25 tours

Étape 3 — Valider et fusionner

Chaque modification proposée est testée sur des tâches réservées.

Corrige-t-elle la faiblesse sans rien casser d'autre ?

Si oui : fusionnée dans le harnais. Si non : enregistrée, rejetée, harnais inchangé.

Le résultat : le harnais s'améliore à chaque génération.

Claude 3.5 Sonnet exécutant Self-Harness est passé de 20 % à 50 % sur SWE-bench Verified.

Pas grâce à un meilleur modèle.

Grâce à un meilleur système.

Recherche évolutive de harnais

Self-Harness corrige un harnais de manière itérative.

AlphaEvolve exécute une population de harnais et fait évoluer les meilleurs.

L'algorithme :

11. Commencer avec un pool de candidats harnais
22. Noter chacun sur des tâches de référence
33. Sélectionner les meilleurs performeurs comme "parents"
44. Demander au modèle de proposer des diffs/améliorations
55. Générer de nouveaux harnais "enfants"
66. Noter les enfants
77. Garder ceux qui s'améliorent
88. Les rajouter au pool
99. Répéter
10
11(Même logique que la sélection naturelle. Appliquée au code.)

(Même logique que la sélection naturelle. Appliquée au code.)

Un détail de conception clé d'AlphaEvolve :

Les régions de code éligibles à l'évolution sont explicitement marquées :

1# EVOLVE-BLOCK-START
2def planifier_prochaine_étape(contexte, outils):
3    # Cette section peut être modifiée par la recherche évolutive
4    prompt = f"Étant donné : {contexte}\nOutils disponibles : {outils}\nAction suivante :"
5    return llm.generer(prompt)
6# EVOLVE-BLOCK-END
7
8# Le reste du harnais reste fixe
9def exécuter_outil(nom_outil, args):
10    return registre_outils[nom_outil](**args)

Ce confinement empêche l'agent de modifier accidentellement du code critique pour la sécurité.

La recherche évolutive ne touche que ce que vous l'autorisez explicitement à toucher.

AlphaEvolve a utilisé cela pour optimiser les algorithmes de multiplication de matrices.

Le résultat : a battu le code optimisé à la main de DeepMind.

L'agent a trouvé des solutions que les ingénieurs humains n'avaient pas découvertes depuis des décennies.

Machine de Darwin Gödel : des agents qui se réécrivent eux-mêmes

La version la plus extrême de cette idée.

Un agent qui modifie son propre code de harnais pour mieux accomplir les tâches.

Machine de Darwin Gödel (DGM) :

11. Commencer avec un agent de codage dans le pool
22. L'exécuter sur des benchmarks, collecter les scores
33. L'agent examine ses propres journaux d'évaluation
44. L'agent propose des améliorations à son propre code de harnais
55. Outils disponibles : bash + éditeur de fichiers (voir/créer/modifier des fichiers)
66. Une nouvelle version de l'agent est créée
77. La nouvelle version est notée
88. Si meilleure : ajoutée au pool
99. Si pire : écartée
1010. Répéter — en sélectionnant les parents par performance, inversement par nombre de descendants

Condition de départ : Claude 3.5 Sonnet + harnais initial simple.

Résultat :

→ SWE-bench Verified : 20 % → 50 %

→ Benchmark de codage polyglotte : 14,2 % → 30,7 %

Zéro changement des poids du modèle. Zéro ingénierie humaine entre les générations.

L'agent a conçu de meilleures versions de lui-même.

Ce n'est pas de la science-fiction.

C'est un article de 2025.

5 modes d'échec à éviter

Voici les façons dont de vraies équipes de recherche ont échoué.

Tous documentés. Tous évitables.

1. Effondrement du contexte

Les tâches à long terme perdent des détails critiques si les journaux ne sont pas écrits comme des artefacts persistants.

Correctif : écrire tout ce qui est important dans des fichiers. Ne jamais se fier uniquement au contexte au-delà de l'étape 20.

2. Dérive d'implémentation

Lorsque la tâche devient techniquement difficile, le modèle dérive vers des solutions plus faciles et plus courantes au lieu de l'objectif réel.

Correctif : écrire un fichier de spécifications au début. L'agent vérifie les spécifications à chaque boucle.

3. Sur-optimisme

Le modèle déclare le succès malgré des expériences échouées.

Il trouve du "ruban adhésif numérique" — des correctifs qui font bonne figure sur les métriques sans résoudre le vrai problème.

Correctif : réserver un ensemble de test que l'agent ne voit jamais. Valider uniquement sur les données réservées.

4. Détournement de récompense

L'agent optimise le signal qu'on lui donne.

Si le signal est des tests unitaires — il écrit des tests qui réussissent toujours. Si le signal est un modèle juge — il apprend des astuces pour tromper le juge. Si le signal est un score de benchmark — il exploite les artefacts du benchmark.

Correctif : l'évaluateur vit en dehors de la boucle. Révision humaine aux points de décision clés.

5. Effondrement de la diversité

Les boucles évolutives convergent vers une seule stratégie.

Chaque génération ressemble à une variante de la même solution.

Correctif : suivre explicitement la nouveauté. Pénaliser les solutions trop similaires aux membres existants du pool (la similarité cosinus basée sur les embeddings fonctionne).

La nouvelle pile IA en termes simples

Voici ce que vous construisez réellement lorsque vous construisez des produits IA sérieux :

Couche 1 — Le modèle

Intelligence brute. Pré-entraîné. Poids fixes à l'exécution.

C'est le CPU. Puissant mais passif.

Couche 2 — Le harnais

L'OS. Enveloppe le modèle. Orchestre tout.

→ Outils (bash, lecture/écriture de fichiers, recherche web)

→ Mémoire (système de fichiers, journaux structurés)

→ Boucle (planifier → exécuter → évaluer → réessayer) → Sous-agents (exécution parallèle)

→ Gestion du contexte (ce que le modèle voit à chaque étape)

Couche 3 — L'optimiseur

Le harnais qui améliore le harnais.

→ Extrait les schémas d'échec des traces d'exécution

→ Propose des modifications ciblées du code du harnais → Valide sur des tâches réservées

→ Fusionne les améliorations, écarte les régressions

Couche 4 — L'évaluateur

Vit en dehors de toutes les autres couches.

→ Scores de benchmark → Révision humaine aux points de décision clés

→ Ensembles de test réservés que l'optimiseur ne touche jamais

Vous ne pouvez sauter aucune couche.

Sautez la couche 2 — votre modèle est un chatbot, pas un produit.

Sautez la couche 3 — votre système ne s'améliore jamais sans ingénierie manuelle.

Sautez la couche 4 — votre agent optimise la mauvaise chose et vous ne le remarquerez pas.

Ce que cela signifie pour les développeurs dès maintenant

Vous n'avez pas besoin de construire un harnais auto-améliorant pour bénéficier de ces idées.

Commencez ici :

Semaine 1 : Construire la boucle

Arrêtez de construire des prompts uniques. Construisez une boucle planifier → exécuter → évaluer → réessayer pour toute tâche qui prend plus d'une étape.

Semaine 2 : Ajouter une mémoire persistante

Arrêtez de vous fier au contexte. Écrivez les sorties intermédiaires dans des fichiers. Laissez l'agent lire son propre travail précédent.

Semaine 3 : Ajouter des sous-agents

Identifiez toute partie de votre flux de travail qui peut s'exécuter en parallèle. Lancez des sous-agents. Écrivez leurs sorties dans des fichiers. Fusionnez.

Semaine 4 : Ajouter l'ingénierie du contexte

Suivez les schémas qui mènent au succès et à l'échec. Construisez un manuel structuré simple qui se met à jour après chaque exécution.

C'est le harnais.

Pas le modèle.

Le modèle est déjà là.

Le harnais est ce que vous construisez.

La vérité inconfortable sur l'IA en 2026

L'accélération de la recherche dans les laboratoires de pointe a considérablement augmenté.

Anthropic et OpenAI livrent plus rapidement que jamais.

Pas parce que les modèles sont devenus plus intelligents du jour au lendemain.

Parce que les harnais se sont améliorés.

Un agent qui boucle, se souvient, sous-délègue et s'auto-corrige surpasse un modèle plus intelligent mal utilisé.

Le fossé n'est pas le modèle.

Le fossé est le système.

Et le système peut désormais s'améliorer lui-même.

Si cela a été utile :

→ Repostez — tout développeur IA doit comprendre cette pile

→ Suivez @sairahul1 pour plus d'analyses comme celle-ci

→ Mettez en favori — la pile à 4 couches vaut à elle seule la peine d'être sauvegardée

Abonnez-vous à theaibuilders.co pour plus d'articles intéressants de ce type

J'écris sur l'IA, la construction de produits et les systèmes qui fonctionnent sans vous.