Un Agent qui s’améliore tout seul : au cœur de l’autoévolution d’Orkas

La plupart des assistants IA sont « utilisés, puis amnésiques ». Corrigez une habitude aujourd’hui et ils répètent la même erreur demain ; enseignez-leur le processus propre à votre équipe la semaine dernière et, cette semaine, ils font comme s’ils ne l’avaient jamais entendu. Chaque conversation repart de zéro : aussi intelligent soit le modèle, il reste une personne intelligente atteinte d’amnésie.

Orkas poursuit une autre voie : laisser l’Agent apprendre de son usage quotidien et condenser les expériences récurrentes pour les réappliquer seul la prochaine fois. En clair, plus vous l’utilisez, plus il devient utile, et cette utilité évolue vers vous, vos préférences et votre domaine, plutôt que vers un réglage prédéfini pour tous par le fournisseur du modèle.

Cet article détaille la construction de ce mécanisme. Il ne suffit pas de « faire mémoriser la conversation au modèle ». Une boucle complète se cache derrière : s’observer → décider s’il faut réfléchir → réfléchir → consigner les conclusions sous une forme réutilisable → les réutiliser la prochaine fois. Nous allons l’examiner étape par étape.

D’abord l’essentiel : tout ce qui suit — « observer », « enregistrer » et « réfléchir » — se déroule entièrement sur votre propre appareil. Les données d’exécution, les Skills, la compréhension que l’Agent a de lui-même : tout reste local, dans des fichiers ordinaires. Rien n’est envoyé aux serveurs d’Orkas ni utilisé pour une analyse entre utilisateurs ou l’entraînement de modèles. L’« autoévolution » désigne un programme qui lit localement ses propres traces d’exécution et s’améliore localement, pas une collecte de vos données. Cette expérience ne quitte jamais la machine et ne sert que vous, sur cette machine.

La boucle, de bout en bout

utilisation réelle, répétée
      │  consignation locale : outils appelés, erreurs ou non, corrections ou non
      ▼
   les signaux s’accumulent
      │  signaux extraits sur place de la conversation ; tout reste sur l’appareil
      ▼
  décider s’il faut lancer une réflexion
      │  score pondéré des signaux, déclenchement uniquement au-delà d’un seuil ; les incidents réseau ne comptent pas
      ▼
   réfléchir en arrière-plan
      │  pas à chaque tour : périodiquement, en sélectionnant les Agents qui remplissent les critères
      ▼
  en tirer deux éléments
      │  ① des "Skills" réutilisables   ② une "compréhension" de soi
      ▼
  les intégrer automatiquement au tour suivant
      └──────────► revenir au début et poursuivre

Chaque étape de cette boucle a ses subtilités. Les erreurs les plus faciles à commettre concernent précisément les deux étapes qui semblent les plus simples : quand réfléchir et quoi enregistrer ensuite. Commençons par le début.

Étape 1 : s’observer à un coût presque nul

Pour apprendre de l’expérience, il faut d’abord une « expérience » à examiner. À la fin de chaque exécution d’Agent, le programme compte localement, sur place, quelques faits légers : approximativement combien d’outils ont été appelés pendant le tour, si une erreur s’est produite, si elle était passagère — comme un problème réseau — ou réelle, et si l’utilisateur a apporté une correction immédiate. Quelques compteurs et indicateurs, tous calculés sur la machine, sans appel de modèle ni envoi ailleurs.

C’est important, car cela ne coûte rien en utilisation de modèles. Ces éléments sont comptés directement dans l’historique du tour courant ; aucun appel supplémentaire n’est nécessaire pour « s’analyser ». Si chaque tour exigeait un autre appel de modèle pour l’introspection, le coût et la latence seraient insupportables et le mécanisme ne verrait jamais le jour.

L’indicateur « corrigé ou non » mérite un détour. C’est un jugement local purement heuristique, estimé en comparant quelques formulations du message sur votre appareil : en chinois, « 不对 » / « 应该是 » / « 重新 », et en anglais, wrong, actually, instead. Il ne vise pas la précision absolue : ce n’est qu’un signal, pas un verdict. Quelques faux positifs sont acceptables puisqu’il sera ensuite pondéré avec d’autres signaux ; aucune décision ne repose sur lui seul.

Étape 2 : quand vaut-il réellement la peine de réfléchir ?

C’est, à mon sens, la partie la plus soigneusement conçue de tout le mécanisme.

L’approche naïve consiste à « réfléchir après N occurrences ». Mais c’est grossier : trois délais réseau dépassés de suite et trois corrections utilisateur successives sont manifestement différents et ne devraient pas être traités de la même manière. Orkas utilise une notation pondérée multisignal : chaque phénomène notable est un signal doté d’un poids ; les poids des signaux déclenchés pendant le tour sont additionnés, et la réflexion n’a lieu que si la somme dépasse un seuil, fixé par défaut à 0.7.

Les principaux signaux ressemblent à ceci :

Par exemple, un tour avec une correction utilisateur (0.9) et une certaine complexité (0.5) totalise 1.4, bien au-delà de 0.7 : il déclenche une réflexion. Un tour seulement un peu complexe (0.5) reste sous le seuil et est ignoré. La pondération reflète aussi un choix : une correction directe de l’utilisateur reçoit le poids maximal, 0.9, car c’est le retour au meilleur rapport signal/bruit. L’utilisateur a clairement indiqué une erreur ; elle mérite donc très probablement d’être consignée.

L’exception décisive

Dans toute cette logique de notation, une règle détermine selon moi si le mécanisme « apprend les bonnes choses » : les erreurs passagères ne comptent jamais.

Délais réseau dépassés, connexions interrompues, limites de débit : ce sont des problèmes d’environnement, pas des insuffisances de l’Agent. Si on ne les exclut pas, un outil échoue à cause d’un incident réseau fortuit et le mécanisme de réflexion enregistre « cet outil n’est pas fiable, l’utiliser moins », voire altère ou supprime un Skill parfaitement valable. L’Agent a alors appris une mauvaise leçon, qui le suivra ensuite.

Les signaux « rétablissement après erreur », « Skill inefficace » et « faiblesse connue rencontrée » excluent donc explicitement les erreurs purement passagères. Le prompt de réflexion le rappelle aussi : les erreurs réseau relèvent de l’environnement, il ne faut ni les enregistrer comme faiblesses ni toucher aux Skills associés. Ce qu’un système qui s’améliore doit craindre le plus n’est pas d’apprendre lentement, mais d’apprendre dans la mauvaise direction. Cette exception protège précisément contre cela.

Étape 3 : la réflexion se déroule en arrière-plan, sans vous interrompre

Un piège fréquent consiste à s’arrêter pour réfléchir dès que le système détecte que le moment est venu. L’Agent donne alors l’impression de hoqueter et de partir parfois « méditer sur la vie » : une mauvaise expérience.

Orkas déplace la réflexion en arrière-plan, à cadence fixe. Les règles de planification sont approximativement les suivantes :

• Lancer périodiquement un cycle de réflexion, par exemple toutes les douze heures ou davantage.
• Imposer un délai minimal de quelques heures entre deux réflexions du même Agent, pour éviter une fréquence excessive.
• Mais forcer une réflexion si elle n’a pas eu lieu depuis trop longtemps, par exemple plus d’une semaine, pour éviter un report indéfini.
• Plafonner le nombre d’Agents retenus par cycle pour ne pas trop disperser les ressources.

J’apprécie un petit dispositif appelé dirty gate : au début d’un cycle, vérifier si l’Agent a du nouveau depuis sa dernière réflexion — nouveaux signaux ou historiques de conversation mis à jour. Sans aucun changement, on le saute cette fois-ci pour ne pas gaspiller une réflexion qui coûte un appel de modèle. C’est simple, mais très économique en pratique.

Étape 4 : comment la réflexion fonctionne réellement

Quand vient effectivement le moment de réfléchir, le processus organise d’abord l’activité récente en un « dossier », puis l’associe à un prompt soigneusement rédigé et confie le tout au modèle pour lecture et synthèse.

Ce dossier a un budget : quelques conversations récentes au maximum, plusieurs catégories d’événements système, le tout entrelacé chronologiquement et plafonné en tokens, par exemple à un peu plus de dix mille. Il ne contient pas tout l’historique : celui-ci ne tiendrait pas et le rapport signal/bruit serait mauvais.

Le prompt exige le plus de soin. Il demande au modèle de produire non des « descriptions », mais des consignes impératives exécutables. La différence paraît petite, mais compte énormément. Comparez :

✗ « Les réponses de l’Agent sont parfois trop longues ; y prêter attention. »

✓ « Pour les questions de family office, ne jamais dépasser 5 puces. »

✗ « L’utilisateur semble préférer les réponses concises. »

✓ « Dans un contexte de family office, toujours donner la conclusion d’abord, puis le raisonnement. »

Le prompt oriente explicitement le modèle vers des structures « jamais / toujours / quand-alors » assorties de conditions de déclenchement concrètes. La raison est pratique : « veiller à être concis » n’indique rien d’exécutable à la prochaine lecture, alors que « ne jamais dépasser 5 puces » se suit directement. Pour être utile, l’autoamélioration doit produire une instruction applicable, pas une banalité juste.

Après réflexion, le modèle peut créer ou modifier un Skill, mettre à jour sa compréhension de lui-même ou, si rien ne mérite vraiment d’être conservé sur la période, simplement dire « rien à enregistrer ». Autoriser l’inaction est un choix de conception important : ne pas imposer un apprentissage évite d’accumuler du bruit inutile.

Deux formes de synthèse

Le résultat de la réflexion aboutit à deux endroits.

Le premier, ce sont les Skills. Chaque Skill est un document Markdown avec des métadonnées : un bloc d’en-tête indiquant le nom, la description, les dates de création et de mise à jour, le nombre de corrections et la dernière utilisation, suivi des étapes ou points essentiels :

---
name: "Weekly Report Export"
description: "Compile this week's data into the standard weekly-report format"
createdAt: "2025-01-01T00:00:00Z"
updatedAt: "2025-01-08T00:00:00Z"
patchCount: 2
lastUsedAt: "2025-01-09T10:00:00Z"
---

## Steps
1. ...
2. ...

Stocker les Skills dans des fichiers est pragmatique : une personne peut les lire et les modifier directement, sans qu’ils soient enfermés dans une base opaque.

Le second est la compréhension de soi. Cette partie ressemble à un mémo que l’Agent s’adresse, en deux volets : « ce que je fais bien et où je trébuche souvent » et « les méthodes que j’ai élaborées pour cet utilisateur et ce domaine ». Les deux ont une limite de longueur qui impose la concision : mieux vaut être plus juste que plus long. Au début de la conversation suivante, ce contenu est injecté dans le prompt système : l’Agent arrive avec une « compréhension de lui-même ».

Les Skills ne sont pas seulement écrits

Se contenter de créer des Skills finit par constituer un dépotoir. Ils ont donc un cycle de vie complet.

Au-delà de la création, l’opération la plus courante est la modification ciblée : changer une petite portion d’un Skill existant plutôt que tout supprimer et réécrire. Chaque modification incrémente un compteur et actualise la date de mise à jour. Le Skill évolue ainsi progressivement avec l’expérience, sans réécriture complète à chaque tour.

Leur nombre est également plafonné, par exemple à 200. Une fois la limite atteinte, en ajouter un nouveau évince un ancien selon la règle LRU, le moins récemment utilisé, pour libérer de la place. L’éviction privilégie ceux qui n’ont jamais servi depuis leur création : un Skill jamais lu a probablement été mal formulé dès le départ et gagne à céder sa place.

Chaque lecture d’un Skill par l’Agent actualise sa date de dernière utilisation. Cet horodatage sert à la décision d’éviction LRU et permet au mécanisme local de distinguer les Skills réellement utilisés de ceux qui occupent seulement de l’espace.

Comment savoir si un Skill est réellement utile

C’est l’étape que beaucoup de systèmes d’« apprentissage automatique » négligent : quelque chose a été appris, mais est-ce utile ? Orkas traduit cette question en quelques indicateurs locaux. Ils servent uniquement au mécanisme d’évolution sur la machine pour décider quel Skill réviser ou supprimer, et ne quittent jamais celle-ci.

Le mécanisme : au début de chaque tour, les Skills disponibles apparaissent dans l’index du prompt système, ce qui compte comme une « impression ». Si l’Agent lit effectivement un Skill pendant le tour, cela compte comme une « invocation ». Leur comparaison donne le premier indicateur :

• Taux d’invocation = invocations / impressions. Un Skill présent jour après jour sans être choisi a un faible taux : il est soit inutile, soit décrit de telle façon qu’on ne comprend pas quand l’utiliser.
• Taux de modification après utilisation = part des invocations après lesquelles l’utilisateur modifie manuellement le résultat. Un taux élevé signifie que la production du Skill ne correspond pas tout à fait à ses attentes.
• Taux d’inefficacité = part des invocations dont le tour se termine par une erreur non passagère. Un taux élevé suggère un problème dans le Skill lui-même.

On retrouve ici l’exception évoquée plus haut : les erreurs passagères ne comptent pas dans le taux d’inefficacité, pas plus que les tours arrêtés manuellement par l’utilisateur. Un incident réseau ne doit pas pénaliser un Skill parfaitement valable.

Grâce à ces quelques chiffres, les Skills passent d’une « accumulation dans une boîte noire » à un ensemble évaluable et améliorable. Décider lesquels réviser ou supprimer ne relève plus de l’intuition.

Fermer la boucle

En réunissant ces éléments, un cycle complet se déroule ainsi :

L’Agent accomplit de vraies tâches, enregistre localement les données d’exécution et marque les signaux au fil du travail. Lorsque le cycle de réflexion en arrière-plan arrive, il sélectionne les Agents ayant une activité nouvelle et dont le délai minimal est écoulé. Il organise leur activité récente en dossiers et demande au modèle de les examiner à la lumière de sa compréhension actuelle de lui-même : fusionner ce qui doit l’être, retirer ce qui doit l’être, transformer les enseignements utiles en nouveaux Skills. La revue produit des Skills et une compréhension de soi. À la conversation suivante, les Skills entrent dans l’index du prompt et la compréhension de soi dans le prompt système ; l’Agent revient avec ce qu’il a appris au cycle précédent. Ce nouveau cycle produit à son tour des indicateurs et signaux réinjectés au début.

La boucle continue, cycle après cycle. Chaque cycle n’apporte pas une amélioration spectaculaire, mais la direction reste la même : mieux vous comprendre et répéter moins souvent les mêmes erreurs.

Quelques compromis à expliciter

Avec le recul, certaines décisions de ce mécanisme sont essentielles.

L’introspection doit être peu coûteuse. L’auto-observation utilise des indicateurs sans coût de modèle ; la réflexion réellement coûteuse est déplacée en arrière-plan, peu fréquente et précédée d’un contrôle de nouveauté. En maîtrisant strictement la partie chère, on rend le mécanisme viable.

Mieux vaut ne pas apprendre qu’apprendre de travers. L’exclusion des erreurs passagères, l’autorisation de ne rien enregistrer et les consignes exécutables plutôt que les descriptions vagues reposent sur le même constat : pour un système qui s’améliore, apprendre dans la mauvaise direction est bien plus dangereux qu’apprendre lentement.

Ce qui est appris doit être visible, modifiable et sous votre contrôle. Les Skills sont des fichiers texte, la compréhension de soi un mémo texte, et l’efficacité des Skills se vérifie par des indicateurs. Tous ces fichiers résident sur votre machine, pas dans le cloud. Aucune boîte noire : une personne peut les ouvrir et les ajuster à tout moment.

Mettre des freins à l’apprentissage. Plafonds de nombre, éviction LRU, limites de longueur : sans eux, l’« apprentissage continu » devient tôt ou tard une « accumulation continue ». Oublier, retirer et élaguer comptent autant que mémoriser.

Pour conclure

L’autoévolution d’Orkas ajoute essentiellement une boucle lente à l’Agent : la boucle rapide fournit la réponse immédiate de chaque conversation ; la boucle lente revient périodiquement sur l’expérience pour en tirer quelque chose d’utile la fois suivante. Le plus difficile n’est pas de « faire mémoriser le modèle », mais de prendre les décisions techniques souvent négligées : quelles expériences conserver, comment ne pas être trompé par un échec fortuit, comment rendre l’apprentissage réellement exécutable et comment l’élaguer avant qu’il ne gonfle.

Ces décisions réunies transforment « plus utile à mesure que vous l’utilisez » d’un slogan marketing en un mécanisme qui fonctionne. Un assistant qui apprend de vous sans apprendre de travers est peut-être plus proche de ce que souhaitent la plupart des gens qu’un assistant simplement plus intelligent.

Pour découvrir les Agents spécialisés sur lesquels s’appuie cette boucle lente, consultez l’équipe d’Agents Orkas.