Surveiller un skill en production¶

Un skill qualifié peut se dégrader sans qu'on y touche : le modèle change, un autre skill entre en concurrence pour le déclenchement, le type de tâches évolue. Ce chapitre propose un dispositif de surveillance, construit à partir des outils des parties précédentes. Contrairement aux chapitres qui précèdent, il ne décrit pas une pratique publiée : c'est une proposition de ce rapport, dont chaque brique est sourcée mais dont l'assemblage n'a pas été évalué.

Les trois cartes d'un skill¶

1. Le taux de déclenchement¶

La télémétrie de Claude Code émet un événement skill_activated (documentation). On peut donc compter, par jour ou par tranche de runs, la proportion de runs où un skill donné a été chargé.

Ce taux mélange deux choses : la fréquence des tâches pertinentes, et la probabilité que le skill se déclenche quand la tâche est pertinente. Pour les séparer, il faut un dénominateur : la proportion de runs dont la tâche relevait du skill. Deux façons de l'obtenir :

un classifieur de tâches indépendant (règles sur les mots-clés, ou modèle de petite taille), avec ses propres limites ;
un échantillon relu à la main chaque semaine (voir Échantillonnage).

On trace alors une carte p du taux de déclenchement parmi les tâches pertinentes, et une autre parmi les tâches non pertinentes (faux déclenchements).

2. Le respect des instructions¶

Pour un skill de discipline (« toujours lancer les tests avant de conclure », « ne jamais modifier /knowledge/site »), le respect est souvent vérifiable mécaniquement dans la trace du run : la commande a-t-elle été lancée, le fichier interdit a-t-il été touché ? Une carte p du taux de respect parmi les runs où le skill a été chargé détecte une dérive de discipline.

3. L'effet sur le résultat¶

C'est la carte la plus difficile. Il faut comparer le résultat des runs avec le skill à ceux sans, ce qui exige que le déclenchement ne soit pas parfait, ou qu'on désactive volontairement le skill sur une petite fraction des runs pertinents — une expérience contrôlée permanente au sens d'un test A/B. La taille d'échantillon nécessaire est celle du chapitre Mesurer un agent : plusieurs centaines de runs pour un effet de 10 points.

Pourquoi garder un témoin en production

Sans témoin, une baisse du taux de réussite des runs qui utilisent le skill ne dit pas si c'est le skill qui se dégrade ou les tâches qui se durcissent. Avec un témoin, les deux groupes subissent la même évolution des tâches, et seule la différence est attribuable au skill. C'est la recommandation des différences appariées d'Evan Miller transposée à la production.

Les événements qui doivent déclencher une requalification¶

Certains changements sont des causes spéciales connues à l'avance. Plutôt que d'attendre qu'une carte les détecte, on les traite comme on traite un changement d'outillage en usine : on requalifie.

Événement	Pourquoi	Ce qu'on relance
Changement de modèle	Le guide d'Anthropic demande de tester avec chaque modèle visé	Batterie d'exécution et de déclenchement
Ajout ou modification d'un autre skill	Concurrence entre descriptions	Batterie de déclenchement de toute la bibliothèque
Modification du skill lui-même	Changement de standard	Batterie complète, contre l'ancienne version comme ligne de base
Changement de l'environnement (outils, serveurs MCP)	Les instructions peuvent référencer des outils qui ont changé	Batterie d'exécution

Règles de décision¶

Quelles règles de détection¶

Les cartes d'un skill sont des cartes p sur des proportions, avec des volumes modestes. Les conclusions du chapitre sur les pièges s'appliquent :

règle 1 (un point hors des limites à 3σ) : toujours ;
règle 4 (8 points de suite du même côté) : utile, parce que les dégradations de skills sont plutôt des dérives durables que des chocs ;
règles 2 et 3 : à éviter si l'on surveille beaucoup de skills, car le nombre de fausses alarmes croît avec le nombre de cartes (script §6) ;
pour une bibliothèque de plusieurs dizaines de skills, préférer une carte CUSUM par skill, qui détecte les petites dérives durables avec un meilleur compromis que l'empilement de règles (script §2).

Ce qu'on fait d'une alarme¶

Vérifier l'instrument : le classifieur de pertinence ou le vérificateur de respect a-t-il changé ?
Chercher l'étiquette qui a changé : modèle, autre skill, environnement (voir les étiquettes du chapitre Instrumenter la chaîne).
Lire les traces des runs du point en alarme. Le guide d'évaluation d'Anthropic le dit sans détour : on ne sait pas si les correcteurs fonctionnent tant qu'on n'a pas lu les traces (source).
Seulement ensuite, modifier le skill — et requalifier.

Et symétriquement : pas d'alarme, pas de modification. Un échec isolé signalé par un utilisateur va dans le jeu de cas de test pour la prochaine requalification ; il ne justifie pas à lui seul une réécriture.

Les skills morts et les skills envahissants¶

Deux pathologies se voient sans carte de contrôle, par un simple inventaire périodique :

le skill mort : jamais déclenché sur la période. Soit la description est mauvaise, soit le besoin a disparu. Dans les deux cas, il coûte des tokens de description à chaque session ;
le skill envahissant : déclenché sur une proportion de runs très supérieure à la proportion de tâches pertinentes. Il charge son corps inutilement, et peut détourner l'agent d'un skill plus adapté.

À retenir

En production, un skill se surveille avec trois cartes p : déclenchement parmi les tâches pertinentes, respect des instructions, effet sur le résultat contre un témoin. Les changements connus (modèle, autre skill, environnement) déclenchent une requalification sans attendre la carte. Et la règle de Deming s'applique : sans signal statistique, on enrichit la batterie de tests, on ne réécrit pas le skill.