Le geste qui se répète sans jamais donner le même résultat
Chaque appel commercial produit un compte-rendu. En théorie. En pratique, la commerciale qui enchaîne quatre appels dans la matinée rédige quatre textes qui ne se ressemblent pas. Le premier est trop long parce qu'elle avait le temps. Le deuxième est un bloc de trois lignes parce qu'elle enchaînait. Le troisième contient les bonnes infos mais dans un ordre que personne d'autre ne peut relire. Le quatrième, elle l'a oublié.
Le problème n'est pas la rigueur. C'est que le geste n'a pas de forme fixe. La commerciale sait exactement ce qui compte dans un appel : est-ce que le prospect a un budget, est-ce qu'il a un calendrier, est-ce qu'il a un problème identifié ou juste une curiosité vague. Elle le sait. Mais entre le savoir et le poser à chaque fois dans le même format, il y a un écart que la bonne volonté ne comble pas.
J'ai eu exactement ce problème quand j'ai voulu standardiser les comptes-rendus d'appels dans une équipe d'une dizaine de commerciaux, chez un ancien employeur. J'avais créé un modèle dans un tableur. Colonnes propres, catégories claires. Au bout de deux semaines, la moitié de l'équipe remplissait le tableur, l'autre moitié continuait d'envoyer des mails en texte libre. Le modèle était bon. Il ne portait pas la méthode.
Un skill, c'est autre chose qu'un modèle. C'est une instruction permanente que Claude applique chaque fois qu'il reconnaît la situation. Tu ne remplis pas un formulaire. Tu parles, tu colles tes notes brutes, et Claude produit le compte-rendu dans ta structure à toi, avec tes critères à toi.
Le signal qu'un geste mérite un skill est simple : tu te répètes, et tu obtiens un résultat différent à chaque fois alors que tu voudrais le même.
Ce qu'on met dedans, et ce qu'on n'y met pas
La compétence métier, pas la procédure générique
Si tu demandes à Claude "fais-moi un compte-rendu d'appel commercial" sans skill, il va produire quelque chose de correct et de parfaitement inutile. Un résumé poli, des bullet points génériques, une section "prochaines étapes" qui ressemble à toutes les sections "prochaines étapes" du monde.
Le résultat n'est pas mauvais. Il est anonyme. Il pourrait sortir de n'importe quelle entreprise, n'importe quel secteur, n'importe quelle méthode de vente.
Ce qui fait la différence, c'est ce que la commerciale sait et que Claude ne sait pas. Par exemple : dans son secteur, un prospect qui dit "on regarde pour le Q3" est en train de dire non poliment. Ou : la vraie information d'un appel de découverte, ce n'est pas le besoin exprimé, c'est qui d'autre dans l'entreprise a été mentionné. Ou encore : un compte-rendu qui ne contient pas le budget évoqué, même approximatif, ne sert à rien pour le pipeline.
Ces critères-là, c'est la compétence métier. C'est ce que la commerciale a appris en trois ans de terrain. Le skill doit porter ça. Pas "résume l'appel". Mais "extrais le budget mentionné même s'il est vague, identifie les interlocuteurs cités, qualifie le niveau d'engagement réel du prospect selon ces critères : budget confirmé, calendrier posé, décideur identifié".
Le format de sortie, avant le reste
Quand j'ai construit mes premiers skills pour Pimpela, j'ai fait l'erreur de commencer par les instructions de traitement. Ce que Claude devait analyser, comment il devait raisonner. Le format de sortie venait en dernier, presque comme une formalité.
C'est l'inverse qui marche. Le format de sortie, c'est la première chose à fixer. Parce que c'est lui qui force la clarté. Si tu sais que ton compte-rendu doit tenir en cinq sections, prospect, contexte de l'appel, qualification (budget/calendrier/décideur), signaux faibles, action suivante, alors tu sais exactement ce que le skill doit extraire. Le format dicte le contenu.
Et le format, c'est toi qui le choisis. Pas Claude. Claude va proposer quelque chose de propre si tu lui laisses le champ libre. Mais "propre" et "utile pour ton pipeline du lundi matin" ne sont pas la même chose.
Le brouillon qu'on soumet à Claude
La première version d'un skill ressemble rarement à la version finale. Ce n'est pas grave. Ce qui compte, c'est d'avoir une matière à travailler.
Pour le skill de compte-rendu commercial, ma première version tenait en une dizaine de lignes. En gros : "Quand je te colle des notes d'appel commercial, produis un compte-rendu structuré avec ces sections : prospect, contexte, qualification BANT, signaux faibles, action suivante. Le ton est factuel, pas de formules de politesse, pas de 'en résumé'. Maximum 300 mots."
C'est un début. Mais il manque tout ce qui fait la signature. Les critères de qualification sont nommés sans être définis. Le skill ne dit pas quoi faire quand une information manque dans les notes. Il ne précise pas si "action suivante" c'est l'action de la commerciale ou celle du prospect.
Lui demander de le réécrire, pas de le valider
La consigne que je donne à Claude à ce stade n'est pas "est-ce que ce skill est bien ?". Claude dira oui. Il dit toujours oui. La consigne, c'est : "Réécris ce skill pour qu'il soit plus précis. Ajoute ce qui manque pour que tu puisses le suivre sans me poser de questions. Si un critère est ambigu, propose une formulation plus nette."
Claude renvoie une version plus longue, plus structurée. Certains ajouts sont pertinents, il a explicité les critères BANT, il a ajouté une consigne sur les informations manquantes ("si le budget n'a pas été mentionné, indique 'budget : non évoqué' plutôt que d'omettre la ligne"). D'autres ajouts sont du remplissage, une section "objectif du skill" qui ne sert à rien, des formulations redondantes.
Je coupe ce qui est en trop. Je garde ce qui est utile. Je reformule deux ou trois phrases dans mon vocabulaire à moi, parce que le skill doit me ressembler, pas ressembler à une documentation technique.
Ce va-et-vient prend dix minutes. Pas une heure. Le skill fait maintenant une vingtaine de lignes. Il est précis, il porte mes critères, il spécifie le format. Il est prêt à être testé.
Le test, lancer un vrai cas
Un skill qui n'a pas été testé sur un cas réel ne vaut rien. C'est comme un formulaire qu'on n'a jamais rempli soi-même : on découvre les problèmes au premier usage.
Je prends des notes d'appel. Pas des notes parfaites, des notes comme celles qu'on griffonne vraiment. "Appel avec Sophie Marchand, DRH chez un éditeur SaaS, 45 personnes. Cherchent à refondre leur onboarding. Budget pas clair, elle a dit 'on a une enveloppe formation mais il faudrait que je vérifie'. Veut avancer vite, recrutent 10 personnes au S2. Mentionne son CEO, Thomas, qui 'veut que ça bouge'. Relance prévue jeudi."
Je colle ces notes dans Claude, dans un projet où le skill est actif.
Le compte-rendu sort. Structuré, cinq sections, format respecté. La section qualification indique "budget : enveloppe formation mentionnée, montant non confirmé". La section signaux faibles a repéré la mention du CEO et l'urgence liée au recrutement S2. L'action suivante est "relance jeudi".
C'est propre. Mais un truc cloche.
Ce qu'on vérifie, et ce qu'on ajuste
La section "contexte de l'appel" fait huit lignes. C'est trop. Ma commerciale veut scanner le compte-rendu en trente secondes le lundi matin, pas lire un paragraphe. Le contexte doit tenir en deux lignes maximum.
Je retourne dans le skill et j'ajoute : "La section contexte ne dépasse pas deux phrases. Une pour le sujet de l'appel, une pour le contexte entreprise."
Deuxième ajustement : Claude a mis "prochaine action : relance jeudi" sans préciser le canal. Appel ? Mail ? LinkedIn ? Je rajoute dans le skill : "L'action suivante précise le canal et la date."
Je relance le test avec les mêmes notes. Le contexte tient en deux lignes. L'action suivante indique "relance par mail jeudi". Claude a inféré "mail" parce que les notes ne précisaient pas, et il a choisi le canal le plus probable. C'est discutable, mais au moins c'est explicite, et la commerciale corrigera en deux secondes si c'est faux.
Troisième test, avec des notes plus pauvres cette fois. "Appel rapide avec un prospect, secteur retail, pas très chaud, rappeler dans un mois." Le skill produit quand même un compte-rendu structuré, avec des "non mentionné" là où les infos manquent. C'est exactement ce que je voulais : le format tient même quand la matière est maigre.
Le skill est stable.
Ce que le skill cristallise
Pour écrire ce skill, la commerciale a dû faire quelque chose qu'elle ne fait jamais : articuler sa méthode. Poser les mots sur ce qu'elle vérifie dans un appel, sur l'ordre dans lequel elle lit un compte-rendu, sur ce qui fait qu'un compte-rendu lui est utile ou pas.
Ce travail d'articulation est le vrai produit. Le fichier texte du skill, c'est l'artefact. Ce qui a de la valeur, c'est le moment où la commerciale a formulé "si le budget n'est pas mentionné, je veux le voir écrit 'non évoqué', pas un blanc". Parce que ce critère, elle l'appliquait intuitivement depuis des années sans jamais l'avoir dit à personne.
J'ai vécu la même chose en construisant les skills de Pimpela. Chaque skill m'a forcée à décomposer un jugement que je portais sans y penser. Le style déco "campagne moderne", ce n'est pas un mot-clé. C'est un ensemble de critères visuels que j'ai dû lister un par un pour que Claude les applique. Les matériaux acceptables, les couleurs dominantes, le rapport entre éléments neufs et éléments anciens. Avant le skill, je savais reconnaître le style. Après le skill, je savais l'expliquer.
Un skill custom, ce n'est pas une automatisation. C'est une compétence métier rendue lisible, transmissible, reproductible. La commerciale qui a construit son skill de compte-rendu peut le partager à un collègue qui arrive dans l'équipe. Le collègue ne reçoit pas un modèle vide. Il reçoit une méthode de qualification encodée, avec les critères qui comptent et le format qui sert.
Le fichier fait vingt lignes. Il porte trois ans de terrain.