Claude oublie. C'est dans sa nature.
Tu passes une heure avec Claude. Tu lui expliques ton contexte, tes préférences, ta façon de formuler les choses. Il comprend vite. Il applique bien. Tu fermes la session, satisfaite.
Le lendemain, tu rouvres une conversation. Claude ne sait plus rien. Ton contexte, tes préférences, ta façon de formuler : disparu. Il faut tout reprendre.
Ce n'est pas un bug. C'est comme ça que Claude fonctionne. Chaque session est une page blanche. Ce que tu lui as dit hier n'existe plus aujourd'hui. Il n'a pas oublié par négligence, il n'a simplement jamais eu de mémoire persistante entre deux conversations.
Si tu utilises Claude pour des questions ponctuelles, ça ne pose pas de problème. Tu poses ta question, tu obtiens ta réponse, tu passes à autre chose. Mais si tu construis quelque chose avec lui sur la durée, un produit, un blog, un process métier, cette amnésie devient un vrai frein.
J'ai passé mes premières semaines avec Claude Code à réexpliquer les mêmes choses. Pas des choses compliquées. Mes choses à moi.
Le vrai problème : ta façon de faire, pas la façon de faire
Le problème n'est pas que Claude ne sache pas donner des idées d'articles, il sait le fait. Des idées génériques, mais lisible.
Le problème, c'est qu'il ne sait pas trouver des idées comme toi tu en voudrais.
Pour mon blog, j'ai des règles. Pas des règles formelles écrites dans un document qualité. Des réflexes, des choix accumulés. Je veux des idées d'articles ancrées dans du concret vécu, pas des concepts flottants qu'on pourrait lire sur n'importe quel blog.
Pas un standard éditorial universel.
Avant d'avoir trouvé la solution, chaque session commençait par le même rituel : je réexpliquais mon public, mon ton, mes interdits, mes critères. Parfois je copiais-collais un message d'une session précédente. Parfois je reformulais de mémoire, en oubliant la moitié. Claude appliquait ce que je lui donnais, mais ce que je lui donnais variait d'une session à l'autre parce que je n'avais pas envie de maintenir un document de briefing à jour.
Le résultat : des sorties inégales. Pas mauvaises. Inégales. Certaines sessions tombaient juste parce que j'avais pris le temps de bien réexpliquer. D'autres passaient à côté parce que j'avais zappé un critère.
Le vrai coût n'était pas le temps passé à réexpliquer. C'était l'inconsistance.
Un skill, c'est une fiche. Pas un script.
Dans Claude Code, un skill est un fichier texte. Un fichier en markdown, écrit en français, dans lequel tu décris une façon de faire. Ta façon de faire.
Ce n'est pas une commande. Ce n'est pas un programme. Ce n'est pas un automatisme qui se déclenche tout seul en arrière-plan. C'est une fiche que Claude peut consulter quand il rencontre une situation qui correspond.
L'image la plus juste que j'ai trouvée : dans une cuisine professionnelle, il y a souvent des fiches accrochées au mur ou glissées dans un classeur. Pas des robots qui cuisinent à ta place. Des fiches. « Pour la vinaigrette maison : huile d'olive, pas de tournesol. Moutarde à l'ancienne, jamais la lisse. Sel avant le vinaigre. » Le cuisinier sait faire une vinaigrette. La fiche lui rappelle comment on la fait ici.
Un skill, c'est ça. Claude sait écrire, structurer, analyser, proposer. Le skill lui rappelle comment on fait ça chez toi.
Concrètement, le fichier vit dans le dossier de ton projet. Claude le repère grâce à son nom et à son contenu. Quand tu lui demandes quelque chose qui entre dans le périmètre du skill, il le consulte et applique les règles qu'il y trouve. Tu n'as pas besoin de lui dire « va lire ma fiche ». Il la trouve.
Le skill backlog-blog : pourquoi je l'ai créé
Mon blog a une ligne éditoriale assez précise. J'écris pour des praticiennes non-tech qui veulent comprendre l'IA par les mains plutôt que par les concepts. Mes articles veulent être ancrés dans des projets réels, pas dans des réflexions abstraites.
Mon idée est de construire des projets, puis d'en tirer des enseignements. Et en général, à cet exercice, je manque de recul. Alors je demande à Claude, avec qui j'ai travaillé sur ces petits projets, de m'identifier les sujets qui pourraient être intéressants. Et là, miracle, il est 100 fois meilleur que moi à l'exercice.
Donc j'ai fini par lui faire une fiche de poste. Une seule fois.
Ce que la fiche contient
Mon skill backlog-blog tient en quelques centaines de mots. Il décrit :
Mon public cible, en termes concrets. Pas « les professionnels en reconversion digitale ». Plutôt : « des profils comme moi ou d'anciens collègues, qui sont compétents dans leur métier et débutants en IA, et qui veulent comprendre par les mains ».
Mes critères pour une bonne idée d'article. Une bonne idée est ancrée dans un cas réel, transmissible à quelqu'un qui n'est pas développeur, et pas vue-et-revue sur les blogs IA francophones. Si l'idée pourrait être le titre d'un post LinkedIn de coach, elle est mauvaise.
Ce que ça change, concrètement
A la fin de chaque session de travail je lui demande de me faire la liste des trois points dont je pourrais parler dans ce blog suite à la session d'aujourd'hui. Et il me les donne.
Claude consulte le skill. Les idées qu'il me propose sont ancrées dans des cas concrets. Aucune n'a un titre générique. Aucune ne portait sur « les 5 outils IA à connaître en 2025 ».
Je ne dis pas que tout était parfait. Sur six idées, j'en ai gardé trois, modifié une, jeté deux. C'est un ratio normal. Ce qui a changé, c'est le point de départ. Je ne partais plus de zéro. Je ne partais plus de propositions génériques qu'il fallait tordre dans tous les sens pour les rapprocher de ce que je voulais. Je partais de propositions qui connaissaient déjà mes règles.
La différence entre Claude sans le skill et Claude avec, ce n'est pas une différence d'intelligence. C'est une différence de contexte. Sans le skill, Claude est un fournisseur d'idées compétent qui ne te connaît pas. Avec le skill, c'est le même fournisseur, mais il a lu ton brief une fois et il s'en souvient à chaque session.
Ta façon de faire mérite une fiche
Tu n'as pas besoin de tenir un blog pour avoir des skills à écrire. Si tu as un geste professionnel que tu fais régulièrement, avec des règles qui te sont propres, tu as le matériau.
Je pense à une amie RH qui rédige ses fiches de poste en commençant toujours par la même question : « Pourquoi quelqu'un quitterait ce poste dans six mois ? » C'est sa méthode. Elle l'a rodée sur des dizaines de recrutements. Elle sait que ça force à écrire des fiches honnêtes, qui attirent les bons profils et repoussent les mauvais. Chaque fois qu'elle utilise Claude pour l'aider à rédiger une fiche, elle doit réexpliquer cette approche. Un skill réglerait ça.
Je pense aussi à une responsable com que j'ai croisée en formation, qui transforme chaque réunion d'équipe en plan d'action selon une structure très personnelle : trois décisions, un blocage identifié, un propriétaire par action, zéro « à suivre ». Elle pourrait écrire ça en dix minutes et ne plus jamais avoir à le réexpliquer à Claude quand elle lui demande de structurer ses notes de réunion.
Ou une contrôleuse de gestion qui formate ses reportings mensuels avec une règle simple : chaque chiffre doit être accompagné de sa variation et d'une phrase d'explication en langage non-financier, parce que ses reportings sont lus par des opérationnels, pas par des financiers. Cette règle de lisibilité, c'est la sienne. Elle l'a construite en constatant que personne ne lisait ses reportings quand ils étaient écrits en jargon finance.
Dans chaque cas, le skill n'est pas un outil technique. C'est une capitalisation sur ce que tu as déjà rodé. Tu écris ta méthode une fois, en français, dans tes mots, et Claude la connaît pour toutes les sessions à venir.
A et ça marche dans tous les Claude (chat, cowork et code) !