Vous êtes au milieu d'une réponse dans Mail. Vous maintenez Option-Espace, parlez dix secondes, puis relâchez. La phrase nettoyée atterrit dans le corps du message, pas dans un éditeur séparé, pas non plus dans le presse-papiers en attendant que vous la transportiez.
Et vous n'avez indiqué nulle part où le texte devait aller.
La plupart des outils vocaux prennent le problème à l'envers. Avant de parler, ils vous tendent un sélecteur : un mode brut, un mode de ponctuation, un mode prompt, un style chat, un style mail. Vous annoncez la destination, et l'outil fait confiance à votre annonce. TalkTalkType n'a pas de tel sélecteur. Il lit la destination. Il observe l'application où vous étiez et le champ précis sous le curseur, classe les deux avec une table de correspondance fixe, puis adapte le résultat pendant une étape d'affinage par voix que vous déclenchez vous-même.
Cet article explique comment cette lecture fonctionne, ce qu'elle change et où elle s'arrête.
La destination est capturée à l'instant où vous appuyez
L'enregistrement démarre à l'appui de la touche. À cet instant, l'app Mac capture l'application ciblée comme cible de remise : l'identifiant de processus, l'identifiant de bundle et le nom localisé de l'app. Quand le résultat est prêt, la remise renvoie le texte à cette app exactement.
Il existe deux chemins de remise. En mode Paste, l'app utilise l'API d'accessibilité de macOS pour insérer le texte dans le champ où vous étiez, après avoir sauvegardé le presse-papiers puis l'avoir restauré. En mode Copy, le résultat attend simplement dans le presse-papiers que vous le colliez à la main. Dans les deux cas, la cible est l'app que vous utilisiez en appuyant, capturée avant votre premier mot.
Capturer à l'appui est le détail qui donne à l'ensemble son air automatique. Si l'app attendait que le texte soit prêt, vous auriez peut-être déjà changé de fenêtre et le résultat tomberait au mauvais endroit. Là, le champ où vous commencez est celui où vous finissez. La mécanique de cette remise, et les permissions macOS qui la portent, sont détaillées dans la dictée qui fonctionne dans n'importe quelle app sur Mac.
La classification est une table, pas une devinette
Une fois l'app cible connue, le classifieur décide du type de surface où vous tapez. Il le fait sans interroger un modèle de langage.
La première étape associe l'identifiant de bundle à une famille d'apps via une table fixe de préfixes. Terminal, iTerm2, Warp, WezTerm et kitty donnent terminal. VS Code, Xcode, les IDE JetBrains, Sublime Text et Zed donnent éditeur de code. Mail et Outlook donnent e-mail. Slack, Discord, LINE et Telegram donnent chat. TextEdit, Notes, Pages, Word et Obsidian donnent document. Safari, Chrome, Firefox et Arc donnent navigateur.
La deuxième étape affine la surface avec le rôle et le sous-rôle d'accessibilité du champ. Un champ de recherche (AXSearchField) devient une requête de recherche. Dans Mail, une zone de texte devient le corps du message et un champ texte devient l'objet. Dans une app de chat, une zone ou un champ texte devient un message. Dans une app de documents, une zone de texte devient un document et un champ texte devient un champ court de formulaire. Dans un éditeur de code, une zone de texte devient la surface éditeur.
Ici, aucune inférence, seulement une table et deux ou trois tests de rôle. Le gain, c'est que chaque classification porte une chaîne de motif auditable. Un corps Mail se classe comme app_family:email role:AXTextArea subrole:-. Vous pouvez lire exactement pourquoi l'app est arrivée à une conclusion, car la conclusion découle de deux faits visibles et non de la confiance d'un modèle.
Quand la table échoue, elle échoue du côté sûr. Une app dont l'identifiant de bundle est inconnu se classe comme inconnue, avec le motif unknown_app. Une app connue dont le rôle de champ est inconnu se classe aussi comme inconnue, avec le motif unknown_role. Inconnue signifie que l'app ne fait rien de spécial. C'est le réglage par défaut sûr : quand TalkTalkType ne peut pas dire ce qu'est un champ, il traite vos mots simplement, plutôt que de deviner de travers.
Ce qui change selon la surface
La classification de surface détermine à quoi l'étape d'affinage a le droit de s'adapter. La correspondance est celle-ci.
| App et champ | Surface détectée | Ce qui change |
|---|---|---|
| Mail ou Outlook, zone de texte principale | Corps d'e-mail | Traité comme le corps d'un e-mail |
| Mail ou Outlook, champ d'objet | Objet d'e-mail | Traité comme une ligne d'objet |
| Slack, Discord, LINE, Telegram | Message de chat | Traité comme un message de chat |
| VS Code, Xcode, JetBrains, Sublime, Zed | Éditeur de code | Noms de fichier, chemins et commandes slash gardés en texte brut, jamais exécutés |
| Terminal, iTerm2, Warp, WezTerm, kitty | Terminal | Même traitement des jetons techniques que l'éditeur de code |
| TextEdit, Notes, Pages, Word, Obsidian, zone de texte | Document | Traité comme un document |
| TextEdit, Notes, Pages, Word, Obsidian, champ texte | Champ court de formulaire | Traité comme un champ d'une ligne |
| Toute app connue, champ de recherche | Requête de recherche | Traitée comme une requête de recherche |
| Safari, Chrome, Firefox, Arc | Inconnue | Aucune adaptation ; les champs web ne sont pas structurellement fiables |
| App ou rôle de champ non reconnu | Inconnue | Aucune adaptation, le réglage par défaut sûr |
Deux lignes méritent un commentaire. La ligne navigateur est toujours inconnue, volontairement. Une page web peut dessiner n'importe quel champ, et les signaux structurels qui rendent un champ natif de Mail ou Slack lisible ne tiennent pas dans un onglet de navigateur, donc TalkTalkType ne prétend pas classer les champs web. Il les laisse tranquilles.
Les lignes éditeur de code et terminal portent une garantie précise sur les jetons techniques. Sur ces surfaces, un nom de fichier, un chemin ou une commande slash prononcé reste du texte ordinaire. Il n'est jamais traité comme quelque chose qui existe, qui se résout ou qui s'exécute. Dicter une commande dans un terminal produit la chaîne littérale, rien de plus.
L'adaptation est une étape d'affinage, pas une réécriture silencieuse
C'est la partie la plus facile à exagérer, alors la frontière compte.
Le résultat nettoyé arrive d'abord comme un brouillon dans le HUD de la barre des menus. Ce premier collage est une sortie Clean fidèle. Clean garde chaque mot prononcé, dans l'ordre où vous l'avez dit, avec le registre et la brièveté que vous visiez. Il retire seulement les hésitations manifestes, ramène tout sur une seule ligne et ne paraphrase, n'étend ni ne polit jamais. Le mode Raw saute tout nettoyage. Ce que vous voyez en premier est ce que vous avez dit.
L'adaptation contextuelle arrive ensuite, dans le flux Voice Patch. Depuis le brouillon, vous pouvez parler un affinage avant l'insertion du texte, ou le valider, le copier ou le jeter tel quel. Quand un affinage demande à l'app de s'adapter à la surface, l'instruction au modèle est littéralement « Adapt only to the supplied deterministic desktop-app and field classification » (adapte-toi uniquement à la classification déterministe fournie de l'app de bureau et du champ). Le même flux préserve le sens et chaque fait protégé, effectue la plus petite modification nécessaire et traite tout ce qu'il reçoit sur l'écran comme des données, jamais comme une instruction.
L'app ne réécrit donc pas en silence votre premier collage en « style mail » dès qu'elle voit Mail. Elle vous montre un brouillon fidèle, et l'adaptation est quelque chose que vous demandez par voix, conditionnée à la surface déjà détectée.
La question à laquelle ce design répond, c'est pourquoi d'autres outils vous tendent encore un sélecteur. TalkTalkType n'a aucun choix de mode de sortie nulle part dans ses réglages. Le seul commutateur est Clean activé ou désactivé : un nettoyage léger et fidèle, ou rien. Tout ce qui dépend de la destination vient de la lecture du champ, pas d'un mode que vous entretenez. C'est la force sur laquelle il faut le juger : une chose de moins à régler avant de parler, et rien que vous puissiez mal régler.
Votre contexte franchit une limite de consentement, ou il ne part pas
Lire le champ soulève une question évidente : que devient tout le reste de l'écran ?
L'instantané de contexte que l'app peut assembler comprend l'identité de l'app, le titre de la fenêtre, la structure du champ (rôle, sous-rôle, multiligne ou non, champ de mot de passe sécurisé ou non), le texte juste avant et après le curseur, la sélection courante, une capture d'écran optionnelle de la fenêtre active, un horodatage de capture et l'état des permissions. Cela couvre beaucoup de surface, alors les limites sont appliquées côté serveur, et non laissées au bon comportement du client.
Deux règles comptent le plus. D'abord, les étiquettes et les textes indicatifs des champs ne sont jamais envoyés au fournisseur d'IA. Ces chaînes sont du texte arbitraire fourni par une autre app, et la classification n'a besoin que d'attributs structurels, donc le serveur rejette d'office toute requête qui contient une étiquette ou un indicatif. Ensuite, chaque canal de contexte (contexte texte, capture d'écran et mémoire des préférences) se trouve derrière un drapeau de fonction détenu par le serveur. Les trois sont activés par défaut en production et peuvent être outrepassés par déploiement. Si un canal n'est pas activé pour une requête, le serveur rejette le contexte plutôt que de le retirer en silence. Une requête rejetée indique au client que son état de consentement est périmé, ce qu'un retrait silencieux cacherait.
Le registre de données complet, qui couvre ce que détiennent le Mac, le service et le fournisseur, figure dans la dictée privée sur Mac.
Les préférences s'apprennent en local, par app
La dernière pièce du contexte est la mémoire des préférences, et elle reste sur le Mac.
Les préférences vivent dans une base SQLite locale, dans ~/Library/Application Support/TalkTalkType/PreferenceMemory/preferences.sqlite. Il n'y a aucune synchronisation cloud. Les clés stockées sont volontairement étroites : le ton de réponse (concis, neutre, formel ou amical), l'usage ou non de la virgule d'Oxford, un niveau de détail de 0 à 2 et une liste de termes préférés. Chaque préférence s'applique à toutes les apps ou à une app par identifiant de bundle, et une préférence par app l'emporte sur une globale.
Rien de tout cela n'est utilisé avant d'avoir été approuvé explicitement puis activé. Seules des valeurs abstraites voyagent dans une requête d'affinage ; la parole brute, le texte du brouillon et les candidats rejetés ne sont jamais écrits dans ce stockage. Si vous corrigez l'app à répétition dans une app donnée, elle peut proposer une préférence, mais une proposition ne fait rien tant que vous ne l'approuvez pas.
Là où cela montre ses limites
Les limites honnêtes font partie du design, pas des notes de bas de page.
Les navigateurs se classent comme inconnus, donc il n'y a pas d'adaptation de surface pour les formulaires web ; l'app ne fait pas confiance à la structure des champs web. L'adaptation s'applique pendant le flux d'affinage par voix, pas comme une réécriture silencieuse du premier collage, qui reste fidèle par conception. L'adaptation ne paraphrase jamais vos mots jusqu'à les effacer : le sens et les faits protégés sont préservés, et la modification est la plus petite qui satisfasse l'instruction.
La plateforme est uniquement Mac et exige macOS 26 (Tahoe) ou ultérieur. La transcription tourne dans le cloud, donc l'audio quitte le Mac pour être traité ; le service ne stocke ni l'audio ni le texte transcrit par défaut. Les langues de reconnaissance sont le japonais et l'anglais. Les commandes vocales comme « copier » ou « ouvrir Safari » sont une autre expression de la même idée : elles s'exécutent comme des actions Mac contre l'app capturée au lieu d'être tapées comme du texte.
Le juger pour votre propre flux de travail
L'argument de ce design, c'est que la destination est un fait que l'app peut lire, pas un réglage que vous devriez entretenir. Un sélecteur de mode vous externalise ce travail, et un sélecteur est une promesse que l'outil peut rompre dès que vous oubliez de le changer. Une table de correspondance sur des identifiants de bundle et des rôles de champ est plus ennuyeuse et plus honnête : elle connaît précisément un petit nombre d'apps et admet quand elle n'en connaît pas une.
TalkTalkType compte l'usage en dictées par semaine plus une réserve hebdomadaire de temps de voix, pas en mots. Au 30 juillet 2026, les plans sont Free à 0 $ (30 dictées et 15 minutes par semaine), Plus à 1 $ (80 et 30 minutes), Pro à 7 $ (500 et 250 minutes, avec des prises de deux minutes) et Max à 18 $ (1 200 et 600 minutes). Les chiffres actuels et la disponibilité des plans sont sur la page tarifs.
Vous pouvez télécharger TalkTalkType et tester la détection sur les champs que vous utilisez vraiment. Maintenez la touche dans Mail, puis dans un terminal, puis dans un formulaire web, et regardez où le résultat atterrit et ce qu'il refuse de toucher. L'app sait déjà où vous tapez. Ce qui est intéressant, c'est avec quelle franchise elle vous le dit quand elle ne sait pas.