Litho (deepwiki-rs) : générer une documentation C4 depuis un dépôt, avec un LLM dans la boucle

Le problème : la documentation d'architecture meurt plus vite que le code

Un diagramme de conteneurs dessiné à la main reste juste environ jusqu'au sprint suivant. Les README décrivent l'intention initiale, pas l'état du dépôt. Litho prend le problème par l'autre bout : il lit le code source et en déduit une documentation structurée selon le modèle C4, avec des diagrammes de contexte, de conteneurs, de composants et une couche code. Le README présente l'outil comme un moyen de garder la documentation synchronisée avec les changements du dépôt, et cite l'intégration en pipeline CI/CD pour régénérer la documentation à chaque commit. Le public visé est explicite : équipes de développement, projets open source, développeurs en entreprise. C'est un outil pour ceux qui ont besoin d'une vue d'ensemble de l'architecture, pas d'une référence exhaustive de chaque fonction.

Ce que Litho produit concrètement, et ce qu'il ne produit pas

La sortie annoncée est un Repo-Wiki au format C4, avec plusieurs niveaux de diagrammes. Le README mentionne aussi un système de templates personnalisables pour la documentation générée, ainsi qu'une intégration de connaissances externes : il est possible de monter des sources documentaires (PDF, Markdown, SQL) comme base de connaissance pour enrichir l'analyse. Cette dernière fonction mérite qu'on s'y arrête, car elle déplace le centre de gravité de l'outil. Litho ne se contente pas de résumer du code : il croise le code avec des documents fournis par l'utilisateur. Le README tronqué évoque également une documentation de base de données, sans que l'on puisse confirmer le périmètre exact de cette fonctionnalité à partir des éléments disponibles. Un point à garder en tête : un générateur de ce type décrit l'architecture telle qu'elle apparaît dans le code, pas telle qu'elle a été voulue. Si votre dépôt contient des modules morts ou des chemins de code désactivés, ils peuvent se retrouver dans la documentation au même titre que le reste.

Le mécanisme : analyse du dépôt, appels à un modèle, rendu C4

Le README décrit une chaîne en trois temps. D'abord une extraction : commentaires, structures et relations sont identifiés dans le code source. Ensuite une phase d'analyse confiée à un modèle de langage, qui s'appuie sur les connaissances externes montées le cas échéant. Enfin une phase de rendu qui applique les templates pour produire la documentation C4. Les sujets du dépôt confirment la dépendance à des fournisseurs de modèles variés : openai, claude, deepseek, mistral, openrouter. Le choix du fournisseur n'est donc pas verrouillé sur une API unique, ce qui est un argument réel pour les équipes qui ont déjà un contrat avec l'un de ces acteurs ou qui font tourner des modèles via OpenRouter. Le langage d'implémentation, Rust, est mis en avant dans la description du dépôt et dans le README. Cela implique un binaire compilé plutôt qu'un script à interpréter, ce qui simplifie l'exécution en CI, mais ne dit rien de la qualité de la sortie : elle dépend du modèle choisi et de la structure du dépôt analysé.

Mise en route : ce que le README permet d'affirmer

Le paquet est publié sur crates.io sous le nom deepwiki-rs, ce qui laisse supposer une installation via cargo. Le README fournit un lien vers la documentation du projet, en anglais et en chinois, hébergée dans le dépôt sous docs/en et docs/zh. C'est là qu'il faut aller chercher les clés de configuration exactes, les noms de providers et les variables d'environnement attendues : le README tronqué ne les expose pas. Je ne peux donc pas donner ici de commande ni de clé de configuration vérifiée, et je préfère l'écrire plutôt que de reconstituer une syntaxe plausible. Ce que l'on peut affirmer : l'outil s'installe depuis crates.io, la version courante est la 1.5.0 publiée le 5 avril 2026, et le dépôt contient un workflow GitHub Actions nommé rust.yml, dont le badge de statut figure en tête du README. Ce workflow indique au minimum que le projet est compilé et testé automatiquement, sans que l'on sache ce que la CI couvre exactement.

La limite qui compte : un outil qui a déjà un successeur annoncé

Le README de Litho contient un encart qui annonce que Litho a évolué vers un projet nommé Terrain, présenté comme une carte vivante du code pour les agents. L'encart précise que Litho reste le générateur C4 rapide et ciblé. Cette situation est inconfortable pour un adoptant. Deux projets coexistent, avec une promesse de continuité, mais rien dans les éléments fournis ne permet de savoir lequel recevra les correctifs de sécurité et les mises à jour de compatibilité avec les API des fournisseurs de modèles. Or c'est précisément le point de fragilité d'un outil de ce type : les API OpenAI, Anthropic, Mistral et les autres évoluent, et un générateur qui ne suit pas ces changements cesse de fonctionner, pas de produire une sortie dégradée. La date du dernier push, le 14 août 2026, montre une activité récente, mais elle ne dit pas sur quel projet elle porte. Autre limite structurelle : chaque régénération consomme des appels à un modèle payant. Sur un dépôt volumineux, la documentation en CI a un coût récurrent qu'il faut budgéter, et ce coût n'est pas mentionné dans le README.

Face à quoi on compare vraiment

L'alternative la plus directe n'est pas un autre générateur de documentation : c'est l'usage direct d'un assistant de code branché sur le dépôt. Un agent qui lit le code à la demande répond à une question précise sans produire d'artefact versionné. Litho fait l'inverse : il produit un ensemble de fichiers Markdown et de diagrammes qui vivent dans le dépôt, se relisent en revue de code et se conservent. La différence de méthode est nette. L'agent interroge le code à chaque question et ne laisse rien derrière lui. Litho fige une interprétation du code à un instant donné, et cette interprétation devient un objet que l'on peut diffuser, comparer d'une version à l'autre et joindre à une revue. Le revers est que cette interprétation peut être fausse ou obsolète, et qu'une documentation fausse est plus dangereuse qu'une absence de documentation, parce qu'elle est lue comme un fait. Un outil de diagramme écrit à la main, de son côté, ne se trompe pas sur l'intention, mais il se périme. Litho échange de la précision d'intention contre de la fraîcheur.

Licence, maintenance et coût de mise à jour

Le dépôt est sous licence MIT, ce qui autorise la réutilisation, la modification et la redistribution, y compris dans un contexte commercial, à condition de conserver la notice de copyright et le texte de la licence. Ce n'est pas un avis juridique : si vous intégrez Litho dans un produit distribué, faites vérifier les obligations de mention par qui de droit. Sur la maintenance, les éléments disponibles donnent trois versions publiées entre février et avril 2026 (1.2.8, 1.3.0, 1.5.0), soit un rythme de publication soutenu sur cette période, puis un dernier push en août 2026. Le coût de mise à jour ne se limite pas au binaire : il inclut la vérification que votre fournisseur de modèle figure toujours parmi les providers pris en charge, et la régénération de la documentation de référence à chaque montée de version, puisque la structure de sortie peut changer entre versions mineures. Le coût le plus lourd reste l'encart Terrain : avant d'investir dans des templates personnalisés ou une intégration CI, il faut décider si l'on parie sur Litho ou sur son successeur.

Conclusion éditoriale

Litho convient aux équipes qui veulent une documentation d'architecture C4 versionnée à côté du code et qui acceptent de payer des appels LLM à chaque régénération. Il ne convient pas à celles qui cherchent une référence d'API exhaustive ou un outil sans dépendance à un fournisseur externe. Avant d'adopter, vérifiez deux points précis : que votre fournisseur est bien dans la liste des providers reconnus, et que le projet Terrain annoncé dans le README ne rend pas votre investissement dans Litho obsolète à court terme.

Sources officielles

1. License: MIT
2. Project website
3. README
4. Releases
5. sopaco/deepwiki-rs on GitHub