code2prompt : transformer un dépôt en un seul prompt, avec ses angles morts

Le problème concret : recopier du code à la main pour le donner à un modèle

Coller des fichiers dans une fenêtre de chat ne tient pas longtemps. Il faut choisir quoi inclure, exclure les dépendances, respecter les fichiers ignorés par Git, et garder une trace de ce qui a été envoyé. code2prompt prend le dépôt comme entrée et produit un bloc de texte unique contenant l'arborescence et le contenu des fichiers retenus. Le README résume la cible : « Convert your codebase into a single LLM prompt ». L'usage visé est double. D'un côté un développeur qui prépare manuellement du contexte pour ChatGPT ou Claude. De l'autre un agent ou un script qui a besoin de ce contexte de façon programmatique, via le SDK Python ou le serveur MCP décrits dans la section Ecosystem du dépôt. Le projet ne cherche pas à sélectionner les fichiers pertinents pour une question donnée. Il assemble un corpus déterministe, filtré par des règles explicites.

Ce que fait réellement le binaire : parcours, filtrage, assemblage

La bibliothèque interne, code2prompt_core, est présentée comme responsable du parcours sécurisé des fichiers, du respect des règles .gitignore et de la structuration des métadonnées Git. Le CLI s'appuie dessus et ajoute la couche de rendu. Le flux est donc séquentiel : on part d'un chemin, on énumère les fichiers, on écarte ceux que les motifs glob et le .gitignore rejettent, on lit le contenu, on l'insère dans un gabarit Handlebars, puis on écrit le résultat sur stdout, dans un fichier ou dans le presse-papiers. Le filtrage est le cœur du comportement. Si un fichier volumineux ou un secret passe à travers, il se retrouve dans le prompt, et rien dans la documentation fournie ne suggère un masquage automatique des identifiants. Le comptage de tokens mérite une lecture attentive. Le README précise que l'estimation repose sur des comptages parallèles par fichier plus une estimation de la surcharge du template, numéros de ligne optionnels compris, que le prompt rendu complet n'est pas re-tokenisé et que l'enveloppe JSON de sortie est exclue. Autrement dit, le chiffre affiché est une approximation, pas une mesure du texte final. Sur un dépôt où le template est lourd, l'écart peut compter.

Installation et première commande

Trois canaux sont documentés. Via Cargo : cargo install code2prompt. Une variante existe pour Wayland, utile si l'intégration presse-papiers doit fonctionner sur ce type de session : cargo install --features wayland code2prompt. Via Homebrew : brew install code2prompt. Et via pip pour le SDK Python uniquement : pip install code2prompt-rs. Le SDK est un binding vers le cœur Rust, publié sur PyPI ; il ne remplace pas le binaire. La commande de base tient en un argument. code2prompt . génère un prompt depuis le répertoire courant, sur stdout par défaut, avec l'option -c pour copier vers le presse-papiers. Pour écrire dans un fichier : code2prompt path/to/project --output-file prompt.txt. Le README mentionne aussi une interface TUI interactive et des templates Handlebars personnalisables, sans détailler les clés de configuration dans l'extrait fourni. C'est une lacune documentaire réelle : pour connaître les noms exacts des options de filtrage ou la structure attendue d'un template, il faut consulter code2prompt.dev/docs. Un point à noter pour les agents : le dépôt fournit une skill installable via npx skills add mufeedvh/code2prompt, qui s'appuie sur sem-core pour cartographier fonctions et classes avant de lire les fichiers, avec un repli sur une carte de répertoires pour les builds standard. L'installateur ajoute le dossier de skill et son template à l'agent, et peut cloner le dépôt temporairement pour les récupérer ; le reste du dépôt n'est pas installé. Le CLI, lui, s'installe séparément.

Là où l'outil atteint sa limite

Un dépôt de taille moyenne dépasse vite la fenêtre de contexte d'un modèle, et code2prompt ne résout pas ce problème : il le rend visible. La documentation ne décrit aucun classement par pertinence, aucune sélection basée sur la question posée. Le filtrage est déclaratif, par motifs. C'est un choix défendable, parce qu'il rend le résultat reproductible, mais cela signifie que la charge de choisir ce qui entre dans le prompt reste entièrement sur l'utilisateur. Deuxième limite : l'estimation de tokens n'est pas le comptage du prompt final, comme indiqué plus haut. Un utilisateur qui dimensionne son budget de contexte sur ce chiffre travaille sur une approximation. Troisième point, l'absence de traitement particulier des secrets n'est compensée que par la qualité du .gitignore et des motifs d'exclusion. Sur un dépôt où des fichiers de configuration locaux ne sont pas ignorés par Git, ils partiront dans le prompt. Enfin, le projet n'est pas le bon outil si vous cherchez une base de code interrogeable en continu par un agent. Le serveur MCP existe précisément pour ce cas, mais il s'agit d'un composant distinct, pas du comportement par défaut du CLI.

Face à un simple script d'assemblage

L'alternative évidente est un script maison : un find, un grep pour lire les fichiers, une concaténation. La différence ne porte pas sur la faisabilité, elle porte sur trois choses que le script doit réimplémenter. D'abord le respect des règles .gitignore, qui n'est pas trivial à reproduire correctement, en particulier avec les motifs imbriqués. Ensuite le rendu par template Handlebars, qui permet de garder plusieurs formats de prompt pour des usages différents sans toucher au code. Enfin le comptage de tokens par fichier, exécuté en parallèle selon le README. Un script fait le travail pour un dépôt personnel et un format figé. code2prompt devient intéressant dès qu'il faut plusieurs formats, un filtrage cohérent avec Git et une intégration dans un pipeline Python ou un agent. La comparaison avec un outil de recherche sémantique est d'une autre nature : ceux-ci sélectionnent des extraits pertinents à la volée, code2prompt produit un instantané complet. Les deux approches répondent à des besoins différents, et le projet assume la seconde.

Coût de maintenance et licence

Le dépôt est publié sous licence MIT, ce qui autorise la réutilisation, la modification et la redistribution, y compris dans un contexte commercial, à condition de conserver l'avis de copyright et le texte de la licence. Ce n'est pas un avis juridique ; pour un usage en entreprise, faites vérifier les obligations exactes par qui de droit. Le langage est Rust, donc la compilation depuis les sources demande une chaîne d'outils Rust et Git, comme l'indique la section Source build du README. Les versions binaires précompilées sont proposées dans les Releases, ce qui évite cette étape. Le rythme des publications visibles dans les métadonnées va de v3.0.2 en avril 2025 à v4.2.0 en décembre 2025, avec une poussée sur la branche principale en septembre 2026. Un passage de version majeure en cours d'année signifie que les templates et les options peuvent bouger : si vous versionnez vos templates Handlebars dans un dépôt, prévoyez de les revérifier à chaque montée de version majeure. Le SDK Python publié sur PyPI suit le cœur Rust, donc une montée de version du binaire peut impliquer une mise à jour du paquet pip pour rester cohérent.

Conclusion éditoriale

code2prompt convient aux développeurs qui veulent un artefact de contexte reproductible, versionnable et scriptable, pas à ceux qui cherchent une sélection sémantique du code pertinent. Avant de l'adopter, lancez code2prompt . et vérifiez le prompt produit sur votre propre dépôt : la présence de fichiers générés, de secrets ou de binaires mal filtrés se voit immédiatement dans la sortie, et c'est le seul contrôle qui compte vraiment.

Sources officielles

1. License: MIT
2. mufeedvh/code2prompt on GitHub
3. Project website
4. README
5. Releases