repo2txt : aplatir un dépôt en un seul fichier texte pour les prompts LLM
Web-based tool converts GitHub repository contents into a single formatted text file
En bref
- De quoi s’agit-il ?
- repo2txt est un outil web TypeScript qui transforme un dépôt GitHub, GitLab, Azure DevOps ou un dossier local en un fichier texte unique destiné aux prompts. Le traitement se fait dans le navigateur, mais la qualité du résultat dépend entièrement de la façon dont vous filtrez les fichiers.
- À qui s’adresse-t-il ?
- repo2txt convient à un développeur qui doit coller rapidement un dépôt de taille moyenne dans un chat LLM et qui veut garder la main sur le filtrage. Il ne convient pas à un pipeline automatisé ni à un dépôt dont le contenu est confidentiel et qui exigerait une politique de conservation.
- Puis-je l’utiliser commercialement ?
- Pas sans autorisation. GitHub ne trouve aucun fichier de licence dans ce dépôt, et sans licence tous les droits sont réservés par défaut : vous pouvez lire le code, mais pas le réutiliser. Consultez le README ou demandez l’accord des auteurs avant de l’utiliser.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 41 jours.
- En quel langage est-il écrit ?
- Principalement TypeScript, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème que repo2txt adresse, et pour qui
Un modèle de langage ne lit pas un dépôt : il lit du texte. Quand on veut lui soumettre un projet entier, il faut donc choisir les fichiers, les concaténer, indiquer les chemins, et couper avant de dépasser la fenêtre de contexte. Fait à la main, cette préparation est répétitive et facile à rater.
repo2txt vise ce moment précis. Le README le formule ainsi : « Convert repositories to plain text for LLM prompts ». La cible est le développeur qui travaille dans un chat, pas l'équipe qui construit une plateforme d'indexation. Les topics du dépôt (ai, anthropic, chatgpt, llm) confirment cette orientation vers la préparation de contexte conversationnel.
Le projet existe en deux versions. Le README renvoie vers repo2txt-classic pour l'ancienne interface, ce qui indique une réécriture plutôt qu'une simple évolution. Le dépôt décrit ici est la version moderne, en React 19 et TypeScript.
Quatre sources d'entrée, un seul format de sortie
L'outil accepte quatre provenances. GitHub, avec ou sans jeton d'accès personnel pour les dépôts privés et pour relever la limite d'API (le README cite 5000 contre 60 requêtes par heure). Les fichiers locaux, via un sélecteur de dossier. Les archives zip, par glisser-déposer. GitLab et Azure DevOps, tous deux marqués Beta dans le README, ce qui laisse entendre une couverture moins complète que GitHub.
Les formats d'URL GitHub reconnus sont listés explicitement : la racine du dépôt, une branche, un sous-dossier dans une branche. Le README précise que les noms de branche contenant des barres obliques sont gérés, avec l'exemple feature/test/branch-name. C'est un détail qui casse beaucoup de parseurs naïfs, et le fait qu'il soit documenté suggère qu'il a été traité.
En sortie, un fichier .txt unique, copiable dans le presse-papiers ou téléchargeable. Pas de format intermédiaire, pas de JSON structuré. C'est un choix assumé : la cible est le collage direct dans une interface de chat.
Le filtrage est le vrai cœur de l'outil
Un dépôt aplati sans filtre produit un fichier inutilisable : lockfiles, images, bundles minifiés, fixtures de test. repo2txt attaque ce point par plusieurs mécanismes distincts. Un filtre par extension permet de sélectionner ou désélectionner des types de fichiers. Le support de .gitignore fait que les motifs déjà présents dans le dépôt sont respectés automatiquement. Des motifs personnalisés peuvent être ajoutés par-dessus. Et une sélection par répertoire permet de ne garder que certaines branches de l'arborescence.
L'aperçu de l'arbre de fichiers sert d'interface à ces filtres. Le README mentionne le défilement virtuel pour absorber les dépôts volumineux, avec un ordre de grandeur de 10 000 fichiers et plus. C'est cohérent avec l'usage de TanStack Virtual dans la pile technique.
Le comptage de tokens en temps réel, via gpt-tokenizer, complète le dispositif : il indique si le résultat tient dans la fenêtre visée avant même l'export. Le README annonce aussi des statistiques par fichier, en tokens et en lignes. Ce sont ces deux fonctions, filtre et compteur, qui distinguent l'outil d'un simple script de concaténation.
Architecture : tout se passe dans l'onglet
Le README insiste sur un point : « 100% Browser-Based - No server uploads, all processing is local ». Il n'y a donc pas de backend qui reçoit votre code. Les jetons GitHub sont stockés dans sessionStorage uniquement, ce qui les efface à la fermeture de l'onglet, mais les laisse accessibles à tout script exécuté dans cette page pendant la session.
La pile est classique pour une application Vite : React 19, TypeScript, Tailwind CSS 3, Zustand pour l'état, JSZip pour les archives. Deux éléments méritent l'attention. D'abord les Web Workers : la tokenisation tourne dans des threads d'arrière-plan, ce qui évite de figer l'interface pendant le comptage. Ensuite le chargement progressif : les contenus de fichiers sont diffusés au fur et à mesure. Le découpage de code avec fournisseurs chargés à la demande vise à ne pas embarquer GitLab et Azure DevOps dans le bundle initial.
Le README annonce un chunk principal d'environ 330 Ko gzippé. C'est une affirmation du projet, pas une mesure indépendante.
Mise en route : trois commandes et un port
L'usage en ligne ne demande rien. Pour une exécution locale, le README donne la séquence suivante :
git clone https://github.com/abinthomasonline/repo2txt.git cd repo2txt npm install npm run dev
L'interface est alors servie sur http://localhost:5173/repo2txt/, chemin de base qui correspond au déploiement sous sous-répertoire. Pour un build de production, npm run build écrit dans ./dist.
Le README mentionne des commandes de test : npm run test:unit et npm run test:e2e, avec Vitest et Playwright. La version de Node.js requise n'est pas indiquée dans le matériel fourni. C'est une lacune pratique : React 19 et Vite 5 imposent des versions minimales récentes, et rien ici ne permet de dire lesquelles. À vérifier dans package.json avant de cloner.
Pour GitHub, l'usage est décrit en six étapes : coller l'URL, ajouter éventuellement un jeton, cliquer sur Load Repository, sélectionner les fichiers, cliquer sur Generate Output, puis copier ou télécharger.
Ce que la documentation ne tranche pas
Le README porte un badge MIT et renvoie vers un fichier LICENSE, mais la licence du dépôt n'est pas renseignée dans les métadonnées fournies. Tant que le fichier LICENSE n'est pas lu directement, la prudence s'impose pour tout usage en contexte commercial. Cette rubrique n'est pas un avis juridique : elle signale seulement une incohérence entre le badge affiché et l'absence de licence déclarée.
Plus gênant pour l'évaluation : aucune section ne décrit le comportement en cas d'échec. Que se passe-t-il si l'API GitHub renvoie un 403 parce que le quota est épuisé au milieu du chargement progressif ? Comment les fichiers binaires sont-ils représentés dans la sortie ? Le README ne le dit pas. Un fichier .png inclus par erreur dans la sélection pourrait produire une sortie volumineuse et inutilisable, et rien n'indique qu'un garde-fou existe.
Autre angle mort : le README recommande de consulter AGENT.md, présenté comme une documentation de conception destinée aux agents LLM. C'est un choix inhabituel, et il suggère que la documentation utilisateur classique est moins fournie que la documentation destinée aux outils.
Enfin, les chiffres de performance du README (moins de 2 s sur 3G, Lighthouse 95+) ne sont pas datés ni rattachés à une configuration de test. Ils ne doivent pas servir de base de décision.
Face à un script de concaténation maison
L'alternative la plus directe n'est pas un concurrent identifié, c'est un script de quelques lignes : parcourir l'arborescence, ignorer les fichiers listés dans .gitignore, préfixer chaque contenu par son chemin, écrire le tout dans un fichier. Un tel script tient en une trentaine de lignes et se branche sur n'importe quel dépôt déjà cloné, sans navigateur ni jeton d'API.
La différence est nette sur deux plans. D'abord le coût de mise en place : le script ne demande aucune installation de dépendances npm, aucun port local, aucune compilation. Ensuite la reproductibilité : un script versionné produit le même résultat à chaque exécution, ce que l'interface graphique ne garantit pas puisque la sélection de fichiers est manuelle.
repo2txt reprend l'avantage quand la source n'est pas locale. Pour parcourir un dépôt distant sans le cloner, gérer les jetons, respecter les quotas d'API et compter les tokens au fur et à mesure, le script maison doit réimplémenter plusieurs choses que l'outil fournit déjà. Le choix se résume donc à ceci : script si le dépôt est sur votre disque et que la sélection est stable, interface si la source est distante ou si la sélection change à chaque fois.
Conclusion éditoriale
repo2txt convient à un développeur qui doit coller rapidement un dépôt de taille moyenne dans un chat LLM et qui veut garder la main sur le filtrage. Il ne convient pas à un pipeline automatisé ni à un dépôt dont le contenu est confidentiel et qui exigerait une politique de conservation. Avant de l'adopter, vérifiez le contenu de LICENSE et la version de Node.js attendue, puis testez le rendu de sortie sur un dépôt contenant des fichiers binaires et un .gitignore non trivial.
Notes de la communauté