Convertisseur de dépôt GitHub en texte

Transformez un dépôt GitHub en un fichier texte unique lisible par un LLM. Sélectionnez les fichiers utiles, vérifiez le nombre de tokens, puis collez le résultat dans ChatGPT, Claude ou Gemini. Gratuit, sans inscription.

Convertir un dépôt GitHub en texte : tout un projet dans un seul fichier lisible par un LLM

Collez une URL GitHub ci-dessus et l'arborescence du dépôt s'affiche sous forme de liste à cocher. Cochez ce qui compte, générez, et vous obtenez un seul fichier texte : la structure des répertoires en tête, puis chaque fichier sélectionné en dessous, séparé par un en-tête indiquant son chemin. C'est le format qui fonctionne avec ChatGPT, Claude, Gemini, DeepSeek ou n'importe quoi d'autre où vous collez du contenu — le modèle voit la forme du projet et le code en même temps, il peut donc raisonner sur la manière dont les pièces s'emboîtent au lieu de deviner à partir d'un fichier isolé.

Rien à cloner, rien à installer, pas d'inscription, et c'est gratuit. Le dépôt est lu via l'API GitHub directement depuis votre navigateur : vous n'avez donc pas besoin du projet sur votre machine — ce qui est justement l'intérêt quand vous regardez le code de quelqu'un d'autre, une dépendance que vous évaluez, ou un dépôt auquel on vient de vous donner accès.

Collez l'URL, branche ou tag compris

La forme simple https://github.com/owner/repo fonctionne et vous donne la branche par défaut. Mais l'URL transporte davantage, et il serait dommage de s'en priver. Copiez la barre d'adresse pendant que vous naviguez sur GitHub et ce que vous êtes en train de regarder est repris tel quel :

  • Une branche — /tree/develop ou une branche de fonctionnalité, pour convertir le travail en cours plutôt que ce qui est sur main.
  • Un tag ou une release — /tree/v2.1.0. Pratique quand vous posez des questions sur la version réellement livrée, ou pour comparer deux releases dans la conversation en convertissant chacune.
  • Un sous-répertoire — /tree/main/packages/api. C'est celui qui vous sauve dans un monorepo. Partez du paquet qui vous intéresse et l'arborescence renvoyée est déjà cadrée, au lieu de dix mille fichiers qu'il faudra ensuite décocher.

Si la branche ou le chemin n'existe pas, on vous dit quelle partie n'a pas pu être résolue — en général une faute de frappe dans un nom de branche, ou un dépôt privé pour le token que vous utilisez.

Dépôts privés, et où passe votre token

Les dépôts privés fonctionnent avec un personal access token GitHub. Générez-en un dans vos paramètres développeur GitHub, avec un accès en lecture aux dépôts nécessaires — un token fine-grained limité à un seul dépôt suffit, et c'est l'option qu'il faut prendre. Collez-le dans le champ prévu et l'arborescence se charge exactement comme pour un dépôt public.

Le token est conservé dans le localStorage de votre navigateur pour ne pas avoir à le ressaisir à chaque visite, et il ne part qu'à un seul endroit : api.github.com, dans les en-têtes de requête, depuis votre propre machine. Il n'y a ici aucun compte auquel le rattacher et aucun backend à nous sur le trajet. Videz le champ et il est effacé du stockage. Sur une machine partagée, effacez-le en partant ; et si vous voulez une certitude, révoquez le token dans GitHub après coup — c'est une action en un clic et elle ne vous coûte rien.

Un token aide aussi sur les dépôts publics. Les requêtes non authentifiées à l'API GitHub sont limitées assez sévèrement en débit : si vous convertissez un gros dépôt, ou plusieurs à la suite, ajouter un token fait la différence entre « ça marche » et une heure d'attente.

Ce qu'il faut décocher avant de générer

C'est l'étape qui décide si la sortie sera utile ou non. Un dépôt contient beaucoup de fichiers versionnés pour de bonnes raisons et qui ne valent malgré tout rien comme contexte pour un modèle. Parcourez l'arborescence et écartez :

  • Les dépendances vendorisées — node_modules, vendor, third_party. Rare dans un dépôt, mais dévastateur quand c'est là. C'est le code source des autres, et il va noyer le vôtre.
  • Les artefacts de build — dist, build, out, .next, target, rapports de couverture. Encore votre propre code, transpilé ou minifié : le modèle lit tout deux fois et n'apprend rien de neuf la seconde.
  • Les lockfiles — package-lock.json, yarn.lock, poetry.lock, Cargo.lock. Des dizaines de milliers de tokens de hachages presque vides de sens. Gardez plutôt le manifeste : c'est package.json ou pyproject.toml qui indique au modèle sur quelle stack vous êtes.
  • Le code généré — sorties protobuf et gRPC, codegen GraphQL, clients OpenAPI, migrations de base de données, tests de snapshot. Écrit par une machine, répétitif, et ça pousse le modèle à modifier des fichiers qui seront de toute façon régénérés.
  • Les gros fichiers de données — fixtures, dumps de seed, CSV d'exemple, bundles minifiés committés il y a des années. Un seul de ces fichiers peut avaler une fenêtre de contexte à lui tout seul.

Le filtrage par extension est la voie rapide sur un gros dépôt : restreignez à .ts et .tsx, ou à .py, et vous avez coupé l'essentiel du bruit en un geste. Rajoutez ensuite la poignée de fichiers de configuration et de documentation qui expliquent le projet — le README, la config principale, le schéma.

Le compteur de tokens, c'est ça qui compte

La sortie générée est accompagnée d'un décompte de tokens, calculé avec la bibliothèque gpt-tokenizer et non par une estimation « nombre de caractères divisé par quatre ». Vérifiez-le avant de coller. Savoir si un dump tient dans la fenêtre de contexte que vous allez utiliser, c'est tout l'enjeu — sinon vous collez, vous attendez, et vous lisez une erreur de longueur.

Servez-vous-en pour piloter, pas seulement pour contrôler. Si le compte fait le double de la place disponible, revenez à l'arborescence et décochez un répertoire au lieu de tronquer le fichier à la fin : un dump coupé en plein projet laisse au modèle la moitié d'une implémentation, sans qu'il sache qu'il lui manque quelque chose. Et gardez en tête qu'une grande fenêtre de contexte n'est pas la même chose qu'une bonne : une sélection ciblée de 8 000 tokens — le module, ses tests et les deux fichiers qu'il importe — bat en général 200 000 tokens de tout et n'importe quoi. Envoyez le dépôt entier quand la question est architecturale, et une tranche quand elle est locale.

Une fois prêt, copiez le texte dans le presse-papiers, téléchargez-le en .txt, ou récupérez les fichiers sélectionnés dans un ZIP si vous préférez des fichiers à un document fusionné.

Comment s'en servir

À quoi les gens s'en servent vraiment

  • Prendre en main une base de code inconnue. Nouveau poste, nouvelle équipe, ou projet open source auquel vous voulez contribuer. Convertissez, collez, et demandez les points d'entrée, les abstractions centrales et les trois choses qui surprendraient un nouveau mainteneur. Vous serez situé plus vite qu'en lisant le README et en cliquant de fichier en fichier pendant une journée.
  • Relire une pull request avec son contexte. Un diff montre ce qui a changé, pas ce que ça touche. Convertissez la branche, ou seulement le paquet concerné, et demandez qui d'autre appelle la fonction modifiée et quelles hypothèses le nouveau code fait à son sujet.
  • Écrire de la documentation qui soit vraie. Les README pourrissent parce qu'ils sont écrits une fois. Générez un aperçu de l'architecture, des résumés de modules, ou la vraie liste des variables d'environnement à partir du code tel qu'il est sur main aujourd'hui.
  • Générer des tests. Incluez le module plus un fichier de test existant comme référence de style. Le modèle reprend votre framework, votre nommage et vos fixtures au lieu d'inventer une convention que personne dans l'équipe n'utilise.
  • Planifier une migration ou un refactor. Composants classe vers hooks, JavaScript vers TypeScript, un ORM vers un autre. Un modèle qui voit tous les sites d'appel produit une vraie séquence d'étapes plutôt qu'une checklist générique.
  • Audits et due diligence. Évaluer un dépôt dont vous héritez, que vous rachetez ou que vous envisagez comme dépendance. Un fichier consolidé rend praticable la question de savoir où les secrets sont manipulés, à quoi ressemblent les chemins d'erreur et où se trouvent les motifs à risque.
  • RAG et embeddings. Les sections délimitées par chemin se découpent proprement : la sortie tombe dans une base vectorielle avec très peu de prétraitement.

Questions fréquentes

Comment convertir un dépôt GitHub en fichier texte ?

Collez l'URL du dépôt ci-dessus et l'arborescence apparaît sous forme de liste à cocher. Décochez ce dont le modèle n'a pas besoin, générez, et vous obtenez un seul fichier texte : la structure des répertoires en tête, puis chaque fichier sélectionné sous un en-tête indiquant son chemin. Rien à cloner, rien à installer, gratuit et sans inscription.

Comment convertir un dépôt GitHub privé ?

Collez un personal access token à côté de l'URL. Créez un token fine-grained limité à ce seul dépôt, avec la permission Contents en lecture seule et une expiration courte — c'est le moindre privilège que l'API accepte pour cet usage. Le token sert à appeler GitHub depuis votre navigateur et n'est stocké nulle part chez nous.

Combien de tokens fait ma base de code, et est-ce que ça va tenir ?

Le compteur se met à jour à mesure que vous cochez des fichiers : vous voyez donc le chiffre avant de coller quoi que ce soit. En ordre de grandeur, du code source tourne autour de 3 à 4 caractères par token, donc une sélection de 500 Ko atterrit vers 140 000 tokens. Ça tient dans une fenêtre de contexte de 200K, et ça ne tiendra pas dans un seul message de chat sur la plupart des interfaces.

Quels fichiers exclure avant de donner un dépôt à un LLM ?

node_modules, vendor et tout répertoire de dépendances en premier — ils représentent en général l'écrasante majorité des octets et n'apprennent rien sur votre code. Ensuite les lockfiles, les artefacts de build, les bundles minifiés, les fixtures de test et les fichiers binaires. Sur un projet JavaScript typique, cette seule passe supprime souvent plus de quatre-vingt-dix pour cent des tokens.

Qu'est-ce que ça vaut face à gitingest, repomix ou code2prompt ?

Ce sont de bons outils, et honnêtement la différence tient au flux de travail, pas aux capacités. Ils sont pensés pour la ligne de commande, scriptables, et c'est la bonne réponse dans une CI ou un traitement par lots. Ici tout se passe dans un onglet de navigateur, avec une arborescence à cocher : vous voyez le dépôt, vous désélectionnez ce que vous ne voulez pas, et vous regardez le compteur de tokens bouger — mieux adapté au cas ponctuel où vous êtes encore en train de décider quoi inclure.

Est-ce prudent de faire passer mon code par là ?

Les dépôts publics sont lus via l'API GitHub depuis votre navigateur : le code va donc de GitHub à vous. Pour tout ce qui est confidentiel, l'option la plus solide est le convertisseur de dossier local, qui n'envoie strictement rien. Dans tous les cas, passez votre sélection en revue à la recherche de clés d'API et d'identifiants avant de la coller dans un modèle — c'est l'étape que les gens sautent.

Dossiers locaux, GitLab, et tout ce qui n'est pas du code

Tout ce que vous voulez convertir n'est pas sur GitHub. Le convertisseur de dossier local en texte prend un répertoire directement sur votre disque et le regroupe en un seul fichier sans rien envoyer — aucun appel réseau, ce qui est exactement ce qu'il faut pour du travail client, des branches non committées ou un projet qui n'a jamais été un dépôt git. Pour GitLab, le convertisseur GitLab vers texte fait le même travail sur des projets publics, privés et auto-hébergés.

Le code n'est souvent que la moitié du contexte, d'ailleurs. La spécification est dans un PDF, le schéma en JSON, la vieille configuration en XML, les données d'exemple dans un CSV. Convertissez tout ça en même temps que votre dépôt avec PDF vers Markdown, JSON vers Markdown, XML vers Markdown, CSV vers Markdown ou HTML vers Markdown. Si on vous remet une archive, ZIP vers texte en extrait le contenu lisible, et File2Txt accepte n'importe lequel des treize formats pris en charge si vous préférez ne pas choisir de page. Pour la documentation qui n'existe que sur le web, Web2Txt récupère une URL en Markdown propre, y compris les pages rendues en JavaScript — associez une référence d'API récupérée à votre dépôt converti et un assistant de code voit les deux côtés à la fois.

Le blog va plus loin : le guide complet de la conversion de dépôts GitHub pour les LLM, transformer une base de code en fichier prêt pour un LLM, donner un dépôt entier à manger à une IA, et le pas-à-pas dossier vers texte pour les répertoires locaux.

Repo2Txt est conçu et maintenu par v12hero, un développeur indépendant qui crée des applications natives et web respectueuses de la vie privée.