Skill Claude « Propale » : le guide complet, de l'architecture à l'équipe

Il y a une confusion qui coûte cher à ceux qui démarrent avec Claude. Ils écrivent un long prompt dans la barre de chat, ils obtiennent quelque chose de correct, et ils appellent ça "utiliser l'IA". C'est pas faux. Mais c'est comme appeler un stagiaire à chaque fois que tu as besoin d'un livrable, lui réexpliquer tout le contexte de zéro, et espérer que le résultat soit cohérent avec la dernière fois.

Un Skill Claude, c'est autre chose. C'est une compétence que tu programmes une fois, que tu ancres dans l'outil, et qui se déclenche au bon moment sans que tu aies à tout réexpliquer. La différence entre un prompt et un Skill, c'est la différence entre une note post-it et un process documenté dans ton CRM.

• L'anatomie complète d'un SKILL.md : frontmatter, description déclencheur, divulgation progressive
• Le pipeline en 5 étapes : de la transcription brute à la propale prête à envoyer
• La structure de la proposition générée : ce qui doit y être, ce qui doit en être absent
• Les 4 erreurs qui ruinent ce type de Skill avant même le premier envoi
• La mise en production en équipe : jeu d'essai, cas dégradés, versionnage, maintenance

Dans la démo, le compte-rendu fictif vient de Phantom, l'outil utilisé pour transcrire les réunions. Il contient les participants, les problématiques exprimées, les contraintes identifiées. Claude est configuré en Opus 4.6. Une seule instruction envoyée : "tu peux utiliser le skill proposition commerciale MIA". Ce qui sort, c'est une propale de 9 pages, mise en page, avec logo, prête à ouvrir dans Drive et à relire.

La qualité est standardisée. N'importe quelle proposition commerciale que je vais pouvoir effectuer avec ce Skill reprendra exactement les mêmes éléments : une première page de garde spécifique, une manière de présenter spécifique, une charte graphique spécifique, une police spécifique.

Ce n'est pas un gadget. C'est ce qui permet de passer de 2h à 30-45 minutes sur une proposition commerciale, tout en garantissant que la propale envoyée le lundi ressemble à celle envoyée le vendredi, par toi ou par quelqu'un d'autre dans l'équipe.

Un Skill, c'est un dossier avec un fichier SKILL.md à l'intérieur. Ce fichier commence par un en-tête YAML, le frontmatter, avec deux champs obligatoires : name et description. Le name, c'est l'identifiant stable. La description, c'est le déclencheur.

Et c'est là que la plupart ratent dès le départ. Une description vague comme "aide commerciale" ne déclenche rien de fiable. Claude ne sait pas quand la charger. Une description opérationnelle, "transforme une transcription de rendez-vous commercial en proposition commerciale structurée", déclenche au bon moment, avec les bons mots que l'utilisateur emploiera vraiment : "propale", "compte-rendu de rendez-vous", "proposition".

Le principe derrière ça s'appelle la divulgation progressive. Au démarrage d'une conversation, Claude ne charge que le nom et la description de chaque Skill. Le corps du SKILL.md n'est lu que si la tâche correspond. Les fichiers annexes, eux, ne sont chargés que s'ils sont explicitement référencés et nécessaires. Conséquence directe : tu peux embarquer un modèle de propale complet de plusieurs pages dans les annexes sans alourdir chaque conversation.

Une transcription brute, c'est du bruit. Des "euh", des horodatages, des répétitions, des apartés qui n'ont rien à voir avec le besoin du prospect. Le Skill commence par nettoyer tout ça. Mais attention : il retire les marqueurs d'hésitation, pas les tours de parole. Qui dit quoi engage la suite de la propale.

1. 1Nettoyage : retirer hésitations, horodatages, répétitions, conserver les tours de parole (qui dit quoi engage la suite)
2. 2Extraction : besoins exprimés, contraintes (budget, délais, décideurs présents), objections formulées, engagements pris. Règle absolue : un besoin non exprimé n'existe pas.
3. 3Qualification : rattacher chaque besoin à une offre du catalogue (fichier annexe offres.md). Si aucun rattachement possible, le signaler, jamais forcer.
4. 4Rédaction : générer la propale selon le modèle annexe, en citant les formulations exactes du prospect quand elles existent. C'est ce qui fait qu'une propale "sonne" comme le rendez-vous.
5. 5Contrôle : vérifier que chaque affirmation est traçable à la transcription ou au catalogue. Tout chiffre non traçable est retiré.

La structure de la proposition générée n'est pas négociable. Chaque section a une fonction précise, et l'ordre compte.

1. 1Contexte et enjeux : reformulation fidèle de la situation du prospect, avec 1 à 2 citations exactes du rendez-vous
2. 2Périmètre proposé : ce qui est inclus ET ce qui est explicitement exclu (les exclusions évitent la plupart des malentendus de cadrage)
3. 3Livrables et planning : jalons datés, responsabilités réparties
4. 4Conditions : tarification issue du catalogue uniquement, modalités de paiement, durée de validité de l'offre
5. 5Prochaine étape : une seule action, datée, un créneau de restitution proposé

Ce que la propale ne doit jamais contenir : un chiffre de ROI inventé, une référence client absente des matériaux, un délai que personne n'a mentionné lors du rendez-vous. Le Skill connaît les tarifs du catalogue. Il ne connaît que ça. Et c'est exactement ce qu'on lui demande.

Le document ci-dessus détaille l'anatomie complète du Skill, les 5 étapes du pipeline et la structure de la propale générée. C'est le document de travail de référence pour construire le tien.

Ces erreurs ne sont pas théoriques. Elles correspondent à ce qui se passe quand on construit un Skill trop vite, sans jeu d'essai, sans cas dégradé prévu.

• Écrire les instructions comme une documentation ("le Skill permet de...") au lieu d'instructions impératives à Claude ("extrais, rattache, rédige"). Claude n'est pas un lecteur de notice.
• Laisser le Skill inventer des chiffres de ROI ou des références clients absentes des matériaux. La propale devient invérifiable et le commercial perd la confiance du prospect en réunion.
• Tout mettre dans SKILL.md au lieu d'annexer le modèle de propale et le catalogue. Le contexte explose, la qualité de rédaction chute.
• Oublier le cas "transcription pauvre". Si le rendez-vous n'a pas exprimé de besoin clair, le Skill doit produire un mail de relance avec questions, pas une propale vide.

Un Skill qu'on teste seul dans son coin et un Skill qu'on confie à une équipe, c'est pas le même niveau d'exigence. Quand c'est toi qui l'utilises, tu corriges intuitivement. Quand c'est un commercial ou un assistant, la propale part telle quelle.

Avant d'écrire une ligne de SKILL.md, tu rassembles trois choses : 3 vraies transcriptions de rendez-vous passés (bonnes et mauvaises, les deux), 2 propales réellement envoyées et signées pour définir le ton et la structure cible, et le catalogue d'offres avec les prix officiels. Le Skill ne doit jamais produire un prix qui n'y figure pas.

Le test de la transcription coupée à moitié est non-négociable. Tu coupes la transcription à la moitié et tu vérifies que le Skill demande ce qui manque au lieu de combler avec de l'inventé. Si le Skill comble, il invente. Et une invention dans une propale, c'est une erreur que le prospect trouvera avant toi.

Un Skill n'est pas un livrable qu'on pose et qu'on oublie. Il vieillit. Et il vieillit mal si on ne le maintient pas.

La première cause de propales fausses en production : le catalogue annexe n'a pas été mis à jour après un changement de prix. Le Skill génère un tarif qui n'existe plus. Le commercial l'envoie. Le prospect le reçoit. Et là, c'est une conversation difficile à avoir.

• Versionner le dossier du Skill avec git : une propale ratée doit pouvoir être rattachée à une version précise des instructions
• Mettre à jour le catalogue annexe à chaque changement de prix, c'est la première cause de propales fausses en production
• Collecter chaque propale corrigée à la main par l'équipe : les corrections récurrentes sont des instructions manquantes dans le SKILL.md