yek : sérialiser un dépôt en un seul flux pour un LLM

Le problème : recoller un dépôt avant de le donner à un modèle

Un modèle de langage ne lit pas un arborescence. Il lit une séquence de texte. Pour lui soumettre un projet, il faut donc choisir des fichiers, les ordonner, les séparer par un marqueur et tenir dans une fenêtre de contexte finie. C'est un travail manuel répétitif, et c'est précisément ce que yek automatise. L'outil prend un ou plusieurs chemins en argument, parcourt les fichiers texte, et produit une sortie unique où chaque fichier est précédé d'une ligne de la forme >>>> README.md, comme le montre le README sur un dépôt d'exemple. La cible est claire : développeurs et équipes qui alimentent un assistant de code ou un pipeline d'analyse avec un dépôt local. Le nom vient du persan يک, qui signifie un, ce que le README rappelle explicitement. Rien dans le matériel fourni n'indique un usage serveur ou une intégration dans une API : c'est un outil en ligne de commande, pensé pour être lancé dans un terminal.

Ce qui décide de la liste des fichiers, et dans quel ordre

Deux mécanismes structurent la sortie. Le premier est l'exclusion : par défaut, yek applique les règles de .gitignore, puis ajoute ses propres motifs pour écarter les binaires, les fichiers trop volumineux et d'autres cas que le README regroupe sous l'expression « additional ignore patterns ». Le second est le classement. Le README indique que yek utilise l'historique Git pour déduire quels fichiers sont les plus importants, et que ces fichiers sont placés en dernier dans la sortie. La justification donnée est comportementale : les modèles prêteraient davantage attention au contenu situé vers la fin du contexte. C'est un pari raisonnable, mais qui dépend du modèle et de la manière dont le prompt est assemblé. Le README précise aussi que l'outil détecte si la sortie est redirigée vers un tube, auquel cas il écrit en flux au lieu de créer un fichier. Cette détection change le mode de sortie sans qu'aucune option ne soit passée, ce qui surprend au premier appel.

Installation et premiers appels

Sur macOS et Linux, le README donne une commande d'installation par script : curl -fsSL https://azimi.me/yek.sh | bash. Sur Windows, l'équivalent PowerShell est irm https://azimi.me/yek.ps1 | iex. Une compilation depuis les sources est également documentée : git clone https://github.com/mohsen1/yek, puis cd yek et cargo install --path . L'exécution de base consiste à lancer yek sans argument dans un dépôt, ce qui produit un fichier temporaire dont le chemin est affiché. Pour envoyer la sortie vers le presse-papiers sur macOS, le README propose yek src/ | pbcopy. Pour plafonner la taille, deux modes coexistent : --max-size 100KB compte en octets, tandis que --tokens 128k bascule en comptage de jetons. Le README signale que dans ce second mode, les fichiers qui ne rentrent pas sont retirés et que l'outil tente de conserver les plus importants. On peut aussi passer plusieurs chemins, des fichiers isolés, ou des motifs glob, à condition de les mettre entre guillemets pour éviter l'expansion par le shell, comme dans yek "src/**/*.ts".

yek.yaml : ce qui se règle sans toucher à la ligne de commande

Le fichier yek.yaml se place à la racine du projet, ou à un chemin arbitraire via --config-file. Le README liste les catégories qu'il couvre : motifs d'exclusion supplémentaires, règles de priorité entre fichiers, extensions binaires à ignorer en plus de la liste interne, activation du bonus lié à Git, répertoire et nom du fichier de sortie, gabarit de sortie. La plupart des options CLI ont un équivalent en configuration, notamment max_size, tokens, ignore_patterns, unignore_patterns, json et debug. Deux options méritent l'attention. --unignore-patterns sert à annuler un motif intégré, ce qui est indispensable quand un fichier utile tombe dans une exclusion par défaut. --output-template accepte les marqueurs FILE_PATH et FILE_CONTENT et remplace la ligne >>>> par défaut, ce qui permet d'adapter le format si votre outil en aval attend autre chose. --no-config force l'ignorance de tout fichier de configuration, pratique pour reproduire un résultat en isolation.

Les cas où l'outil ne fait pas ce qu'on attend

Le mode jeton ne fait pas de magie. Le README est explicite : les fichiers qui ne tiennent pas dans le plafond sont supprimés de la sortie. Autrement dit, --tokens 128k ne tronque pas un fichier, il en écarte des entiers. Un unique fichier volumineux peut donc disparaître alors que des dizaines de petits fichiers restent. Pour un dépôt où la logique vit dans un gros module, c'est un comportement à vérifier avant de faire confiance au résultat. Deuxième limite, plus structurelle : le classement par historique Git suppose un dépôt Git avec un historique exploitable. Sur un dossier hors dépôt, ou sur un dépôt fraîchement initialisé avec un seul commit, la notion de fichier important n'a pas grand-chose à exploiter, et le README ne documente pas de repli. Troisième point, l'exclusion par .gitignore : des fichiers présents localement mais ignorés par Git, comme un .env de configuration ou des fixtures générées, ne seront pas inclus sans --unignore-patterns. Enfin, --tree-header et --tree-only sont déclarés incompatibles avec --json, ce qui interdit de combiner un arbre lisible et une sortie structurée.

Face à une simple boucle find et à l'indexation

L'alternative immédiate est un script maison : find, grep, puis cat avec un séparateur. Ce script a l'avantage d'être lisible et de ne rien installer, mais il faut réimplémenter soi-même le respect de .gitignore, l'exclusion des binaires, le plafonnement par jetons et l'ordre de priorité. C'est là que se loge la différence réelle : yek traite ces quatre points comme des fonctions de premier plan, alors qu'un script les traite comme des cas particuliers découverts à l'usage. L'autre famille d'outils est l'indexation : au lieu de produire un flux de texte, elle découpe le dépôt en morceaux, calcule des vecteurs et permet une recherche par similarité. L'approche est différente, pas supérieure : elle nécessite un service de stockage et une étape d'indexation, et ne fournit pas un fichier unique que l'on peut inspecter avant envoi. yek reste dans le modèle du tout-en-un, ce qui le rend vérifiable à l'œil, mais inadapté à un dépôt qui dépasse largement la fenêtre de contexte du modèle visé.

Coût de maintenance et licence

Le dépôt est publié sous licence MIT, ce qui autorise la réutilisation et la modification, y compris dans un contexte commercial, à condition de conserver la mention de copyright et le texte de la licence. Ce n'est pas un avis juridique : si l'outil est redistribué dans un produit, faites relire la notice par qui de droit. Le rythme de publication est soutenu, avec trois versions rapprochées listées entre juin 2026 (v0.25.3, v0.25.4, v0.25.5). Une numérotation encore en 0.x signifie que l'interface en ligne de commande peut évoluer, et le README documente déjà des incompatibilités entre options. Pour un usage interne, mettre à jour revient à relancer le script d'installation ou cargo install --path . après un git pull. Le risque de rupture est faible sur les options de base, plus élevé sur --output-template et sur le format JSON, dont le schéma n'est pas décrit dans le matériel fourni.

Conclusion éditoriale

yek convient aux équipes qui veulent fournir un dépôt entier à un modèle sans écrire de script de concaténation : la détection de .gitignore, le classement par historique Git et le plafonnement par --tokens couvrent l'essentiel du besoin. Il ne convient pas si vous devez indexer un dépôt volumineux de façon incrémentale, si vos fichiers utiles sont ignorés par Git, ou si vous voulez interroger le code par recherche sémantique. Avant de l'adopter, vérifiez la version installée par le script d'installation, puis lancez yek --tree-only sur votre dépôt pour contrôler la liste des fichiers retenus avant de générer la sortie complète.

Sources officielles

1. Issues
2. License: MIT
3. mohsen1/yek on GitHub
4. README
5. Releases