--- title: "Maintenir des compétences sur plusieurs dépôts · SourceAnt" description: "Comment partager des compétences d'agent sans perdre le contrôle des mises à jour : compétences locales, épinglage Git, MCP, exceptions par dépôt et tests pour les instructions révisées." url: "https://sourceant.ai/fr/blog/maintain-skills-across-repositories/" --- [Tous les articles](https://sourceant.ai/fr/blog) 26 septembre 2026 · SourceAnt compétencesmcpcollaboration # Comment maintenir une compétence sur plusieurs dépôts Supposez que vous écrivez une compétence pour la revue des changements d'API. Elle demande à votre assistant de codage de vérifier les permissions, de préserver la compatibilité et de tester les requêtes rejetées. Elle fonctionne assez bien pour que vous la copiiez de votre dépôt de facturation vers votre service de comptes et votre API publique. Puis un relecteur découvre une vérification manquante. L'assistant a vérifié si un utilisateur était connecté, mais a omis de vérifier si cet utilisateur était propriétaire de l'enregistrement. Vous améliorez la compétence dans la facturation. Les deux autres copies contiennent encore les anciennes instructions. Vous pourriez copier à nouveau le correctif. Mais quelqu'un a déjà modifié la version de l'API publique pour gérer un client plus ancien. Remplacer ce fichier effacerait sa modification. Le laisser tel quel laisserait la vérification manquante. C'est ici que partager une compétence devient en maintenir une. Vous devez savoir quelles instructions sont partagées, quelles différences sont délibérées, et comment une amélioration parvient à ceux qui les utilisent. ## Décidez quand une mise à jour doit atteindre un dépôt Un emplacement partagé répond à la question de savoir où vit la compétence. Il ne répond pas à la question de savoir quand quelqu'un doit commencer à utiliser un changement. Pour une compétence de rédaction, vous pourriez vouloir que tout le monde reçoive des instructions plus claires dès sa prochaine tâche. Pour une compétence de publication, vous pourriez vouloir que chaque dépôt examine une nouvelle procédure avant de l'utiliser. Aucune de ces politiques ne convient à toutes les compétences. Il existe plusieurs façons de faire ce choix. ### Les compétences d'une seule personne sur plusieurs projets Si vous êtes le seul utilisateur, un répertoire de compétences personnel peut suffire. Claude Code, par exemple, prend en charge les compétences personnelles sur plusieurs projets au sein d'une même machine. Il prend également en charge des répertoires de compétences liés à un autre emplacement sur le disque. Ce sont des fonctionnalités documentées, donc copier une compétence dans chaque dépôt est inutile dans ce cas. Voir [les emplacements des compétences de Claude Code](https://code.claude.com/docs/en/skills#choose-where-skills-load). Un lien peut pointer plusieurs projets vers une copie locale unique. Il ne peut pas garder la machine d'un collègue à jour. Dès qu'une autre personne a besoin de la compétence, décidez comment elle obtient cette copie et ses mises à jour. ### Un dépôt Git partagé avec des mises à jour revues Conservez les compétences dans un dépôt séparé lorsque vous voulez que leur historique et leur processus de revue soient dans Git. Chaque projet consommateur peut inclure une révision choisie via un sous-module. Git enregistre un commit précis pour ce sous-module ; il ne suit pas silencieusement chaque changement du dépôt partagé. Voir [la documentation des sous-modules de Git](https://git-scm.com/book/en/v2/Git-Tools-Submodules). Cela donne au propriétaire d'un dépôt une décision claire : conserver les instructions actuelles ou adopter une révision plus récente. Cela ajoute aussi une tâche de mise à jour à chaque projet consommateur. Votre configuration doit placer la compétence là où l'outil de codage peut la découvrir, et les nouveaux clones doivent récupérer le contenu du sous-module. Choisissez cette approche lorsque pouvoir identifier et restaurer les instructions exactes compte plus que recevoir immédiatement chaque amélioration. Épingler les instructions ne rend pas la sortie du modèle identique, mais cela supprime une source de changement. ### Récupérez les instructions partagées lorsqu'elles sont nécessaires Une autre approche consiste à laisser l'outil de codage demander la compétence à un service partagé. MCP fournit une connexion par laquelle un outil peut récupérer ces instructions. Avec un service qui renvoie la version actuelle, une mise à jour peut atteindre la requête suivante sans modifier chaque dépôt. Cela échange un travail de mise à jour local contre une dépendance au service. Décidez ce qui se passe si une requête échoue. Si vous conservez une copie de secours, enregistrez d'où elle vient et quand elle a été mise à jour pour la dernière fois. Sinon, vous avez recréé le problème de la copie oubliée sous un autre nom. Ma recommandation est de choisir la politique de mise à jour avant l'outil de distribution. Utilisez des révisions revues pour les procédures qui nécessitent une adoption contrôlée. Récupérez les instructions actuelles lorsque l'équipe veut une version commune et à jour. Une équipe peut utiliser les deux pour des compétences différentes. ## Séparez la règle du détail propre au dépôt Même une distribution parfaite ne peut pas rendre une instruction propre à la facturation utile partout. Prenons cette instruction : > Exécutez les tests de l'API de facturation, puis vérifiez que les utilisateurs ne peuvent pas lire les factures d'un autre client. Elle contient une vérification réutilisable et des détails locaux. Séparez ces idées : > Pour chaque endpoint modifié qui accède à un enregistrement appartenant à un utilisateur, vérifiez à la fois la propriété et l'authentification. Trouvez la commande de test documentée du dépôt et testez la requête rejetée via l'endpoint. La compétence partagée décrit désormais ce qu'il faut vérifier. Le dépôt fournit sa commande de test et ses exemples de domaine. Cela ne signifie pas rendre chaque instruction vague. « Suivez les bonnes pratiques » ne donne pas grand-chose à faire à un assistant. « Vérifiez si un utilisateur authentifié peut accéder à l'enregistrement d'un autre utilisateur » nomme un échec précis tout en restant utile à travers les services. Un test de rédaction utile consiste à se demander si une phrase aurait encore du sens dans le second dépôt. Si elle nomme un script, un répertoire ou une cible de déploiement locaux, placez ce détail à côté du projet qui le possède. Indiquez à la compétence partagée où le chercher, et quoi faire s'il est absent. Vérifiez aussi ce que vous partagez. La [spécification Agent Skills](https://agentskills.io/specification) définit une compétence comme un répertoire, qui peut inclure des scripts, des références et des ressources à côté de `SKILL.md`. Un document qui renvoie à `scripts/check-api.py` est incomplet sans ce script. Déplacer le Markdown seul ne déplace pas ses dépendances. ## Traiter une dérogation comme une version distincte à maintenir Il arrive parfois que l'API publique ait réellement besoin d'instructions différentes. Ses anciens clients dépendent peut-être d'un champ de réponse que les services internes n'utilisent plus. Gardez cette exception étroite. Consignez pourquoi elle existe, qui en est responsable et ce qui permettrait de la supprimer. Lorsque c'est possible, conservez la procédure partagée et fournissez la contrainte locale séparément. Si votre outil remplace l'intégralité de la compétence lorsqu'il trouve une dérogation au niveau du référentiel, la dérogation devient une version supplémentaire à maintenir. Une correction apportée à la compétence partagée ne la atteindra pas nécessairement. Pour le contrôle de propriété de notre exemple, le mainteneur doit examiner les deux versions. La règle de compatibilité de l'API publique n'explique pas pourquoi il faudrait omettre un contrôle de propriété. Ce sont des préoccupations indépendantes. C'est également une raison d'éviter de remplacer une compétence entière simplement pour modifier une commande de test. Une petite différence locale ne devrait pas vous obliger à maintenir une seconde copie de chaque règle partagée. ## Tester une amélioration avant de la partager Une instruction qui semble plus claire peut néanmoins produire une revue de moindre qualité. Conservez quelques tâches réelles issues de référentiels qui utilisent la compétence, ainsi que le résultat attendu. Le [guide d'évaluation des compétences d'agent](https://agentskills.io/skill-creation/evaluating-skills) recommande de comparer des exécutions avec une compétence à une référence, qui peut être la version précédente. Utilisez des sessions neuves afin qu'une discussion antérieure ne fournisse pas des instructions que la compétence elle-même n'apporte pas. Jugez les résultats observables, plutôt que la question de savoir si la réponse semble approfondie. Pour la compétence de revue d'API, sélectionnez d'anciens changements réels couvrant ces cas : | Ancien changement à sélectionner | Ce qu'il faut rechercher dans la revue | | --- | --- | | Un bug de propriété connu | Identifie l'échec d'accès et pointe vers le code concerné | | Une correction qui applique déjà le contrôle de propriété | Reconnaît la protection au lieu de répéter l'ancienne conclusion | | Un changement impliquant le champ de réponse hérité | Respecte la contrainte de compatibilité documentée de l'API publique | | Un changement en dehors du comportement de l'API | Évite d'inventer des conclusions sur l'API pour satisfaire la liste de contrôle | Exécutez l'ancienne compétence et la compétence révisée sur les mêmes changements. Conservez ensemble les entrées, les instructions et les sorties. Si un résultat vous surprend, répétez la comparaison avant de décider que la modification a aidé. Le second cas compte autant que le premier. Une instruction qui pousse un assistant à accuser chaque point de terminaison d'absence de contrôle d'accès a augmenté le bruit, même si elle détecte le bug d'origine. Confiez à une personne ou à une équipe la responsabilité d'accepter les changements partagés. Les coéquipiers doivent pouvoir proposer des améliorations, mais quelqu'un doit décider si les preuves justifient d'en faire la version par défaut. ## Où se situe SourceAnt SourceAnt prend en charge l'approche du service partagé. Une compétence d'espace de travail est disponible dans ses référentiels. Les outils de codage connectés peuvent rechercher une compétence, la lire ou la demander via une invite MCP. La mise à jour de la compétence d'espace de travail modifie ce qu'une demande ultérieure récupère, sauf si ce référentiel possède une dérogation. Le [guide des compétences](https://sourceant.ai/fr/docs/skills) couvre la configuration et l'utilisation. Cela supprime la nécessité de maintenir un fichier d'instructions distinct à jour dans chaque copie de travail. Cela ne supprime pas la nécessité de tester les changements ou de maintenir des exceptions. Les dérogations de référentiel de SourceAnt remplacent la version de l'espace de travail ; elles n'y intègrent pas les modifications ultérieures. Les instructions déjà lues dans une conversation doivent également être demandées à nouveau après une mise à jour. SourceAnt via MCP Utiliser une compétence partagée depuis votre outil de codage 1. **Rechercher la compétence**Saisissez le préfixe. Chaque compétence de l'espace de travail est répertoriée avec sa fonction. /sourceant:skill - `**/sourceant:skill:**test-culture`Décrivez le framework de test, l'organisation et les limites visibles sans présumer de la couverture ni de la qualité. - `**/sourceant:skill:**contract-consistency`Vérifiez si des entrées, sorties, erreurs ou règles d'accès modifiées cassent des consommateurs existants. - `**/sourceant:skill:**duplicate-implementation`Vérifiez si le code nouvellement ajouté duplique un comportement existant et introduit un problème concret. 2. **Donnez-lui une tâche**Ajoutez ce sur quoi travailler. Nommez un référentiel pour utiliser sa propre version de la compétence, si elle existe. /sourceant:skill:contract-consistency tâche Examiner la modification du point de terminaison de facturation référentiel billing 3. **Travailler à partir de la version actuelle**SourceAnt envoie les instructions les plus récentes dans la conversation avec votre tâche jointe. Envoyé à l'assistant Appliquez la compétence de revue de cohérence des contrats à la tâche demandée. Suivez chaque contrat modifié depuis le code qui produit une valeur jusqu'au code qui l'utilise. 1\. Lisez les deux côtés. Comparez les entrées acceptées, les champs renvoyés, la gestion des erreurs et les contrôles d'accès. Référentiel : billing Tâche demandée : Examiner la modification du point de terminaison de facturation Affiché dans Claude Code. Les noms des invites dépendent de la connexion et des compétences disponibles. Commencez par une compétence que vous utilisez déjà dans deux référentiels. Comparez les copies. Déplacez les instructions véritablement partagées dans une version maintenue, et notez pourquoi les différences restantes existent. Avant de distribuer la prochaine modification, essayez-la sur une tâche réelle de chaque référentiel. Vous obtiendrez ainsi une réponse utile à la question que la copie seule ne peut pas trancher : les deux projets ont-ils bénéficié du changement ? ## Donnez à votre IA une mémoire de confiance À partir de $49 par mois, avec vos propres clés de modèle. Chaque ingénieur et chaque agent inclus, jamais par siège. [Commencer gratuitement](https://app.sourceant.ai/) [Voir les tarifs](https://sourceant.ai/fr/pricing)