Quand mes agents IA apprennent de leurs erreurs : bilan de 73 compétences apprises

Débat audio sur l'article:

**Speakers :** Mathieu (homme), Vivienne (femme) **Duration :** ~7 minutes **Date :** 2026-02-24 **Note :** Termes anglophones réduits au maximum — traductions françaises privilégiées dans le script --- [Vivienne] Mathieu, tu as construit un système où tes agents accumulent des compétences au fil du temps. Et tu viens de faire un premier bilan chiffré. Soixante-treize compétences en deux semaines. Qu'est-ce qui t'a poussé à mesurer ? [Mathieu] Le doute. Le système fonctionnait en théorie : chaque agent qui résout un problème capture la solution dans une mémoire partagée. Les autres agents peuvent la récupérer ensuite. Mais est-ce que ça marchait vraiment ? Est-ce que les compétences étaient réellement réutilisées ? Sans mesure, c'est juste une conviction. [Vivienne] Comment fonctionne ce mécanisme d'apprentissage exactement ? [Mathieu] C'est un cycle en quatre phases. À chaque tâche, l'agent commence par le rappel : il va chercher dans la base vectorielle les compétences déjà capturées par ses pairs ou par lui-même. Ensuite vient la vérification pré-action : avant toute opération complexe, il cherche si quelqu'un a déjà résolu un problème similaire. Pendant l'exécution, il prend des notes en temps réel dans un carnet — chaque découverte, chaque contournement, chaque piège rencontré. Et à la fin, il évalue ses notes et décide : créer une nouvelle compétence, enrichir une existante, ou créer un raccourci d'optimisation. [Vivienne] Le carnet de notes en temps réel, c'est ce qui différencie ton système d'un simple historique de sessions ? [Mathieu] Exactement. C'est de la capture contextuelle immédiate. L'agent note au moment où il découvre quelque chose, pas trois heures après quand le contexte est perdu. Et chaque note est catégorisée : interface de programmation, piège, patron réutilisable, optimisation. Ce sont ces catégories qui permettent ensuite de décider si la note mérite de devenir une compétence permanente. [Vivienne] Parlons des chiffres. Soixante-treize compétences, quarante-neuf agents contributeurs, cent cinquante-cinq mille caractères de connaissance. Comment se répartissent ces compétences ? [Mathieu] Trois catégories ont émergé naturellement. Les compétences factuelles — ce que j'appelle « appris » — représentent quarante-six pour cent. Ce sont des corrections de bogues, des interfaces de programmation maîtrisées, des contournements de plateforme. Exemple concret : sur Windows, les fichiers de variables d'environnement contiennent des retours chariot différents. L'agent a appris à découper le texte avec une expression régulière qui gère les deux formats au lieu d'un seul. [Vivienne] Et les deux autres catégories ? [Mathieu] Les synergies représentent quarante-deux pour cent — presque autant que les compétences factuelles. Ce sont des combinaisons d'outils en ligne de commande qui produisent un résultat supérieur à chaque outil séparé. Par exemple, utiliser ef-dé pour trouver les fichiers, ripgrep pour chercher dedans, et jé-ku pour extraire les données en format d'échange structuré. Le tout en une seule commande enchaînée. Et les optimisations, onze pour cent : des réductions d'étapes. Quand un agent constate qu'il fait huit requêtes de base de données pour une tâche récurrente, il crée une fonction qui fait tout en un seul appel. [Vivienne] Quarante-deux pour cent de synergies, c'est énorme. Pourquoi autant ? [Mathieu] Un événement particulier l'explique. Le vingt-deux février, j'ai lancé un audit massif des outils en ligne de commande. En une seule journée, quarante nouvelles compétences ont été créées, dont vingt-six synergies. Un seul agent — l'auditeur d'adoption d'outils — a produit vingt-neuf compétences à lui seul. C'est un pic d'apprentissage lié à une session intensive, pas un rythme de croisière. [Vivienne] Et au niveau de la maturité des agents ? Ils n'apprennent pas tous au même rythme ? [Mathieu] Non, et c'est révélateur. J'ai classé les cinquante agents en quatre niveaux. Quatre agents sont au niveau expert avec dix compétences ou plus — ils concentrent soixante-trois compétences à eux seuls. Huit sont au niveau mature, entre cinq et neuf compétences. Vingt-neuf sont en croissance avec deux à quatre compétences. Et neuf sont débutants avec une seule compétence. Mais le plus intéressant : quarante agents n'ont encore aucune compétence. [Vivienne] Quarante agents sans aucune compétence. C'est un problème ? [Mathieu] Pas nécessairement. Certains agents sont rarement appelés — l'agent de sécurité ou celui de l'intégration continue par exemple. Ils n'ont tout simplement pas encore eu l'occasion d'apprendre. Le système est conçu pour accumuler progressivement, pas pour forcer l'apprentissage. [Vivienne] Passons aux problèmes que l'audit a révélés. Tu en as trouvé quatre ? [Mathieu] Quatre problèmes que je n'aurais jamais détectés sans mesure. Le premier : trente-trois sections dupliquées dans la base. Des « cas limites » génériques avaient été copiés-collés entre compétences. Le même texte de modèle apparaissait dans des compétences différentes, polluant la recherche sémantique et gaspillant de l'espace. [Vivienne] La cause ? [Mathieu] Le modèle de capture initiale incluait des cas limites par défaut. Les agents les recopiaient mécaniquement sans les personnaliser. Un biais de conception que seul un audit quantitatif pouvait révéler. [Vivienne] Le deuxième problème, c'est le plus ironique d'après toi. [Mathieu] Le suivi des rappels affichait zéro pour cent. Zéro. Le système était conçu pour que les agents rappellent leurs connaissances à chaque session. Mais le crochet de suivi ne capturait que les appels via l'outil de compétence de Claude Code — pas les requêtes de base de données directes que les agents utilisent en phase un et deux. Le système fonctionnait — les agents rappelaient bien leurs compétences — mais le suivi était aveugle. Comme un compteur de pas qui ne détecte que la course et ignore la marche. [Vivienne] Sans suivi fiable, impossible de savoir quelles compétences sont réellement utilisées. [Mathieu] Et donc impossible de savoir lesquelles conserver, élaguer ou améliorer. C'est le point aveugle le plus dangereux d'un système d'apprentissage : la mesure de l'utilisation. [Vivienne] Les deux autres problèmes ? [Mathieu] Deux compétences incomplètes. L'une avait sa section « processus » manquante — le mode d'emploi n'existait pas. L'autre avait un type de métadonnée incorrect qui la rendait invisible au mécanisme de rappel. Deux bogues silencieux qui auraient pu rester indéfiniment sans audit. [Vivienne] Comment tu as corrigé tout ça ? [Mathieu] Chaque problème a reçu sa solution. Pour les doublons : purge des trente-trois sections en conservant la version la plus ancienne de chaque groupe. Pour le suivi : création d'une fonction de base de données qui fait deux choses en un seul appel — retourner les compétences pertinentes et enregistrer le rappel. Plus de trou dans la mesure. Pour les compétences cassées : ajout de la section manquante et correction des métadonnées. [Vivienne] Et le quatrième problème — l'ironie de l'audit lui-même. [Mathieu] L'audit nécessitait huit requêtes de base de données manuelles. Pour un système censé optimiser le travail des agents, devoir exécuter huit requêtes à la main pour mesurer sa santé, c'était un comble. J'ai donc créé une fonction d'audit qui retourne un objet structuré complet avec toutes les métriques en un seul appel. Et cette optimisation a elle-même été capturée comme une compétence de type « optimisation ». Le système a appris à mieux s'auditer. [Vivienne] Le système d'apprentissage qui apprend à s'auditer. C'est le cercle vertueux que tu visais ? [Mathieu] Exactement. Et ça illustre le principe fondamental : un bug résolu une fois ne l'est plus jamais deux fois. Trente-quatre connaissances factuelles capturées, disponibles immédiatement pour cinquante agents. Quand un agent s'attaque à un problème Windows, il n'a plus besoin de redécouvrir le contournement des retours chariot — c'est dans sa mémoire de démarrage. [Vivienne] Quelle est la leçon principale de ce bilan ? [Mathieu] Qu'un système d'apprentissage sans audit dérive silencieusement. Les doublons s'accumulent, le suivi décroche, les compétences incomplètes passent inaperçues. L'apprentissage entre machines est fondamentalement différent du nôtre — les agents n'oublient pas, ne déforment pas les souvenirs, et partagent instantanément. Mais ils ont les mêmes faiblesses organisationnelles que les équipes humaines : sans mesure, sans nettoyage régulier, la base de connaissances se dégrade. [Vivienne] Et la prochaine étape ? [Mathieu] Automatiser l'audit. Que le système se surveille lui-même sans intervention manuelle. Parce que si j'ai appris une chose de ce bilan, c'est que mesurer régulièrement est le seul moyen de savoir si vos agents apprennent vraiment. [Vivienne] Soixante-treize compétences, un suivi réparé, et un système qui apprend à se corriger. On peut dire que le bilan est positif. [Mathieu] Positif, mais humble. Le vrai test, ce sera dans un mois, quand on pourra mesurer combien de ces compétences sont effectivement rappelées. Le suivi fonctionne maintenant — les données diront si l'apprentissage tient ses promesses.

Est-ce que mes agents IA apprennent vraiment ?

C'est la question que je me suis posée après plusieurs semaines à faire tourner un système multi-agents sur mes projets. J'avais mis en place un mécanisme de « learned skills » : quand un agent résout un bug, découvre une astuce ou contourne un problème plateforme, il capture automatiquement cette connaissance dans une mémoire RAG partagée. En théorie, les autres agents en bénéficient.

En théorie.

Parce qu'entre le concept et la réalité, il y a toujours un écart. J'ai décidé de mesurer. Le bilan : 73 compétences distinctes, 50 agents contributeurs, 155 000 caractères de connaissance accumulée — mais aussi des doublons, un tracking défaillant, et une ironie savoureuse que je vous raconte plus loin.

Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.

S'inscrire

Comment un agent « apprend »

Le mécanisme repose sur un cycle en quatre phases, exécuté à chaque tâche.

Phase 1 — Rappel. Au démarrage, l'agent charge ses learned skills depuis le RAG pgvector. Il récupère les connaissances pertinentes capturées par ses pairs ou par lui-même lors de sessions précédentes.

Phase 2 — Vérification pré-action. Avant toute action complexe (trois étapes ou plus), l'agent recherche dans la base de skills si quelqu'un a déjà résolu un problème similaire. S'il trouve un match, il applique la solution connue au lieu de tâtonner.

Phase 3 — Carnet de notes. Pendant l'exécution, chaque découverte est capturée en temps réel : une API qui se comporte différemment de sa documentation, un contournement pour Windows, un pattern réutilisable. Un simple append dans un fichier de notes, catégorisé ([api], [gotcha], [pattern], [efficiency]).

Phase 4 — Évaluation. Après la tâche, l'agent relit ses notes, cherche les skills existants, et décide : créer un nouveau skill (NEW), enrichir un skill existant (IMPROVE), ou créer un raccourci (OPTIMIZE).

Ce qui rend le système intéressant, ce sont les trois types de connaissances qui émergent :

Learned — un bug résolu, une API maîtrisée, un contournement plateforme. Exemple : « Sur Windows, les fichiers .env contiennent des CRLF — utiliser split(/\r?\n/) au lieu de split("\n") ».
Synergy — une combinaison d'outils CLI qui produit un résultat supérieur à chaque outil isolé. Exemple : fd pour trouver les fichiers, rg pour chercher dedans, jq pour extraire les données JSON — le tout en une seule commande.
Optimize — une réduction d'étapes. Quand un agent constate qu'il effectue huit requêtes SQL manuelles pour une tâche récurrente, il crée une fonction PgSQL qui fait la même chose en un seul appel.

La propagation est automatique : quand un agent apprend un skill, il est poussé vers tous les agents liés via un graphe de relations défini dans le RAG. Un bug résolu par un agent profite immédiatement à tous les agents du même domaine.

Les chiffres du bilan — 73 compétences en deux semaines

Voici les KPI extraits directement de la base pgvector.

Métrique	Valeur
Skills distincts	73
Sections RAG	447
Caractères de connaissance	155 587
Agents contributeurs	49
Moyenne de sections par skill	6,1

Répartition par catégorie

La répartition entre les trois types n'est pas celle que j'attendais :

Catégorie	Skills	%	Sections
Learned	34	46 %	184
Synergy	31	42 %	221
Optimize	8	11 %	42

Les synergies représentent presque autant que les learned. Cela s'explique : la journée du 22 février a été consacrée à un audit massif des outils CLI (jq, ripgrep, fd, bat, fzf...). En un seul jour, 40 nouveaux skills ont été créés, dont 26 synergies entre outils et agents.

Les agents qui apprennent le plus

Agent	Skills	Catégorie dominante
tool-adoption-auditor	29	Synergy (26)
rag-optimizer	13	Learned (7)
orchestrator	11	Synergy (5)
explore-codebase	10	—
refactor-cleaner	9	—

Le tool-adoption-auditor domine largement — c'est l'agent qui a produit les 26 synergies CLI en une seule session. Le rag-optimizer, lui, a accumulé 13 skills en diagnostiquant et optimisant le système RAG lui-même.

Maturité des agents

J'ai classé les 50 agents en quatre niveaux de maturité :

Niveau	Agents	Skills
Expert (10+ skills)	4	63
Mature (5-9)	8	44
Growing (2-4)	29	87
Beginner (1)	9	9

Le plus révélateur : 40 agents n'ont encore aucun skill. Ce n'est pas nécessairement un problème — certains agents (comme security-reviewer ou ci-pipeline) sont appelés rarement et n'ont pas encore eu l'occasion d'apprendre.

Ce qui ne marchait pas

L'audit a révélé quatre problèmes que je n'aurais pas détectés sans mesure.

33 sections dupliquées

Des « Edge Cases » génériques avaient été copiées-collées entre skills. Le même texte boilerplate apparaissait dans des skills différents, gaspillant de l'espace dans le RAG et polluant la recherche sémantique. Cause probable : lors de la capture initiale, le template de skill incluait des edge cases génériques que les agents recopiaient sans les personnaliser.

Un tracking de rappel à 0 %

C'est le problème le plus ironique. Le système de learned skills était conçu pour que les agents rappellent leurs connaissances à chaque session. Mais le hook de tracking ne capturait que les appels au Skill tool de Claude Code — pas les rappels SQL directs que les agents utilisent en Phase 1 et 2.

Résultat : le système fonctionnait (les agents rappelaient bien leurs skills), mais le tracking indiquait 0 % de rappel. Sans mesure fiable, impossible de savoir quels skills étaient réellement utilisés, et donc lesquels conserver ou élaguer.

Deux skills incomplets

Un skill avait sa section « process » manquante (le mode d'emploi était absent), et un autre avait un type de métadonnée incorrect (skill au lieu de learned-skill), ce qui le rendait invisible au mécanisme de rappel.

L'ironie de l'audit

Le problème le plus savoureux : l'audit lui-même nécessitait huit requêtes SQL manuelles. Pour un système censé optimiser le travail des agents, devoir exécuter huit requêtes à la main pour mesurer sa santé, c'était un comble. Le système d'apprentissage avait besoin... d'apprendre à s'auditer lui-même.

Les corrections appliquées

Chaque problème a reçu sa solution :

Purge des doublons. 33 sections désactivées en conservant la version la plus ancienne (MIN(id)) de chaque groupe de doublons.

Nouveau tracking. Création d'une fonction PgSQL recall_learned_skills() qui fait deux choses en un seul appel : retourner les skills pertinents ET enregistrer le rappel dans la table de tracking. Plus de trou dans la mesure.

Skills corrigés. Ajout de la section process manquante, correction du type de métadonnée. Backfill des embeddings pour restaurer la recherche sémantique.

OPTIMIZE de l'audit. Création de rag_learned_skills_audit(), une fonction PgSQL qui retourne un objet JSON complet avec toutes les métriques — résumé, catégories, tendances 14 jours, qualité. Les huit requêtes manuelles ont été remplacées par un seul appel. Et cette optimisation a elle-même été capturée comme un OPTIMIZE skill, pour que les futurs audits en bénéficient automatiquement.

Ce que cela change en pratique

Le résultat concret de ce système, après corrections :

Chaque agent démarre avec la connaissance de ses pairs. Un agent qui s'attaque à un problème Windows n'a plus besoin de redécouvrir le contournement CRLF — il est dans sa mémoire de démarrage.

Un bug résolu une fois ne l'est plus jamais deux fois. C'est la promesse fondamentale des learned skills, et les chiffres montrent qu'elle tient : 34 connaissances factuelles capturées, disponibles immédiatement pour 50 agents.

Les synergies CLI sont partagées automatiquement. Quand le tool-adoption-auditor découvre que fd + rg est plus efficace que find + grep, cette connaissance est propagée aux neuf agents qui font des recherches de fichiers.

Le système s'auto-améliore. L'audit a produit un OPTIMIZE skill qui réduit le coût des futurs audits. C'est exactement le cercle vertueux visé : le système d'apprentissage apprend à mieux s'auditer.

Conclusion

73 compétences capturées, 50 agents contributeurs, un écosystème d'apprentissage mesurable. Le bilan est positif, mais il porte une leçon importante : un système d'apprentissage sans audit dérive silencieusement. Les doublons s'accumulent, le tracking décroche, les skills incomplets passent inaperçus.

L'apprentissage machine-to-machine est fondamentalement différent du nôtre. Les agents n'oublient pas, ne déforment pas les souvenirs, et partagent instantanément. Mais ils ont les mêmes faiblesses organisationnelles que les équipes humaines : sans mesure, sans nettoyage régulier, la base de connaissances se dégrade.

La prochaine étape : automatiser l'audit lui-même, pour que le système se surveille sans intervention. Parce que si j'ai appris une chose de ce bilan, c'est que mesurer régulièrement est le seul moyen de savoir si vos agents apprennent vraiment.

Qui suis je ?

Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.

J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.

Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.

L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.

La technologie, les méthodes, le management sont le cœur de mes compétences.

Vous pouvez me faire confiance sur ces points là.

Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr

Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100% IA.

Mathieu Grenier 24 février 2026