Convertir un dépôt GitLab en texte : un seul fichier que votre LLM peut vraiment lire
Coller du code dans une fenêtre de chat fichier par fichier, c'est une belle façon de perdre son après-midi. Le modèle répond à chaque question à travers un trou de serrure, vous passez votre temps à dire « attendez, voilà l'autre fichier qu'il importe », et le temps que le contexte soit complet, la conversation est déjà partie de travers. La solution n'a rien de spectaculaire, mais elle marche : donnez d'emblée la tranche pertinente du dépôt, en un seul bloc de texte.
C'est ce que fait cette page. C'est le chemin le plus court entre un dépôt GitLab et le contexte d'un
LLM : collez une URL de projet https://gitlab.com/..., l'outil lit l'arborescence du dépôt
via l'API GitLab, et vous obtenez une arborescence à cocher de tous les fichiers. Cochez ce qui compte,
décochez le reste, générez. En sortie : une carte des répertoires, puis le contenu intégral des fichiers
que vous avez retenus, avec un compteur de tokens pour savoir si ça tient. Copiez, téléchargez en texte,
ou récupérez les fichiers sélectionnés dans un ZIP.
Collez l'URL que vous avez déjà sous les yeux
Aucun identifiant de projet à aller chercher, aucun champ séparé pour l'espace de noms. Copiez l'URL
depuis la barre d'adresse de votre navigateur et collez-la. Les sous-groupes imbriqués passent sans
problème : cette manie qu'a GitLab d'enterrer un projet trois ou quatre niveaux plus bas sous
company/platform/services/billing est gérée, parce que le chemin du projet est encodé pour
l'URL avant d'atteindre l'API.
Si l'URL copiée contient une branche ou un tag, c'est cette référence qui est utilisée. Si c'est l'URL nue
du projet, la branche par défaut est résolue toute seule — inutile de vous souvenir si ce dépôt-là s'est
arrêté sur main, master ou develop. L'arborescence est récupérée
récursivement et paginée, ce qui compte plus qu'il n'y paraît : beaucoup de monorepos GitLab dépassent les
milliers de fichiers, et une requête unique sans pagination vous rendrait discrètement un projet tronqué.
Projets privés, et où va exactement votre token
Les projets publics ne demandent rien. Pour un projet privé, ajoutez un personal access token GitLab : il
est envoyé dans l'en-tête PRIVATE-TOKEN des requêtes vers
l'API GitLab.
Se méfier avant de coller un token dans un outil web est le bon réflexe, alors voici la version sans
détour : le token est conservé dans le localStorage de votre navigateur et sert uniquement à
appeler gitlab.com directement depuis votre navigateur. Il n'est envoyé à aucun serveur à
nous, pour la simple raison que les requêtes n'en traversent aucun.
Une portée en lecture seule suffit : read_api ou read_repository. Ne lui donnez
pas un accès en écriture dont il ne se servira jamais, et fixez une date d'expiration tant que vous êtes
sur l'écran des tokens. Ça vaut d'ailleurs le coup d'en ajouter un même pour les dépôts publics : les
appels non authentifiés à l'API GitLab sont limités en débit, donc si vous récupérez un gros projet ou si
vous relancez plusieurs fois la même conversion, une requête authentifiée fait la différence entre un
chargement fluide et un mur d'erreurs.
GitLab auto-hébergé : la réponse honnête
Cet outil parle à gitlab.com, et seulement à gitlab.com. Il n'y a pas de champ
pour l'URL d'une instance personnalisée, et coller gitlab.yourcompany.internal ne donnera
rien. Si vous êtes sur une instance auto-hébergée ou auto-gérée, c'est non, franchement.
La bonne nouvelle, c'est que pour une instance auto-gérée, la meilleure réponse n'a jamais été un appel d'API de toute façon. Clonez le dépôt — vous avez déjà les identifiants — et pointez le convertisseur de dossier local sur le répertoire. Il lit les fichiers via les API fichier du navigateur : rien n'est envoyé, rien ne quitte votre machine. Pour une instance privée derrière un pare-feu d'entreprise, c'est de toute façon la version que votre équipe sécurité aurait exigée. Même arborescence à cocher, même sortie, même compteur de tokens. Il accepte aussi un ZIP si vous préférez exporter une archive plutôt que cloner.
Ce qu'il faut sélectionner, et ce qu'il faut laisser dehors
Tout est coché au départ, ce qui est la mauvaise sélection pour à peu près tous les projets réels. Le réflexe, quand on convertit un dépôt GitLab en texte, c'est de tout prendre ; résistez. Un dump de dépôt utile est un dump trié — chaque token dépensé en bruit généré est un token que le modèle ne dépense pas sur votre vrai code. Décochez ceci en premier :
- Les dépendances vendorisées et installées —
node_modules,vendor,.venv, tout ce qui vient d'un registre de paquets et a été committé. Le modèle sait déjà à quoi ressemble Express. - Les lockfiles.
package-lock.json,yarn.lock,poetry.lock,Gemfile.lock. Un lockfile, ce sont des dizaines de milliers de tokens de hachages et de versions épinglées qui ne répondent à aucune question que quiconque se pose. Gardez le manifeste, jetez le lock. - Les artefacts de build et les assets minifiés —
dist,build,.next, les bundles compilés, les source maps. C'est votre propre code, reformulé sous une forme sur laquelle rien ne peut raisonner. - Les snapshots et les fixtures. Les grosses fixtures de test et les fichiers de snapshot sont répétitifs par construction. Deux ou trois exemples représentatifs valent mieux que les quatre cents.
- Les migrations, en général. Un répertoire de schéma avec six ans de migrations incrémentales ne mérite d'être inclus que si la question porte sur l'historique des migrations lui-même.
Gardez ce qui explique l'intention : les fichiers source, le README, le manifeste, et
.gitlab-ci.yml. Ce dernier est le conseil vraiment spécifique à GitLab — la configuration CI
est l'endroit où les étapes de build, les commandes de test, les cibles de déploiement et les hypothèses
sur l'environnement cohabitent en un seul fichier. Incluez-le et le modèle peut répondre à « pourquoi ça
échoue en CI mais passe en local » au lieu de deviner.
Le bouton d'affichage de l'arborescence est l'autre moitié de l'histoire. Sur Full, la
sortie contient la structure complète du dépôt avec vos fichiers sélectionnés marqués : le modèle voit
donc qu'un module payments existe même si vous ne l'avez pas inclus — du contexte utile, et
peu coûteux en tokens. Sur Filtered, seul ce que vous avez coché apparaît. Full est
généralement le meilleur choix quand vous avez isolé un service dans un monorepo ; filtered est plus net
quand vous envoyez une poignée de fichiers bien ciblés.
Ce pour quoi convertir un dépôt GitLab en texte sert vraiment
- Atterrir sur un projet inconnu. Sélectionnez le répertoire source, le README et la configuration CI, puis demandez une visite guidée des points d'entrée et du trajet d'une requête à partir du moment où elle arrive. Vingt minutes d'orientation, compressées en un seul prompt.
- Relire une merge request avec ce qui l'entoure. Un diff vous dit ce qui a changé ; il ne vous dit pas qui d'autre appelle la fonction modifiée. Exportez le répertoire touché et ses voisins, collez le diff à côté, et vous obtenez des remarques sur les conséquences plutôt que sur le style.
- Écrire la documentation que personne n'a écrite. Donnez-lui un module et demandez un README, une note d'architecture ou des docstrings qui suivent les conventions déjà présentes dans le code au lieu d'en inventer de nouvelles.
- Générer des tests. Incluez le module plus deux ou trois fichiers de test existants. C'est la seconde partie qui rend la sortie exploitable — le modèle reprend vos fixtures, votre nommage et votre style d'assertions au lieu de produire quelque chose qui ne rentre pas dans la suite.
- Les migrations et les montées de version. Changement de version de framework, réécriture dans un autre langage, remplacement d'un ORM. Ça demande une visibilité sur toute la base de code pour attraper chaque site d'appel, ce qu'un export texte unique vous donne exactement.
- Les audits. Demandez où les secrets sont lus, quels endpoints sautent l'authentification, ou ce qui tape encore sur une API interne dépréciée. Des questions aussi larges sont sans réponse quand on avance fichier par fichier.
Dans la plupart de ces cas, ce qui vous intéresse, c'est le répertoire d'un service et pas le groupe
entier. Sélectionnez ce sous-arbre, laissez le reste, et regardez le compteur de tokens avant de coller —
il est calculé avec la bibliothèque gpt-tokenizer, c'est donc un vrai décompte que vous pouvez
comparer à la fenêtre de contexte de votre modèle, pas une estimation. La sortie est la même que vous
exportiez du code GitLab pour une passe de relecture par une IA ou que vous transformiez un projet GitLab
en fichier texte pour ChatGPT, Claude ou Gemini — un seul fichier, et vous pouvez le lire avant de
l'envoyer.
Les fichiers posés à côté de votre code
Un dépôt, ce n'est pas que des fichiers source. La configuration, les schémas, les données de seed et les spécifications sont committés à côté, et certains se lisent mal une fois vidés bruts. Les formats structurés passent mieux en Markdown : JSON vers Markdown pour la configuration et les payloads d'API, XML vers Markdown pour les fichiers Maven, Android et les vieux SOAP qui ne sont jamais partis, CSV vers Markdown pour les données de seed et les exports, et HTML vers Markdown pour les gabarits et la documentation générée. Une spécification arrivée en PDF se convertit aussi, et une archive ZIP peut être aplatie directement en texte. File2Txt prend tout en charge si vous préférez ne pas choisir de page.
Questions fréquentes
Comment convertir un dépôt GitLab en fichier texte ?
Collez l'URL du projet ci-dessus et l'arborescence se charge sous forme de liste à cocher. Sélectionnez les fichiers voulus et exportez un fichier texte unique, avec la structure des répertoires en tête et chaque fichier en dessous, précédé de son chemin. Gratuit, sans installation, sans inscription.
Est-ce que ça marche avec un GitLab auto-hébergé ?
Les instances auto-gérées exposent la même API REST que gitlab.com : une instance joignable se comporte donc de la même manière. Le hic, c'est l'accès réseau — une instance derrière un VPN d'entreprise ou sur un réseau privé n'est pas joignable depuis votre onglet de navigateur, et aucun token n'y changera quoi que ce soit. Dans ce cas, clonez le projet et passez par le convertisseur de dossier local.
Comment convertir un projet GitLab privé ?
Fournissez un personal access token avec la portée read_repository. Créez-le dans Préférences → Jetons d'accès, donnez-lui l'expiration la plus courte qui couvre votre session, et supprimez-le ensuite. La lecture seule suffit largement — un token avec des droits d'écriture ou une portée API complète vous expose plus que la tâche ne l'exige.
Pourquoi exporter un projet GitLab pour un LLM plutôt que le cloner ?
Un clone vous donne un arbre de travail, ce qui n'est pas la bonne forme pour cet usage. Ce qu'un modèle veut, c'est un document unique contenant la structure et le contenu ensemble, débarrassé du bruit. Un clone tire aussi tout l'historique et toutes les dépendances — en général bien plus d'octets que le code sur lequel vous vouliez réellement raisonner.
Les sous-groupes et les chemins de projet imbriqués sont-ils gérés ?
Oui. La structure de groupes imbriqués de GitLab fait que les chemins de projet comptent plusieurs segments, et c'est le chemin complet qui identifie le projet — collez l'URL entière depuis la barre d'adresse plutôt que d'en reconstituer une à la main, et la résolution se fait correctement.
Puis-je convertir le diff d'une merge request au lieu du projet entier ?
Pas depuis cette page — elle travaille sur l'arborescence du dépôt à une référence donnée. Pour de la relecture, la méthode habituelle consiste à convertir les fichiers touchés par la merge request, à coller ça comme contexte, puis à coller le diff en dessous. Le modèle a besoin du code environnant pour juger un changement, et un diff seul le lui donne rarement.
Le reste de la boîte à outils
Votre code est plutôt sur GitHub ? Le convertisseur de dépôt GitHub vers texte fonctionne pareil. Uniquement sur votre machine, ou sur une instance auto-gérée que vous avez clonée ? Passez par le convertisseur de dossier local. Il vous faut le site de documentation plutôt que les sources qui le génèrent ? Web2Txt récupère une URL en Markdown.
Pour le raisonnement en détail derrière tout ça, il y a un guide sur donner un dépôt à manger à un modèle d'IA, un autre sur transformer une base de code en fichier prêt pour un LLM, un guide complet de la conversion de dépôts pour les LLM, et un texte plus large sur la préparation de fichiers pour les outils d'IA.
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.