2/4. Exemple de structure de projet

Après avoir vu les cinq niveaux d’instructions, place à l’application concrète : un projet de freelance WordPress pour la rédaction de posts LinkedIn. L’exemple sert de fil conducteur pour montrer comment répartir les instructions à chaque niveau, du plus global au plus précis.

Un point important avant de commencer : il ne faut pas se laisser impressionner par la quantité d’instructions possibles. Il n’est pas nécessaire de tout planifier seul. On peut se faire accompagner par Claude lui-même pour rédiger ces instructions et réfléchir à leur répartition — l’exemple qui suit a d’ailleurs été rédigé presque intégralement par Claude, à titre indicatif plutôt que comme un modèle parfait.

Niveau 1 : instructions générales de Claude

Dans les réglages de l’application, on définit l’identité professionnelle de façon large : « Julien Martin, freelance WordPress depuis plusieurs années, basé à Lyon », le type de clients visés, la stack principale (WordPress, Bricks Builder, telles extensions SEO et performance).

On y ajoute aussi des consignes de comportement, pas seulement du contexte :

  • ton direct, pédagogue, sans jargon non expliqué ;
  • réponses structurées et concises plutôt que de longs paragraphes ;
  • réponses en français ;
  • pas d’émojis sauf demande explicite.

Ce niveau s’applique à 100 % des conversations, tous contextes confondus (chat, CoWork, code). L’intérêt de ces consignes comportementales est double : elles évitent le blabla inutile et réduisent la consommation de tokens en sortie.

Niveau 2 : instructions globales CoWork

Ici, on met uniquement des règles techniques propres à l’usage de CoWork — l’IA agissant directement sur l’ordinateur, ces instructions servent de garde-fous :

  • ne jamais supprimer un fichier sans confirmation explicite ;
  • avant de modifier un fichier important (livrable, document client, contenu publié), en dupliquer une copie dans un sous-dossier backup avec un suffixe dédié ;
  • ne jamais écraser un fichier existant sans prévenir ;
  • jamais de commande destructrice au niveau du terminal sans validation.

La duplication systématique avant modification est une bonne pratique à généraliser à tous les projets : ça ne coûte presque rien en espace disque (surtout pour du Markdown) et ça garantit un historique de secours permanent. Une seule instruction globale suffit à instaurer ce réflexe partout.

Niveau 3 : instructions du projet

Dans le projet CoWork « Freelancing LinkedIn », le champ d’instructions dédié permet de donner le contexte d’origine : cible, cadence de publication (deux à trois posts par semaine), angles éditoriaux autorisés (retour d’expérience, vulgarisation, opinions tranchées sur le marché WordPress, études de cas), objectif de chaque post (éduquer puis déclencher un DM vers Calendly).

Recommandation : rester léger à ce niveau — un à deux paragraphes suffisent généralement. L’essentiel du travail de structuration doit plutôt se faire au niveau 4, dans le fichier claude.md.

Niveau 4 : le fichier claude.md du projet

C’est le niveau qui accueille le plus de détail, organisé en Markdown :

  • Structure du dossier — description des sous-dossiers (brouillons, publié, idées, backup, etc.), avec consigne de les créer automatiquement s’ils n’existent pas.
  • Conventions de nommage — potentiellement redondantes avec le niveau 2, mais utiles quand une précision spécifique au projet s’impose.
  • Front matter YAML — métadonnées associées à chaque post créé (date, statut, angle choisi, etc.).
  • Règles d’exécution — par exemple : avant d’écrire un post, toujours lire les fichiers de référence (/references/ton-de-voix.md, template-post.md), ne jamais déplacer un brouillon vers « publié » sans validation à l’écran, générer plusieurs variantes sur demande.

Niveau 5 : les fichiers référencés

Le fichier claude.md pointe vers des fichiers séparés — ton de voix, stratégie éditoriale, calendrier — qui seront lus par Claude avant d’agir. Ce pointage peut en théorie se faire à n’importe quel niveau (2, 3 ou 4), mais il se fait le plus souvent depuis le claude.md, projet par projet.

Séparer forme et fond dans deux fichiers distincts est une bonne pratique : un fichier capture la manière de s’exprimer (élaboré via une interview avec l’IA), l’autre capture le fond — les opinions et positions réelles sur les sujets abordés.

Test concret

Une fois la structure en place, une simple demande — « rédige mon prochain post LinkedIn » — suffit à observer le comportement de Claude : il lit automatiquement le claude.md, sans qu’on le lui demande.

Dans cet exemple, les fichiers de référence pointés (ton de voix, stratégie) n’existaient pas encore, car ils avaient été créés dans le cadre d’un autre projet en amont de la formation. Claude a détecté seul cette incohérence : le fichier claude.md mentionnait « Julien Martin », mais le fichier strategie.md (créé lors d’une leçon précédente) était rédigé pour « Alexis ».

Ce test, même imparfait, illustre un point clé : Claude lit réellement les instructions à chaque niveau et est capable de repérer les contradictions entre elles plutôt que de les ignorer silencieusement.