Transformer une note Obsidian en consigne claire pour Claude Code

La semaine dernière, j’avais laissé une note de 2000 caractères dans Obsidian, puis le lendemain j’ai simplement demandé à Claude Code : « le bouton du paiement, corrige-le ».

Ce que j’ai reçu, c’est bien plus que la correction du bouton : un ajustement des marges du header, un réordonnancement des liens du footer, et au passage trois fichiers de diff pour « nettoyer » les conventions de nommage CSS. Je n’avais rien demandé de tout ça. Pourquoi ? Parce que j’avais collé ma note entière. Même un « tiens, ça aussi ça me dérange » griffonné trois jours plus tôt avait été lu avec le même poids que la consigne du jour.

La note n’était pas le problème. Le problème, c’était moi : je croyais qu’une note se transmettait « telle quelle ». Une longue note est parfaite pour archiver, mais inutile comme consigne de travail. Aujourd’hui, je décris le format qui comble cet écart, c’est-à-dire la méthode pour transformer une note Obsidian en une consigne courte.

Points clés

• Coller une longue note entière empêche l’IA de distinguer un vieux griffonnage de la consigne du jour, et elle élargit le travail à des choses que vous n’aviez pas demandées.
• On ne transmet que quatre choses : « les faits établis », « les décisions prises », « ce qu’on ignore encore » et « la prochaine action ». On y ajoute « les zones à ne pas toucher » et « la preuve qu’on a fini ».
• Réduisez la condition d’arrêt : un seul fichier, un seul écran, une seule commande, et vérifiez le build et la capture d’écran avant de passer à la suite.
• Le modèle de prompt et le petit script de conversion sont copiables tels quels.
• On délègue à l’IA « écrire, chercher, corriger ». L’humain tranche « le périmètre, la priorité, le feu vert à la publication ». Mélanger les deux provoque l’accident.

Pourquoi tout coller fait déborder le travail

Claude Code agit vite. C’est justement pour ça que si la première information transmise est large, il fonce à pleine vitesse dans cette largeur.

Une note contient des décalages temporels. Le fait du jour « le bouton passe sur deux lignes » et l’impression d’il y a une semaine « tiens, les couleurs font peut-être un peu vieillot » figurent côte à côte, dans la même liste à puces. Un humain lit la différence grâce à la date ou au contexte, mais l’IA à qui on a collé le bloc ne sait pas laquelle de ces consignes est encore vivante. Résultat : par gentillesse, elle touche à tout.

Autre chose. Une note mélange « les décisions prises » et « ce sur quoi on hésite encore ». Si la partie hésitation est lue comme une consigne, l’IA décide elle-même d’un côté ou de l’autre et avance. C’est le plus effrayant. Il faut donc trier une seule fois, du côté humain, avant de transmettre.

On ne transmet que quatre choses

L’axe de tri est simple : il suffit de répartir entre ces quatre catégories.

1. Faits : ce qu’on a réellement vérifié. « Sur un écran de 375 px, le bouton passe sur deux lignes », « l’URL publique est correcte » : tout ce sur quoi n’importe qui serait d’accord en regardant.
2. Décisions : ce qui est déjà tranché. « Le PDF gratuit passe avant le guide payant » : une orientation déjà débattue qu’on ne bouge plus.
3. Inconnues : ce qu’on ignore encore. « On ne sait pas quel composant porte la marge du bouton » : les trous qu’on ne veut surtout pas voir l’IA combler toute seule.
4. Prochaine action : la seule chose à faire cette fois. Aussi concret que « identifier le composant, appliquer le plus petit changement CSS possible, vérifier en largeur mobile ».

On y ajoute deux choses : les zones à ne pas toucher (ex. : on ne touche pas aux fichiers d’authentification cette fois) et la preuve qu’on a fini (ex. : le build passe, capture d’écran en largeur mobile). Ces six points constituent le contenu de la consigne.

Pendant le tri, l’important est de ne pas effacer les « inconnues ». Si on laisse honnêtement ce qu’on ignore, l’IA pose la question à cet endroit. À l’inverse, si on efface une inconnue en l’écrivant comme un fait, l’IA fonce sur une prémisse fausse.

Ce qu’on délègue à l’IA et ce que l’humain décide

On trace dès le départ la frontière entre ce qu’on peut confier et ce que l’humain doit garder. Si cette ligne est floue, même avec une consigne bien faite, tout finit par dériver.

Étape	Délégué à l’IA	Décidé par l’humain
Périmètre	-	Sur quel fichier / écran se limiter
Recherche	Trouver le composant ou le code	La priorité de ce qu’on cherche
Implémentation	Écrire le plus petit changement	La limite du changement autorisé
Vérification	Lancer le build et les tests	Le feu vert final à la publication

Comme le montre le tableau, « chercher, écrire, lancer » sont les points forts de l’IA. En revanche, « jusqu’où aller » et « peut-on publier » restent dans la main de l’humain. Si vous écrivez cette ligne dans la consigne, l’IA s’arrête d’elle-même même quand elle tente d’élargir le périmètre.

Le modèle de prompt à copier-coller

Commencez par sélectionner votre note telle quelle et collez-la sous ce texte de demande. C’est une manière de faire faire le tri lui-même par l’IA.

Réorganise la note Obsidian suivante en une consigne courte pour Claude Code.
La sortie ne doit contenir que les rubriques ci-dessous, jette tout le reste.

- Faits : seulement ce qui est vérifié
- Décisions : les orientations qu'on ne bouge plus
- Inconnues : ne les comble pas, laisse-les comme inconnues
- Prochaine action : une seule chose à faire cette fois, de façon concrète
- Zones à ne pas toucher : fichiers ou fonctions à ne pas modifier cette fois
- Preuve : le moyen de juger qu'on a fini (build, capture d'écran, etc.)

Regroupe les vieilles impressions et les digressions dans un bloc séparé
« notes de référence », sans les mêler à la consigne.

Relisez la consigne produite et vérifiez seulement deux choses : aucune inconnue ne s’est transformée en fait, et la prochaine action se limite bien à une seule. Si tout est bon, collez ça directement dans CLAUDE.md ou dans le commentaire du ticket et demandez l’implémentation. La façon d’écrire CLAUDE.md est détaillée dans claude-md-best-practices.

Le script de conversion d’une note en consigne

Avant le travail manuel, voici un petit code pour intégrer la structure dans vos réflexes. Il tourne sous Node.js. Il garde la note répartie selon les six points ci-dessus et assemble une consigne d’une seule page à passer à Claude Code.

// Garder la note répartie en « faits, décisions, inconnues, prochaine action »
const note = {
  title: "Le bouton du paiement passe à la ligne sur mobile",
  facts: ["Sur 375 px, le bouton passe sur deux lignes", "L'URL publique est correcte"],
  decision: "Le PDF gratuit passe avant le guide payant",
  unknowns: ["On ignore quel composant porte la marge du bouton"],
  nextAction: "Identifier le composant, appliquer le plus petit changement CSS, vérifier en largeur mobile",
  doNotTouch: ["Les fichiers d'authentification"],
  proof: ["Le build passe", "Capture d'écran en 375 px"],
};

// Assembler les six points en une consigne d'une page
function toBrief(item) {
  return [
    `Objectif : ${item.nextAction}`,
    `Faits : ${item.facts.join(" / ")}`,
    `Décision : ${item.decision}`,
    `Inconnues (ne pas combler) : ${item.unknowns.join(" / ")}`,
    `Zones à ne pas toucher : ${item.doNotTouch.join(" / ")}`,
    `Preuve : ${item.proof.join(" / ")}`,
  ].join("\n");
}

// Le gardien qui vérifie mécaniquement les oublis de tri
function checkBrief(item) {
  const missing = [];
  if (item.facts.length === 0) missing.push("faits");
  if (item.unknowns.length === 0) missing.push("inconnues");
  if (!item.nextAction) missing.push("prochaine action");
  if (missing.length) {
    throw new Error(`Tri incomplet : ${missing.join(", ")}`);
  }
  return true;
}

checkBrief(note);
console.log(toBrief(note));

checkBrief est discret mais essentiel. Si vous tentez de sortir une consigne avec des faits vides, des inconnues vides ou une prochaine action vide, ça s’arrête ici. Interdire le « bon, je colle quand même » dès l’étape du code réduit les accidents où une note bâclée file directement à l’IA. Collez la sortie telle quelle dans un commentaire de ticket ou une note de passation, et vous réutiliserez le même jugement au travail suivant. Pour rédiger une note de passation, claude-code-session-handoff-template sert de référence.

Les situations où ça marche

1. Quand on demande l’amélioration d’un article Si vous lancez « améliore cet article » sans rien d’autre, l’IA a tendance à tout réécrire. Alors écrivez dans la consigne « ne transmets que l’intention de recherche et la politique de CTA », « réécriture intégrale du corps interdite ». On répartit : les faits sont les titres actuels, la décision est l’orientation du parcours, l’inconnue est le paragraphe faible, la prochaine action ne corrige qu’un seul titre. Le diff devient petit et le retour en arrière instantané. Le réglage de la liaison avec Obsidian lui-même est résumé dans claude-code-obsidian-integration.

2. Quand on corrige un bug L’astuce est de séparer le fait reproduit de la cause encore inconnue. « Sur 375 px, le bouton passe à la ligne » est un fait ; « quel composant porte la marge » est une inconnue. Si vous mélangez les deux en écrivant « la cause doit être dans le CSS », l’IA se met à corriger sur une mauvaise piste. En transmettant l’inconnue comme inconnue, l’IA commence par enquêter à cet endroit.

3. Quand on reçoit une demande d’accompagnement On ne montre pas la note métier du client telle quelle : on la répartit en « périmètre qu’on touche cette fois », « zones qu’on ne touche jamais », « ce qu’on vérifiera la prochaine fois ». On ne laisse pas l’IA toucher automatiquement aux données de production ou à la facturation tant qu’elles sont inconnues. Écrire cette frontière dans la consigne suffit à partager son écran sereinement pendant le rendez-vous.

Les erreurs fréquentes et comment les corriger

Mes premières bourdes se résument à peu près à ces trois-là.

La première : avoir collé tout le vault. Les vieilles décisions et les contraintes actuelles se sont mélangées, et l’IA ne savait plus laquelle croire. La correction est simple : trier dans les six points avant de coller. L’impression d’il y a trois jours est isolée dans les « notes de référence ».

La deuxième : n’avoir transmis que la décision. Quand j’ai écrit seulement « le PDF passe devant », l’IA, ne sachant pas pourquoi, a fait l’inverse dans une autre situation. En gardant le fait et la raison ensemble, ça se généralise.

La troisième : avoir fait trop grande la condition d’arrêt. Demandez « mets tout au propre » et l’IA, par gentillesse, élargit le périmètre. Limitez à un fichier, un écran, une commande, et regardez le build et la capture avant la suite. Rien que ça réduit le temps de retour en arrière sans perdre en vitesse. Pour resserrer un prompt, voyez aussi claude-code-prompt-engineering-advanced.

FAQ

Q. Faire une consigne, n’est-ce pas plus de travail que coller toute la note ? Les premières fois, oui, on a cette impression. Mais le temps passé à relire et annuler les diffs qui ont débordé pèse plus lourd à long terme. Une fois habitué, le tri prend une minute.

Q. Peut-on aussi faire faire le tri par l’IA ? Oui. Le modèle de prompt ci-dessus est exactement cet usage. Mais relisez une fois la consigne produite et vérifiez seulement qu’aucune inconnue ne s’est muée en fait.

Q. Quelle différence entre CLAUDE.md et la consigne ? CLAUDE.md est le dépôt des règles qui ne changent pas pour tout le projet ; la consigne est une demande pour une seule session de travail. Si une « décision » revient sans cesse dans vos consignes, c’est le signal de la promouvoir dans CLAUDE.md.

Q. Ça marche même sans Obsidian ? Oui. Notion ou une simple note texte conviennent aussi. L’important n’est pas l’outil, mais la façon de penser : répartir en faits, décisions, inconnues et prochaine action.

Q. Jusqu’où déléguer à l’IA et à partir d’où l’humain décide ? « Chercher, écrire, lancer » : déléguez sans crainte. « Jusqu’où élargir le périmètre », « peut-on publier » : l’humain garde la main. L’astuce est d’écrire cette ligne dans la consigne. Les bases de la délégation à l’IA sont expliquées dans claude-code-for-non-engineers.

Ce que j’ai vraiment obtenu en l’essayant

Après « l’accident des trois fichiers non demandés » du début, je trie systématiquement dans les six points avant de coller une note.

J’ai refait passer la même correction du bouton de paiement, cette fois sous forme de consigne. Le diff : un seul fichier, quelques lignes de CSS. Ni le header ni le footer, rien de ce que je n’avais pas demandé n’a été touché. checkBrief m’a aussi arrêté une fois parce que je tentais de sortir avec l’inconnue vide ; le fait d’avoir ajouté « quel composant porte la marge » avant de transmettre a, je crois, aidé. L’IA a commencé par chercher ce composant.

J’ai vérifié deux choses. Que « laisser une inconnue pousse l’IA à enquêter au lieu de combler toute seule ». Et que « limiter la prochaine action à une seule rend le diff petit et facile à annuler ». Plutôt que de chercher le prompt malin, la minute de tri avant de transmettre reste, au final, la plus rapide. C’est mon ressenti actuel.

Une fois à l’aise avec le tri des notes, si vous voulez faire tourner le même format dans toute l’équipe, je propose aussi un accompagnement pour concevoir ensemble la marche à suivre.

Vous pouvez vérifier les prérequis officiels sur Anthropic Claude Code getting started.