Comment les skills dérivent

Une équipe travaillait sur plusieurs dépôts produit. Elle avait passé les sessions de refinement du trimestre précédent à façonner sa skill de revue de code, en ajoutant des vérifications sur les stratégies de rollback des migrations et d'autres conventions décidées en réunion. La skill à jour vivait dans un seul dépôt. Des copies plus anciennes traînaient dans les autres, jamais rafraîchies depuis leur copier-coller des mois plus tôt. Un ingénieur arrivé dans l'équipe après ces sessions relisait des merge requests dans l'un des dépôts qui contenait encore l'ancienne skill. La skill ressemblait au standard actuel de l'équipe. C'était celui du trimestre précédent.

Personne n'avait tort. Le nouvel arrivant exécutait la version de la skill présente dans le dépôt qu'on lui avait confié. Les standards avaient été décidés en réunion et commités dans un seul dépôt. Les autres gardaient l'ancienne version. La pratique actuelle vivait chez les membres de l'équipe présents en réunion. Les dépôts gardaient celle du trimestre précédent. Le nouvel arrivant travaillait sur celle d'hier.

Ce n'est pas un problème nouveau. Les configs d'éditeur dérivent, les règles de lint dérivent, les formateurs dérivent. Si cela compte davantage pour Claude Code, c'est que l'artefact n'est plus cosmétique. Une skill change le code que Claude écrit. Un subagent change les outils qu'il peut appeler. Un hook change ce qui s'exécute autour de chaque appel d'outil. Quand les setups de l'équipe divergent entre dépôts, les sorties du modèle divergent avec eux, et vous le découvrez la prochaine fois que l'équipe change de dépôt.

Pourquoi le partage de dotfiles échoue ici

Quatre schémas reviennent dans les équipes qui utilisent Claude Code sur plusieurs dépôts. Pris isolément, ils n'ont rien de surprenant. Ce qui surprend, c'est qu'ils ont tous le même remède.

La dérive entre coéquipiers. La même skill, deux versions, aucun diff à comparer. Les recommandations se contredisent. Le lead devient la source de vérité humaine, ce qui signifie que la connaissance est à une démission près de devoir être reconstruite.

Le coût d'onboarding. Un nouvel ingénieur arrive en cours de mission et reconstitue le setup de l'équipe en remontant l'historique du chat et en demandant : « quelles skills utilisez-vous ? » Il n'y a pas de bundle canonique à installer. Le premier jour est artisanal.

Des skills liées à un dépôt de projet. Une skill utile écrite pour le projet A devient une friction pour le projet B. Réutiliser signifie copier des fichiers, corriger des chemins relatifs et se rappeler quelle version est la bonne. L'infrastructure IA de l'équipe finit façonnée par le projet où chaque pièce a été écrite, pas par la pratique collective de l'équipe.

Aucune gouvernance. Quelqu'un ajoute un hook qui lance un scanner de secrets avant chaque écriture de fichier. Utile. Mais jamais relu. Deux semaines plus tard, vous découvrez que la regex a un faux négatif, et qu'un autre coéquipier laisse tranquillement fuiter des valeurs à travers.

Une marketplace de plugins règle les quatre. La marketplace est un dépôt git. Chaque artefact vit dans le code, chaque changement passe en revue, chaque coéquipier lance /plugin marketplace update et obtient les mêmes versions. Le schéma n'est pas nouveau : les équipes qui rencontrent ces problèmes construisent souvent une version maison (un dépôt de dotfiles partagé, un script d'installation, un wiki de conventions). La marketplace en est le mécanisme formel.

Marketplace vs dépôt

Une séparation claire des responsabilités en découle. Les skills, subagents et hooks encodent « comment l'équipe travaille » et restent constants à travers les projets qu'elle touche. Leur place est dans la marketplace : agnostiques au projet, installés une fois, disponibles partout. Les rules encodent « ce qu'est ce système » (la stack technique, la structure des fichiers, les conventions de ce dépôt) et leur place est dans le dépôt du projet, dans son propre répertoire .claude/.

L'erreur commode est de mettre une skill utile dans le dépôt du projet où vous l'avez écrite. La skill cesse d'être réutilisable, accumule des hypothèses propres au projet et impose un copier-coller au projet suivant. Le temps d'avoir deux projets, vous avez deux copies. Elles dérivent l'une de l'autre pour la même raison que tout artefact partagé dérive : il n'y a pas de source canonique.

La marketplace prévient l'erreur en donnant aux « artefacts d'équipe » un foyer distinct des « artefacts de projet ». Une skill qui vit dans la marketplace s'utilise sur chaque codebase de l'équipe sans modification. Une rule qui vit dans un dépôt de projet reste là où on en a besoin, limitée au système qu'elle décrit.

Ce qui reste humain

La marketplace donne à l'équipe un setup IA versionné et relisible. Ce qu'on y met reste une affaire d'équipe.

Un bundle relu vaut mieux que des copies qui dérivent. L'équipe peut voir ce qu'il contient. C'est ce qui lui permet d'y réfléchir.

Cet argument n'est pas propre à Claude. La même séparation s'applique à tout CLI agentique : conventions d'équipe dans un bundle versionné et agnostique au projet ; règles de projet dans le dépôt. Claude Code en est une implémentation, ergonomique et facile à livrer. Des outils comme opencode permettent d'aller plus loin en routant différentes parties du workflow vers différents LLM : un modèle moins cher pour les commits de routine, un meilleur raisonneur pour la revue d'architecture, un modèle local pour le code sensible. L'architecture reste la même. L'implémentation devient plus granulaire et plus hyper-optimisée.

Si votre équipe compte trois personnes ou plus utilisant des assistants de code IA, vous avez un problème de dérive, que vous l'ayez nommé ou pas. Publiez une marketplace. Le gain dépasse la cohérence : c'est une source de vérité unique sur la façon dont l'équipe travaille, accessible à quiconque sait lancer une commande. Ce qui était quatre assistants différents sur quatre machines différentes devient un bundle partagé. Versionné. Relisible. Installé une fois.