Text Generator pour Obsidian : générer du texte dans le coffre, pas à côté

Le problème : produire du texte là où vivent déjà vos notes

La plupart des outils d'écriture assistée vivent dans un onglet de navigateur. Vous copiez un passage, vous collez la réponse, vous la remettez en forme. Text Generator prend le chemin inverse : il s'installe comme plugin Obsidian et travaille sur le coffre lui-même. Le README cite des cas d'usage précis, générer des idées, des titres, des résumés, des plans ou des paragraphes entiers à partir de votre base de connaissances. Le public visé est donc celui qui pratique déjà la gestion personnelle des connaissances dans Obsidian, pas l'utilisateur occasionnel qui veut discuter avec un modèle. Le plugin se décrit comme un assistant IA open source, sous licence MIT, ce qui autorise la redistribution et la modification, y compris dans un contexte commercial, à condition de conserver la notice de licence. Rien dans le matériel fourni ne documente une limite d'usage ou un quota imposé par le projet lui-même.

Ce qui se branche derrière : fournisseurs et frontmatter

Text Generator ne fournit pas de modèle. Il joue le rôle de client. Le README énumère OpenAI, Anthropic, Google (dont Gemini-Pro), HuggingFace et des modèles locaux. La description du dépôt mentionne elle aussi OpenAI, Anthropic, Google et les modèles locaux. Cette liste de fournisseurs n'est pas figée dans un écran de réglages unique : le README parle de configuration par frontmatter, ce qui signifie que le choix du service peut être déclaré dans l'en-tête YAML d'une note. C'est un choix architectural qui a des conséquences pratiques. Un modèle donné peut être associé à un type de tâche, une note peut porter sa propre configuration, et un modèle de note peut embarquer ce frontmatter. En contrepartie, la cohérence repose sur vous : rien n'indique qu'un frontmatter mal formé produise autre chose qu'un échec silencieux ou une erreur peu explicite. Le matériel fourni ne détaille pas les clés exactes du frontmatter, seulement le principe.

Le moteur de modèles et les modèles communautaires

Deux fonctionnalités structurent l'usage au quotidien. D'abord le moteur de modèles, décrit comme un moyen de rendre gérables les tâches répétitives : au lieu de retaper une invite, vous l'enregistrez une fois et vous la réutilisez. Ensuite les modèles communautaires, un mécanisme de découverte et de partage. C'est probablement l'argument le plus concret du projet, parce qu'une invite bien écrite est un artefact réutilisable, et qu'un catalogue partagé évite à chacun de réinventer la mise en forme d'un résumé ou d'un plan. Le revers est connu d'avance : un modèle communautaire dépend d'un fournisseur, d'un format de sortie et d'un niveau de langue. Un modèle écrit pour Gemini-Pro ne se transportera pas nécessairement vers un modèle local sans ajustement. Le README ne décrit ni la procédure de publication, ni la façon dont les modèles sont versionnés, ce qui laisse la question ouverte.

Installation : deux chemins, dont un qui compile

Le chemin simple passe par les plugins communautaires d'Obsidian : Settings > Community plugins, désactiver le mode restreint, chercher Text Generator, installer, activer. Le second chemin, documenté pour la version de développement, suppose une chaîne Node et pnpm. Le README donne les commandes : git clone https://github.com/nhaouari/obsidian-textgenerator-plugin.git, puis cd obsidian-textgenerator-plugin, puis pnpm install, puis pnpm run build. Pour le développement, pnpm run dev est proposé à la place du build. Il faut ensuite redémarrer Obsidian et activer le plugin, ou s'appuyer sur le plugin Hot-Reload de pjeby pour éviter les redémarrages. Ce second chemin implique de cloner le dépôt dans le dossier des plugins du coffre, ce qui veut dire que votre coffre contient du code source et un node_modules. Pour un utilisateur non développeur, c'est un coût réel : mises à jour manuelles, résolution des conflits de dépendances, et aucune garantie que la branche master soit stable.

Limites : une branche master qui publie des beta

Les trois versions les plus récentes listées sont 0.8.11-beta, 0.8.10-beta et 0.8.9-beta. Aucune version stable n'apparaît dans cet extrait. Ce n'est pas un détail cosmétique : qui installe depuis master récupère du code estampillé beta, avec le risque de régression que cela suppose entre deux mises à jour. Le dépôt n'est pas archivé et le dernier push date du 6 août 2026, donc le projet est actif, mais l'activité ne dit rien de la stabilité de l'API. Deuxième limite, la dépendance externe. Le plugin n'exécute rien localement par défaut : vos notes, ou les extraits envoyés comme contexte, transitent vers le fournisseur que vous avez configuré. Le README ne contient aucune section sur la confidentialité, la journalisation ou la conservation des données chez les fournisseurs. Si votre coffre contient des informations sensibles, c'est un point à trancher avant l'installation, pas après. Troisième limite, le mode d'emploi. Le README renvoie à une documentation externe et à un serveur Discord pour le dépannage. Le contenu du dépôt seul ne suffit pas à comprendre le fonctionnement du frontmatter ni la syntaxe des modèles.

Face à quoi : l'alternative du script et de l'API brute

L'alternative la plus directe n'est pas un autre plugin, c'est de ne pas en utiliser. Un script qui appelle l'API du fournisseur et écrit un fichier Markdown dans le coffre fait la même chose en apparence. La différence est dans ce que Text Generator apporte par-dessus l'appel réseau : l'intégration à l'éditeur, le moteur de modèles, la configuration par frontmatter et le catalogue communautaire. Un script maison vous laisse tout écrire, y compris la gestion des erreurs et la mise en forme, et il ne casse pas à chaque mise à jour du plugin. En sens inverse, il ne bénéficie d'aucun partage d'invites et il faut le maintenir soi-même. Le choix se joue donc sur un critère simple : combien de modèles réutilisables vous comptez écrire. En dessous de quelques-uns, le script tient la route. Au-delà, la couche du plugin commence à se justifier. Le matériel fourni ne permet pas de comparer les performances des deux approches, seulement leur périmètre.

Coût de maintenance et implications de licence

Le projet est sous MIT, une licence permissive qui autorise l'usage, la modification et la redistribution, y compris commerciale, avec conservation du copyright et de la notice. Cela concerne le code du plugin, pas les services qu'il appelle : votre relation contractuelle avec OpenAI, Anthropic ou Google reste régie par leurs propres conditions, et le README n'en dit rien. Côté maintenance, deux régimes coexistent. Si vous passez par les plugins communautaires, les mises à jour suivent le rythme de publication du dépôt, actuellement des beta. Si vous compilez depuis master, vous prenez en charge pnpm install et pnpm run build à chaque mise à jour, avec la possibilité qu'une dépendance casse la compilation. Le README mentionne un serveur Discord et un système d'issues pour le support, ce qui déplace une partie du coût vers la communauté plutôt que vers une documentation de référence. Ce texte ne constitue pas un avis juridique : pour un usage en entreprise, faites relire la licence et les conditions du fournisseur choisi.

Conclusion éditoriale

À adopter si vous écrivez déjà dans Obsidian et voulez générer du texte à partir de vos notes sans quitter l'application, en acceptant de configurer vous-même une clé API. À éviter si vous attendez un assistant conversationnel autonome ou une interface stable : la branche master publie des versions beta (0.8.11-beta au 6 août 2026) et la documentation renvoyée par le README (bit.ly/tg_docs) reste votre seule référence fiable. Avant d'installer, vérifiez deux choses concrètes : la licence MIT du dépôt, et le fournisseur que vous comptez utiliser, car le choix se fait par frontmatter et non par un assistant de configuration.

Sources officielles

1. License: MIT
2. nhaouari/obsidian-textgenerator-plugin on GitHub
3. Project website
4. README
5. Releases