ConcluantEXP-01iones lab
Skills & MCP : outiller huit développeurs et mesurer ce que ça change
La questionUn outillage IA partagé (skills et serveurs MCP) améliore-t-il réellement la productivité et la qualité d’une équipe, ou seulement celle de quelques développeurs déjà convaincus ?
Verdict
Le gain est réel et mesurable sur les tâches standard, à condition de cadrer strictement ce que les agents peuvent faire. Sans catalogue partagé, chacun réinvente ses règles et la qualité diverge.
DécisionAdopté pour toute l’équipe, avec un catalogue de skills versionné et des serveurs MCP en lecture seule par défaut.
- Statut
- Concluant
- Durée
- 8 semaines
- Équipe
- 8 développeurs, 1 lead technique
- Stack
- Cursor
- Claude Code
- MCP
- Redmine
- Postgres
- Playwright
- Git
−32 %temps sur les tâches standardCRUD, tests, migrations, sur 140 tickets
−18 %commentaires de revue par PRdont −41 % sur le style et la structure
+9 %temps sur les tâches complexesles 4 premières semaines, puis retour à l’équilibre
23skills au catalogueaprès 8 semaines, 6 écartées
Contexte
Chaque développeur de l’équipe utilisait déjà un assistant de code, chacun à sa manière : prompts personnels, règles dans un coin de dépôt, outils différents. Résultat : des gains individuels visibles, mais impossible à généraliser, et des revues de code où l’on retrouvait les mêmes écarts de style d’un développeur à l’autre. Le lab a posé la question autrement : que se passe-t-il quand l’outillage est partagé, versionné et mesuré ?
Ce qu’on a testé
Nous avons construit deux briques et les avons déployées pour les huit développeurs d’une équipe BUILD sur deux projets clients réels, pendant huit semaines.
- Un catalogue de skills versionné dans un dépôt commun : conventions de code, gabarits de migration, procédure de revue, génération de tests, rédaction de tickets, chacun documenté et relu par le lead.
- Cinq serveurs MCP branchés sur nos outils : Redmine (lecture des tickets), Postgres (schéma et requêtes en lecture seule), Playwright (tests de bout en bout), documentation projet, et Git.
- Deux périodes de mesure : quatre semaines sans le catalogue (chacun ses outils), quatre semaines avec, sur des tickets de complexité comparable classés à l’avance.
Nous avons mesuré le temps passé par ticket (déclaré dans Redmine), le nombre et la nature des commentaires de revue par pull request, et recueilli chaque semaine le ressenti de l’équipe sur une échelle simple.
Résultats
−32 %
temps sur les tâches standard
−18 %
commentaires de revue par PR
+9 %
temps sur les tâches complexes (4 premières semaines)
7 / 8
développeurs souhaitant conserver l’outillage
Sur les tâches standard, le gain est net et homogène. Un écran CRUD, une migration, une série de tests : un tiers de temps en moins, et surtout un écart entre développeurs qui se resserre. Les développeurs les moins à l’aise avec l’IA au départ sont ceux qui ont le plus progressé, parce que le catalogue leur donnait un cadre.
Sur les tâches complexes, nous avons d’abord perdu du temps. Les quatre premières semaines, les tickets d’architecture ou de correction subtile ont pris 9 % de plus : l’équipe cherchait à faire faire à l’agent ce qu’il fallait faire soi-même, puis relisait tout. L’écart s’est refermé quand nous avons documenté explicitement dans quels cas ne pas utiliser l’agent.
- Les commentaires de revue sur le style et la structure ont chuté de 41 %. Les commentaires sur la logique métier n’ont pas bougé : l’outillage uniformise la forme, pas le fond.
- Le serveur MCP Postgres en lecture seule a été le plus utilisé : comprendre un schéma sans ouvrir un client SQL fait gagner du temps à tout le monde.
- Six skills sur vingt-trois ont été retirées du catalogue : trop génériques, ou contredisant une convention de projet. Un catalogue vit s’il est élagué.
- Une tentative de serveur MCP en écriture sur Redmine a été abandonnée après deux tickets modifiés par erreur. Lecture seule par défaut, sans exception.
“Avant, l’agent faisait ce que je lui demandais. Avec le catalogue, il fait ce que l’équipe a décidé. C’est moins spectaculaire et beaucoup plus utile.”
Ce qu’on en conclut
L’outillage IA d’une équipe n’est pas une somme d’outils individuels, c’est une convention partagée. Le gain vient moins de la puissance des modèles que du fait que tout le monde leur donne les mêmes règles, les mêmes accès, et les mêmes limites. C’est un travail de lead technique, pas de prompt.
Le coût d’adoption est réel : environ trois jours de lead pour construire le catalogue, et une demi-journée par développeur. Il est amorti en moins d’un mois sur une équipe de huit. Nous n’avons en revanche constaté aucun gain sur ce qui fait la valeur d’un développeur senior : comprendre le besoin, choisir l’architecture, repérer le cas limite.
Et maintenant
- Le catalogue de skills est déployé sur toutes nos équipes BUILD et RUN, avec revue mensuelle et retrait des skills inutilisées.
- Les serveurs MCP sont en lecture seule par défaut ; toute ouverture en écriture passe par une décision du lead et une branche isolée.
- Ce protocole nous sert désormais de base pour accompagner les clients qui veulent outiller leurs propres équipes.