Skip to content

manuel-github-claude-code.md

Latest commit

 

History

History
938 lines (637 loc) · 47.5 KB

manuel-github-claude-code.md

File metadata and controls

938 lines (637 loc) · 47.5 KB
Raw
title Manuel GitHub & Claude Code pour indépendants et créatifs

Manuel GitHub & Claude Code pour indépendants et créatifs

Version du 23 juillet 2026

Ce manuel réunit en un seul fil de lecture deux outils souvent présentés séparément : GitHub, pour organiser et tracer un projet, et Claude Code, un assistant qui travaille à l'intérieur de ce projet. L'objectif est de les comprendre, puis de les combiner dans un flux de travail simple et fiable.

Sommaire

À qui s'adresse ce manuel ?

Ce manuel s'adresse aux indépendants, créatifs, consultants, auteurs, designers, photographes, formateurs, responsables associatifs, petites équipes et profils non développeurs qui veulent organiser, relire, documenter et faire évoluer des projets.

Il peut servir à une graphiste qui suit l'évolution d'une identité visuelle, à un consultant qui documente une mission, à une autrice qui prépare un guide, à une équipe culturelle qui coordonne une exposition, à un studio qui gère des retours client, ou à un indépendant qui veut rendre son travail plus traçable.

Il ne suppose aucune culture de développement logiciel. L'idée centrale est simple : ni GitHub ni Claude Code ne sont réservés au code. Dès qu'un projet contient des fichiers, une structure, des versions, des décisions et des retours, ces deux outils aident à y voir clair.

La bonne image mentale

Imaginez GitHub comme un dossier de projet vivant.

Dans un dossier classique, vous accumulez souvent des fichiers nommés ainsi :

  • proposition_finale.pdf
  • proposition_finale_v2.pdf
  • proposition_finale_v2_corrigee.pdf
  • proposition_finale_v2_corrigee_CLIENT_OK.pdf

GitHub remplace cette accumulation par une logique plus propre : les fichiers restent à leur place, et GitHub garde l'historique des changements, les discussions et les décisions autour de ces fichiers.

On peut donc le voir comme un dossier partagé, un carnet de bord, un tableau de suivi, un espace de validation et une mémoire collective du projet.

Claude Code, lui, est l'assistant qui travaille dans ce dossier : il lit les fichiers, comprend l'organisation, propose des changements, modifie des documents et prépare une validation.

La bonne posture n'est pas : « L'outil décide à ma place. »

La bonne posture est : « L'outil analyse, prépare et propose ; je relis, je décide et je valide. »

Exemple concret
Vous préparez un dossier de marque pour un client. Au lieu d'envoyer dix versions du même PDF par e-mail, vous placez les éléments dans un dépôt GitHub, vous notez les demandes dans des issues, et vous demandez à Claude Code de résumer l'état du dossier, de transformer les retours en tâches et de préparer une checklist de validation.

Vocabulaire de base

Voici les mots à connaître, sans jargon inutile. Ils reviendront tout au long du manuel. Cette première approche est pédagogique : elle explique chaque notion dans son contexte. Un lexique de référence, sous forme de tableau, figure en annexe pour retrouver une définition d'un coup d'œil.

Côté GitHub

  • Dépôt (repository) : l'espace central d'un projet. C'est le dossier qui contient les fichiers, l'historique, les discussions et parfois un tableau de suivi.
  • README : la page d'accueil du dépôt. Elle explique le projet, son contexte, son organisation et les règles de collaboration.
  • Commit : l'enregistrement daté d'un changement, accompagné d'un court message.
  • Branche : une piste de travail séparée, pour essayer une modification sans toucher la version principale.
  • Issue : une fiche de suivi. Elle peut représenter une tâche, une question, un retour client, un problème ou une décision à documenter.
  • Pull request : une demande de validation pour intégrer des changements. Dans un contexte non technique, c'est une proposition de modification à relire avant adoption.
  • Merge : l'intégration d'un changement validé.

Côté Claude Code

  • Claude Code : un assistant qui travaille dans un projet réel, avec ses fichiers, sa structure et parfois son historique.
  • CLAUDE.md : un fichier d'instructions qui explique à Claude Code comment travailler dans ce projet (ton, public, structure, limites, validation).
  • Prompt : la consigne que vous donnez à l'assistant.
  • Surface : l'endroit où vous utilisez Claude Code (le web, le terminal, une application de bureau, un éditeur).

Exemple concret
Pour une exposition, vous créez un dépôt exposition-lumieres-2026. Le README présente le projet, chaque retour de partenaire devient une issue, et un CLAUDE.md indique à l'assistant de rédiger en français clair et de ne jamais publier d'information non validée.

Claude classique ou Claude Code ?

Il est utile de distinguer Claude Code de Claude conversationnel.

Besoin Claude classique Claude Code
Réfléchir à une idée Très adapté Possible, mais pas nécessaire
Rédiger un texte isolé Très adapté Possible
Lire tout un dossier de projet Limité aux fichiers fournis Très adapté
Modifier plusieurs fichiers Non, sauf copier-coller manuel Très adapté
Comprendre une arborescence Limité Très adapté
Préparer une validation de changements Possible Très adapté
Travailler avec GitHub Possible par discussion Adapté à un projet connecté

En résumé : Claude classique est un excellent partenaire de réflexion et de rédaction ; Claude Code est un assistant de travail dans un projet réel, souvent hébergé sur GitHub.

Partie 1 — Organiser son projet avec GitHub

GitHub devient utile dès qu'un projet a besoin de clarté. Il aide à répondre à des questions très concrètes : où est la dernière version ? Qui a demandé cette modification ? Pourquoi avons-nous choisi cette option ? Qu'est-ce qui reste à faire ? Qu'est-ce qui a été validé ?

Quand GitHub est une bonne idée

GitHub est pertinent pour :

  • un portfolio ou un site personnel ;
  • une documentation de formation ;
  • un guide de marque ;
  • un calendrier éditorial ;
  • une méthode de travail partagée ;
  • un dossier client évolutif ;
  • un projet associatif ou culturel ;
  • une base de ressources, modèles ou checklists ;
  • un projet où plusieurs personnes donnent des retours.

Il est moins adapté comme simple espace de stockage de fichiers lourds (médiathèque de vidéos ou de photos haute définition). Il affiche et compare certains fichiers non-code, mais ne remplace pas un Drive, un Dropbox ou un DAM professionnel.

Première prise en main

Créer son compte

Créez un compte personnel sur github.com. Choisissez un nom d'utilisateur, vérifiez votre adresse e-mail et complétez votre profil.

Conseil important : activez l'authentification à deux facteurs. C'est une protection supplémentaire contre les connexions non autorisées.

Créer un dépôt

Donnez au dépôt un nom clair, court et descriptif : minuscules, mots séparés par des tirets, en évitant les noms trop génériques comme projet-final. Préférez portfolio-photo-2026, guide-marque-atelier-nova ou calendrier-editorial-newsletter.

Choisissez ensuite la visibilité :

  • public : visible par tout le monde ;
  • private : visible seulement par vous et les personnes invitées.

Pour un projet client, choisissez presque toujours private.

Ajouter un README

Acceptez la proposition d'ajouter un README. Un bon README répond à cinq questions : de quoi parle le projet ? À qui sert-il ? Où trouver les fichiers importants ? Comment participer ou donner un retour ? Quel est l'état actuel du projet ?

Ajouter et organiser des fichiers

Vous pouvez ajouter des fichiers directement depuis le navigateur. Organisez le dépôt en dossiers au rôle clair, plutôt que tout mettre à la racine :

README.md
brief/
documents/
visuels/
modeles/
comptes-rendus/
archives/

Attention aux fichiers sensibles

Ne mettez jamais dans un dépôt public des données personnelles, des contrats confidentiels, des mots de passe, des clés d'accès ou des fichiers client non validés pour diffusion. Même dans un dépôt privé, si un fichier est vraiment sensible, demandez-vous s'il doit être sur GitHub.

Comprendre l'historique des versions

Chaque changement enregistré crée une trace. Pour qu'elle soit utile, écrivez des messages de commit lisibles.

Messages peu utiles : modif, update, final, corrections diverses.

Messages utiles :

  • Ajoute la structure du dossier client
  • Corrige les exemples du chapitre 2
  • Met à jour la checklist de validation

Exemple concret
Trois mois après une mission, un client demande pourquoi une section a été retirée du dossier. Grâce à l'historique, vous retrouvez le commit « Retire la section tarifs après arbitrage client » et l'issue liée à cette décision.

Utiliser les issues comme fiches de travail

Une issue peut être très simple : un titre, une description, une personne responsable, une étiquette et une discussion. Créez une issue pour une tâche à faire, un retour à traiter, une question à trancher, une décision à documenter, un problème à corriger ou une idée à garder.

Une bonne issue contient un titre clair, le contexte, le résultat attendu, les critères de validation et les liens utiles.

Exemple concret
Titre : « Clarifier la promesse de l'offre premium ». Contexte : le client trouve la page trop vague. Résultat attendu : reformuler l'introduction avec un bénéfice concret. Validation : relu par Claire avant vendredi.

Étiquettes utiles

Les labels aident à trier les issues : à faire, en attente client, à relire, bloqué, idée, urgent, contenu, design, administratif, validation.

Organiser le travail avec GitHub Projects

GitHub Projects est le tableau de pilotage du projet (table, kanban ou chronologie). Pour démarrer, trois colonnes suffisent : À faire, En cours, Terminé. Ajoutez ensuite En attente de retour, À valider, Bloqué, et des champs comme priorité, échéance, responsable ou statut client. Vous pouvez aussi regrouper les issues par jalon (milestone), par exemple autour d'une échéance de livraison.

Commenter, mentionner, décider

GitHub permet de commenter les issues, les pull requests et certains fichiers. Utilisez les commentaires pour clarifier le travail, pas pour disperser les décisions : une question par commentaire, une décision clairement formulée, une personne mentionnée avec @nom-utilisateur si son avis est attendu, un résumé quand la discussion s'allonge.

Relire et valider avec les pull requests

Le principe d'une pull request est simple : quelqu'un propose un changement, les autres le relisent, puis le changement est intégré. Concrètement, les changements sont d'abord préparés sur une branche — la piste de travail séparée évoquée plus haut — puis la pull request propose de les intégrer à la version principale. Pour un usage non technique, elle sert surtout à présenter une version à relire, rassembler les commentaires au bon endroit, vérifier ce qui change et conserver une trace de l'accord.

Utilisez une pull request quand le changement est important ou doit être relu (nouvelle version d'un README public, réorganisation d'un dossier, mise à jour d'un guide de marque). Pour une petite coquille, un commit direct suffit.

Travailler avec des fichiers non-code

GitHub peut afficher plusieurs types de fichiers utiles aux créatifs : Markdown, images, PDF, tableaux CSV, certains fichiers 3D et diagrammes Mermaid. Il peut aussi comparer certaines images entre deux versions. Pour des fichiers lourds ou très spécialisés, gardez les sources dans leur outil d'origine et utilisez GitHub pour la documentation, les exports, les retours et les décisions.

Partie 2 — Faire assister son projet par Claude Code

Claude Code est un assistant qui travaille dans un projet : il peut lire les fichiers, comprendre l'organisation, proposer des changements, modifier des documents et préparer une validation.

Ce que Claude Code peut faire pour vous

Claude Code peut aider à expliquer l'organisation d'un projet, retrouver les fichiers importants, améliorer un README, relire des textes, transformer des notes en tâches, préparer des checklists, organiser des livrables, documenter des décisions, résumer les changements récents, préparer une demande de validation et repérer les zones ambiguës, obsolètes ou redondantes.

Exemple concret
Pour un guide de formation, Claude Code peut relire tous les fichiers Markdown, repérer les doublons, proposer un ordre de lecture, signaler les passages trop techniques et préparer une version plus claire pour les apprenants — sans que vous ayez à ouvrir chaque fichier un par un.

Ce que Claude Code ne doit pas faire sans vous

Claude Code peut modifier des fichiers, mais gardez la main sur les décisions client, les informations sensibles, les engagements commerciaux, les prix, délais et conditions contractuelles, les formulations publiques importantes, les suppressions de fichiers et les validations finales.

Règle simple : demandez d'abord une analyse ou un plan, puis seulement ensuite une modification.

Analyse le projet et propose un plan.
Ne modifie aucun fichier tant que je n'ai pas validé le plan.
Signale les points ambigus ou risqués.

Choisir sa surface

Claude Code s'utilise sur plusieurs surfaces. Pour un public non développeur, le choix doit rester pragmatique.

Option Pour quoi faire ? Niveau conseillé
Claude Code sur le web Démarrer sans installation, lancer une tâche sur un dépôt GitHub Débutant accompagné
Application de bureau Suivre plusieurs sessions, relire visuellement les changements Débutant à intermédiaire
Terminal Travailler directement dans un dossier local Intermédiaire
VS Code ou JetBrains Travailler dans un éditeur avec vue sur les changements Intermédiaire
Automatisations Déclencher des tâches récurrentes ou des revues Avancé ou accompagné

Pour commencer : si votre projet est déjà sur GitHub, utilisez Claude Code sur le web. S'il est sur votre ordinateur et que vous êtes accompagné, utilisez le terminal ou l'application de bureau. Gardez les automatisations pour plus tard.

La méthode en cinq temps

La bonne façon de travailler avec Claude Code tient en cinq mouvements : analyser, planifier, modifier, résumer, valider.

1. Demander une lecture sans modification

Je découvre ce projet.
Explique-moi son organisation comme si je n'étais pas développeur.
Indique les fichiers importants, les zones floues et les améliorations possibles.
Ne modifie rien pour l'instant.

2. Demander un plan

Propose un plan d'amélioration du projet.
Classe les actions en trois niveaux : indispensable, utile, optionnel.
Pour chaque action, indique les fichiers concernés et le résultat attendu.
Ne modifie encore aucun fichier.

3. Autoriser une modification précise

Applique uniquement la première action du plan : améliorer le README.
Garde un ton accessible pour des partenaires non techniques.
Ne touche pas aux autres fichiers.

4. Demander une synthèse

Résume les changements effectués.
Indique les fichiers modifiés, les points à relire, les risques éventuels et la décision attendue avant validation.

5. Valider vous-même

Relisez toujours les fichiers modifiés. Claude Code accélère le travail, mais il ne remplace pas votre responsabilité de validation.

Le rôle de CLAUDE.md

CLAUDE.md est un fichier d'instructions placé à la racine du projet. Il note les règles du projet — ton, public, structure, limites, procédures de validation — pour éviter de répéter les mêmes consignes à chaque session.

Un bon CLAUDE.md répond à ces questions : quel est le projet ? Qui est le public ? Quel ton respecter ? Quels dossiers sont importants ? Que Claude Code peut-il proposer ? Que ne doit-il pas faire sans validation ? Quels points vérifier avant partage ?

Un modèle complet est fourni en annexe.

Exemple concret
Une consultante ajoute dans son CLAUDE.md : « Rédige en français clair, ne modifie jamais les fichiers du dossier contrats/, et signale toute information tarifaire au lieu de la reformuler. » À chaque nouvelle session, Claude Code applique ces règles sans qu'elle ait à les répéter.

Partie 3 — Combiner les deux

C'est ici que le manuel prend tout son sens. GitHub conserve et trace le projet ; Claude Code travaille dedans. Reliés, ils forment un flux simple où rien ne se perd et où l'assistant agit dans un cadre relu et validé.

Qui fait quoi

La règle reste constante à chaque étape : GitHub conserve, Claude Code prépare, vous décidez.

Moment GitHub : conserver & tracer Claude Code : analyser & proposer Vous : décider & valider
Démarrer un projet Accueille le dépôt, le README et la structure Explique l'organisation, repère les manques Choisissez la structure et les règles
Traiter un retour Garde le retour sous forme d'issue Transforme le retour en tâches claires Arbitrez et validez l'action
Préparer un livrable Conserve l'historique de chaque version Relit, prépare une checklist, résume les changements Relisez et approuvez la version
Publier une version Conserve la version publiée et ses fichiers Rédige le résumé des changements Décidez ce qui est publié

Le cycle de travail

  1. GitHub garde les fichiers et l'historique du projet.
  2. Claude Code lit le projet, propose un plan, puis modifie les fichiers demandés.
  3. Le changement est enregistré dans un commit, avec un message clair.
  4. Une pull request rassemble les changements pour qu'ils soient relus.
  5. Après validation, la pull request est intégrée (merge).

Visuellement, le cycle ressemble à ceci (ce schéma s'affiche automatiquement sur GitHub, qui sait lire les diagrammes Mermaid) :

flowchart LR
    A[GitHub<br/>fichiers et historique] --> B[Claude Code<br/>analyse et propose]
    B --> C[Commit<br/>changement enregistré]
    C --> D[Pull request<br/>relecture]
    D --> E{Validation<br/>humaine}
    E -->|Approuvé| F[Merge<br/>intégration]
    E -->|À revoir| B
Loading

À chaque étape, Claude Code peut préparer le travail : il rédige le message de commit, le brouillon d'une issue ou le texte d'une pull request. Mais la validation reste humaine : vous relisez avant d'enregistrer, d'ouvrir ou d'intégrer.

Trois gestes concrets

Faire résumer les changements avant un commit

Résume les changements en cours avant enregistrement.
Indique les fichiers modifiés, ce qui a changé et pourquoi.
Propose un message de commit clair en français.
N'enregistre aucun commit tant que je n'ai pas relu.

Transformer des notes ou des retours en issues

Transforme ces retours en issues prêtes à créer sur GitHub.
Pour chacune : un titre actionnable, le contexte, le résultat attendu et des critères de validation.
Regroupe les doublons et signale les demandes ambiguës.

Rédiger le texte d'une pull request de validation

Prépare le texte d'une pull request pour les changements récents.
Explique ce qui change, pourquoi, les fichiers concernés, les points à relire et la décision attendue.
Garde un ton accessible pour des relecteurs non techniques.

Ces trois gestes ne sont qu'un début. Ils illustrent le mécanisme le plus important de tout ce manuel, développé dans la section suivante.

Déléguer les tâches fastidieuses

C'est ici que se joue le vrai changement. La plupart des gens n'évitent pas GitHub parce qu'il est inutile, mais parce qu'il « fait technique » : la barrière n'est pas l'intérêt de l'outil, c'est le réflexe technique qu'il semble exiger.

Claude renverse ce rapport. Vous n'avez plus besoin de savoir comment structurer une issue, rédiger des notes de version ou trier un backlog. Vous décrivez en français clair ce que vous voulez ; Claude produit l'objet GitHub correctement formé ; vous relisez et vous validez. Le gain n'est pas seulement du temps : c'est l'accès à GitHub qui s'ouvre à des personnes qui s'en tenaient jusque-là à l'écart.

Le point commun des tâches à déléguer est simple. Ce sont des tâches répétitives, structurantes, et à faible enjeu de décision : le travail d'organisation et de mise en forme, pas le travail de choix. Le principe tient en une ligne :

matière brute → Claude structure → vous validez

Les tableaux ci-dessous listent, par famille, ce que vous pouvez déléguer. La dernière colonne est la plus importante : elle rappelle qu'à la fin, c'est toujours vous qui décidez.

Trier et entretenir un backlog

Le tri d'un ensemble d'issues est fastidieux à la main, et c'est là que Claude Code est le plus fort, car il peut lire tout le dépôt d'un coup.

Tâche fastidieuse Prompt type Ce que vous validez
Dédoublonner les issues « Lis toutes les issues ouvertes, regroupe-les par thème et signale les doublons. » Les regroupements et les fusions proposés
Proposer des étiquettes « Propose une taxonomie de labels et suggère le label de chaque issue. » La taxonomie et l'attribution
Résumer un long fil « Résume cette discussion en une décision claire à coller avant fermeture. » La formulation de la décision
Repérer les issues dormantes « Liste les issues sans activité récente et propose pour chacune : fermer, relancer ou garder. » Le sort de chaque issue

Transformer de la matière brute en éléments GitHub

Tâche fastidieuse Prompt type Ce que vous validez
E-mail ou PDF de retours → issues « Transforme ces retours en issues structurées : titre, contexte, résultat attendu, critères de validation. » Le découpage et les priorités
Notes de réunion → tâches « À partir de ce compte rendu, liste les actions à créer en issues, avec responsable et échéance si mentionnés. » Les actions retenues
Créer un modèle d'issue ou de PR « Crée un modèle d'issue “Retour client” avec les sections que j'utilise habituellement. » Les champs du modèle

Pull requests et relecture

Tâche fastidieuse Prompt type Ce que vous validez
Rédiger la description d'une PR « Rédige la description de cette pull request pour un relecteur non technique : ce qui change, pourquoi, points à relire. » L'exactitude du résumé
Relire un document en PR « Relis ce document : clarté, ton, cohérence, coquilles, liens cassés. Propose les corrections sans les appliquer. » Les corrections proposées

README, notes de version et journal de décisions

Tâche fastidieuse Prompt type Ce que vous validez
Rafraîchir un README « Mets à jour le README à partir du contenu réel du dépôt. » Le contenu et le ton
Rédiger des notes de release « Rédige les notes de la version à partir des changements depuis la dernière release. » Les faits marquants retenus
Tenir un journal de décisions « Ajoute à decisions.md la décision prise : date, contexte, décision, impact. » La formulation de la décision

Synthèses et suivi

Tâche fastidieuse Prompt type Ce que vous validez
Synthèse hebdomadaire « Prépare une synthèse des changements de la semaine à partir de l'historique. » Ce qui est mis en avant
Plan de tableau Projects « À partir de ce backlog, propose des colonnes, des jalons et une priorisation. » L'organisation retenue

Hygiène et cohérence

Le travail ingrat par excellence — et pourtant celui où une erreur coûte le plus cher.

Tâche fastidieuse Prompt type Ce que vous validez
Audit avant publication « Passe le dépôt en revue et signale toute donnée personnelle, tarif, mot de passe ou secret avant de le rendre public. » Les alertes, et la décision de publier
Cohérence des fichiers Markdown « Vérifie l'homogénéité des titres, le nommage des fichiers et les liens internes cassés sur tous les fichiers Markdown. » Les corrections proposées
Générer un .gitignore « Propose un .gitignore adapté à mes types de fichiers : exports lourds, brouillons, fichiers temporaires. » La liste des fichiers ignorés

Trois prompts détaillés pour les tâches phares

Pour les tâches les plus utiles, voici des consignes plus complètes, prêtes à copier.

Trier un backlog d'issues :

Lis toutes les issues ouvertes du dépôt.
Regroupe-les par thème, signale les doublons et les issues sans activité récente.
Pour chaque groupe, propose un label et une priorité.
Présente le résultat sous forme de tableau. Ne modifie ni ne ferme aucune issue : je déciderai.

Auditer un dépôt avant de le rendre public :

Passe l'ensemble du dépôt en revue avant publication.
Signale toute donnée personnelle, information tarifaire, coordonnée client, mot de passe ou clé d'accès.
Indique le fichier et la ligne concernés, et propose une version anonymisée si pertinent.
Ne supprime rien : liste les points à traiter et attends ma décision.

Relire un document avant validation :

Relis le document en préparation comme un relecteur exigeant mais bienveillant.
Vérifie la clarté, le ton, la cohérence, les coquilles et les liens cassés.
Propose les corrections sous forme de liste, sans les appliquer.
Signale les passages ambigus au lieu de les réécrire toi-même.

Chat ou Claude Code ?

Deux repères simples pour choisir l'outil :

  • Claude (chat) convient pour une tâche ponctuelle sur un contenu que vous collez : reformuler une issue, rédiger un message, structurer des notes.
  • Claude Code est meilleur dès qu'il faut lire tout le dépôt ou agir sur plusieurs fichiers : trier un backlog, auditer avant publication, vérifier la cohérence de vingt fichiers Markdown, refondre une structure de dossiers.

Exemple concret
Camille, illustratrice, n'avait jamais osé toucher à GitHub : les issues, les pull requests, tout lui semblait réservé aux développeurs. Pour un projet client, elle se contente de coller ses retours reçus par e-mail et de demander : « Transforme ces retours en issues structurées et prépare-moi une checklist de validation. » Claude produit huit issues claires, un résumé des priorités et une checklist. Elle n'a eu qu'à relire, corriger deux formulations et valider. En une session, GitHub est passé d'obstacle à outil de travail.

Garde-fou

Claude Code peut proposer un commit, une issue ou une pull request, mais il ne remplace pas votre validation. Gardez trois réflexes : relire les changements avant de les enregistrer ou de les publier ; ne pas exposer d'informations sensibles dans un commit, une issue ou un dépôt public ; documenter la décision, pas seulement l'action.

Scénarios combinés

Scénario 1 : gérer un dossier client

Objectif : centraliser le brief, les livrables, les retours et les validations.

Structure possible :

README.md
CLAUDE.md
brief/
livrables/
retours-client/
comptes-rendus/
archives/

Méthode :

  1. Créez un dépôt privé au nom de la mission et rédigez un README avec le contexte, les objectifs, les contacts et les échéances.
  2. Ajoutez un CLAUDE.md précisant le ton, le public et les règles de validation.
  3. Placez les documents de départ dans brief/.
  4. Demandez à Claude Code de résumer l'état du projet et de signaler les manques.
  5. Créez une issue par retour client — ou demandez à Claude Code de transformer les retours en issues prêtes à créer.
  6. Suivez l'avancement dans un tableau GitHub Projects.
  7. Avant livraison, demandez à Claude Code une checklist de validation, puis relisez.
  8. Archivez les versions livrées dans livrables/ ou archives/, et documentez les arbitrages dans les comptes rendus.

Prompt de validation :

Prépare une checklist de validation pour le livrable client.
Vérifie la clarté du message, la cohérence des exemples, la confidentialité et les points à confirmer.

Bonne règle : une demande client importante doit devenir une issue, pour ne pas se perdre dans les e-mails.

Scénario 2 : produire une documentation ou une formation

Objectif : suivre les contenus en cours et les publications validées, avec une progression pédagogique claire.

Structure possible :

README.md
CLAUDE.md
plan/
chapitres/
exemples/
ressources/
relectures/
livrables/

Méthode :

  1. Décrivez l'objectif dans le README et le ton, le niveau et le public dans le CLAUDE.md.
  2. Créez une issue par contenu à produire, avec des labels (idée, brouillon, à relire, validé, publié).
  3. Rédigez les contenus dans chapitres/.
  4. Demandez à Claude Code de relire la progression pédagogique et de lister les notions à clarifier.
  5. Utilisez GitHub Projects comme calendrier de production.
  6. Préparez la version finale dans livrables/.

Prompt de relecture :

Relis cette documentation comme support de formation pour débutants.
Vérifie la progression, les termes trop techniques, les exemples et les transitions.
Propose un plan de correction sans modifier les fichiers.

Bonne règle : GitHub garde la mémoire des idées refusées, reportées ou transformées, ce qui évite de recommencer les mêmes discussions.

Scénario 3 : suivre les retours sur une maquette ou une charte

Objectif : transformer des retours dispersés en actions claires.

Structure possible :

README.md
CLAUDE.md
exports/
retours/
decisions/
versions/

Méthode :

  1. Ajoutez les exports de maquette dans exports/.
  2. Créez une issue par retour important, avec une capture d'écran jointe par glisser-déposer.
  3. Demandez à Claude Code de classer les retours par thème (structure, ton, design, contenu, lisibilité, validation) et par priorité.
  4. Résumez la décision dans l'issue avant de la fermer.

Prompt d'analyse :

Analyse les retours du projet.
Classe-les par thème et par priorité.
Propose une liste d'actions avec des critères de validation.

Bonne règle : ne fermez pas une issue seulement parce que quelqu'un a répondu. Fermez-la quand la décision est claire ou l'action terminée.

Faire suivre une pull request par Claude (usage avancé)

Sur une configuration où Claude est connecté à GitHub, il peut aller plus loin que préparer un texte : il peut suivre une pull request. Concrètement, il réagit aux commentaires de relecture, propose un correctif et le repousse sur la branche — toujours sous votre validation.

C'est utile quand une pull request reçoit beaucoup de retours, ou quand des vérifications automatiques signalent un problème à corriger. Plutôt que de traiter chaque remarque à la main, vous laissez Claude préparer les ajustements et vous relisez le résultat.

Deux réserves, cependant :

  • C'est un usage avancé. Le manuel recommande de garder les automatisations pour plus tard : cette fonctionnalité s'adresse aux personnes déjà à l'aise avec les pull requests, une fois les bases acquises.
  • Cela dépend de la configuration. Ce suivi n'est possible que si Claude est effectivement connecté au dépôt GitHub ; il n'est pas disponible partout ni dans toutes les formules.

Le principe reste le même que dans tout ce manuel : Claude prépare et corrige, vous gardez la décision finale.

Partie 4 — Enrichir son dépôt GitHub

Une fois le flux de travail en place, ces fonctionnalités enrichissent votre dépôt sans exiger de culture technique. Plusieurs se préparent d'ailleurs très bien avec Claude Code : rédiger les notes d'une release, créer un modèle d'issue ou dresser la liste des fichiers à ignorer.

Publier un site ou un portfolio avec GitHub Pages

GitHub Pages transforme un dépôt en site web accessible en ligne, à une adresse du type votre-nom.github.io/nom-du-depot. Le service est gratuit pour un dépôt public ; pour publier depuis un dépôt privé, un abonnement payant est nécessaire. C'est utile pour un portfolio, une documentation publique, une page de services ou un mini-guide. La publication est automatique : à chaque changement enregistré, le site se met à jour.

Exemple concret
Une photographe place ses pages de présentation dans un dépôt, active GitHub Pages, et obtient un portfolio en ligne qu'elle met à jour en modifiant simplement ses fichiers, sans hébergeur ni outil supplémentaire.

Marquer les versions livrées avec les releases

Une release, ou version publiée, marque une étape officielle : elle porte un numéro (v1.0), une description, et peut contenir des fichiers attachés. Là où un commit enregistre chaque petit changement, une release dit « voici la version livrée et validée ».

Exemple concret
À la fin d'une mission, vous créez la release v1.0 – Guide de marque livré avec le PDF final attaché. Six mois plus tard, le client retrouve la version exacte remise ce jour-là.

Standardiser les demandes avec des modèles d'issues et de pull requests

GitHub peut afficher un modèle prérempli à chaque nouvelle issue ou pull request, placé dans un dossier spécial .github/. Chaque retour s'ouvre déjà structuré, avec les champs Contexte, Résultat attendu et Critères de validation.

Exemple concret
Un studio crée un modèle d'issue « Retour client ». Chaque nouvelle fiche affiche les sections à remplir, ce qui garantit que rien d'important n'est oublié.

Joindre des captures et des fichiers par glisser-déposer

Dans une issue ou un commentaire, vous pouvez ajouter une image ou un fichier par glisser-déposer, ou par copier-coller d'une capture. C'est essentiel pour les retours visuels : au lieu de décrire un problème, vous le montrez.

Éviter les fichiers indésirables avec .gitignore

Le fichier .gitignore indique à GitHub les fichiers à ne jamais enregistrer (fichiers temporaires, exports lourds, dossiers de travail personnels). C'est une protection simple contre l'ajout accidentel de fichiers volumineux ou sensibles.

Fonctionnalités utiles selon les projets

Ces fonctionnalités deviennent précieuses dès qu'un projet grandit ou implique plusieurs personnes :

  • Discussions : un espace d'échanges ouverts, plus libre que les issues, pour les questions et les idées sans fin nette.
  • Wiki : un espace de documentation longue séparé des fichiers (méthode interne, FAQ, glossaire).
  • Notifications et abonnements (Watch) : réglez votre niveau d'alertes pour ne rater aucun retour important sans être noyé.
  • Comparer les versions d'un texte : GitHub surligne les ajouts et suppressions, ligne par ligne, entre deux versions.
  • Organisations, équipes et rôles : regroupez les dépôts d'un studio ou d'une association et attribuez des droits (lecture, modification, administration).
  • Réactions et réponses enregistrées : approuvez un message d'un 👍 ou réutilisez des réponses fréquentes, pour garder les discussions lisibles.

Partie 5 — Routines, modèles et bonnes pratiques

Routine hebdomadaire recommandée

Chaque semaine :

  1. Ouvrez le tableau projet et vérifiez les issues bloquées.
  2. Demandez à Claude Code une synthèse des changements de la semaine.
  3. Fermez les tâches réellement terminées.
  4. Résumez les décisions importantes et documentez-les.
  5. Ajoutez les nouveaux fichiers livrables.
  6. Mettez à jour le README si le projet a changé.

Prompt utile :

Prépare une synthèse hebdomadaire du projet.
Indique ce qui a avancé, ce qui bloque, les décisions prises et les prochaines actions recommandées.

Avant partage ou livraison

  1. Demandez une relecture à Claude Code.
  2. Vérifiez les informations sensibles.
  3. Préparez une checklist.
  4. Relisez vous-même.
  5. Validez ou corrigez, puis rangez le livrable au bon endroit.

Erreurs fréquentes à éviter

  • Créer trop de dépôts : un dépôt doit correspondre à un vrai projet ou une vraie ressource.
  • Tout mettre dans le README : c'est une porte d'entrée, pas une armoire complète.
  • Ouvrir des issues trop vagues : « Améliorer le document » est trop flou ; préférez « Reformuler l'introduction pour expliciter la cible ».
  • Confondre discussion et décision : à la fin d'un échange, ajoutez « Décision : nous conservons la version B ».
  • Utiliser un dépôt public par défaut : pour un projet client, choisissez privé.
  • Demander à Claude Code une action trop vague : préférez une consigne précise, avec le public, le ton et les fichiers concernés.
  • Laisser Claude Code modifier trop de fichiers : commencez par des modifications limitées.
  • Ne pas relire les changements : même quand le résultat semble bon, relisez.

Sécurité et limites

  • Permissions : n'accordez pas plus de droits que nécessaire. Commencez par une analyse sans modification.
  • Fichiers sensibles : ne laissez pas Claude Code manipuler librement mots de passe, clés d'API, contrats confidentiels, données personnelles ou documents financiers. Signalez-les dans CLAUDE.md.
  • Validation humaine : Claude Code peut produire une synthèse convaincante mais incomplète. Avant de partager, vérifiez les faits, les noms, les dates, les prix, les engagements, le ton et la confidentialité.
  • Actions et vérifications automatiques : vous verrez parfois des coches vertes ou des croix rouges sur les pull requests. Ce sont des vérifications automatiques (GitHub Actions), utiles surtout aux projets de code. Pour un projet documentaire, vous pouvez généralement les ignorer. Gardez les automatisations pour plus tard, avec accompagnement.

Annexes — Modèles à copier

Modèle de README

# Nom du projet

## Résumé

Décrire le projet en trois à cinq lignes.

## Objectif

Expliquer ce que ce projet doit produire, clarifier ou permettre.

## Public ou destinataires

Indiquer à qui s'adresse le projet.

## Organisation des fichiers

- `brief/` : documents de départ et contexte.
- `documents/` : fichiers de travail.
- `livrables/` : versions prêtes à partager.
- `comptes-rendus/` : notes de réunion et décisions.
- `archives/` : anciennes versions conservées pour mémoire.

## Règles de collaboration

- Une demande importante doit être créée sous forme d'issue.
- Une décision doit être résumée avant fermeture de l'issue.
- Les fichiers livrés au client doivent être placés dans `livrables/`.
- Les informations confidentielles ne doivent pas être ajoutées sans validation.

## État actuel

Statut : en préparation / en cours / en attente de validation / terminé.

## Contacts

- Responsable projet :
- Validation finale :
- Référent client :

Modèle d'issue

# Titre court et actionnable

## Contexte

Pourquoi cette demande existe-t-elle ?

## Résultat attendu

Que doit-on obtenir à la fin ?

## Critères de validation

- [ ] Critère 1
- [ ] Critère 2
- [ ] Critère 3

## Responsable

@nom-utilisateur

## Échéance

Date ou période visée.

## Liens et pièces utiles

Ajouter les liens, captures, fichiers ou références.

Modèle de CLAUDE.md

# Instructions pour Claude Code

## Contexte du projet

Ce dépôt sert à organiser un projet créatif, documentaire ou éditorial.
Le public principal est non technique.

## Ton et style

- Rédiger en français clair.
- Respecter la typographie française.
- Éviter le jargon technique.
- Préférer des phrases simples, concrètes et actionnables.

## Organisation des fichiers

- `brief/` contient le contexte de départ.
- `documents/` contient les fichiers de travail.
- `retours/` contient les remarques client ou partenaires.
- `decisions/` contient les arbitrages validés.
- `livrables/` contient les versions prêtes à partager.
- `archives/` contient les anciennes versions.

## Règles de travail

- Commencer par analyser avant de modifier.
- Proposer un plan avant toute modification importante.
- Ne pas supprimer de fichier sans validation explicite.
- Ne pas inventer d'information client, tarifaire, juridique ou contractuelle.
- Signaler les ambiguïtés au lieu de les corriger silencieusement.

## Confidentialité

- Ne pas afficher inutilement de données personnelles.
- Ne pas intégrer de mot de passe, clé d'accès ou secret.
- Signaler tout fichier qui semble sensible.

## Validation

Avant de proposer une validation, fournir :

- un résumé des changements ;
- la liste des fichiers modifiés ;
- les points à relire ;
- les risques ou incertitudes ;
- une checklist de validation.

Modèle de checklist de validation

# Checklist de validation

## Contenu

- [ ] Le message principal est clair.
- [ ] Les informations essentielles sont présentes.
- [ ] Les exemples sont compréhensibles.
- [ ] Les éléments obsolètes ont été retirés.

## Forme

- [ ] Le titre est explicite.
- [ ] La structure est facile à parcourir.
- [ ] Les visuels sont à jour.
- [ ] Les noms de fichiers sont compréhensibles.

## Projet

- [ ] Les retours importants ont été traités.
- [ ] Les décisions sont documentées.
- [ ] Les livrables finaux sont rangés au bon endroit.
- [ ] Les personnes concernées ont validé.

Plan de démarrage combiné en 45 minutes

0 à 10 minutes : créer le cadre

  • Créez le dépôt (private si le projet n'est pas public) et ajoutez un README.
  • Ajoutez un CLAUDE.md.
  • Créez quelques dossiers principaux et ajoutez le brief.

10 à 20 minutes : faire analyser le projet

Explique-moi ce projet comme si je le découvrais.
Je ne suis pas développeur.
Indique ce qui est clair, ce qui manque et ce qu'il faudrait améliorer.
Ne modifie rien.

20 à 30 minutes : suivre le travail

  • Créez trois à cinq issues pour les premières tâches, avec des labels simples.
  • Créez un tableau GitHub Projects avec À faire, En cours, Terminé.

30 à 40 minutes : améliorer un seul élément

Améliore uniquement le README.md.
Rends-le compréhensible pour un partenaire non technique.
Ajoute une section sur l'organisation des fichiers et une section sur la validation.

40 à 45 minutes : sécuriser la suite

  • Invitez les bonnes personnes et vérifiez la visibilité du dépôt.
  • Demandez à Claude Code un résumé des changements et notez la prochaine action dans une issue.

Petit lexique

Ce lexique sert de référence rapide : il reprend et complète le vocabulaire présenté en début de manuel, pour retrouver une définition sans relire le chapitre concerné.

Terme Traduction pratique
Repository / dépôt Dossier central du projet
README Page d'accueil du projet
Commit Enregistrement d'un changement
Branch / branche Piste de travail séparée
Issue Fiche de tâche, retour ou question
Label Étiquette de tri
Milestone Jalon ou étape importante
Project Tableau de suivi
Pull request Proposition de changement à relire
Merge Intégration d'un changement validé
Markdown Format simple pour écrire des documents structurés
Release / version publiée Étape officielle marquant une version livrée
GitHub Pages Publication d'un site ou portfolio depuis un dépôt
.gitignore Liste des fichiers à ne jamais enregistrer dans le dépôt
Modèle (template) Trame préremplie pour les issues ou pull requests
Discussions Espace d'échanges ouverts, plus libre que les issues
Wiki Espace de documentation longue séparé des fichiers
Watch / abonnement Réglage du niveau de notifications d'un dépôt
Organisation Espace partagé regroupant les dépôts d'une équipe
Claude Code Assistant qui travaille dans le projet
CLAUDE.md Fichier d'instructions pour Claude Code
Prompt Consigne donnée à l'assistant

Sources officielles utiles

Documentation GitHub et Claude Code, consultée en juillet 2026 :

Résumé à retenir

GitHub et Claude Code deviennent accessibles dès qu'on cesse de les voir comme des outils réservés au code. GitHub structure le projet, garde l'historique et trace les décisions ; Claude Code analyse, propose et prépare le travail à l'intérieur.

Le vrai basculement est là : en déléguant à Claude les tâches fastidieuses et structurantes — écrire des issues, trier un backlog, rédiger des notes de version, auditer avant publication — vous abaissez radicalement la barrière à l'entrée de GitHub. Vous décrivez en français clair, Claude met en forme, vous validez.

Commencez petit : un dépôt privé, un bon README, un CLAUDE.md, quelques issues bien écrites et un tableau de suivi simple. Demandez d'abord une analyse, puis un plan, puis une modification précise. Relisez toujours avant de valider.

Le meilleur usage tient en cinq verbes : comprendre, organiser, proposer, modifier, valider.