# Extraction de compétences : de 3 500 candidates à 466 capacités Canonical source: https://maguyva.ai/fr/blog/skill-mining-3500-and-counting License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license). Date: 2026-01-27 · Author: Maguyva Team > Nous avons passé au crible 3 500 compétences candidates et en avons adopté 466. Une boucle systématique d'extraction et d'ingestion pour construire, à grande échelle, une bibliothèque de compétences d'agents IA cohérente. > *Les chiffres de cet article reflètent le système au moment de la publication (janvier 2026). Consultez notre [page équipe](/fr/team) pour les chiffres actuels.* ## Le problème des 3 500 compétences Quand nous avons commencé à construire un système d'orchestration d'agents, nous avons fait face à un défi intéressant : des milliers de compétences potentielles sont éparpillées dans tout l'écosystème IA. Dépôts GitHub, documentation d'éditeurs, projets communautaires, schémas internes — les compétences existent partout. Mais lesquelles comptent ? Lesquelles fonctionnent ? Et comment maintenir une bibliothèque de compétences cohérente que les agents peuvent réellement utiliser ? Notre réponse : une boucle systématique d'extraction et d'ingestion. ## Les chiffres aujourd'hui À peine plus de trois mois après le lancement des Agent Skills par Anthropic le 16 octobre 2025, voici où nous en étions à la publication de cet article, le 27 janvier 2026 : | Métrique | Nombre | |--------|-------| | Candidates identifiées | plus de 3 500 | | Compétences adoptées | 466 | | Compétences d'éditeurs | 373 | | Compétences internes | 93 | | Éditeurs actifs | plus de 25 | | Tokens moyens par compétence | 2 834 | | Outils référencés | 89 | | Tags uniques | 635 | Nous avons passé en revue plus de 3 500 compétences candidates. Nous en avons adopté 466. Cela représente un taux d'adoption de 13 % — et cette sélectivité est voulue. ## Le système de paliers de connaissance Toutes les compétences ne se valent pas. Nous les organisons en cinq couches de connaissance (K0-K4), chacune représentant une portée d'applicabilité différente : ### K0 : Fondations (universelles) Des compétences que chaque agent devrait posséder. Elles représentent des capacités de « bon penseur » qui fonctionnent partout. ``` foundations/ ├── test-first-discipline # TDD: Red-Green-Refactor ├── evidence-based-completion # Verify before claiming done ├── systematic-debugging # Root cause methodology ├── structured-planning # Break work into tasks └── context-budget-awareness # Manage token consumption ``` Les compétences K0 sont portables vers n'importe quel projet, domaine ou pile technologique. Elles encodent des schémas cognitifs universels. ### K1 : Identités (discipline) Des compétences de « bon ingénieur » ou de « bon chercheur » qui s'appliquent à travers les projets au sein d'une discipline. ``` identities/ ├── research-workflows # Multi-source research ├── web-extraction-playbook # Content extraction ├── code-review # PR review patterns └── cli-interface-standards # CLI design patterns ``` ### K2 : Domaines (expertise sur un sujet) Des compétences de « bon expert base de données » ou de « bon ingénieur sécurité », portables au sein d'un domaine. ``` domains/ ├── schema-migration-workflow # Safe migration patterns ├── rpc-validation-checklist # RPC health checks ├── auth-validation-checklist # JWT/OAuth patterns └── secrets-audit-checklist # Credential scanning ``` ### K3 : Piles techniques (technologie) Des compétences de « bon utilisateur Supabase » ou de « bon développeur Cloudflare » pour des piles technologiques spécifiques. ``` stacks/ ├── maguyva-quickstart # Our semantic search patterns ├── cloudflare-deployment # Workers/Pages deployment └── mcp-tool-best-practices # MCP tool selection ``` ### K4 : Projet (organisation) Des compétences propres à notre organisation et à nos flux de travail. ``` project/ ├── agent-creation-workflow # How we build agents ├── skill-authoring-workflow # How we write skills ├── mining-session-workflow # This very process └── vendor-skill-evaluation # Evaluation rubrics ``` ## La boucle d'extraction ### Phase 1 : découverte Les compétences viennent de partout : **Dépôts d'éditeurs** : AWS, Anthropic, Cloudflare, Supabase et des contributeurs communautaires publient des collections de compétences. Nous suivons plus de 25 racines d'éditeurs. **Projets communautaires** : GitHub regorge de templates Claude Code, de schémas d'agents et de définitions de flux de travail. **Schémas internes** : à mesure que notre équipe résout des problèmes, des schémas émergent. Ils sont formalisés en compétences. **Extraction depuis la documentation** : la documentation technique contient souvent des compétences implicites — procédures, listes de vérification, arbres de décision. La découverte est continue. Nous utilisons un backlog de compétences pour suivre les candidates avant évaluation formelle. ### Phase 2 : évaluation Chaque candidate passe par la même grille : ```yaml adoption_criteria: - fills_real_gap: true # We lack this capability - well_structured: true # Progressive disclosure - actively_maintained: true # Commits in last 6 months - portable: true # Not hyper-specific - tested: true # Evidence of usage ``` Les cinq critères produit doivent tous être satisfaits. C'est pourquoi 87 % des candidates sont rejetées. Ensuite, chaque candidate passe par une revue de confiance distincte. Nous ne traitons pas un dépôt officiel d'éditeur, un mainteneur communautaire bien connu et un dépôt GitHub aléatoire comme des sources de vérité équivalentes. ```yaml trust_review: vendor_credibility: - ownership_verified # Official vendor, known maintainer, or internal source - maintenance_signal # Recent commits, issue response, release history - adoption_signal # Evidence of real use, stars alone are not enough - provenance_clear # We can trace where the skill came from prompt_injection_scan: - hidden_instruction_check # Buried "ignore previous instructions" patterns - exfiltration_check # Prompts that try to leak files, secrets, or context - authority_check # Claims of priority over system or developer rules script_audit: - inspect_scripts # Read shell/python/js helpers before adoption - network_and_exec_review # curl|bash, remote downloads, subprocess execution - file_and_secret_review # Env vars, credential access, broad file writes - destructive_action_check # rm, reset, overwrite, or unsafe automation ``` Les éditeurs de confiance bénéficient d'une revue de provenance plus légère, mais pas d'un laissez-passer. Les sources non fiables ou inconnues subissent un audit manuel plus approfondi, et nous n'exécutons pas les scripts intégrés avant qu'ils n'aient été lus, délimités, et classés comme sûrs. **Analyse d'écart** : avant d'adopter, nous cherchons dans notre registre : ```bash uv run orkestra skills search "" ``` Si nous l'avons déjà, nous n'en avons pas besoin. Si nous avons quelque chose de proche, nous pourrions fusionner plutôt qu'adopter. **Notation de profondeur et de conformité aux standards** : nous notons aussi à quel point une candidate exploite pleinement le modèle agent-compétence. Un simple `SKILL.md` isolé peut rester utile, mais des compétences plus profondes ont plus de valeur quand elles séparent instructions, références, scripts et actifs comme le recommande `agentskills.io`. ```yaml skill_depth: - level_1: SKILL.md only # Single instruction file - level_2: SKILL.md + strong description # Clear triggers and scope - level_3: adds references/ # Load docs only when needed - level_4: adds atomic scripts/ # Small, reviewable helpers - level_5: adds assets/examples/templates # Full progressive disclosure depth_signals: - standards_adherence # Structure aligns with agentskills.io conventions - reference_quality # Curated references, not giant context dumps - script_atomicity # Focused helpers, not opaque monoliths - tool_boundary_clarity # Clear limits on what the skill can execute - community_signal # Stars/forks/users help, but only as a weak boost ``` Les étoiles GitHub peuvent légèrement rehausser un score de crédibilité, mais elles ne sauvent jamais une compétence superficielle ou dangereuse. Un dépôt très étoilé avec un seul `SKILL.md` vague et des scripts opaques obtient une moins bonne note qu'un plus petit dépôt avec une description précise, des `references/` soignées, et des utilitaires atomiques qui exploitent réellement toute la capacité du modèle de compétence. **Analyse structurelle** : nous vérifions la qualité de la compétence : ```bash wc -l vendor///SKILL.md # Size check ls vendor///scripts/ # Supporting files ls vendor///references/ # Bundled docs ``` Si une candidate inclut des scripts, cette revue devient plus stricte. Une bonne compétence n'est pas seulement utile ; elle doit être lisible, délimitée et sûre à confier à un agent. Ce seul filtre de sécurité disqualifie une part significative de candidates par ailleurs intéressantes. ### Phase 3 : ingestion Quand une compétence passe l'évaluation, elle entre dans le registre. Mais les compétences ne sont jamais adoptées sans modification. Elles sont adaptées à notre système. **Modifications lors de l'adoption** : 1. **Normalisation des métadonnées** : chaque compétence reçoit notre schéma de frontmatter 2. **Attribution du palier K** : les compétences sont placées dans la couche de connaissance appropriée 3. **Enrichissement des tags** : des tags sont ajoutés pour la découverte 4. **Déclaration des outils** : les outils autorisés sont explicitement déclarés 5. **Alignement des sections** : le contenu est restructuré pour correspondre à notre modèle Un YAML de compétence typique après ingestion : ```yaml metadata: identifier: vendor-skill-evaluation name: vendor-skill-evaluation description: Systematic evaluation of vendor skills for adoption. type: workflow layer: K4 semantic_folder: project source: core last_updated: '2026-01-17' frontmatter: tags: - agents - meta - skill-adoption - vendor allowed_tools: - Bash - Read - Write - Edit - Grep - Glob - Task ``` ### Phase 4 : attribution de portée Les compétences sont attribuées à des portées — des catégories qui déterminent quels agents chargent quelles compétences : ```yaml scopes: database: primary_skills: - domains/schema-migration-workflow - domains/rpc-validation-checklist - vendor/supabase/supabase-database - vendor/supabase/supabase-auth research: primary_skills: - identities/research-workflows - identities/web-extraction-playbook - identities/dataset-discovery-quickstart ``` Les agents déclarent leurs portées, et les compétences sont attribuées automatiquement : ```yaml # Agent definition scopes: [database, research] # Gets: all database skills + all research skills + universal skills ``` ### Phase 5 : matérialisation Les compétences ne vivent pas en YAML en production. Elles sont rendues en fichiers SKILL.md que Claude Code peut charger : ```bash uv run orkestra sync ``` Cette commande : 1. Lit toutes les définitions YAML de compétences 2. Les rend via des templates Jinja 3. Écrit les fichiers SKILL.md dans `.claude/skills/` 4. Organise par palier K (foundations/, identities/, domains/, stacks/, project/) La structure de sortie finale : ``` .claude/skills/ ├── foundations/ # K0: Universal ├── identities/ # K1: Discipline ├── domains/ # K2: Subject ├── stacks/ # K3: Technology ├── project/ # K4: Organization └── vendor/ # External skills ``` ## Le schéma des portées dormantes L'un de nos schémas les plus puissants est celui des compétences « adoptées mais non chargées ». Nous appelons cela des portées dormantes. Prenez les compétences de calcul scientifique du dépôt k-dense-scientific. Nous avons adopté plus de 120 compétences couvrant la bio-informatique, la chimie, l'informatique quantique et l'informatique clinique. Mais la plupart de nos agents n'ont pas besoin d'amarrage moléculaire ni d'analyse d'expression génique. Au lieu de charger les 120 compétences dans chaque agent (ce qui gonflerait les fenêtres de contexte), nous : 1. **Adoptons** les compétences avec une portée spécifique (par exemple, `bioinformatics`) 2. Les gardons **dormantes** — enregistrées mais non chargées 3. Les **activons** seulement quand un agent déclare cette portée ```yaml # In scopes.yaml - dormant scope bioinformatics: description: "Bioinformatics and genomics" primary_skills: [] # Empty - skills exist but aren't loaded # When an agent needs bioinformatics: # Agent YAML scopes: [research, bioinformatics] # Now loads bioinformatics skills ``` Ce schéma nous permet d'avoir 466 compétences dans le registre, tandis qu'un agent typique n'en charge que 40 à 60 pertinentes. ## Types de compétences Les compétences suivent trois schémas cognitifs : ### Flux de travail Des étapes procédurales ordonnées : « 1. Faire X, 2. Puis Y, 3. Enfin Z » ```yaml type: workflow # Examples: schema-migration-workflow, mining-session-workflow ``` ### Discipline Des garde-fous comportementaux : « Toujours X », « Jamais Y », « Préférer Z » ```yaml type: discipline # Examples: test-first-discipline, evidence-based-completion ``` ### Liste de vérification Des critères de vérification : « Confirmer X », « Vérifier Y », « Contrôler Z » ```yaml type: checklist # Examples: auth-validation-checklist, secrets-audit-checklist ``` ## Contrôles qualité Chaque compétence doit passer une validation avant de partir en production : ```yaml validation: file_exists: true # Skill file at declared path frontmatter_valid: true # Frontmatter parses correctly sections_complete: true # Expected sections present tools_registered: true # Declared tools exist in registry ``` Les descriptions doivent compter de 50 à 400 caractères, avec des phrases de déclenchement (« À utiliser quand... », « Quand vous avez besoin de... ») pour que Claude Code sache quand les suggérer. Nous validons en continu : ```bash uv run orkestra validate --show-warnings ``` ## L'écosystème d'éditeurs Nos 373 compétences d'éditeurs viennent de : | Fournisseur | Compétences | Domaine | |----------|--------|--------| | AWS Agent | 19 | Services cloud | | Anthropic | 12 | Génération de documents | | Cloudflare | 8 | Edge computing | | Supabase | 5 | Base de données | | k-dense | plus de 100 | Calcul scientifique | | silvainfm | 4 | Data science | | Java Developer Kit | plus de 45 | Spring/Java | | Vercel | 1 | Automatisation navigateur | Chaque racine d'éditeur est déclarée dans metadata.yaml : ```yaml vendor_roots: - path: vendor/aws-agent-skills provider: aws - path: vendor/k-dense-scientific/scientific-skills provider: k-dense - path: vendor/supabase-skills provider: supabase ``` Quand `orkestra sync` s'exécute, les compétences d'éditeurs sont liées par symlink dans `.claude/skills/vendor/` avec leur espace de noms fournisseur. ## Ce que nous avons appris **La sélectivité paie.** Il est tentant d'adopter tout ce qui paraît utile. Mais chaque compétence coûte des tokens. Avec 2 834 tokens en moyenne par compétence, le gonflement fait mal vite. Notre taux d'adoption de 13 % garde les agents légers. **La structure permet la découverte.** Le système de paliers K n'est pas qu'une question d'organisation — c'est une question de portabilité. Les compétences K0 sont réutilisables partout. Les compétences K4 sont intentionnellement propres au projet. Cette clarté aide les humains comme les agents à trouver ce dont ils ont besoin. **Les portées dormantes passent à l'échelle.** Vous pouvez adopter des centaines de compétences sans toutes les charger. Les portées vous permettent de construire un registre exhaustif tout en gardant maniables les fenêtres de contexte de chaque agent. **La modification lors de l'adoption est essentielle.** Les compétences brutes d'éditeurs correspondent rarement à votre système. Le processus d'ingestion — ajouter des métadonnées, attribuer des paliers, enrichir les tags — fait fonctionner les compétences externes en interne. **L'extraction est continue.** Le chiffre de 3 500 continue de croître. De nouveaux dépôts d'éditeurs apparaissent. Des schémas communautaires émergent. Des flux de travail internes se solidifient. La boucle ne s'arrête jamais. ## Et ensuite Nous travaillons sur plusieurs améliorations : 1. **Détection automatisée d'écarts** : alerter quand des échecs courants d'agents pourraient être résolus par une compétence non adoptée 2. **Flux de travail de dépréciation des compétences** : un processus formel pour retirer les compétences supplantées ou inutilisées 3. **Dépendances entre compétences** : déclaration explicite des prérequis d'une compétence 4. **Analytique d'usage** : suivre quelles compétences les agents invoquent réellement, par opposition à celles qu'ils se contentent de charger La boucle d'extraction de compétences est de l'infrastructure. Ce n'est pas glamour. Mais c'est ce qui fait que 41 agents travaillent de façon cohérente avec 466 capacités, tout en restant dans les limites de contexte. Voilà l'histoire de comment 3 500 devient 466. Pas en ignorant 3 000 — en les évaluant systématiquement et en n'adoptant que ce qui fonctionne. --- *Vous voulez voir le système de compétences en action ? Consultez `uv run orkestra skills list` pour explorer notre registre actuel.*