OpenLess : dicter vers n'importe quelle application, avec le mode prompt comme argument principal

Le problème visé : supprimer les décisions répétées entre la pensée et le texte

Dicter ne suffit pas. Une transcription brute laisse passer les noms propres mal orthographiés, le ton inadapté au destinataire, et la reformulation manuelle qui suit. Le README d'OpenLess décrit cette friction comme une série de négociations répétées : quel ton pour ce message, comment s'écrit ce nom, où coller le résultat, où sont stockées les clés du modèle. L'application cible les utilisateurs de macOS 12+ et Windows 10+ qui écrivent dans ChatGPT, Claude, Cursor, Notion, un brouillon d'e-mail ou une zone de chat, et qui veulent éviter de reprendre le texte après coup.

Le positionnement est explicite : le projet se présente comme une alternative open source à Typeless, Wispr Flow, Lazy et Superwhisper. La différence revendiquée n'est pas la vitesse de dictée mais le mode prompt IA : l'utilisateur parle librement, et l'application ajoute une structure, conserve les contraintes exprimées et produit un prompt contextualisé à coller dans un assistant. C'est un usage différent de la dictée classique, et le README en fait la capacité principale plutôt qu'un réglage secondaire.

Le trajet de l'audio : enregistrement, transcription, polissage, insertion

Le flux décrit par le README tient en quatre étapes. L'utilisateur place son curseur dans un champ de texte, appuie sur un raccourci global, parle. OpenLess enregistre l'audio, le transcrit, applique le mode de polissage sélectionné, puis insère le résultat à la position du curseur. Si l'insertion est bloquée, le texte part dans le presse-papiers : la parole n'est pas perdue.

Ce dernier point est un choix d'ingénierie concret. L'insertion au curseur dépend de l'application cible et du système, et un échec silencieux serait le pire résultat possible pour un outil de dictée. Le repli vers le presse-papiers transforme un échec en une action manuelle supplémentaire. Le README ne détaille pas comment l'application détecte le blocage ni quelles applications sont concernées.

L'architecture visible dans le dépôt combine Tauri 2 et Rust 2021. Les badges du README mentionnent Linux avec egui, alors que la description du projet et le texte principal annoncent macOS et Windows. Le dépôt contient un dossier openless-all/app/src-tauri, ce qui correspond à la structure d'une application Tauri. Le README ne décrit pas le chemin exact des modules de transcription ou de polissage, donc l'organisation interne du code reste à examiner dans le dépôt.

Style packs, hotwords et insertion : trois mécanismes de mémorisation

Le README décrit trois mécanismes qui évitent de redécider les mêmes paramètres. Le ton se fixe dans un style pack nommé, que l'on change au clavier. Les noms propres se fixent dans des hotwords de dictionnaire, transmis à la reconnaissance vocale et suggérés au modèle de polissage. Le lieu d'arrivée du texte se fixe dans un protocole d'insertion unique, avec le repli presse-papiers déjà mentionné.

Les hotwords sont le mécanisme le plus intéressant des trois, parce qu'ils agissent à deux endroits : côté ASR pour la reconnaissance, côté LLM pour la reformulation. Un nom mal reconnu par l'ASR ne sera pas nécessairement corrigé par le modèle de polissage, et l'inverse est vrai aussi. Alimenter les deux étages est une réponse raisonnable, mais le README ne précise ni le format de ces hotwords, ni leur nombre maximal, ni la manière dont ils sont transmis au fournisseur de reconnaissance.

Le style pack est présenté comme nommé, commutable et actif en une frappe. Rien dans le matériel fourni n'indique comment un style pack est défini, s'il s'agit de texte libre, de modèles prédéfinis ou des deux. C'est une zone où la documentation est mince, et c'est aussi celle qui détermine si l'outil s'adapte vraiment à un usage professionnel précis.

Installation : ce que le dépôt indique, et ce qu'il ne dit pas

Le README renvoie vers la page des releases pour le téléchargement, et vers openless.top comme site officiel. Les versions récentes listées sont v1.3.18-Beta.7-tauri, v1.3.18-tauri et v1.3.18-Beta.6-beta-tauri, publiées en août 2026. La branche par défaut du dépôt est beta, ce qui signifie que le code le plus visible n'est pas nécessairement celui d'une version stable. Un utilisateur qui veut la version publiée doit passer par les releases plutôt que par un clone de la branche par défaut.

Le README ne fournit pas de commandes d'installation ni de compilation. Le matériel disponible ne permet donc pas d'affirmer qu'une commande précise fonctionne, ni quels prérequis Rust ou Tauri sont nécessaires pour construire l'application depuis les sources. Le dépôt contient un fichier LICENSE, et le badge de licence pointe vers main/LICENSE alors que la branche par défaut est beta : c'est un détail de navigation, pas une contradiction de licence, mais cela complique le repérage des fichiers pour qui explore le dépôt.

Ce que le README décrit, en revanche, c'est le premier lancement : autorisation du microphone, de l'accessibilité et des identifiants cloud. Le texte parle d'une autorisation unique au démarrage, avec stockage des identifiants dans le coffre du système d'exploitation. C'est le bon endroit pour ces secrets, mais le README ne nomme pas les fournisseurs cloud concernés ni les clés de configuration attendues.

La dépendance au cloud, angle mort du discours sur les defaults

Le README présente l'autorisation des identifiants cloud comme une étape unique, ce qui est exact du point de vue de l'utilisateur. Du point de vue technique, cela signifie que la transcription et le polissage passent par des services externes. Un outil de dictée qui envoie l'audio et le texte à un fournisseur tiers n'a pas le même profil de confidentialité qu'un outil local, et c'est un point que le README n'aborde pas.

Le matériel fourni ne permet pas de savoir si un moteur local est pris en charge, ni si l'application fonctionne sans connexion. Il ne permet pas non plus de savoir quels fournisseurs sont configurables, ni si l'utilisateur peut pointer vers une instance auto-hébergée. Pour un lecteur qui écrit du code propriétaire ou traite des données sensibles, cette incertitude est plus importante que la qualité du polissage.

Le mode prompt IA amplifie le phénomène : il envoie non seulement l'audio, mais aussi les contraintes exprimées et le contexte de la demande à un modèle de langage. Le README vante la richesse du prompt produit, ce qui est cohérent avec cet envoi. Il faut simplement le dire clairement : plus le prompt est contextuel, plus la quantité d'information transmise est importante.

Alternative réelle : la dictée native du système

La comparaison la plus utile n'est pas avec Wispr Flow ou Superwhisper, mais avec la dictée intégrée à macOS et à Windows. Celle-ci ne demande aucune installation, aucun compte, aucune clé API, et fonctionne hors-ligne sur les versions récentes. Son approche est opposée : elle produit une transcription, éventuellement ponctuée, et s'arrête là. Pas de style pack, pas de hotwords transmis à un modèle, pas de mode prompt.

OpenLess ajoute donc une couche de polissage et de mise en forme que la dictée native ne propose pas. Le prix de cette couche est une dépendance à des services externes, des identifiants à gérer et une licence AGPL-3.0. Pour quelqu'un qui dicte quelques phrases par jour dans un chat, la dictée native suffit et ne demande aucune configuration. Pour quelqu'un qui rédige de longs prompts ou des messages à contraintes, le mode prompt d'OpenLess répond à un besoin que la dictée native ignore complètement.

Le choix se joue donc sur la fréquence et la nature de l'usage, pas sur une supériorité générale de l'un ou de l'autre.

Licence AGPL-3.0 et coût de maintenance

Le projet est publié sous AGPL-3.0. Pour un usage personnel, cela ne change rien. Pour une intégration dans un produit distribué ou un service accessible par réseau, la licence impose des obligations de publication du code source. Ce point mérite un examen juridique propre : je ne donne pas de conseil juridique ici, et le texte exact de la licence fait foi.

Le rythme de publication observé est soutenu : trois versions en août 2026, dont deux estampillées Beta. La branche par défaut est beta, ce qui suggère que le développement actif se fait sur cette branche et que la stabilité n'est pas la priorité affichée. Pour un utilisateur qui suit les releases, cela implique de vérifier régulièrement les changements, d'autant que le README ne décrit pas de canal de mise à jour automatique.

Le coût de maintenance inclut aussi les identifiants cloud : si un fournisseur change son API ou son tarif, l'application doit suivre. Le README ne mentionne pas de mécanisme de repli entre fournisseurs, ni de politique de compatibilité. C'est un coût récurrent qui ne dépend pas seulement des mainteneurs du projet.

Ce qu'il faut vérifier avant d'adopter

Trois points méritent un examen avant de s'engager. D'abord, la liste des fournisseurs ASR et LLM pris en charge et la possibilité d'en changer. Ensuite, le stockage effectif des identifiants : le README parle du coffre de l'OS, ce qui est le bon endroit, mais il faut confirmer qu'aucune clé ne se retrouve en clair dans un fichier de configuration. Enfin, le comportement du mode prompt : quelles données partent vers le modèle, et si l'utilisateur peut le désactiver pour un usage purement local.

Le dépôt contient un dossier openless-all/app/src-tauri et un fichier LICENSE à la racine. Ces éléments sont vérifiables directement. Le reste, notamment la configuration des hotwords et le format des style packs, ne figure pas dans le matériel fourni et devra être lu dans le code ou la documentation du site officiel.

OpenLess est un projet actif, écrit en Rust, avec une licence copyleft et une branche par défaut en beta. Ces caractéristiques suffisent à le classer comme un outil à essayer avant de l'intégrer dans un flux de travail quotidien, pas comme une dépendance à installer sans inspection.

Conclusion éditoriale

OpenLess convient aux utilisateurs de macOS 12+ ou Windows 10+ qui dictent souvent et veulent un texte déjà mis en forme, avec un mode prompt IA pour alimenter ChatGPT, Claude ou Cursor. Il ne convient pas à qui refuse d'accorder les permissions microphone et accessibilité, ni à qui veut du hors-ligne strict. À vérifier avant d'adopter : quels fournisseurs ASR et LLM sont configurables, si les identifiants sont bien stockés dans le coffre de l'OS, et si la licence AGPL-3.0 est compatible avec votre usage.

Sources officielles

1. License: AGPL-3.0
2. Open-Less/openless on GitHub
3. Project website
4. README
5. Releases