On ne pilote pas ce qu'on ne mesure pas : le casse-tête de la valeur des skills

Toutes les équipes qui travaillent avec des agents IA accumulent discrètement la même chose : des skills. Un skill pour rédiger une clause de contrat. Un autre pour rapprocher des factures d’un grand livre. Un troisième pour transformer un CSV désordonné en graphique présentable au comité de direction. Depuis qu’Anthropic a présenté les Agent Skills en octobre 2025, des dossiers d’instructions, de scripts et de ressources qu’un agent charge quand la tâche l’exige, les organisations en produisent à un rythme soutenu. (Si la notion est nouvelle pour vous, voici pourquoi les skills rendent les agents plus efficaces.)

Puis, en réunion de planification, quelqu’un pose la question évidente : lesquels de ces skills valent vraiment la peine d’être gardés ? Et plus personne ne parle.

La plupart des équipes savent combien de tokens un agent a consommés le mois dernier. Elles connaissent la latence d’un appel d’outil à la milliseconde près. Mais demandez quel skill a produit de la valeur, pour qui et combien, et la réponse honnête est qu’aujourd’hui personne ne le sait vraiment. L’instrumentation des systèmes d’IA mesure le moteur, pas le travail accompli. Les équipes qui combleront cet écart les premières investiront dans leur bibliothèque de skills en connaissance de cause, et non au jugé.

Pourquoi la question devient urgente

Pendant un temps, la prolifération des skills n’avait pas grande importance. Vous en aviez une poignée, vous les connaissiez tous par leur nom, et « est-ce utile ? » se tranchait autour d’un café.

Cette époque se termine. Les bibliothèques de skills atteignent des dizaines, puis des centaines d’éléments. Elles sont partagées entre équipes, intégrées à plusieurs agents, versionnées, dupliquées, abandonnées. Beaucoup d’organisations les regroupent désormais en rôles : un rôle, c’est le travail que fait réellement un poste de l’organigramme, réuni en un ensemble de skills, des outils dont ils ont besoin et des permissions qui vont avec. Chaque skill a un coût : le temps de le construire et de le maintenir, les tokens qu’il consomme à l’exécution, la relecture nécessaire pour qu’il reste sûr et à jour.

Le coût, justement, est la partie facile à mesurer. C’est du côté du bénéfice que tout se complique, et cette asymétrie fausse chaque décision sans bruit. Vous pouvez prouver ce qu’un skill coûte ; vous ne pouvez qu’évoquer vaguement ce qu’il rapporte.

Pourquoi les skills résistent à la mesure

Le problème ne vient pas d’équipes négligentes avec leurs indicateurs. Les skills ont des propriétés structurelles qui mettent en échec les habitudes de mesure héritées du logiciel classique.

Un skill ne « s’exécute » pas proprement

Dans un logiciel classique, un appel de fonction est un événement net. Il démarre, s’exécute, renvoie un résultat, et tout se journalise. Un skill est plus flou. Le modèle décide, selon le contexte, s’il s’appuie sur un skill et comment. La même demande peut l’invoquer une fois, deux fois, en partie ou pas du tout. La frontière entre « le modèle a fait ceci » et « le skill a fait ceci » est réellement floue : le skill oriente le comportement du modèle au lieu de tourner comme une unité isolée. Même l’indicateur le plus simple, ce skill a-t-il tourné et qu’a-t-il produit, se révèle étonnamment difficile à capter de façon fiable.

Personne ne sait qui l’a consommé

Un skill sert rarement une seule personne. Il est intégré à un agent, qui sert un processus, qui sert de nombreux utilisateurs dans plusieurs équipes. Quand la valeur apparaît enfin (une affaire conclue plus vite, un rapport qui n’a pas dû être repris), aucune filiation ne permet de remonter jusqu’au skill qui a aidé. Demandez « qui profite vraiment de ce skill, et à quelle fréquence ? » et vous reconstituez la réponse à partir de fragments.

Un résultat n’est pas un impact, et il n’y a pas de contrefactuel

Admettons que vous puissiez compter parfaitement les exécutions. Vous n’auriez toujours pas mesuré la valeur, car la valeur, c’est l’effet produit : du temps gagné, des erreurs évitées, une qualité améliorée. Relier un appel à un résultat métier suppose de suivre une longue chaîne causale, pleine de facteurs confondants, au bout de laquelle se dresse le mur le plus difficile : le contrefactuel. Pour savoir ce qu’un skill a ajouté, il faudrait savoir ce qui se serait passé sans lui. Les agents ne sont pas déterministes et coûtent cher à relancer, si bien que la comparaison A/B qui trancherait la question n’est presque jamais faite.

Interroger les utilisateurs ne règle rien. Dans un essai contrôlé randomisé mené par METR en 2025, 16 développeurs open source expérimentés s’attendaient à ce que l’IA les accélère de 24 %. Avec les outils, ils ont en réalité mis 19 % de temps en plus, et ils restaient persuadés, après coup, d’avoir été 20 % plus rapides. Le gain de temps déclaré est une preuve fragile.

Le mérite est partagé, et personne ne sait le répartir

Les vraies tâches combinent plusieurs skills. Un même travail peut s’appuyer successivement sur un skill de recherche, un skill de raisonnement et un skill de mise en forme. Quand le résultat est bon, comment répartir le mérite ? Un skill peut être nécessaire sans être suffisant ; sa contribution marginale dépend de tout ce qui l’entoure dans la chaîne. Hors expérimentation contrôlée, la plupart des équipes règlent la question en ne la réglant pas : elles attribuent le mérite à l’ensemble et passent à autre chose. Organiser le catalogue en graphe de skills aux dépendances explicites permet au moins de rendre cette chaîne visible.

L’outillage a été pensé pour le modèle, pas pour le skill

Sous tout cela se trouve une pile d’observabilité conçue autour des appels de modèle et d’outils. Les conventions sémantiques OpenTelemetry pour l’IA générative, ce qui se rapproche le plus d’un standard du secteur, définissent des spans, des métriques et des événements pour les clients de modèles et pour MCP, avec la consommation de tokens et la latence comme métriques principales. Elles n’ont pas été conçues pour suivre un skill à travers ses appels, ses consommateurs, ses versions et ses résultats. Tant que les skills ne seront pas des entités de premier rang dans la télémétrie, les données pour répondre à la question de la valeur n’existeront tout simplement pas.

Le piège des indicateurs indirects

Face à tout cela, les équipes se rabattent sur les chiffres qu’elles peuvent obtenir : nombre d’appels, taux d’adoption, « ce skill a été utilisé 4 000 fois le trimestre dernier ». On a l’impression d’avancer. C’est aussi un piège.

L’usage n’est pas la valeur. Un skill très sollicité peut faire un travail trivial, tandis qu’un skill appelé deux fois par mois peut être celui qui évite un incident de conformité. Optimiser l’usage récompense l’agitation plutôt que l’essentiel, et pousse à retirer exactement les mauvais skills. On passe aussi à côté de leur raison d’être : capter le savoir-faire plutôt que le savoir, c’est-à-dire précisément ce qu’aucun compteur ne voit.

À quoi ressemble une mesure honnête

Rien de tout cela n’est insoluble ; c’est simplement non résolu. Une nouvelle couche se forme au-dessus de la télémétrie brute des modèles et des tokens, dont le rôle est de rendre les skills mesurables. Appelons-la l’observabilité des skills. Où qu’elle se trouve, elle doit apporter quelques capacités :

• Des skills observables. Une instrumentation à la frontière du skill, pour que chaque appel soit un événement réel, journalisé, avec sa propre identité.
• La filiation des consommateurs. Chaque appel rattaché à l’agent, à la personne, à l’équipe, au processus et à la tâche qui l’ont déclenché.
• Le lien avec les résultats. Un moyen de relier les appels à des signaux en aval : relecture humaine, tâche réussie, délai de réalisation.
• Une capacité contrefactuelle. Faire tourner un processus avec et sans un skill donné, au moins en évaluation, pour estimer sa valeur marginale au lieu de la supposer.
• Une attribution pour les combinaisons. Une règle claire pour répartir le mérite quand plusieurs skills concourent à un même résultat.
• Une définition commune de la valeur. Les mêmes unités (temps gagné, erreurs évitées, coût de service) pour tous les skills, afin de pouvoir les comparer.

Une discipline compte plus que la liste : appeler une estimation une estimation. Même les travaux les plus rigoureux le font. Quand Anthropic a analysé 100 000 conversations réelles avec Claude en novembre 2025, l’entreprise a estimé une réduction moyenne du temps de tâche d’environ 80 %, puis a précisé que ce chiffre ne compte pas le temps passé à vérifier ou retravailler le résultat hors de la conversation, et qu’il ne s’agit pas d’une prévision. C’est la bonne posture pour la valeur des skills : le temps gagné et ce qu’il vaut se déduisent de l’usage réel, tâche par tâche, et se présentent comme des estimations, jamais comme des économies mesurées.

C’est la posture de skilder. L’usage est suivi par rôle : une organisation voit quelles capacités servent, à qui et à quelle fréquence, avec une estimation du temps gagné et de sa valeur. Ces chiffres sont des estimations tirées de l’usage réel, et présentés comme tels.

En résumé

Aujourd’hui, la plupart des organisations pilotent leur bibliothèque de skills à l’aveugle. Elles voient la jauge de carburant (le coût) avec une netteté parfaite, et presque rien de la destination. C’est tenable avec cinq skills. Avec cinq cents, dont beaucoup vivent dans des dossiers personnels où SKILL.md alimente le shadow AI, cela devient un vrai risque.

La première étape n’est pas un meilleur tableau de bord : c’est décider que la valeur d’un skill se conçoit pour être mesurée, dès l’instant où il est invoqué. Pour savoir rapidement où en est votre organisation, le bilan IA en 10 questions prend deux minutes et ne vous demande rien. Les équipes qui adoptent cette discipline tôt ne se contenteront pas d’élaguer leur bibliothèque avec plus de discernement : elles disposeront d’une estimation défendable de ce que valent vraiment leurs agents.

Questions fréquentes

Comment mesurer la valeur d'un skill d'agent IA ? +

Commencez par rendre le skill observable : journalisez chaque appel à la frontière du skill, rattachez-le à la personne et à la tâche qui l'ont déclenché, puis reliez-le à un signal de résultat (tâche réussie, relecture humaine, délai de réalisation). À partir de cet usage, on peut estimer le temps gagné et ce qu'il vaut. Cela reste une estimation, car le contrefactuel (la même tâche faite sans le skill) est rarement observé directement.

Le nombre d'appels est-il un bon indicateur pour un skill ? +

Le nombre d'appels dit qu'un skill est sollicité, pas qu'il apporte de la valeur. Un skill très utilisé peut faire un travail trivial, un skill rarement appelé peut éviter une erreur coûteuse. L'usage alimente une estimation, il ne la remplace pas.

Peut-on mesurer précisément le temps gagné grâce à l'IA ? +

Pas précisément. Les études contrôlées montrent que chacun se trompe sur son propre gain de vitesse, et les analyses à grande échelle de conversations réelles présentent leurs chiffres comme des estimations, avec des réserves explicites. L'approche défendable consiste à estimer le temps gagné à partir de l'usage réel, tâche par tâche, en disant clairement qu'il s'agit d'une estimation.