Checklist : mettre en production un Skill de propale sans se planter

Un Skill Claude mal configuré, c'est pire qu'aucun Skill. Il génère des propales avec des chiffres inventés, des délais que tu n'as jamais promis, des références client qui n'existent pas. Et c'est ton commercial qui l'envoie sans relire, parce qu'il fait confiance à l'outil.

Ce document est la liste de vérifications que j'applique avant de diffuser un Skill de proposition commerciale à une équipe. Trois phases, dans cet ordre : avant d'écrire une ligne, pendant l'écriture du SKILL.md, et le jeu d'essai avant diffusion. Une quatrième phase, la maintenance, démarre dès le premier jour de production.

• Phase 1, avant d'écrire : les matériaux à rassembler
• Phase 2, écriture du SKILL.md : les règles non négociables
• Phase 3, jeu d'essai : comment chercher activement l'erreur
• Phase 4, maintenance : ce qui fait planter un Skill en production

Dans cette vidéo, j'ouvre le SKILL.md que j'utilise en production depuis trois semaines. Charte graphique, typographie, structure de propale, grille de pricing, exemples de sections réelles pour des clients existants. La checklist ci-dessous est le protocole qui m'a permis d'arriver à ce résultat sans mauvaise surprise.

La plupart des gens ouvrent Claude et commencent à écrire le SKILL.md. C'est l'erreur. Un Skill sans matériaux de référence, c'est un commercial sans brief : il invente. Et il invente bien, ce qui est encore plus dangereux.

Trois choses à rassembler avant de toucher au clavier. D'abord, 3 transcriptions réelles de rendez-vous passés, bonnes et mauvaises. Elles serviront de jeu d'essai en Phase 3. Ensuite, 2 propales réellement envoyées et signées : elles définissent le ton et la structure cible, pas tes intuitions sur ce qu'une propale devrait être. Enfin, le catalogue d'offres avec les prix officiels. Le Skill ne doit jamais produire un prix qui n'y figure pas.

Je n'oublie plus certaines datas, certains insights du client. Tout cela fait qu'aujourd'hui je passe environ 35 à 45 minutes sur une proposition commerciale, là où avant j'étais plutôt sur 2 heures.

Ce gain ne vient pas du Skill seul. Il vient du fait que le Skill a été nourri avec les bons matériaux dès le départ. Sans ça, tu passes autant de temps à corriger qu'à rédiger.

Le SKILL.md, c'est le cerveau de ton workflow. Ce que tu y mets, Claude l'applique. Ce que tu oublies, il l'invente. Quatre règles non négociables.

1. 1Frontmatter : un name court et stable, plus une description qui contient les mots que l'utilisateur emploie vraiment (« propale », « compte-rendu de rendez-vous », « proposition »). Pas les mots que toi tu utilises en interne.
2. 2Instructions impératives, ordonnées, testables une par une. Si tu ne peux pas tester une instruction isolément, elle est trop vague.
3. 3Modèle de propale et catalogue en fichiers annexes référencés, pas collés dans le corps du SKILL.md. Le corps reste lisible, les annexes restent maintenables.
4. 4Une section « cas dégradés » : transcription incomplète, rendez-vous sans besoin exprimé, prospect hors cible. Si tu ne l'écris pas, Claude comble les trous. Et il comble bien.

La plupart des gens testent leur Skill en espérant que ça marche. C'est l'inverse qu'il faut faire : tester en cherchant activement ce qui cloche. Un Skill qui passe un test bienveillant plante en production.

Quatre vérifications dans l'ordre. Passe les 3 transcriptions d'essai rassemblées en Phase 1 : la propale générée cite-t-elle des phrases réellement prononcées lors du rendez-vous ? Cherche ensuite activement une invention : un chiffre, un délai, une référence absents des matériaux. Une seule invention = retour à l'écriture. Pas de négociation.

Troisième vérification : fais relire une propale générée par la personne qui a mené le rendez-vous. Pas par toi. La question est simple : reconnaît-elle son échange ? Quatrième vérification : coupe une transcription à la moitié et confirme que le Skill demande ce qui manque au lieu de combler. Si Claude invente la deuxième moitié du rendez-vous, ta section « cas dégradés » est insuffisante.

Un Skill validé en semaine 1 peut planter en semaine 6. Pas parce que Claude a changé, mais parce que le catalogue de prix a bougé, ou parce que l'équipe a corrigé les mêmes erreurs dix fois sans jamais les remonter dans les instructions.

Trois réflexes à mettre en place dès la diffusion. 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. Et collecter chaque propale corrigée à la main par l'équipe : les corrections récurrentes sont des instructions manquantes.

Tout ce que tu viens de lire est condensé dans ce document de travail Made in AI. Une page, quatre phases. Chaque point est testable isolément : c'est la condition pour qu'une checklist serve vraiment, plutôt que de finir dans un dossier qu'on n'ouvre plus.

Le Skill proposition commerciale que j'utilise depuis trois semaines contient : charte graphique, typographie, éléments visuels obligatoires, structure de propale avec framework ROI et prochaines étapes, code pour générer du .docx, tableau de pricing dans un format défini, workflow complet, règles de qualité, et des exemples de sections réelles tirées de clients existants. Le tout dans un seul SKILL.md avec annexes référencées.

Résultat concret sur mes missions : 35 à 45 minutes par proposition commerciale, contre 2 heures auparavant. Pas parce que Claude est meilleur qu'ailleurs, mais parce que le Skill a été construit avec les bons matériaux, testé avec les bons cas, et maintenu avec les bons réflexes. C'est le protocole qui fait la différence, pas l'outil seul.

Ce que je montre dans la vidéo (l'interface Claude, la petite valise, les connecteurs MCP, le SKILL.md) reste accessible à un non-technicien. Tu peux énoncer à l'oral ce que tu attends, donner tes exemples, et Claude te constitue une première version en quasi-autonomie. Ce qui n'est pas accessible sans méthode, c'est la mise en production fiable. C'est exactement ce que cette checklist adresse.

La prochaine ressource montrera le Skill en action sur une vraie transcription de rendez-vous, du brief au .docx final. En attendant, la checklist est là. Utilise-la dans l'ordre : Phase 1 avant Phase 2, Phase 3 avant diffusion, Phase 4 dès le premier jour de production.