J’améliore des skills d’agents IA avec n8n et Cognee en créant une boucle contrôlée : analyse des runs faibles, proposition de réécriture, validation humaine, puis application. Le vrai sujet, c’est d’éviter que vos fichiers SKILL.md vieillissent sans contrôle.
Pourquoi les skills deviennent-ils faibles ?
Les skills deviennent faibles quand ils arrêtent de coller au terrain. Un agent IA peut avoir de bonnes instructions au départ, mais si ces instructions ne suivent pas les vrais cas rencontrés, les erreurs répétées, les nouveaux patterns de code ou les règles métier qui changent, elles perdent vite de leur valeur.
Le fichier SKILL.md, c’est souvent le point de départ. Il décrit comment l’agent doit travailler, quelles conventions suivre, quoi éviter, comment raisonner sur certains cas. C’est très utile. Mais avec le temps, il peut devenir incomplet, trop vague, ou carrément déconnecté des exécutions réelles.
Comment bâtir un agent infrastructure stack fiable ?
Ce n’est pas un problème théorique. C’est un problème de maintenance. Quand un agent rate trois fois le même type de tâche, il y a probablement une règle à ajouter, un exemple à préciser, ou une exception à documenter. Si personne ne récupère cette erreur pour améliorer le skill, l’agent va continuer à se planter. Et là, on ne parle pas d’un manque “d’intelligence”, on parle juste d’un manque de retour d’expérience.
Dans mes projets data et IA, j’ai souvent vu la même chose. Les équipes documentent très bien au début. Puis les instructions se dégradent doucement, parce que personne ne sait vraiment qui doit les maintenir. Le métier pense que c’est à la tech. La tech pense que c’est au produit. Et au final, le fichier reste là, propre en apparence, mais de moins en moins utile.
Entre nous, on le sait bien, faire appel à un consultant en automatisation intelligente et en agent IA, c’est souvent le raccourci le plus malin. On en parle ?
Le bon réflexe, c’est de créer une boucle d’amélioration continue autour des skills :
- Repérer les exécutions faibles, par exemple une tâche ratée, une correction manuelle, ou un résultat refusé.
- Analyser ce qui manque dans le SKILL.md.
- Générer une proposition d’amélioration claire.
- Afficher un diff avant/après pour voir exactement ce qui change.
- Demander une validation humaine avant toute modification.
Comment l’AIoT transforme les données en valeur ?
L’automatisation ne doit pas écrire directement dans les skills sans contrôle. C’est tentant, mais dangereux. Un agent qui modifie ses propres règles sans validation peut ajouter une mauvaise consigne, surcorriger un cas isolé, ou casser une règle métier importante.
Le compromis sain, c’est une proposition claire, une validation, puis une mise à jour propre. Cognee va servir de couche mémoire et de raisonnement sur les connaissances. Côté orchestration, n8n va piloter tout le workflow, du signal faible jusqu’à la mise à jour validée.
Quel rôle joue Cognee ?
Cognee joue le rôle de mémoire structurée pour l’agent IA. Je m’en sers pour éviter que l’agent reparte de zéro à chaque exécution, ou qu’il improvise à partir d’un prompt trop vague. Cognee prend les documents et les skills, puis transforme ça en connaissances exploitables.
Concrètement, Cognee extrait des entités, des relations et de la provenance. Une entité, c’est un objet important comme un skill, une règle métier, un fichier ou un cas de test. Une relation, c’est le lien entre deux éléments, par exemple “ce skill vérifie cette règle”. La provenance indique d’où vient l’information. C’est important, parce qu’un agent doit pouvoir retrouver pourquoi il pense quelque chose.
Dans n8n, avec le nœud vérifié Cognee, j’utilise ces opérations pour faire évoluer un skill proprement :
- Ingest Skill charge le fichier SKILL.md dans Cognee. C’est le point de départ, l’agent sait enfin lire le skill comme une connaissance durable.
- Review Skill évalue la qualité du skill face à un cas donné. Je lui donne une situation concrète, et Cognee regarde si le skill couvre bien le besoin.
- Propose Improvement génère une proposition de réécriture. L’idée n’est pas d’écraser le skill tout de suite, mais de proposer une amélioration lisible.
- Get Proposal récupère cette proposition. Ça permet de la relire, de la valider, ou de la bloquer.
- Apply Improvement applique la modification validée. Là, le skill est réellement mis à jour.
- Get Skill récupère le skill final. Je peux ensuite le réinjecter dans un agent, un repo, ou une étape suivante du workflow.
Prenons un exemple simple. Un agent de relecture de code doit vérifier une boundary d’autorisation. Une boundary, c’est la limite à ne pas franchir côté sécurité. Ici, l’agent doit contrôler que l’utilisateur est bien propriétaire du dataset avant de lire ou modifier les données.
Comment utiliser Claude Code avec un modèle local ?
Avec Cognee, le skill peut être relu sur ce cas précis. Il doit dire clairement que l’agent vérifie la propriété du dataset, qu’il prévoit le cas où l’enregistrement est manquant, et qu’il demande des tests pour trois scénarios : owner, non-owner et missing. J’ai vu ce genre d’oubli chez un client, le code gérait le non-owner, mais pas le dataset inexistant. Résultat, une erreur bizarre au lieu d’un vrai refus propre.
| Opération | Rôle | Moment dans le workflow |
| Ingest Skill | Charge le fichier SKILL.md dans Cognee | Au démarrage |
| Review Skill | Évalue le skill face à un cas concret | Après l’ingestion |
| Propose Improvement | Prépare une amélioration du skill | Après la revue |
| Get Proposal | Récupère la proposition | Avant validation |
| Apply Improvement | Applique la modification validée | Après validation |
| Get Skill | Récupère le skill final | À la fin du workflow |
Quel rôle joue n8n ?
N8n joue le rôle du chef d’orchestre. Il ne raisonne pas à la place de Cognee, et c’est important de garder cette séparation claire. Cognee analyse, comprend le skill, propose une amélioration. N8n, lui, organise la boucle, pose les conditions, gère l’approbation et déclenche les actions dans le bon ordre.
Dans un workflow propre, je démarre avec Ingest Skill. Le skill est envoyé dans Cognee pour être indexé et compris. Ensuite, je lance Review Skill, qui produit une évaluation avec un score. Ce score devient le point de décision dans n8n. Si le score est suffisant, le flux peut s’arrêter là. Pas besoin de sur-automatiser pour le plaisir.
Si le score est faible, n8n lance Propose Improvement. Cognee prépare une proposition d’amélioration. Puis n8n récupère cette proposition avec Get Proposal, construit un diff avant/après, et ouvre une porte d’approbation. Tant que cette validation n’est pas acceptée, rien n’est appliqué. Si quelqu’un valide, alors seulement n8n déclenche Apply Improvement. À la fin, Get Skill permet de récupérer la version modifiée et d’afficher le delta final.
Le diff est vraiment un élément clé. Un diff, c’est simplement la comparaison lisible entre l’ancienne version et la nouvelle. Ça permet de voir ce qui change, ligne par ligne ou bloc par bloc. Et surtout, ça se réutilise partout : dans Slack, dans une pull request, dans un outil interne, dans un ticket de validation. Ça évite les modifications opaques. On sait ce qui change, et pourquoi.
La porte d’approbation dans n8n est centrale. Elle empêche qu’un agent réécrive automatiquement un skill sensible sans contrôle humain. C’est encore plus vrai quand le skill touche au code, à la sécurité, à la conformité ou à des règles métier. Là, le “ça a l’air mieux” ne suffit pas.
Sur le terrain, je vois souvent le même frein chez les clients. Le problème n’est pas toujours la génération IA. Elle marche plutôt bien. Le vrai sujet, c’est la gouvernance. Qui valide ? Qui garde la trace ? Qui peut revenir en arrière si la modification pose problème ? N8n aide justement à rendre ces étapes concrètes, visibles, auditables. Et ça change tout.
Comment déployer ce workflow ?
Pour déployer ce workflow, je pars d’un choix assez simple : soit je le construis visuellement dans n8n avec le nœud Cognee, soit je branche le SDK Python Cognee dans n8n avec un nœud Execute Command. Les deux options sont propres. Elles ne répondent juste pas au même niveau de contrôle.
Quand je veux un workflow lisible, facile à relire et maintenable par une équipe ops, data ou automation, je préfère l’approche visuelle dans l’éditeur n8n. On importe un template, puis on utilise le nœud Cognee vérifié pour les opérations clés : ingest, review, propose, get proposal, apply et get skill. C’est pratique parce qu’on voit tout le parcours. Qui déclenche quoi, où part la donnée, où se fait la validation, où la mise à jour est appliquée.
J’ai souvent vu ça mieux marcher dans les équipes où plusieurs personnes doivent comprendre le workflow sans ouvrir du code. Le visuel évite pas mal d’ambiguïtés, surtout quand le process doit être audité ou repris par quelqu’un d’autre trois mois plus tard.
L’autre option, c’est le SDK Python Cognee. Là, je le choisis quand j’ai besoin de plus de contrôle, d’un runner personnalisé, ou d’une logique plus fine autour des appels search et improve_skill. Dans ce cas, n8n reste l’orchestrateur, mais il déclenche le script Python via Execute Command. C’est utile si votre environnement technique a déjà ses conventions, ses logs, ses secrets, ses tests, ou une manière précise de gérer les erreurs.
| Approche | Quand je la choisis | Avantage | Point d’attention |
| N8n visuelle avec le nœud Cognee | Quand je veux un workflow lisible, rapide à mettre en place et maintenable par une équipe non exclusivement dev | Lisibilité, rapidité de mise en place, suivi clair des étapes | Moins flexible si la logique devient très spécifique |
| SDK Python Cognee via Execute Command | Quand je veux plus de contrôle, un runner personnalisé ou une intégration technique spécifique | Contrôle fin, logique sur mesure, intégration facile dans un environnement existant | Demande plus de rigueur côté code, logs et gestion des erreurs |
Dans les deux cas, le résultat reste le même : détecter un skill faible, générer une proposition, demander une validation, appliquer la mise à jour et produire un diff exploitable. Le prérequis à garder en tête est simple : il faut une instance n8n avec le nœud Cognee en version v0.5.1 ou plus, avec installation possible depuis l’éditeur local.
Peut-on garder les données en local ?
Oui, on peut garder les données en local. C’est même un des points qui rend l’approche intéressante pour une entreprise sérieuse. Avec n8n en self-hosted, un serveur Cognee hébergé côté entreprise, et des modèles LLM ou embeddings locaux, le workflow peut tourner sans envoyer les données vers des services externes.
C’est important parce qu’un skill d’agent IA, ce n’est pas juste un petit prompt sympa. Ça peut contenir des règles internes, des bouts de logique métier, des conventions de code, des patterns d’architecture, parfois même des éléments très proches de la propriété intellectuelle. Et franchement, je comprends très bien qu’une équipe sécurité bloque dès qu’on propose d’envoyer ça dans une API externe.
La logique reste simple. N8n orchestre le workflow sur une instance self-hosted. Cognee tourne dans l’environnement de l’entreprise et sert à structurer, retrouver et enrichir la connaissance utile aux agents. Les modèles de langage et les modèles d’embeddings, c’est-à-dire les modèles qui transforment du texte en représentations numériques exploitables pour la recherche sémantique, peuvent aussi être exécutés en local. Résultat, les données restent sur site.
Ce point change beaucoup la perception du système. Une boucle de self-improvement, donc un mécanisme où un agent propose d’améliorer ses propres skills à partir de retours ou d’erreurs, n’est saine que si elle est contrôlée. Il faut des seuils, une validation humaine ou technique, un diff clair, une traçabilité, et une application seulement après approbation. Le local n’enlève pas ce besoin de contrôle, il ajoute une couche de maîtrise sur les données.
Je reprends l’exemple du skill de relecture de code sur une boundary d’autorisation. Ce skill peut contenir des règles sensibles comme :
- Contrôler qu’un utilisateur est bien propriétaire du dataset avant d’autoriser l’accès.
- Gérer proprement le cas où l’enregistrement demandé n’existe pas.
- Vérifier les tests pour un owner, un non-owner et un missing record.
Ce sont exactement les cas où les équipes sécurité, data et engineering veulent comprendre ce qui part, où ça part, et qui peut le relire. En local, la discussion devient plus simple. On parle de gouvernance, de logs, de validation, pas de fuite potentielle vers un service tiers.
Ce workflow ne sert donc pas juste à automatiser une mise à jour. Il sert à créer une maintenance continue, validée et traçable des compétences des agents IA.
Et si vos agents apprenaient enfin de leurs mauvaises exécutions ?
Ce que je retiens, c’est que les skills d’agents IA ne devraient pas rester figés. Un fichier SKILL.md utile au départ peut vite devenir trop faible si personne ne le relie aux erreurs réelles. Avec Cognee et n8n, je peux construire une boucle propre : analyser, proposer, comparer, valider, appliquer. Cognee apporte la couche mémoire et la proposition d’amélioration. n8n apporte l’orchestration, les seuils, le diff et l’approbation. Le bénéfice pour vous est simple : vos agents progressent sans perdre le contrôle sur ce qui est modifié.
FAQ
- À quoi sert un fichier SKILL.md pour un agent IA ?
Un fichier SKILL.md sert à formaliser une compétence que l’agent peut réutiliser. Il peut contenir des instructions, des règles, des critères de contrôle ou des exemples. Le problème, c’est qu’il peut devenir obsolète si les erreurs réelles de l’agent ne sont jamais réinjectées dans sa maintenance. - Pourquoi utiliser Cognee avec n8n ?
Cognee apporte la couche mémoire et la capacité à structurer les connaissances autour des skills. n8n orchestre le flux : analyse, seuils, proposition, approbation, application et affichage du diff. Les deux outils se complètent bien parce que Cognee traite la connaissance et n8n contrôle le processus. - Est-ce que les modifications des skills sont appliquées automatiquement ?
Non, pas dans l’approche saine décrite ici. Le workflow génère d’abord une proposition d’amélioration, puis un diff avant/après. La modification n’est appliquée qu’après une étape d’approbation dans n8n. C’est ce qui évite les réécritures automatiques non contrôlées. - Quelle approche choisir entre le nœud Cognee dans n8n et le SDK Python ?
Je choisis le nœud Cognee dans n8n quand je veux aller vite avec un workflow visuel et lisible. Je choisis le SDK Python quand j’ai besoin de plus de contrôle, d’un runner personnalisé ou d’une intégration plus technique. Les deux approches peuvent produire le même résultat final. - Peut-on exécuter ce système sans envoyer les données à l’extérieur ?
Oui. Le workflow peut tourner en local avec n8n self-hosted, un serveur Cognee self-hosted et des modèles LLM ou embeddings locaux. C’est utile quand les skills contiennent des règles internes, du code, des logiques métier ou des informations sensibles.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent automatiser sans perdre la maîtrise de leurs données, de leurs workflows et de leur gouvernance. Avec webAnalyste et Formations Analytics, j’ai travaillé pour des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez mettre en place ce type de boucle IA et automation dans votre business, contactez-moi.
⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.