Outiller une équipe de dev avec l’IA : un catalogue de skills partagé

Quand chaque développeur a ses propres prompts, l’agent de code produit autant de styles qu’il y a de personnes. Un catalogue de skills IA partagé, versionné dans le dépôt et gouverné par le lead technique, change la donne. Voici comment le structurer, le brancher sur votre SI sans risque, le mesurer, et savoir quand ne pas utiliser l’agent.

Le problème : huit développeurs, huit façons de prompter

Dans la plupart des équipes, l’adoption des agents de code s’est faite par le bas : chacun a trouvé ses formulations, ses astuces, ses fichiers de contexte personnels. Résultat : l’agent écrit des tests dans trois styles différents, nomme les migrations selon l’humeur du jour, et les relecteurs passent leurs revues à corriger la forme plutôt qu’à vérifier le fond. Le savoir-faire reste dans des historiques de conversation que personne ne relira.

Les études disponibles invitent à la prudence. Un essai contrôlé de METR, mené début 2025 sur 16 développeurs open source expérimentés, a mesuré qu’ils mettaient 19 % de temps en plus avec les outils d’IA, alors qu’ils pensaient avoir gagné du temps [1]. Le rapport DORA 2025 décrit l’IA comme un amplificateur des forces et des faiblesses d’une organisation, et range parmi les capacités qui en démultiplient l’effet une position claire et communiquée sur l’IA et l’accès de l’IA aux données internes [2][3]. Un catalogue de skills partagé traite précisément ces deux points.

C’est ce que nous avons testé dans l’expérience EXP-01 du iones lab (fiche EXP-01) : 8 semaines, 8 développeurs et 1 lead de l’équipe BUILD, sur 2 projets clients, avec un catalogue de skills versionné et 5 serveurs MCP.

Ce qu’est un skill, et ce que ce n’est pas

Le format Agent Skills

Un skill est un dossier qui contient au minimum un fichier SKILL.md : un en-tête YAML avec un nom et une description, puis des instructions en Markdown. Le dossier peut embarquer des scripts, des documents de référence et des modèles de fichiers [4]. Le format a été conçu par Anthropic, présenté en octobre 2025, puis publié comme standard ouvert en décembre 2025 [5] ; il est aujourd’hui reconnu par de nombreux outils, dont Claude Code, Cursor, GitHub Copilot, Codex et Gemini CLI, selon la liste tenue sur le site du standard.

Le mécanisme clé est la divulgation progressive : au démarrage, l’agent ne charge que le nom et la description de chaque skill (de l’ordre de 100 tokens) ; il ne lit les instructions complètes que lorsque la tâche correspond, et les fichiers annexes seulement si nécessaire [4]. Vous pouvez donc maintenir des dizaines de skills sans saturer le contexte.

Skills, règles de projet, AGENTS.md : qui fait quoi

Sources : documentation Claude Code [6][7] et Cursor [8][9]. AGENTS.md est un format ouvert, désormais hébergé par l’Agentic AI Foundation sous l’égide de la Linux Foundation [10] ; Cursor le lit, et Claude Code le lit lorsqu’aucun CLAUDE.md n’est présent [7].

À retenir : ces fichiers sont du contexte, pas une configuration contraignante. La documentation de Claude Code le dit explicitement et renvoie, pour bloquer une action quoi qu’il arrive, vers les hooks et les règles de permission [7]. Un skill guide ; une interdiction se configure.

Anatomie d’un skill : un exemple complet

Exemple pour un projet Symfony, versionné avec le code :

.claude/skills/migration-doctrine/
├── SKILL.md
├── references/
│   └── conventions-bdd.md
└── scripts/
    └── verifier-migration.sh

---
name: migration-doctrine
description: Crée et vérifie une migration Doctrine selon les conventions du projet.
  À utiliser pour tout ajout ou modification de table, colonne, index ou contrainte.
---

## Étapes
1. Modifier l'entité, puis générer la migration avec `bin/console make:migration`.
2. Relire le SQL généré : une migration = un changement fonctionnel.
3. Toute colonne NOT NULL ajoutée à une table existante reçoit une valeur par défaut
   ou une migration de données séparée.
4. Nommer index et contraintes selon references/conventions-bdd.md.
5. Exécuter scripts/verifier-migration.sh (migration aller, retour, aller).

## Ne pas utiliser ce skill pour
- les changements de schéma touchant plus de trois tables : proposer un plan au lead ;
- les données de production : jamais d'exécution hors environnement local.

Quelques contraintes du standard à respecter [4] : le name fait au plus 64 caractères, en minuscules, chiffres et tirets, et doit correspondre au nom du dossier ; la description fait au plus 1 024 caractères et doit dire quoi et quand ; le SKILL.md reste sous 500 lignes, le détail va dans references/. La description est ce qui déclenche le skill : « aide pour la base de données » ne sera jamais choisie au bon moment.

Cinq familles de skills utiles

Dans EXP-01, le gain le plus net est venu des deux premières familles : les commentaires de revue sur le style et la structure ont baissé de 41 %. Le skill de rédaction de tickets a un effet indirect : un ticket bien écrit est un meilleur point de départ, pour un humain comme pour l’agent.

Brancher le SI : des serveurs MCP en lecture seule

Un skill dit comment faire ; un serveur MCP donne accès aux informations. Dans EXP-01, l’équipe a utilisé 5 serveurs MCP : Redmine en lecture, PostgreSQL en lecture seule, Playwright, la documentation du projet et Git. Un serveur MCP en écriture sur Redmine a, lui, été abandonné après avoir modifié 2 tickets par erreur. Depuis, notre règle est simple : lecture seule par défaut, écriture seulement sur justification et avec validation humaine.

La lecture seule doit être garantie à la source, pas par une consigne. La spécification MCP 2026-07-28 précise d’ailleurs que les annotations d’outils doivent être considérées comme non fiables, sauf si elles viennent de serveurs de confiance [11].

-- Rôle PostgreSQL dédié à l'agent, sur une copie anonymisée
CREATE ROLE agent_ro LOGIN PASSWORD '***';
GRANT CONNECT ON DATABASE projet_dev TO agent_ro;
GRANT USAGE ON SCHEMA public TO agent_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO agent_ro;
ALTER ROLE agent_ro SET default_transaction_read_only = on;

Dans Claude Code, un fichier .mcp.json à la racine du dépôt déclare les serveurs partagés par l’équipe (portée « project ») ; l’outil demande une approbation avant d’utiliser ces serveurs en session interactive [12]. Même logique pour les jetons d’API : un jeton Redmine ou GitLab en lecture seule, propre à l’agent, révocable. Pour les évolutions récentes du protocole, voir notre article MCP : la spécification 2026-07-28.

Gouvernance : un catalogue vivant, un propriétaire

Un catalogue non gouverné redevient vite une collection de prompts individuels. Dans EXP-01, 6 skills ont été retirés en cours de route : trop génériques, ou contraires aux conventions de l’équipe. Élaguer fait partie du travail.

• Un propriétaire : le lead technique. Il arbitre, fusionne, retire.
• Tout passe par pull request, comme le code : un skill modifié est relu.
• Une revue mensuelle de 30 à 60 minutes avec l’équipe.
• Pas de doublons ni de contradictions : la documentation de Claude Code prévient qu’en cas de règles contradictoires, l’agent peut en choisir une arbitrairement [7].

Checklist de la revue mensuelle :

• [ ] Quels skills n’ont pas été déclenchés ce mois-ci ? À retirer ou à mieux décrire.
• [ ] Quels commentaires de revue reviennent encore ? Candidats à un nouveau skill.
• [ ] Un skill a-t-il produit un résultat contraire aux conventions ? À corriger ou à retirer.
• [ ] Les références (versions de framework, commandes) sont-elles à jour ?
• [ ] La section « ne pas utiliser pour » reflète-t-elle les incidents du mois ?

Mesurer l’impact

Mesurez avant de déployer, sur les mêmes catégories de tickets, puis pendant au moins huit semaines. Les résultats d’EXP-01 :

Deux indicateurs suffisent pour commencer : le temps par ticket, ventilé entre tâches standard et complexes, et les commentaires de revue par PR, classés entre forme et fond. Ajoutez un signal qualitatif : les développeurs veulent-ils garder l’outil ? Une développeuse senior de l’équipe BUILD l’a résumé ainsi : « Avant, l’agent faisait ce que je lui demandais. Avec le catalogue, il fait ce que l’équipe a décidé. »

Quand ne pas utiliser l’agent

Le chiffre le plus instructif d’EXP-01 est peut-être le +9 % de temps sur les tâches complexes au début. L’équilibre n’est revenu qu’après avoir documenté quand ne pas utiliser l’agent. Et nous n’avons mesuré aucun gain sur la compréhension du besoin, l’architecture ou les cas limites.

Notre liste, intégrée au catalogue :

• besoin ambigu ou ticket incomplet : clarifier avec le métier d’abord ;
• décision d’architecture ou choix de dépendance structurante ;
• code de sécurité (authentification, droits, cryptographie) : l’agent peut assister, la conception reste humaine ;
• cas limites de logique métier que personne n’a encore formulés ;
• tout ce qui touche la production.

Pour les agents qui agissent de manière plus autonome, les règles se durcissent : voir nos garde-fous des agents IA autonomes.

Coût d’adoption et plan sur huit semaines

Dans EXP-01, l’adoption a coûté environ 3 jours de lead et une demi-journée par développeur, soit environ 7 jours-personne pour une équipe de 8, amortis en moins d’un mois.

Questions fréquentes

Passer des prompts individuels au catalogue d’équipe

Un catalogue de skills transforme des habitudes individuelles en décisions d’équipe : versionnées, relues, mesurées. Commencez par les tâches répétitives, gardez le SI en lecture seule, nommez un propriétaire, mesurez avant et après, et documentez dès le départ quand ne pas utiliser l’agent.

Pour cadrer cette démarche avec vos équipes, découvrez notre accompagnement en stratégie et acculturation IA ; pour renforcer une équipe déjà outillée, nos développeurs dédiés travaillent avec ces méthodes. Agence web ? Voyez aussi comment vendre des offres IA en marque blanche. Ou parlons de votre équipe : réponse sous 48 à 72 heures.