Claude Skills en prod : retour terrain sur 12 déploiements (et 4 morts)

Sur les 12 Claude Skills qu'on a déployés en production sur 3 mois chez des PME industrielles, 4 sont morts avant la fin de leur première semaine. Pas à cause de Claude. À cause de 4 erreurs qu'on voit revenir systématiquement, et que personne ne documente parce que personne ne veut admettre qu'il les a faites.

Ce que tu vas lire ici, c'est le retour terrain brut : les chiffres réels (coût, latence, taux d'auto-trigger), les patterns qui font qu'un skill devient un réflexe quotidien chez Claude, et une template atomique prête à copier-coller. Pas de théorie. Du concret.

• Les 4 erreurs qui tuent un skill dès la première semaine (vues 3+ fois en prod)
• Les 3 patterns des 8 skills qui survivent et deviennent des réflexes
• Les mesures réelles : coût, latence p95, taux d'auto-trigger
• Une template de skill atomique prête à dupliquer
• Une checklist d'audit lexical pour éviter les chevauchements

Un skill Claude, c'est une compétence configurée à l'avance que Claude va lire et appliquer au moment où tu en as besoin. Pas un prompt que tu réécris à chaque fois. Pas un template que tu colles dans le chat. Une vraie instruction permanente, contextualisée sur ton entreprise, tes offres, ta charte graphique, tes tarifs.

Dans la démo, le skill proposition commerciale connaît l'entreprise par cœur. Il sait comment présenter la page de garde, quelle police utiliser, quelles offres proposer, dans quel ordre. À partir d'un compte-rendu de réunion (généré par Phantom), il produit une proposition de 9 pages en 2 à 3 minutes. Le résultat est standardisé. N'importe quelle proposition générée avec ce skill reprend exactement les mêmes éléments.

C'est une véritable compétence à part entière. Il connaît l'entreprise tout simplement. Il est contextualisé sur toute l'entreprise.

Le gain de temps est réel et mesurable. Sur les compte-rendus : 1h à 1h30 réduit à une demi-heure. Sur les propositions commerciales : 2h réduit à 30-45 minutes. Le temps de traitement divisé par deux, avec une qualité qui ne varie plus selon l'humeur du jour ou le niveau de fatigue.

Ces 4 erreurs, on les a vues revenir au moins 3 fois chacune sur les 12 déploiements. Elles ne sont pas liées à Claude. Elles sont liées à la façon dont on conçoit les skills avant de les pousser en prod.

Le chevauchement lexical, c'est le piège le plus sournois. Deux skills avec des noms proches font hésiter Claude entre les deux. Il ne choisit pas le bon. Il alterne. Et tu ne comprends pas pourquoi le résultat change d'une invocation à l'autre.

L'output non contractuel, c'est le deuxième tueur. Si ton skill produit parfois du JSON et parfois du markdown selon l'humeur, le système qui consomme ce skill va planter. Pas parfois. Systématiquement, dès que le format dévie.

Sur les 8 skills vivants à 30 jours, trois caractéristiques reviennent sans exception. Ce ne sont pas des règles arbitraires. Ce sont des patterns empiriques tirés de ce qui a survécu vs ce qui est mort.

1. 1Nom verbe-objet : "detect-pii-in-text" plutôt que "helper" ou "util". Claude comprend immédiatement ce que le skill fait et quand l'invoquer.
2. 2Une seule responsabilité : ≤ 200 lignes de prompt. Dès que tu dépasses, c'est que tu as mis deux skills dans un seul.
3. 3Output contractuel testé sur 20 cas avant prod : JSON ou markdown, jamais les deux. Le format est gravé dans le skill, pas suggéré.

Le nom verbe-objet, c'est contre-intuitif au début. On a tendance à nommer les skills comme des modules ("commercial", "formatting", "output"). Mais Claude ne lit pas le nom comme un humain lit un label. Il l'utilise pour décider si ce skill est pertinent dans le contexte. Un nom ambigu, c'est une invocation aléatoire.

Voilà ce que 3 mois de production donnent comme mesures réelles. Ces chiffres sont issus des 12 déploiements chez des PME industrielles, sur Claude Sonnet 4.6 avec un prompt moyen de 4k tokens.

Le delta de latence entre un skill atomique (1.8s) et un monolithe (4.2s) est le chiffre qui convainc le plus vite les tech leads hésitants. 2.4 secondes de différence, ça paraît rien. Multiplié par 200 invocations par jour, c'est 8 minutes de latence cumulée que tu offres à tes utilisateurs. Et les 2 monolithes restants sont en cours de refactorisation.

Le taux d'auto-trigger à 87% est honnête. L'objectif est à 95%. Les 13% restants, c'est quasi exclusivement des skills sans instruction WHEN explicite. La correction est simple. L'identifier en prod, c'est moins simple.

Ce que j'ai mis en place pour le skill proposition commerciale, tu peux le reproduire sur n'importe quel livrable récurrent. Le principe est le même : tu contextualises Claude sur ton entreprise une fois, et tu n'y reviens plus. La template ci-dessous est la structure minimale viable d'un skill atomique.

La section WHEN est la plus négligée. C'est pourtant elle qui détermine si Claude invoque le skill au bon moment ou aléatoirement. Elle doit décrire précisément le contexte déclencheur : "Quand l'utilisateur fournit un compte-rendu de réunion et demande une proposition commerciale", pas "Quand c'est utile".

La section CONTEXT, c'est là que tu mets tout ce que Claude doit connaître de ton entreprise : tes offres, tes tarifs, ta charte graphique, ta police, ton logo. Comme dans le skill proposition commerciale de la démo : Claude connaît l'entreprise. Il ne la réinvente pas à chaque fois.

Un audit lexical, c'est simple : tu listes tous tes skills actifs, tu extrais leurs noms et leurs conditions WHEN, et tu cherches les synonymes. "format-currency" et "format-money" font la même chose avec des mots différents. Claude ne sait pas lequel choisir. Il choisit les deux en alternance.

Cet audit, fais-le avant chaque nouveau déploiement. Pas après. En production, un chevauchement se détecte par des comportements erratiques difficiles à reproduire. En pré-prod, il se détecte en 10 minutes avec cette liste.

La vision à terme, c'est une chaîne de valeur complètement automatisée : une transcription de réunion entre dans le workflow, elle passe dans le skill, un document standardisé sort dans le drive du client. N8N, Phantom, Claude Skills. Pas de copier-coller manuel. Pas de mise en forme à la main. Juste la relecture.

Ce n'est pas de la science-fiction. C'est le workflow qu'on est en train de mettre en place. Les skills sont la pièce centrale : ils garantissent que le livrable qui sort de l'automatisation est standardisé, conforme à la charte graphique, et contextualisé sur le client. Sans eux, l'automatisation produit du volume. Avec eux, elle produit de la qualité.