Repo-to-Skill : et si vos dépôts de code devenaient la bibliothèque de compétences de vos agents IA ?

Vos agents IA ont besoin de compétences pour bien faire leur travail : un fichier SKILL.md qui décrit la procédure à suivre, des références pour aller plus loin, des scripts à exécuter. Ce format s'est imposé en quelques mois. Mais une question reste suspendue au-dessus de chaque déploiement : qui écrit toutes ces compétences ? Quand l'équipe rédige sa dixième skill à la main, tout va bien. À la centième, avec des centaines de dépôts, de runbooks et d'API métier à transformer en connaissance opérationnelle réutilisable, l'approche manuelle s'effondre.

Le 2 septembre 2026, la Beijing Academy of Artificial Intelligence (BAAI) a publié sur arXiv « Repo-To-Skill: Distilling GitHub Repositories Into AI4AI Skills ». Le papier présente DisCo, un pipeline qui distille automatiquement des dépôts de code et des papiers de recherche en « skills » vérifiées — exactement cette connaissance opérationnelle qui manque aux agents autonomes. Le résultat : l'AREX-Skill Library, plus de 5 000 compétences distillées de 1 000 dépôts de machine learning, organisées en 20 domaines et 178 familles de capacités.

Le chiffre qui fait lever les sourcils en comité d'architecture : sur les 75 compétitions de MLE-bench, un agent GPT-5.5 passe de 31,1 % à 72,9 % de score une fois équipé de ces compétences distillées — +134,3 % en relatif, sans modifier un seul poids du modèle. Derrière le résultat de recherche se cache une question très concrète pour toute entreprise qui industrialise ses agents : et si vos dépôts de code interne devenaient votre bibliothèque de compétences agentiques ?

1. Le point aveugle des Skills agentiques : qui écrit les centaines de compétences dont vos agents ont besoin ?

Dans notre article de mars, Skills vs MCP : quand utiliser l'un, quand utiliser l'autre ?, nous expliquions comment choisir entre deux patterns d'extension : un Skill encode une façon de raisonner et d'agir, un MCP server donne accès à des systèmes externes. Cet article tranchait un choix d'architecture. Il laissait ouverte une question de production : qui écrit ces Skills ?

Fabriquer une skill, ce n'est pas écrire un prompt au café : c'est extraire la connaissance opérationnelle d'un expert, la structurer en procédure vérifiable, la documenter, la maintenir. Quelques heures de travail par compétence, réalisées par vos profils les plus chers. Or un agent en production a besoin de compétences par centaines : une par domaine métier, une par type de procédure, une par intégration.

Pour rendre le problème tangible : une équipe plateforme qui veut équiper son agent de déploiement avec la connaissance de 50 runbooks internes fait vite le calcul — même à deux heures par runbook, ce sont 100 heures d'un ingénieur senior avant que l'agent sache correctement diagnostiquer un incident de prod. Multipliez ce calcul par les dépôts applicatifs, les API métier et les procédures de conformité, et l'approche manuelle ne tient plus. (Ce chiffrage est une illustration, pas une donnée du papier BAAI.)

À l'échelle d'un patrimoine de code interne — dépôts applicatifs, runbooks d'exploitation, API métier — la question n'est plus « comment écrire une bonne skill ? » mais « qui fabrique nos skills, à quel coût, avec quelle gouvernance ? ». C'est cette question, jamais posée jusqu'ici, que Repo-To-Skill attaque frontalement : après le choix du format, voici la chaîne de fabrication.

2. Repo-To-Skill (BAAI) : distiller un dépôt de code en compétence vérifiée, sans intervention humaine

DisCo, le pipeline présenté par les chercheurs de la BAAI, transforme un dépôt de code (ou un papier de recherche) en compétences vérifiées selon quatre étapes :

Scoping : restreindre le périmètre de ce qui mérite d'être distillé dans le dépôt — tout ne vaut pas la peine d'être transformé en compétence.
Ancrage dans des preuves : chaque affirmation écrite dans une skill doit pointer vers une preuve dans la source — le code, la documentation, les résultats du papier. Pas de connaissance flottante.
Construction d'un graphe de compétences : les compétences sont organisées en 20 domaines et 178 familles de capacités, pour pouvoir les retrouver et les composer.
Vérification : chaque compétence est vérifiée avant d'intégrer la bibliothèque — une skill fausse ou obsolète ne rentre pas.

Le résultat est l'AREX-Skill Library : plus de 5 000 compétences distillées de 1 000 dépôts de machine learning. Le dépôt GitHub VectorSpaceLab/AREX-Skill a dépassé 240 étoiles quelques jours après sa publication et figure dans les tendances GitHub — signe que la communauté a immédiatement compris l'enjeu.

3. Même format que vos Skills Claude : SKILL.md, références, scripts — et une disclosure progressive pensée pour l'échelle

Détail qui change tout pour une entreprise : chaque compétence produite suit une structure SKILL.md + références + scripts. C'est structurellement le même format que celui que nous recommandons déjà pour vos Skills — pas un format propriétaire à faire transiter dans votre SI, mais directement compatible avec la façon dont vos agents chargent déjà leurs instructions.

L'innovation d'architecture tient dans la disclosure progressive. Un routeur restreint d'abord la requête de l'agent à un domaine, puis à une famille, puis à un dépôt, puis à un flux de travail ; l'agent ne charge ensuite que la branche dont il a besoin. Concrètement : face à 5 000 compétences, l'agent n'a jamais en contexte que la poignée de fichiers pertinents pour sa tâche courante.

C'est cette architecture qui rend crédible une bibliothèque à l'échelle de milliers de compétences sans saturer le contexte du modèle — le point qui tue la plupart des bases de connaissances agentiques dès qu'elles grossissent. Une procédure encodée en début d'année se retrouve par son domaine et sa famille, pas en parcourant un prompt système de 200 pages.

4. Les chiffres qui comptent : +134 % sur MLE-bench, jusqu'à +367 % sur les tâches les plus difficiles

L'évaluation porte sur MLE-bench, un benchmark de 75 compétitions de machine learning. Un agent GPT-5.5 est évalué sans puis avec l'AREX-Skill Library :

Périmètre	Sans compétences distillées	Avec AREX-Skill	Gain relatif
75 compétitions MLE-bench	31,1 %	72,9 %	+134,3 %
Tâches les plus difficiles	13,3 %	62,2 %	+366,8 %

Deux lectures. D'abord, l'ampleur : doubler le score d'un agent, et le multiplier par presque cinq sur les tâches les plus difficiles, c'est le genre de saut qu'on attend d'un changement de modèle — pas d'un changement de documentation. Ensuite, la méthode : aucun poids du modèle n'a été modifié. L'intégralité du gain vient de ce que l'agent sait charger, et à quel moment.

C'est la démonstration la plus nette à ce jour d'une thèse que nous défendons chez Brainum : la connaissance opérationnelle est un levier de performance distinct du modèle lui-même. Vous n'êtes pas obligé d'attendre le prochain frontier model pour transformer vos agents ; vous devez leur donner accès à la bonne connaissance, au bon moment, dans un format vérifié.

5. Le coût réel : ~40 $ par dépôt distillé, un investissement ponctuel séparé du coût d'exécution

La construction de la bibliothèque coûte environ 40 $ par dépôt distillé — un investissement ponctuel, séparé du coût d'exécution des agents. À mettre en regard des heures d'expert qu'exige l'écriture manuelle d'une seule compétence, et des niveaux de rémunération qui vont avec.

Le calcul devient vite parlant : distiller un patrimoine de 100 dépôts internes représente quelques milliers de dollars d'investissement ponctuel — le budget d'une semaine d'un ingénieur senior — là où l'écriture manuelle des mêmes compétences mobiliserait des mois de vos experts. Et contrairement à un projet de documentation classique, le produit est directement exploitable par vos agents, dans un format vérifié et organisé.

C'est le rapport coût/résultat qui rend le sujet industriel et pas seulement académique : 40 $ par dépôt pour transformer du code qui dort dans votre GitLab en connaissance opérationnelle que vos agents savent mobiliser.

6. Grille de décision DSI : quel patrimoine interne (code, runbooks, API) mérite d'être distillé en premier

Une fois le rapport coût/bénéfice établi, reste une question opérationnelle : par où commencer ? Si la méthode tient ses promesses, la première décision ne revient pas à l'IA mais à vous : quel patrimoine distiller en premier. Quatre critères de priorisation :

Critère	Question à se poser	Signal de priorité
Fréquence d'usage	La tâche revient-elle chaque jour ou chaque semaine ?	Plus la tâche est fréquente, plus la compétence amortit vite
Stabilité	La procédure est-elle stabilisée et documentée ?	Un runbook stable est un candidat idéal à la distillation
Coût d'erreur	Que coûte un échec de l'agent sur cette tâche ?	Coût élevé = vérification renforcée, pas d'exclusion
Vérifiabilité	Peut-on vérifier la compétence contre une preuve (tests, logs, docs) ?	Oui = distillable et gouvernable

Trois familles d'actifs ressortent typiquement : les dépôts de code (connaissance d'implémentation, conventions, procédures de build et de déploiement), les runbooks (procédures d'exploitation et de diagnostic, souvent disparates et tributaires de leurs auteurs), et les API métier (règles de gestion encapsulées dans des services que personne n'ose plus toucher). Dans les trois cas, la logique est la même : la connaissance existe déjà dans votre patrimoine — il manque la chaîne qui la transforme en compétences exploitables par vos agents.

7. Comment Brainum construit et gouverne votre bibliothèque de compétences agentiques internes

Le choix du format — Skills ou MCP — est une décision d'architecture que vous pouvez trancher en interne. Construire, vérifier et gouverner la chaîne de fabrication à l'échelle de centaines, voire de milliers de compétences, est un autre métier. C'est là que nous intervenons.

Chez Brainum, nous construisons et gouvernons des bibliothèques de compétences à partir de votre patrimoine de code, de vos runbooks et de vos API internes :

Distillation de vos dépôts et procédures en compétences au format SKILL.md + références + scripts, compatible avec vos agents existants.
Disclosure progressive pour maîtriser le coût de contexte à l'échelle : routeur par domaine et famille, chargement à la demande, contexte qui ne sature pas quand la bibliothèque grossit.
Gouvernance : chaque compétence est ancrée dans des preuves et vérifiée avant d'intégrer la bibliothèque ; les évolutions sont versionnées et validées — une bibliothèque de compétences est un actif gouverné, pas un dossier de prompts.

Question à vous poser dès cette semaine : combien de vos runbooks, dépôts internes et procédures métier pourraient devenir des compétences agentiques réutilisables dès aujourd'hui ? La réponse se compte en jours, pas en mois.

Pour aller plus loin

arXiv — Repo-To-Skill: Distilling GitHub Repositories Into AI4AI Skills (2609.02749) : le papier de la BAAI présentant DisCo et l'AREX-Skill Library.
Hugging Face — Paper page: Repo-To-Skill : la page du papier et les discussions de la communauté.
GitHub — VectorSpaceLab/AREX-Skill : la bibliothèque de compétences et le pipeline.
Brainum — Skills vs MCP : quand utiliser l'un, quand utiliser l'autre ? : notre article de mars sur le choix du format, dont cet article est la suite logique.

Vous voulez transformer vos dépôts, runbooks et procédures en bibliothèque de compétences agentiques gouvernée ? Discutons de votre patrimoine.