Le ajustement fin est devenu peu coûteux, mais les agents ont toujours besoin d’un mécanisme de contrôle pour les poids.

Chaque nuit, le cerveau exécute silencieusement une tâche en lot. Les épisodes de la journée, dispersés dans l’hippocampe, y sont rejoués pendant le sommeil et enregistrés de manière sélective dans le cortex. Des chercheurs ont observé ce phénomène de rejouement chez des rats des heures après que le labyrinthe ait été retiré. Le lendemain matin, certaines compétences, acquises seulement la veille, sont déjà présentes, sans que l’on ait jamais vu la séance d’entraînement elle-même.

Il y a quelque temps, Andrej Karpathy a souligné l’absence d’une phase essentielle chez ces agents : aucune étape de distillation, pas de sommeil. Environ dix-huit mois plus tard, le domaine travaille à mettre en place cette phase. Une étude de 2026 a même porté le titre « Language Models Need Sleep » et décrit comment intégrer les mémoires contextuelles d’un modèle dans de nouveaux poids d’expert pendant une phase de sommeil explicite.

La séparation entre veille et sommeil est ainsi passée de métaphore à diagramme architectural, ce qui constitue à la fois une bonne nouvelle et un piège. La consolidation est devenue suffisamment peu coûteuse pour être intégrée dans un calendrier, et c’est pourquoi les travaux d’ingénierie intéressants se sont déplacés ailleurs, vers le filtre qui sélectionne, parmi dix mille, les quelques leçons qui méritent d’être intégrées dans les poids.

Quatre compétences en découlent. Premièrement, séparer le cycle rapide (le contexte, géré par demande) du cycle lent (les poids, modifiés à chaque mise à jour), en évaluant le coût de chacun. Deuxièmement, transformer l’agent déjà en production en un enseignant autonome privilégié, sans besoin d’un modèle plus volumineux. Troisièmement, évaluer chaque leçon selon quatre critères de promotion avant même que le gradient ne s’y applique. Quatrièmement, détecter les échecs que les démonstrations en une seule itération cachent en exécutant le cycle trois fois. La seule exigence est d’avoir déployé un produit qui appelle une API de LLM.

Deux cycles avec des horloges différentes

La première moitié de l’histoire concerne l’agent qui termine une tâche et enregistre ce qu’il a appris dans un playbook, un fichier de texte brut contenant des leçons consultées au début de chaque demande, afin que la prochaine exécution parte de là où s’est arrêtée la précédente. La seconde moitié correspond à la consolidation : un processus hors ligne distinct qui rejoue les traces enregistrées, détermine lesquelles sont suffisamment stables et précieuses pour servir d’entraînement, et n’écrit que ces éléments dans les paramètres.

Une étude sur la mémoire de 2026 a donné à ce cycle le nom d’Accumuler-Internaliser. D’abord accumuler, en mémoire et dans les playbooks, où une leçon peut être consultée et modifiée facilement. Ensuite internaliser le reste stable dans les paramètres, où il devient rapide, généralisable et gratuit au moment de l’inférence. En termes simples, l’agent travaille toute la journée à partir d’un carnet, tandis qu’un autre mécanisme, ultérieurement et séparément, choisit quelles pages méritent d’être mémorisées.

Le pipeline nocturne comporte trois étapes : rejouer, sélectionner, distiller. Seule l’étape intermédiaire implique un jugement, et c’est celle qui compte le plus.

• L’horloge rapide égrène ses secondes au moment de la demande. Le contexte et la mémoire s’adaptent à chaque conversation, et ces modifications sont réversibles et peu coûteuses.
• L’horloge lente égrène ses secondes au moment de la publication. La consolidation met à jour les poids toutes les quelques semaines, derrière un mécanisme de contrôle et à un coût réel.

Les bonnes configurations utilisent les deux horloges et suivent l’emplacement de chaque leçon. Les mauvaises configurations soit n’avancent jamais l’horloge lente et doivent payer un coût de contexte de plus en plus élevé, soit connectent directement l’horloge rapide aux poids, ce qui favorise précocement la contamination.

Le meilleur enseignant est l’agent lui-même, qui détient le manuel de procédures

La distillation classique forme un étudiant à imiter les résultats d’un enseignant. Le problème réside dans l’origine des données : l’étudiant apprend à partir des trajectoires parfaitement maîtrisées de l’enseignant sans jamais voir les états chaotiques créés par ses propres erreurs. Sa première erreur le conduit dans un endroit que l’ensemble d’entraînement n’a jamais visité.

La distillation on-policy corrige cet objectif. Les échantillons proviennent du comportement même de l’étudiant, et un enseignant évalue ou guide ces éléments, de sorte que le signal de correction cible bien la distribution des erreurs réelles de l’étudiant. Il s’agit d’un retour d’information précis sur ses propres erreurs, et non d’une série de réussites appartenant à quelqu’un d’autre.

Ce qui rend cela pratique, c’est que l’enseignant n’a pas besoin d’être un modèle plus puissant. Il peut s’agir du même modèle doté d’un avantage significatif : le guide pédagogique dans son contexte, les leçons déjà consultées, ainsi que des informations sur une séquence déjà terminée. Un système de recherche appelé SEED fonctionne précisément sur ce principe. Il transforme les trajectoires des agents achevées en compétences exprimées en langage simple, puis intégre ces directives directement dans la politique de décision, sans nécessiter de rappel de compétences ni de recherche dans la mémoire lors de l’inférence. La leçon devient ainsi le comportement.

Imaginez l’enseignant comme l’élève portant un sac à dos. La distillation correspond au processus de suppression de ce sac sans perdre ce qui s’y trouvait.

Une version simplifiée peut être mise en œuvre en une après-midi. Choisissez cinquante tâches que l’agent gère déjà, figez le guide pédagogique pour qu’il cesse de changer, puis configurez les deux parties nécessaires :

# teacher: same model, unfair advantage
teach = Agent(system=playbook)
# student: same model, empty context
bare = Agent()

tries = [bare.run(t) for t in tasks]

Ensuite, faites évaluer les tentatives du élève par le juge enseignant, et entraînez-vous à partir de ces évaluations. Voilà l’essentiel de la distillation on-policy en quelques lignes :

graded = [teach.grade(x) for x in tries]
finetune(bare, graded)   # one round only
# now serve it with NO playbook

Cette exécution produit trois chiffres dignes d’être enregistrés. Lors d’une tentative sur un ensemble de cinquante tâches d’une file d’attente d’aide en juin, l’étudiant sans aide a vu 61 % de ses réponses acceptées, celui qui disposait du guide a atteint 79 %, tandis que le modèle internalisé, exécuté sans aucun guide, a obtenu 77 %.

Seize des dix-huit points améliorés grâce au guide se sont maintenus, et chaque requête est passée de 4 270 tokens à 910. Le « sac à dos » n’est plus nécessaire, et un bail se transforme en propriété. La première exécution donne l’impression que le problème est résolu.

Un gradient, c’est un engagement

L’industrie a résisté aux mises à jour des poids pendant environ trois ans, et cette résistance était rationnelle. Le contexte peut être différé, audité et supprimé en une après-midi. Une mise à jour des poids, en revanche, est opaque, complexe, et ne peut être annulée que en revenant à un point de contrôle, ce qui entraîne la perte de tout ce que le modèle a appris depuis ce moment-là.

L’oubli catastrophique représente la forme classique de ce risque : des régressions dans les capacités que personne n’avait mesurées, découvertes plus tard par un client. L’alignement en matière de sécurité doit également être réverifié après chaque mise à jour, car les propriétés confirmées sur le modèle de base ne se transmettent pas automatiquement à une version affinée.

Une comparaison utile est celle d’une branche fonctionnelle intégrée dans la branche principale, où s’appliquent la récurrence, l’examen, la traçabilité ainsi qu’un mécanisme de réversion. Cette comparaison présente cependant un point faible coûteux : la réversion dans Git est précise et contrôlée, tandis que le rétablissement des poids entraîne soit un résultat complet, soit rien du tout, de sorte qu’une seule fusion défectueuse annule tout ce qui a été intégré après le point de contrôle.

Quatre critères déterminent ce qui est retenu :

• La leçon s’est reproduite suffisamment de fois dans des épisodes distincts pour ressembler à un schéma plutôt qu’à un accident.
• Elle est restée intégrée dans le manuel de procédures sans jamais être contredite.
• Il affiche une valeur mesurée permettant de combler l’écart par rapport à une ligne de référence qui a réellement été exécutée.
• Il dispose d’un historique de provenance clair, ce qui permet d’identifier les éléments qui l’ont généré.

Tout ce qui échoue à ces vérifications reste dans son contexte, où une erreur entraîne des frais supplémentaires et non une interruption du processus. En règle générale, les poids conservent les résidus tandis que le contexte enregistre les variations.

Les quatre étapes s’exécutent dans l’ordre, et cet ordre fait partie de la conception : une leçon qui échoue à la première étape ne bénéficie jamais d’une révision à la quatrième. Une étape qui ne sélectionne que très peu de candidats ne peut pas être considérée comme une véritable étape de filtrage.

D’après une enquête menée en juin 2026 sur les agents d’amélioration continue, la décision réside dans le système de contrôle, et non dans le modèle. C’est ce système qui sélectionne les traces à transformer en signaux d’entraînement, en extrait les informations de supervision, en conserve les conditions dans lesquelles elles étaient valables, et juge si une expérience donnée est même adaptée à un apprentissage basé sur les paramètres.

Lorsqu’il existe deux voies possibles, un élément supérieur doit choisir quel processus d’amélioration sera activé, à quel moment et dans quelles limites, en tenant compte des critères de preuve et des conditions de réversion. Cette couche de contrôle constitue le véritable résultat attendu. Lors du choix, consultez d’abord la colonne des conditions de réversion, car les voies qui permettent une révision par suppression simple méritent environ neuf choix sur dix.

La première étape fonctionne ; la troisième échoue

Un résultat nouveau devrait ralentir tout le monde. L’article « Rethinking Continual Experience Internalization » indique qu’une seule étape de transformation de l’expérience en poids fonctionne bien, tandis que la répétition de ce cycle d’évolution autonome entraîne un effondrement des performances.

Les auteurs attribuent cet effondrement à trois facteurs : la manière dont l’expérience est représentée, la façon dont cette représentation influence ce que le « professeur » supervise, ainsi que la distribution des trajectoires permettant le transfert de connaissances. La victoire obtenue en une seule tentative n’était qu’une démonstration. Ce qui est réellement nécessaire, c’est de rester stable au fil des étapes, et personne n’a encore trouvé de solution à ce problème.

La première évaluation de la file d’attente de support a suivi exactement le parcours prévu selon le rapport. La deuxième évaluation a donné 74 %, légèrement en dessous des 77 % de la première, ce qui pouvait facilement être considéré comme une variation anodine. La troisième évaluation a atteint 58 %, en dessous du niveau des étudiants de base avec lesquels l’expérience avait commencé, et le modèle s’était discrètement détérioré dans deux catégories de tickets absentes de l’ensemble d’évaluation. Ce qu’il faut retenir, c’est l’écart entre la première et la troisième évaluation, car seule la première est mentionnée dans la plupart des rapports.

Il existe une deuxième limite. L’apprentissage par renforcement agent-based consiste à appliquer cet apprentissage à des séquences complètes d’actions multiples, où les récompenses proviennent de résultats que la machine peut vérifier. Cette approche est avantageuse lorsque la vérification est peu coûteuse, comme dans le cas du code, des calculs mathématiques ou des tâches structurées. La plupart des tâches réelles pour des agents génèrent des signaux flous, tardifs ou exploitables. L’article « Early Experience » l’affirme clairement : de nombreux environnements réels ne disposent pas de récompense vérifiable, et ceux qui en ont nécessitent fréquemment des tests longs et coûteux. La solution proposée est d’apprendre à partir des interactions initiales de l’agent, sans récompense externe, en considérant les conséquences des actions comme une forme de supervision.

La propriété engendre également des coûts supplémentaires. Chaque variante consolidée devient un artefact à part entière, nécessitant un ensemble de tests de régression, une évaluation de sécurité renouvelée ainsi qu’un espace de déploiement distinct ; de plus, le nombre de variantes par utilisateur multiplie cette liste par le nombre de clients.

Une vision réaliste pour le milieu de 2026 : l’apprentissage basé sur des paramètres est déjà utilisé en production pour des agents de codage et d’utilisation d’outils, dont les récompenses sont vérifiables, mais il reste à un stade de recherche lorsque les récompenses sont subjectives. Le camp du contexte propose une réfutation valable. Lorsqu’une leçon correspond au playbook et aux fonctions de récupération, l’intégrer dans les poids accélère le processus et améliore la qualité, mais au détriment de la traçabilité ; pour de nombreux produits, c’est un mauvais échange.

Construisez le mécanisme de contrôle avant qu’il ne soit nécessaire

Un modèle figé reste un choix de conception délibéré, avec une particularité. Les modèles de pointe actuels sont eux-mêmes entraînés en tant qu’agents, grâce à un apprentissage par renforcement sur l’utilisation d’outils sur de longues périodes dans des environnements exécutables. L’artefact figé fourni via une API est de plus en plus issu des mêmes boucles décrites ici, de sorte que l’ère de l’expérience arrive d’abord sous forme de changement dans la manière dont les modèles de base sont créés.

Une première étape pratique consiste à bien instrumenter la boucle d’accumulation. Ensuite, procédez à un audit peu coûteux : ouvrez le playbook du mois dernier et comptez les entrées qui sont apparues dans cinq épisodes ou plus distincts sans être contredites. Une telle analyse a transformé quarante-trois entrées en six candidats, dont une seule a été approuvée.

Cette unique entrée constitue le premier gradient. Le reste relève de bruit, qui doit rester dans son contexte, où une erreur coûte des tokens et non un point de contrôle. La question à se poser est la suivante : quelle leçon du playbook est-elle réapparue suffisamment souvent, sans contradiction, pour être validée pour sa publication ?

Lectures complémentaires

• Choisir un framework d’agent en fonction de la forme des tâches : six axes et une voie de décision — Sélectionnez LangGraph, CrewAI, AutoGen, Temporal ou rien en testant six axes liés aux tâches : déterminisme, durée de vie, idempotence, trace d’audit, vitesse d’exécution de l’équipe et coût par décision.
• Deuxes mains, un crie : sept règles pour orchestrer des agents IA — Lorsqu’un flux de travail est préférable à un agent, pourquoi les orchestrateurs ne devraient pas détenir les outils, comment saisir les résultats des sous-agents et écrire les conditions de terminaison, avec des exemples en Python pour chacun.

Affiner un modèle de vision sur Apple Silicon avec MLX et Ollama — Réduire les hallucinations liées à la lecture de graphiques en affinant Qwen2-VL avec MLX LoRA sur un Mac, puis en convertissant le modèle en format GGUF pour le servir via Ollama au sein d’une application RAG existante.