Convertisseur de dossier local en texte

Convertir un dossier local en texte : votre base de code dans un seul fichier, sans rien envoyer

Pointez cet outil vers un dossier de votre machine et vous récupérez un seul fichier texte : l'arborescence des répertoires en tête, puis chaque fichier que vous avez sélectionné, séparé par un en-tête indiquant son chemin. Peu importe le nom qu'on lui donne — regrouper une base de code dans un fichier unique, concaténer des sources, fusionner un répertoire en un seul document — l'idée est là. C'est le format qu'un LLM digère le mieux, parce que le modèle voit la forme du projet et le contenu en même temps, et qu'il peut raisonner sur la façon dont un fichier se rattache à un autre.

C'est gratuit, sans inscription, et il n'y a rien à installer. Choisissez un dossier, décochez ce dont le modèle n'a pas besoin, et exportez le projet en un seul fichier texte que vous collerez où vous voulez.

Le point qui intéresse tout le monde : rien n'est envoyé. Il n'y a aucun serveur dans ce circuit. Vos fichiers sont lus dans le navigateur, assemblés en mémoire, et vous sont rendus. Si vous évitiez jusqu'ici les convertisseurs en ligne parce que la base de code appartient à un client, qu'elle est sous NDA, ou tout simplement qu'elle n'est pas à vous et n'a rien à faire chez un tiers, l'objection ne tient plus — et la section suivante explique précisément pourquoi, parce que « faites-nous confiance, c'est sécurisé » n'est pas une réponse acceptable.

Comment convertir un répertoire en fichier texte sans que rien ne quitte votre machine

Les navigateurs modernes savent lire des fichiers sur le disque sans les envoyer nulle part. Quand vous choisissez un dossier, le navigateur remet à la page une liste de handles de fichiers. Chacun est lu avec l'API standard FileReader, qui décode les octets en chaîne de caractères dans la mémoire de l'onglet lui-même. L'arborescence, le compteur de tokens, la concaténation — tout se passe en JavaScript, sur votre machine. Aucun fetch, aucun XHR, aucun endpoint d'API, aucun appel d'analytics tiers transportant le contenu de vos fichiers. Ouvrez l'onglet réseau de votre navigateur pendant la conversion : vous le verrez rester vide.

Ce mécanisme a des effets de bord utiles, au-delà de la confidentialité :

• Ça marche hors ligne. Une fois la page chargée, débranchez le câble réseau : la conversion tourne toujours. Pratique sur une machine isolée ou sur un réseau d'entreprise verrouillé.
• Ni limite d'envoi, ni limite de débit. Il n'y a aucun quota d'API à saturer, puisqu'il n'y a pas d'API. Le seul plafond, c'est la mémoire de votre navigateur et votre patience.
• Ça marche sur du code qui n'a jamais été committé. Une branche de brouillon, un essai non suivi, un dossier qui n'a jamais vu passer un git init — le convertisseur de dépôt GitHub en texte ne peut rien pour vous là-dessus, puisqu'il lit via l'API GitHub. Celui-ci lit sur le disque : votre situation vis-à-vis du gestionnaire de versions lui est complètement indifférente.
• Rien n'est conservé. Fermez l'onglet et l'état disparaît — pas d'historique à purger, aucun compte qui garde une copie de vos sources.

Trois façons de faire entrer un projet

Utilisez le sélecteur de répertoire pour naviguer jusqu'à un dossier, ou glissez le dossier directement depuis le Finder ou l'Explorateur sur la zone de dépôt. Les deux parcourent l'arborescence récursivement : vous récupérez tout le projet, sous-répertoires imbriqués compris, et pas seulement le premier niveau.

Vous pouvez aussi déposer une archive ZIP, qui est décompressée dans le navigateur — pratique quand quelqu'un vous a envoyé un projet par mail, ou que vous préférez ne pas l'extraire du tout. Une distinction mérite d'être connue : passez par cette page quand l'archive contient un projet de code, parce que vous voulez l'arborescence et les en-têtes de chemin fichier par fichier. Si c'est un tas de documents — rapports, tableurs, PDF —, ZIP vers texte ou ZIP vers Markdown conviennent mieux, puisque ces pages extraient le contenu lisible de chaque document au lieu de traiter les fichiers comme du code source.

N'importe quel IDE, n'importe quel éditeur — il ne demande qu'un dossier

Il n'y a pas de plugin à installer ni d'extension à autoriser, parce que cet outil ne s'intègre pas du tout à votre éditeur. Il prend un répertoire. Que ce répertoire soit un espace de travail VS Code, un projet IntelliJ IDEA ou PyCharm, une solution Visual Studio, un module Android Studio, un projet Xcode, un workspace Eclipse ou un dossier que vous n'avez jamais ouvert ailleurs que dans Neovim, ce sont les mêmes fichiers sur le même disque. Pointez le sélecteur dessus et c'est réglé.

Ça mérite d'être dit, parce que « exporter mon projet VS Code en un seul TXT » et « exporter un projet IntelliJ dans un fichier unique » sont des questions qu'on pose d'abord à son éditeur. Or l'éditeur est en général le mauvais endroit où chercher. Il exporte des fichiers, un par un. Quelques-uns ont une extension du marketplace qui règle à moitié le problème, la plupart n'ont rien, et chacun s'y prend à sa manière : la réponse valable pour un IDE ne sert plus à rien dès que vous en changez. Le dossier, lui, est le dénominateur commun.

C'est aussi un meilleur réflexe que de zipper le projet et de l'envoyer. Une archive convient très bien de développeur à développeur, mais un modèle de chat veut du texte, pas un conteneur, et un relecteur doit l'extraire avant de lire une seule ligne. Un .txt consolidé se lit tel quel : collez-le dans une conversation, attachez-le à un ticket, glissez-le dans un fil de mail. Et si c'est vous qui avez reçu un ZIP, déposez-le directement sur cette page plutôt que de le décompresser d'abord.

Élaguez sans pitié avant de générer

C'est l'étape que les gens sautent, et c'est celle qui décide si la sortie sera exploitable. Tout est coché par défaut dans l'arborescence, ce qui veut dire que vous êtes sur le point d'inclure une quantité de choses qu'aucun modèle n'a besoin de voir.

Un point joue en votre faveur. Si le dossier contient un .gitignore, il est lu et ses règles sont appliquées — y compris les fichiers imbriqués plus bas dans l'arborescence, chacun limité à son propre répertoire, les lignes de commentaire étant ignorées. Sur un dépôt normal, ça écarte discrètement l'essentiel des pires coupables avant même que vous touchiez à quoi que ce soit, parce que ce qui gonfle un dump est en général exactement ce que vous aviez déjà demandé à git de laisser tranquille. Le répertoire .git lui-même est toujours exclu.

Ne vous reposez pas dessus pour autant. Un dossier sans .gitignore — un ZIP extrait, une livraison de prestataire, un répertoire qui n'a jamais été un dépôt — ne bénéficie d'aucune de ces protections. Et beaucoup de choses bruyantes sont légitimement suivies par git. Parcourez l'arborescence et décochez ceci :

• node_modules, vendor, .venv, site-packages. Les arbres de dépendances sont énormes et rien là-dedans n'est votre code. Un node_modules non élagué représente à lui seul des centaines de milliers de tokens de sources écrites par d'autres. Il va noyer le vrai projet, et les réponses du modèle dériveront vers les entrailles des bibliothèques.
• Les artefacts de build — dist, build, .next, target, out, rapports de couverture. C'est votre propre code, minifié ou transpilé, en double. Du bruit pur.
• Les lockfiles. package-lock.json, yarn.lock, poetry.lock, Cargo.lock. Des milliers de lignes de hachages qui ne portent presque aucune information. Gardez le manifeste (package.json, pyproject.toml) — c'est lui qui indique au modèle sur quelle stack vous êtes.
• Le code généré et les fixtures — sorties protobuf, codegen GraphQL, migrations de base de données, gros fichiers de seed ou de snapshot.
• Tout ce qui contient des secrets. Rien n'est transmis d'ici, mais le fichier de sortie finira dans une fenêtre de chat. Laissez .env de côté.

Les fichiers binaires sont traités pour vous : images, polices, artefacts compilés et compagnie sont filtrés par extension avant même d'arriver dans l'arborescence, et ce qui passe entre les mailles est rattrapé par une détection d'octet nul, puis remplacé par un court marqueur au lieu d'être déversé en charabia. Les fichiers de plus de 1 MB reçoivent eux aussi un marqueur indiquant leur taille, ce qui évite qu'un CSV égaré avale tout votre budget de contexte.

Il y a également un commutateur pour l'arborescence en tête de la sortie : filtrée n'affiche que ce que vous avez sélectionné, complète affiche la structure entière avec vos sélections marquées. Complète est le meilleur choix quand votre question porte sur l'architecture, parce que le modèle peut voir qu'un répertoire tests/ existe même si vous ne l'avez pas inclus. Filtrée vaut mieux quand vous voulez que le modèle reste concentré sur un point précis, et rien d'autre.

Rester dans la fenêtre de contexte

La sortie générée est accompagnée d'un vrai décompte de tokens, produit par la bibliothèque gpt-tokenizer et non par une estimation « nombre de caractères divisé par quatre ». Vérifiez-le pour le modèle que vous visez avant de coller. C'est un flux de travail nettement plus efficace que de coller, d'attendre, et de récupérer une erreur de longueur.

Quelques repères sur la quantité à envoyer. Envoyez le projet entier quand il tient confortablement et que votre question est architecturale — « où l'authentification est-elle réellement appliquée », « qu'est-ce qui casserait si je changeais cette interface », « expliquez le flux de données de la requête jusqu'à la base ». Le modèle a besoin de la vue d'ensemble pour y répondre honnêtement, et un dump partiel produit des suppositions très assurées sur des fichiers qu'il n'a jamais vus.

Envoyez une tranche quand la question est locale — un module, plus les tests qui le couvrent, plus les deux ou trois fichiers dont il importe quelque chose. Un contexte plus réduit donne des réponses plus nettes et moins de dérive, et 5 000 tokens bien choisis valent en général mieux que 200 000 pris au hasard.

Les monorepos demandent une approche délibérée. Ne convertissez pas la racine du dépôt. Convertissez un paquet à la fois, et si ce paquet dépend d'une bibliothèque interne partagée, joignez-y la surface publique de cette bibliothèque. Si vous avez besoin de contexte inter-paquets, une bonne astuce consiste à procéder en deux passes : une première avec l'arborescence complète et presque aucun fichier sélectionné — ça donne une carte au modèle — puis une seconde, riche en fichiers, sur le paquet dans lequel vous travaillez vraiment.

Pourquoi ne pas simplement lancer cat ou un script shell ?

La question est légitime, et la réponse honnête est parfois que oui, il faut le faire. Si vous voulez réunir trois fichiers que vous connaissez déjà, cat auth.py models.py routes.py > out.txt est plus rapide que d'ouvrir un navigateur. Personne n'essaie de vous en dissuader.

Ça cesse d'être rentable au moment où vous le pointez sur un projet entier. Lancez find . -type f -exec cat {} + sur un vrai dépôt et voici ce que vous obtenez :

• Des binaires au milieu de vos sources. PNG, polices, objets compilés, une fixture SQLite oubliée là — tout décodé comme du texte, tout en mojibake. Et vous voilà parti à maintenir une liste blanche d'extensions.
• L'arbre de dépendances au complet. node_modules, .venv, vendor, target, et le contenu de .git lui-même. Les exclure, c'est écrire des expressions de prune et les tenir à jour pour chaque projet sur lequel vous travaillez. Ici, votre .gitignore décrit déjà exactement ça, fichiers imbriqués compris, et il est appliqué pour vous.
• Aucune idée de la taille obtenue. Une concaténation vous donne des octets, pas des tokens, et diviser les caractères par quatre est une approximation fausse dans les deux sens. Vous découvrez que ça ne rentre pas au moment où le modèle refuse.
• Le contrôle fin coûte du script. « Tout ce qui est sous src sauf le client d'API généré, plus les deux fichiers de configuration à la racine » : c'est encore une option et encore une regex. Une arborescence à cocher fait ça en quatre clics.
• Aucune carte en tête de fichier. Une concaténation brute est un mur de texte sans en-tête de structure : le modèle ne peut pas dire où un fichier se termine et où le suivant commence, ni à quoi ressemble la disposition du projet. Les sections délimitées par chemin et l'arborescence font l'essentiel de ce qui rend un dump lisible.

Tout cela est constructible, et beaucoup de gens l'ont construit. C'est un après-midi de script, puis un petit outil de plus à maintenir. L'arbitrage porte sur ce que vous voulez vraiment : le script, ou la sortie.

À quoi les gens s'en servent vraiment

• La base de code dont vous venez d'hériter. Quelqu'un est parti, et voilà un service de 40 000 lignes qui est à vous. Convertissez, collez, et demandez les points d'entrée, les abstractions principales et les trois choses qui surprendraient le plus un nouveau mainteneur. Vous serez situé plus vite qu'avec n'importe quel document de passation qu'on vous remettra.
• De la documentation tirée du vrai code. Les README pourrissent parce qu'ils sont écrits une fois. Générez-les à partir du code tel qu'il existe aujourd'hui — aperçu d'architecture, résumés de modules, liste exacte des variables d'environnement que l'application lit réellement.
• Des tests pour du code qui n'en a pas. 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 de test que vous n'utilisez pas.
• 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 vous donne une vraie séquence d'étapes plutôt qu'une checklist générique.
• RAG et embeddings. Un fichier texte unique et propre, aux sections délimitées par chemin, se découpe sans difficulté sur ces délimiteurs et part dans une base vectorielle.

Une fois terminé, copiez la sortie dans le presse-papiers ou téléchargez-la en .txt — ça vaut le coup de la garder si vous réutilisez le même contexte sur plusieurs conversations.

Le code n'est que la moitié du contexte

La plupart des vraies questions sur un projet font aussi intervenir des choses qui ne sont pas des fichiers source. La spécification est dans un PDF, le schéma dans un fichier JSON, la configuration en XML, les données dans un CSV. Convertissez tout ça séparément et collez-le à côté du dump de votre base de code : PDF vers Markdown pour les spécifications et la documentation fournisseur, Word vers Markdown pour les cahiers des charges, JSON vers Markdown pour les payloads et les schémas d'API, XML vers Markdown pour les vieilles configurations, CSV vers Markdown pour les données d'exemple, et HTML vers Markdown pour les pages exportées. Si vous préférez ne pas choisir de format, File2Txt prend ce que vous lui donnez.

Questions fréquentes

Comment convertir un dossier en texte pour un LLM ?

Choisissez un répertoire ci-dessus et son arborescence apparaît sous forme de liste à cocher. Cochez les fichiers voulus et exportez un seul fichier texte : la structure des répertoires d'abord, puis chaque fichier sous un en-tête indiquant son chemin. Gratuit, sans inscription, rien à installer.

Mon code est-il envoyé sur un serveur ?

Non. Il n'y a aucun serveur dans ce circuit. Le dossier est lu dans le navigateur, la sortie est assemblée dans le navigateur, et rien ne traverse le réseau — ouvrez les outils de développement et regardez, ou coupez la connexion une fois la page chargée : ça fonctionne toujours. C'est là toute la différence avec le convertisseur GitHub, qui doit appeler l'API.

Peut-on convertir la base de code d'une entreprise en ligne sans risque ?

Cette page est celle qui répond à la question par un mécanisme plutôt que par une promesse : les fichiers ne quittent jamais la machine, il n'y a donc rien à nous accorder comme confiance. Ce qui compte encore, c'est la suite — coller la sortie dans un modèle hébergé l'envoie chez ce fournisseur, alors vérifiez la politique de votre organisation et retirez les secrets avant de le faire.

Puis-je convertir un projet entier, sous-dossiers compris ?

Oui, toute l'arborescence est parcourue et chaque niveau est sélectionnable. Désélectionner un dossier retire en un clic tout ce qu'il contient : c'est comme ça qu'on écarte node_modules ou .git sans aller fouiller les enfants. Le compteur de tokens se met à jour au fur et à mesure, l'effet est donc visible immédiatement.

Quels navigateurs permettent de choisir un dossier entier ?

La sélection de dossier repose sur l'attribut d'envoi de répertoire que Chrome, Edge, Firefox et Safari prennent en charge depuis des années : n'importe quel navigateur de bureau récent fait l'affaire. Les navigateurs mobiles sont le point faible — ni iOS ni Android n'expose de sélecteur de dossier. Sur téléphone, zippez le répertoire et passez plutôt par ZIP vers texte.

Y a-t-il une limite de taille de fichier ?

Il n'y a pas d'envoi, donc pas de limite d'envoi — la contrainte, c'est la mémoire de votre machine et la quantité de texte que vous pourrez ensuite coller utilement quelque part. En pratique, le compteur de tokens devient la vraie limite bien avant le navigateur. Un dépôt dont les sources utiles pèsent moins d'un mégaoctet couvre la plupart des projets, une fois les dépendances désélectionnées.

Le reste de la boîte à outils

Si le code est hébergé plutôt que local, le convertisseur GitHub vers texte et le convertisseur GitLab vers texte font le même travail sur un dépôt distant, dépôts privés compris avec un token. Pour la documentation qui n'existe que sur le web, Web2Txt récupère une URL en Markdown propre — associez une référence d'API récupérée à vos sources locales et un assistant de code voit les deux côtés à la fois.

Il y a de quoi aller plus loin sur le blog : transformer une base de code en fichier prêt pour un LLM, un pas-à-pas du convertisseur de dossier en texte, un guide pour donner un dépôt entier à manger à une IA, et le guide général de la conversion de fichiers en texte pour tout ce qui n'est pas du code.

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.