Transformer une note Obsidian en demande que Claude Code implémente aujourd'hui

Vendredi soir, j’ai laissé dans Obsidian une note vite griffonnée : « L’incitation à l’inscription me semble faible. Beaucoup de gens ne voient le lien du PDF gratuit qu’après avoir scrollé. » Lundi matin, j’ai collé cette note entière dans Claude Code en lui demandant « corrige ça ». Ce qu’il m’a renvoyé, c’était deux écrans entiers de « voici la situation actuelle ». Pas une seule ligne de code.

La note n’était pas mauvaise. Le problème, c’est que je l’ai transmise telle quelle. Ce jour-là, j’ai perdu trente minutes à me faire réexpliquer le contexte que je connaissais déjà.

Le savoir s’accumule dans Obsidian, et pourtant je réécris à chaque fois le même préambule pour Claude Code. Si ça vous parle, ce qui vous manque n’est pas une IA plus intelligente : c’est un format pour réduire une note en une vraie demande.

Points clés

• Coller une note Obsidian telle quelle transforme Claude Code en preneur de notes et retarde l’implémentation. On ne transmet pas le texte entier, mais une seule tâche bouclable aujourd’hui.
• On extrait de la note six éléments seulement : objectif, périmètre intouchable, premier geste, méthode de vérification, parcours, retour arrière.
• Écrire d’abord « ce qu’il faut lire » et « ce qu’il ne faut pas toucher » fait disparaître les dérapages vers le paiement ou l’authentification.
• Une fois rédigée, la demande se transforme en gabarit qu’on range dans Obsidian, pour ne plus repartir de zéro la fois suivante.
• Au lieu de croire le rapport de fin, on tranche sur des preuves : capture d’écran, sortie du build, diff.

Pourquoi il ne faut pas tout transmettre

Une note Obsidian est une lettre à votre futur vous. Le contexte, les hésitations, tout y est. C’est précisément pour ça que, transmise à l’IA, elle déclenche un réflexe : « tout lire et tout comprendre ».

Un collègue humain lirait la longue note et la réduirait de lui-même : « En gros, c’est la position du lien d’incitation. » Claude Code ne fait pas preuve de cette intuition. Plus vous lui donnez de texte, plus il vous rend un résumé soigné, proportionnel au volume reçu. C’est gentil, mais ce n’est pas un résumé que je veux.

Alors avant de transmettre, on coupe côté humain. Sur une note de mille caractères, on ne garde que les trente caractères nécessaires à l’implémentation. Ce travail de réduction est justement le raccourci qui supprime le préambule de chaque fois.

Si vous voulez déléguer le rangement même des notes à Claude Code, lire d’abord les bases de l’intégration avec Obsidian rendra la méthode de cet article plus facile à enchaîner.

Les six éléments à extraire de la note

À chaque fois, je ne tire de la note que ces six éléments. Peu importe qu’ils n’y figurent pas tous : les cases manquantes, je les décide moi-même au moment de couper.

Élément	Contenu	Exemple
Objectif	Le résultat pour l’utilisateur, en une phrase	Le visiteur voit le lien du PDF gratuit avant de scroller
Périmètre intouchable	Ce qu’on ne veut pas casser	Le paiement, la connexion, l’affichage mobile
Premier geste	Par où commencer	Ajouter une section sur le premier écran de la page d’accueil
Méthode de vérification	De quoi juger que c’est fini	Le build passe, le diff des changements, le rendu de l’URL publique
Parcours	Où l’on envoie le lecteur ensuite	La page d’inscription au PDF gratuit
Retour arrière	L’issue de secours en cas d’échec	Il suffit d’annuler ce seul commit

Le point crucial, c’est le « périmètre intouchable ». Laissez cette case vide, et l’on vous répondra qu’en corrigeant le lien, le code du paiement a été « rangé au passage ». Tracer d’abord la zone interdite, c’est ce qui marche le mieux.

Ce qu’on délègue à l’IA, ce qu’on décide soi-même

Mélanger les deux, c’est l’accident assuré. Posons une frontière nette.

• L’humain décide : objectif, périmètre intouchable, retour arrière. Ce sont des choix métier, on ne les confie pas à l’IA en bloc.
• On délègue à l’IA : la concrétisation du premier geste, l’écriture du code, l’exécution des commandes de vérification.
• L’humain regarde à la fin : le rendu de l’URL publique et la conformité du diff aux attentes. C’est le seul point qu’on vérifie de ses propres yeux.

On peut confier le « comment construire », jamais le « quoi protéger ». Décider ce qu’on protège revient toujours à l’humain.

Le gabarit de prompt pour convertir une note en demande

On met les six éléments extraits sous une forme directement transmissible à Claude Code. Copiez le gabarit ci-dessous et collez votre note à la fin, c’est tout.

Convertis la note Obsidian suivante en UNE demande que tu peux implémenter aujourd'hui.
Structure la sortie sous les six titres ci-dessous. N'écris pas encore de code.

- Objectif (le résultat pour l'utilisateur, en une phrase)
- Périmètre intouchable (ce qu'il ne faut pas modifier)
- Premier geste (un seul changement minimal)
- Méthode de vérification (build, diff, URL publique, etc.)
- Parcours (où envoyer le lecteur ensuite)
- Retour arrière (comment revenir en arrière en cas d'échec)

[Note]
(collez ici la note Obsidian)

Le plus important, c’est la dernière phrase : « N’écris pas encore de code. » Sans elle, Claude Code essaie d’enchaîner conversion et implémentation, et saute la vérification du périmètre intouchable. On lui fait d’abord produire la demande, l’humain contrôle la zone interdite, puis on répond « maintenant, implémente exactement selon cette demande ». Ce dispositif en deux temps réduit les accidents.

Pour affiner encore la précision du gabarit, j’ai rassemblé les tournures fines dans les techniques avancées de conception de prompts pour Claude Code.

Un script de conversion prêt à copier-coller

Si assembler le prompt à la main vous lasse, écrivez la note sous forme d’objet et générez la demande automatiquement. Avec Node.js installé, ça tourne tel quel.

// Script minimal pour convertir une note en « demande implémentable aujourd'hui »
// Usage : node note-to-issue.mjs

const note = {
  objectif: "Le visiteur voit le lien du PDF gratuit avant de scroller",
  perimetreIntouchable: ["paiement", "connexion", "affichage mobile"],
  premierGeste: "Ajouter une section d'annonce sur le premier écran de l'accueil",
  verification: ["le build passe", "le diff des changements", "le rendu de l'URL publique"],
  parcours: "La page d'inscription au PDF gratuit",
  retourArriere: "Annuler ce seul commit suffit à revenir en arrière",
};

function toIssuePrompt(n) {
  // Repérer un champ requis manquant AVANT de produire la demande
  const required = ["objectif", "perimetreIntouchable", "premierGeste", "verification"];
  const missing = required.filter((key) => {
    const v = n[key];
    return v === undefined || (Array.isArray(v) && v.length === 0);
  });
  if (missing.length > 0) {
    throw new Error(`Champs requis manquants pour la demande : ${missing.join(", ")}`);
  }

  const line = (label, value) =>
    `${label} : ${Array.isArray(value) ? value.join(" / ") : value}`;

  return [
    line("Objectif", n.objectif),
    line("Périmètre intouchable", n.perimetreIntouchable),
    line("Premier geste", n.premierGeste),
    line("Vérification", n.verification),
    line("Parcours", n.parcours),
    line("Retour arrière", n.retourArriere),
    "N'écris pas encore de code ; renvoie seulement le plan d'implémentation minimal dans ce périmètre.",
  ].join("\n");
}

console.log(toIssuePrompt(note));

À l’exécution, vous obtenez la demande : six lignes plus la phrase finale. Repassez le script avec perimetreIntouchable mis à un tableau vide, et il s’arrête sur « Champs requis manquants » avant même de produire la demande. C’est le code qui bloque en amont l’accident le plus banal : transmettre une case laissée vide.

Trois situations où ça marche vraiment

1. La note d’amélioration d’un lien d’incitation La note « le lien du PDF gratuit est faible » collée telle quelle déclenche un flot d’explications sur les pistes d’amélioration. Réduite en demande, le premier geste se resserre sur un seul point — « ajouter une section au premier écran » — et le paiement reste hors de portée. En comparant le rendu avant/après sur l’URL publique, on juge l’effet de ses yeux, pas à l’intuition.

2. La note d’investigation d’un bug La note « parfois l’écran devient blanc après la connexion » contient trop d’informations. Dans la demande, on resserre le premier geste sur « partager d’abord uniquement les conditions de reproduction et les logs d’erreur ». En faisant d’abord se concentrer sur la reproduction, sans enchaîner enquête et correction, on évite les correctifs à côté de la plaque.

3. La note de planification d’un article Même une note floue comme « le prochain article, bien poser les liens internes » devient implémentable en réduisant l’objectif à « fixer deux liens internes vers des articles connexes ». En mettant « le build passe » comme vérification, on bloque les liens morts avant publication. Avant de déléguer le travail éditorial, se faire la main avec l’introduction à Claude Code pour les non-développeurs met en confiance.

Garder la demande comme gabarit

Une demande rédigée une fois, je ne la jette pas : je la renvoie dans Obsidian. La prochaine note similaire, je réutilise les six titres tels quels.

J’ai créé une note unique, templates/issue-prompt.md, où je garde le gabarit vide des six titres. Quand une nouvelle note arrive, je copie ce gabarit et je le remplis, point. Le temps passé à réécrire le préambule a disparu.

Mieux encore : en fixant dans le projet les règles que Claude Code doit lire, la demande raccourcit encore. Confiez les conventions communes au projet à la façon d’écrire un CLAUDE.md, et vous n’aurez plus à les répéter dans chaque demande.

Pièges fréquents et comment les corriger

Voici les erreurs que j’ai commises au début, avec leur correctif.

• Coller toute la note : Claude Code devient preneur de notes. Correctif : réduire aux six éléments avant de coller. Une note qu’on n’arrive pas à réduire est la preuve qu’elle n’est pas encore une demande mûre — écrivez d’abord vous-même une conclusion en une phrase.
• Ne pas écrire le périmètre intouchable : ça déborde sur le paiement ou l’authentification. Correctif : ne pas tolérer la case vide, et ne pas écrire « rien de particulier » non plus. Prenez l’habitude de citer au moins une zone interdite.
• Une vérification du type « si ça tourne, c’est bon » : il ne reste qu’à croire le rapport de fin. Correctif : imposer au moins l’un des trois — sortie du build, diff, URL publique.
• Faire implémenter d’un coup : conversion et implémentation se mélangent, le contrôle de la zone interdite saute. Correctif : toujours inclure « N’écris pas encore de code », contrôler la demande, puis seulement demander l’implémentation.

Aucun de ces pièges n’aurait existé si une seule ligne avait été décidée à l’avance.

FAQ

Q. Ma note est fragmentaire, je n’arrive pas à remplir les six éléments. Pas besoin de tout remplir. Décider au minimum l’« objectif » et le « périmètre intouchable » suffit à en faire une demande. Le reste, vous pouvez le compléter après coup, en regardant les propositions de Claude Code.

Q. Faut-il une intégration qui fait lire les notes Obsidian directement par Claude Code ? Au début, non. Copier la note à la main et la coller dans le gabarit fonctionne très bien. Vous envisagerez l’automatisation une fois que vous répéterez ce geste souvent — ce ne sera pas trop tard.

Q. Même en écrivant « N’écris pas encore de code », il commence à implémenter. Inscrire dans le CLAUDE.md du projet « ne pas écrire de code lors de la conversion d’une demande » stabilise le comportement. Une règle commune au projet est mieux respectée qu’une consigne donnée une seule fois dans un prompt.

Q. Quelle longueur de demande est appropriée ? Je vise une dizaine de lignes au total sur les six titres. Au-delà, c’est le signe que plusieurs objectifs se mélangent dans une seule tâche. Découpez la tâche.

Q. Je ne sais pas quoi mettre comme méthode de vérification. En cas de doute, commencez par deux choses : « le build passe » et « le rendu de l’URL publique ». Ces deux-là suffisent à sortir de l’état où l’on gobe le rapport de fin.

Ce que ça a donné en pratique

J’ai repris la note du lien d’incitation du début, je l’ai réduite avec ce gabarit de six éléments, puis je l’ai redonnée à Claude Code. Cette fois, pas de résumé : il a d’abord sorti un plan d’implémentation, « ajouter une section d’annonce sur le premier écran ». Le paiement, cité dans le périmètre intouchable, n’a pas été touché du tout.

Côté script de vérification, en le lançant avec perimetreIntouchable volontairement vide, il s’est arrêté sur « Champs requis manquants » avant de produire la demande. J’ai pu confirmer que l’accident le plus courant — transmettre une case vide — se bloque avant l’exécution.

Plutôt que d’inventer une consigne maligne à chaque fois, avoir un format pour réduire la note va plus vite. C’est mon ressenti actuel. Si vous voulez étendre la même méthode à la rédaction d’articles ou au support client de votre équipe, la formation et le conseil pour les entreprises permettent de construire le format au plus près de votre exploitation réelle. Les critères officiels se vérifient dans la documentation officielle d’Anthropic.