Sauvegarder repos, issues et PRs GitHub en Markdown (Guide 2026)

Le contenu GitHub est éparpillé entre READMEs, issues, PRs, discussions et gists --- et fournir tout ça à un LLM est pénible si ce n’est pas en Markdown. Le README est déjà là, certes, mais la partie dont tu as vraiment besoin, c’est le fil d’une issue à 80 commentaires où quelqu’un a fini par trouver le contournement, ou la PR où le breaking change a été expliqué, ou la discussion qui explique pourquoi l’API a été conçue ainsi. Rien de tout cela n’est à un clic d’être un contexte Claude utilisable.

Ce guide couvre toutes les méthodes pour convertir du contenu GitHub en Markdown propre --- d’un seul README à une longue discussion de PR à un repo entier.

Pourquoi sauvegarder du contenu GitHub en Markdown ?

Markdown est le format qui fonctionne partout où la connaissance du code doit aller :

• Le fournir à un LLM --- Claude, ChatGPT, Gemini et les modèles locaux lisent tous nativement le Markdown comme contexte, avec blocs de code et identifiants de langage préservés
• L’insérer dans Obsidian ou Notion --- un fichier par issue ou repo, entièrement cherchable, correctement structuré
• Archiver un fil avant qu’il ne soit verrouillé ou supprimé --- les mainteneurs ferment des issues, des repos passent en privé, tes notes ne devraient pas dépendre de l’uptime de GitHub
• Construire de la documentation hors-ligne --- compiler les READMEs de plusieurs repos en une seule référence
• Citer un commentaire spécifique dans un long fil --- revenir à la seule réponse utile dans une issue de 200 commentaires est à une recherche près

Le cas d’usage qui génère le plus de trafic GitHub-vers-Markdown en 2026, c’est le premier : les développeurs veulent interroger un LLM sur une bibliothèque, un bug ou une décision de design, et coller l’URL ne donne pas au modèle ce dont il a besoin.

Méthode 1 : Save (Le plus rapide, en un clic)

Save est une extension Chrome qui transforme n’importe quelle page GitHub en fichier Markdown en un clic. Elle lit la page rendue, reconstruit le Markdown d’origine quand c’est possible, et produit quelque chose qui s’intègre directement dans Claude, Obsidian ou ton dossier de docs.

Comment ça marche :

1. Ouvre la page GitHub dans Chrome --- repo, issue, PR, discussion, gist ou wiki
2. Clique sur l’icône de l’extension Save dans ta barre d’outils
3. Un fichier .md se télécharge instantanément (ou atterrit dans ton Save Vault s’il est connecté)

Ce que tu obtiens :

• READMEs avec blocs de code, tableaux et titres intacts
• Titre, corps, statut et commentaires en fil de discussion des issues et PRs
• Fils de discussion avec imbrication correcte
• Issues référencées et @mentions préservées
• Labels, milestones, assignés en frontmatter
• Les blocs de code gardent leur identifiant de langage (la coloration syntaxique fonctionne dans les visualiseurs Markdown)
• Gists (mono-fichier et multi-fichiers) supportés
• Frontmatter avec repo, auteur, date, URL et état (open/closed/merged)

Ce qui est retiré :

• Navigation, barres latérales et pied de page de GitHub
• Lignes d’emojis de réaction sous chaque commentaire
• Replis “X hidden items” (Save les déplie et les inclut)
• Commentaires de bots provenant de CI, dependabot et stale-bot (activable)
• Quote-replies répétés qui ne font qu’écho au commentaire précédent

Idéal pour : Devs qui débuguent avec l’IA, rédacteurs techniques qui compilent de la doc, chercheurs qui archivent des fils, et toute personne construisant une base de connaissances perso sur le fonctionnement réel des bibliothèques en pratique. Si tu as besoin de Markdown propre que tu colleras dans Claude ou liras dans Obsidian, c’est la voie la plus propre.

Exemple de sortie

Sauvegarder un fil d’issue produit :

---
title: "Memory leak when using streaming with large responses"
repo: anthropics/anthropic-sdk-python
number: 412
author: alice-dev
state: closed
labels: ["bug", "streaming", "memory"]
assignees: ["bob-maintainer"]
milestone: "v0.34.0"
created: 2026-03-12
closed: 2026-03-18
url: https://github.com/anthropics/anthropic-sdk-python/issues/412
---

## Issue

When streaming responses larger than ~50MB, memory grows linearly and is
never released. Reproduced on Python 3.11 and 3.12, macOS and Linux.

**Reproduction:**

\`\`\`python
from anthropic import Anthropic

client = Anthropic()
with client.messages.stream(...) as stream:
    for text in stream.text_stream:
        print(text, end="")
\`\`\`

After the loop ends, `tracemalloc` shows the buffer is still resident.

## Comments

### bob-maintainer (maintainer) --- 2026-03-13

Confirmed. The internal buffer in `_streaming.py` isn't being cleared on
context exit. Looking at it now.

### alice-dev --- 2026-03-14

Thanks. Workaround for anyone hitting this: call `stream.close()`
explicitly before the `with` block exits. References #389.

### bob-maintainer (maintainer) --- 2026-03-18

Fixed in #418, released in v0.34.0. Closing.

Ce fichier est à un coller près d’être un contexte Claude utilisable, à une touche près d’être une note Obsidian permanente.

Méthode 2 : API GitHub + Script

Les APIs REST et GraphQL de GitHub exposent tout --- READMEs, issues, commentaires, diffs de PR. Tu peux écrire un script pour récupérer et convertir.

gh api repos/OWNER/REPO/issues/412 --jq '.body' > issue-412.md
gh api repos/OWNER/REPO/issues/412/comments --jq '.[].body' >> issue-412.md

Idéal pour : Équipes d’ingénierie qui construisent des pipelines de documentation, et toute personne scriptant des exports en masse d’issues ou de PRs sur plusieurs repos.

Problèmes de cette approche :

• L’API renvoie des corps Markdown bruts, mais assembler titre + corps + commentaires + métadonnées en un seul fichier lisible, c’est ton problème
• Le frontmatter (labels, milestones, assignés, état) nécessite plusieurs appels d’API et un assemblage manuel
• L’ordre des commentaires, l’attribution d’auteur et les chaînes de réponses imbriquées nécessitent une logique custom
• Les rate limits sont vite atteints sur les gros repos (5 000 requêtes/heure authentifié)
• Les Discussions vivent derrière l’API GraphQL, pas REST, donc le script devient deux pipelines
• Les diffs de PR et commentaires de review sont encore des endpoints séparés

C’est la bonne méthode si tu construis un pipeline. C’est overkill pour une seule issue.

Méthode 3 : Clone + conversion locale (pour les repos entiers)

Pour les READMEs et la doc in-repo, la méthode la plus simple est de cloner et lire les fichiers directement --- ils sont déjà en Markdown sur disque.

git clone https://github.com/OWNER/REPO.git
cd REPO
cat README.md docs/*.md > combined.md

Idéal pour : Développeurs qui veulent un accès hors-ligne à la doc d’un repo, ou qui ont besoin de fournir un arbre de doc entier à un LLM à long contexte.

Problèmes de cette approche :

• Ne fonctionne que pour du contenu stocké dans le repo (READMEs, /docs, wiki si cloné séparément)
• Ne capture pas les issues, PRs ou discussions --- celles-ci vivent dans la base de données de GitHub, pas dans l’arbre git
• Les références croisées entre docs et issues cassent (#412 ne se résout pas localement)
• Les URLs d’images dans les READMEs pointent souvent vers user-attachments.githubusercontent.com et doivent être réécrites pour un usage hors-ligne
• Tu as toujours besoin d’un script pour combiner et nettoyer si tu veux un seul fichier

Bien pour “je veux la doc hors-ligne.” Mauvais outil pour “je veux ce fil d’issue de 80 commentaires.”

Méthode 4 : Copier manuellement depuis le navigateur

La méthode brute : ouvre la page, sélectionne tout, colle dans un éditeur Markdown, nettoie.

Étapes :

1. Ouvre l’issue ou PR dans le navigateur
2. Sélectionne la section pertinente (ou toute la page)
3. Colle dans Obsidian, VS Code ou un autre éditeur Markdown
4. Retire à la main le bruit UI (réactions, nav, barres latérales)
5. Re-ajoute les blocs de code, corrige l’ordre des commentaires, ajoute le frontmatter

Problèmes de cette approche :

• Les blocs de code perdent leur identifiant de langage et la coloration syntaxique
• L’auteur et l’horodatage des commentaires finissent en texte libre, pas en frontmatter structuré
• Les tableaux dans les READMEs se collent souvent en texte brut avec séparateurs tab
• Les lignes de réaction (+1 heart rocket) fuient dans le corps
• L’imbrication des discussions s’aplatit en texte plat
• Prend 10 minutes pour un long fil ; multiplie par chaque issue que tu sauvegardes

Fonctionne pour un court README. S’effondre sur de vrais fils d’issue.

Quelle méthode utiliser ?

Scénario	Meilleure méthode
Coller une issue ou PR dans Claude	Save --- un clic, sortie structurée
Archiver un long fil de discussion	Save --- imbrication et métadonnées préservées
Copie hors-ligne de la doc d’un repo	git clone --- les READMEs sont déjà en Markdown
Export en masse d’issues sur plusieurs repos	API GitHub + script --- programmatique
Sauvegarder rapidement un seul README	Save --- évite l’étape de clone
Référence rapide one-off pour notes perso	Copie manuelle --- pour de courtes pages

Pour la plupart des développeurs --- surtout ceux qui utilisent du contenu GitHub comme contexte IA --- Save est la réponse. Il produit le Markdown le plus propre sans aucune configuration, et il gère les longs fils d’issues à la même vitesse qu’un README.

Cas limites gérés par Save

• Repos privés. Save utilise ta session de navigateur loggée. Si ton compte GitHub peut voir le repo, Save peut le lire. Pas de token API à configurer.
• GitHub Enterprise auto-hébergé. Fonctionne sur tout pattern de domaine github.*. Save lit la page rendue, donc tant que l’UI est la mise en page standard de GitHub, la conversion fonctionne.
• GitHub Discussions vs Issues. Les deux supportés. Les Discussions obtiennent leur catégorie en frontmatter (category: Q&A, category: Announcements) et les réponses imbriquées en structure de fil.
• Diffs et changements de fichiers de PR. Conservés quand c’est pertinent. Le corps de la PR, les commentaires de review et les conversations au niveau fichier sont inclus. Le diff brut lui-même est résumé plutôt que vidé --- tu ne veux généralement pas 5 000 lignes de diff dans ton contexte LLM.
• Lignes d’emojis de réaction. Supprimées. Les lignes +1, heart, rocket sous chaque commentaire sont du bruit pour tout sauf l’analyse de tendances.
• Fils d’issues très longs. Pour les fils avec des centaines de commentaires, Save garde le corps de l’issue, les réponses du mainteneur, le commentaire de résolution, et un marqueur “Other comments: N omitted”. Activable pour inclusion complète si tu as besoin de chaque réponse.
• Pages Wiki. Les wikis de repo sont supportés. Chaque page devient un fichier Markdown, avec les liens wiki internes réécrits en chemins relatifs.
• Project boards. Les vues de project board sont capturées en liste structurée : colonne → titre de carte → issue/PR liée. Utile pour archiver un sprint avant qu’il ne se ferme.
• Commentaires de bots. Dependabot, stale-bot, CodeQL, GitHub Actions --- tous détectés et activables. Désactivés par défaut parce qu’ils ajoutent presque toujours du bruit.
• Blocs de code avec identifiants de langage. Le tag de langage triple-backtick (```python, ```rust) est préservé pour que tout rendu Markdown ou LLM reçoive l’indice de coloration syntaxique.
• Gists. Gists mono-fichier et multi-fichiers tous deux supportés. Les gists multi-fichiers deviennent un seul fichier Markdown avec chaque fichier en section.

Intègre-le à ton workflow

La sortie Markdown fonctionne partout où tu en as besoin :

• Claude / ChatGPT / Gemini --- colle le fichier, demande “pourquoi cette issue a-t-elle été fermée ?” ou “résume la décision de design dans cette PR”
• Obsidian --- dépose-le dans ton vault, lie des issues à des notes connexes, cherche sur toutes les bibliothèques que tu as sauvegardées
• Notion --- colle directement, les titres, tableaux et blocs de code rendent correctement
• Cursor / Claude Code --- dépose le fichier dans le projet, l’IA a maintenant le contexte upstream quand elle suggère des fixes
• Save Vault --- si tu en as connecté un, chaque sauvegarde GitHub y atterrit automatiquement avec le repo en tag et des backlinks vers les autres fils sauvegardés

FAQ

Save fonctionne-t-il sur les repos privés ? Oui. Il utilise ta session de navigateur loggée, donc tout ce que ton compte GitHub peut voir, Save peut le sauvegarder. Pas de PAT ni d’OAuth à configurer.

Fonctionne-t-il sur GitHub Enterprise (auto-hébergé) ? Oui. Toute UI GitHub est supportée quel que soit le domaine. Si ta boîte fait tourner github.acme-corp.com, Save y fonctionne aussi.

Va-t-il capturer chaque commentaire dans un fil de 500 commentaires ? Par défaut, Save garde le corps de l’issue, les réponses du mainteneur et la résolution. Pour le fil complet, active “Include all comments” dans le menu de l’extension avant de sauvegarder.

Les blocs de code sont-ils correctement formatés ? Oui. Les blocs triple-backtick et les identifiants de langage sont préservés exactement. ```python reste ```python pour que tout LLM ou visualiseur Markdown obtienne la coloration syntaxique.

Gère-t-il les diffs de PR ? Le corps de la PR, les commentaires de review et les conversations inline sur fichiers sont inclus. Le diff brut est résumé par fichier plutôt que vidé en gros --- généralement ce que tu veux pour un contexte LLM. Active “Include raw diff” si tu as besoin du patch complet.

Et les GitHub Discussions ? Entièrement supporté. Catégories, réponses imbriquées et statut marqué-comme-réponse, tout vient en Markdown structuré.

Préserve-t-il les @mentions et références croisées ? Oui. Les mentions @username restent en mentions texte, et les références d’issues #123 sont conservées telles quelles. Si tu les veux en hyperliens vers GitHub, l’extension peut les réécrire à la sauvegarde.

Fonctionne-t-il sur le site mobile de GitHub ? L’extension est Chrome desktop uniquement. Sur mobile, copie l’URL et ouvre-la sur desktop, ou partage vers un Save Vault sur Mac.

Combien ça coûte ? Save a une offre gratuite pour que tu puisses l’essayer sur quelques repos et issues. Au-delà, un petit abonnement couvre une utilisation plus lourde.

Guides Save associés

• Sauvegarder les réponses Stack Overflow en Markdown --- réponses acceptées avec blocs de code et commentaires
• Sauvegarder les conversations ChatGPT en Markdown --- chaque tour, avec blocs de code intacts
• Sauvegarder les conversations Claude en Markdown --- artefacts, code et raisonnement préservés
• Sauvegarder les vidéos YouTube en Markdown --- transcript, résumé, timestamps, marqueurs de chapitre