Ce qui se passe réellement entre le moment où vous déposez un manuscrit dans Bethaniel et celui où vous en récupérez un annoté — les passes, l'ordre dans lequel elles s'exécutent, et pourquoi chacune est là.
Six paragraphes, puis le détail.
Les étapes s'exécutent dans l'ordre, et l'ordre porte une information : le découpage ne peut pas précéder la détection des chapitres, et le relecteur ne peut pas noter une correction qui n'a pas encore été proposée.
DOCX, EPUB, PDF, Markdown ou texte brut. Le DOCX entre via mammoth ; EPUB et PDF ont leurs propres lecteurs. Le lecteur PDF reconstruit paragraphes, emphases et titres d'après la position physique des glyphes sur la page — et refuse tout net les documents scannés plutôt que de faire semblant de les lire.
Tout devient du Markdown en interne. C'est ce format interne unique qui permet à une correction trouvée au chapitre 12 d'être réécrite dans le DOCX d'origine avec sa mise en forme intacte.
Les titres sont détectés et le manuscrit est découpé en unités modifiables. Les sections de moins de cinquante mots — pages de titre, un titre isolé, une dédicace — sont repliées dans le chapitre auquel elles appartiennent plutôt que de devenir leur propre « chapitre » d'une ligne, ce qui fait que la liste de progression d'un travail se lit comme la table des matières d'un livre et non comme la sortie d'un analyseur.
Les marqueurs de changement de scène sont reconnus et normalisés en même temps, de sorte qu'un manuscrit qui utilise *** à un endroit et # à un autre ressort cohérent.
Chaque chapitre est découpé en segments d'environ 2 500 mots, en ne coupant qu'aux frontières de paragraphe, le dernier paragraphe d'un segment étant répété en tête du suivant. C'est ce chevauchement qui empêche une correction à la jointure d'un segment d'être faite hors contexte. Les frontières de chapitre remettent le chevauchement à zéro — la fin du chapitre 4 n'est pas un contexte pour le début du chapitre 5.
Avant que le modèle ne voie quoi que ce soit, les vérificateurs à base de règles parcourent le segment. Ils sont rapides, identiques à chaque fois, et n'inventent jamais un mot. Ce qu'ils trouvent va dans l'ensemble des corrections et dans le prompt du modèle sous forme d'indices — parce qu'un correcteur orthographique sait qu'un mot est faux bien plus sûrement qu'il ne sait ce que le mot aurait dû être, et que le modèle qui lit la phrase est meilleur pour la seconde partie.
Le segment, les indices déterministes, votre guide de style si vous en avez fourni un, et les réglages que vous avez choisis sont assemblés en un prompt. Le modèle renvoie les corrections proposées sous forme de paires original/corrigé, pas comme un segment réécrit — de sorte qu'un changement peut toujours être localisé, affiché et refusé individuellement.
À côté, une passe distincte lit le même extrait pour une seule chose : un mot tombé d'une phrase. Elle est décrite plus bas, sous Mots manquants.
Un second prompt renvoie chaque correction proposée au modèle dans le rôle d'un second lecteur sceptique : est-ce vraiment une erreur, et est-ce vraiment la correction ? Chacune reçoit une note de confiance de 1 à 5. Tout ce qui est sous le seuil est signalé plutôt qu'écarté, de sorte qu'une suggestion correcte que le relecteur n'a pas aimée est marquée pour votre attention au lieu de disparaître. Un signalement du dictionnaire ou du serveur de grammaire n'est jamais annulé de cette façon — un dictionnaire n'est pas une opinion qu'un modèle a le droit de mettre en minorité.
Le relecteur tourne en parallèle de l'éditeur du segment suivant, si bien que la passe supplémentaire coûte bien moins de temps réel qu'il n'y paraît.
Chaque correction survivante doit franchir une série de garde-fous mécaniques avant de pouvoir toucher le texte. Ils sont décrits ci-dessous ; la façon la plus courte de le dire est qu'une correction n'a pas le droit de dégrader le manuscrit d'une manière qu'un relecteur humain ne ferait jamais.
Vous obtenez un diff en ligne au niveau du mot, correction par correction, avec la raison attachée et la note de confiance visible. Accepter, rejeter, ou tout accepter. Export en Markdown, DOCX ou EPUB — et pour un import DOCX, retour dans le document d'origine avec ses propres styles, plutôt que dans un document fraîchement généré.
Le choix de conception central est que les vérificateurs à base de règles et ceux à base de modèle sont maintenus comme des sources séparées, exécutés sur le même texte, puis fusionnés. Aucun ne peut faire le travail de l'autre.
a/an, mots doublés, apostrophes manquantes, « PIN number »Elles n'hallucinent jamais. Elles ne peuvent pas non plus voir que their aurait dû être there, parce que les deux sont de vrais mots.
Il lit la phrase. Il proposera aussi de temps à autre quelque chose de faux avec assurance, et c'est pourquoi rien de ce qu'il dit n'est appliqué sans relecture.
Pré-approbation croisée. Quand un vérificateur déterministe et le modèle produisent indépendamment la même correction, elle est appliquée automatiquement sans avoir besoin de l'aval du relecteur. Une règle et un modèle de langue se trompent de façons complètement différentes, donc leur accord est un signal bien plus fort que la confiance de l'un ou l'autre seul.
Un vrai Hunspell, compilé en WebAssembly, qui lit tels quels les couples de dictionnaires standard .aff/.dic. Il signale chaque mot hors dictionnaire dans le segment, sans plafond par segment, tout en protégeant les noms de votre feuille de style et les mots qui se comportent comme des noms propres.
Utiliser le vrai moteur plutôt qu'une réimplémentation est ce qui fait fonctionner les langues à composition. Le danois et l'allemand fabriquent des mots nouveaux en soudant des anciens — rådhusarkivet, Werkstattfenster — et un roman dans l'une ou l'autre regorge de composés qui ne figurent dans aucun dictionnaire. Hunspell les compose à partir de leurs parties. Un vérificateur sans cette mécanique lit chacun d'eux comme une faute, ce qui en pratique signifie que l'auteur désactive le correcteur.
Des mots que le dictionnaire ne peut jamais attraper, parce que les deux graphies existent : their/there, en danois nogen/nogle, en allemand das/dass, en espagnol si/sí. Bethaniel entretient une liste sélectionnée par langue et injecte les paires pertinentes dans le prompt du modèle — mais seulement quand les deux membres d'une paire apparaissent réellement à proximité l'un de l'autre dans le segment. Une règle qui se déclencherait à chaque occurrence de their inonderait le manuscrit ; un indice qui ne se déclenche que là où la confusion est possible ne coûte presque rien.
« They expect us to look each other in the same place. » Chaque mot présent est bien orthographié, donc aucun dictionnaire ne voit le for qui est tombé — et un auteur passe droit dessus, parce que l'esprit fournit le mot. Demander au modèle éditeur de les chercher aussi n'a pas marché : il n'en trouvait pas davantage et commençait à laisser passer des erreurs qu'il attrapait auparavant.
C'est donc une passe à part, en trois étapes. Le modèle lit l'extrait par petits lots à la recherche de mots omis, et de rien d'autre. Une règle ne garde ensuite qu'une suggestion qui insère exactement un petit mot — une préposition, un article, un pronom, un auxiliaire — entre deux mots déjà présents, ce qui écarte presque tout ce que le modèle propose. Enfin, on montre la phrase deux fois au modèle, telle qu'elle est et avec le mot, et on lui demande laquelle est grammaticale. Ce qui survit vous est présenté comme n'importe quelle autre trouvaille, et compte comme bloquant dans la relecture finale. Elle fonctionne dans les cinq langues ; la page des performances dit avec quel succès, par langue et par moteur.
Un serveur LanguageTool local, fonctionnant hors ligne sur votre machine, à son niveau de règles le plus strict, picky. Les installateurs publiés embarquent à la fois LanguageTool et un environnement Java compatible, de sorte qu'il n'y a rien à installer ; s'il manque, il se contente de ne rien faire plutôt que de faire échouer le travail.
Une courte liste de règles LanguageTool est désactivée en permanence, chacune avec la mesure qui l'y a placée. La barre est volontairement sévère — zéro vraie erreur trouvée, au moins une inventée — parce qu'une correction LanguageTool contourne le relecteur, si bien que rien en aval ne retient une règle qui se déclenche à tort. Une règle espagnole, qui réécrivait chaque guillemet droit en guillemet angulaire, s'était déclenchée 248 fois sur le corpus de test sans jamais tomber une seule fois sur une vraie erreur.
Des vérifications déterministes réservées à l'anglais pour a contre an, les apostrophes de contraction manquantes, les mots doublés, les acronymes redondants et l'espacement des phrases. Les autres langues sautent entièrement cette passe plutôt que de se voir appliquer des règles anglaises.
La réparation des guillemets est déterministe, parce que la différence entre un guillemet ouvrant et un fermant est une chose qu'un modèle survole et qu'une règle ne rate jamais. Elle a la pleine propriété des guillemets, et c'est pourquoi le serveur de grammaire n'a pas le droit d'y toucher. La normalisation de la variante — orthographe britannique vers américaine ou l'inverse — fonctionne de la même façon, une fois que vous avez indiqué dans laquelle le manuscrit est écrit.
Certaines choses qui ressemblent à des erreurs sont des choix. La règle de Bethaniel est que, là où une convention est réellement disputée, l'auteur la précise et c'est seulement alors qu'elle est appliquée — parce qu'un vérificateur qui devine se trompe une fois sur deux et fait du bruit dans les deux cas.
| Langue | Le choix | Par défaut |
|---|---|---|
| Anglais | Virgule d'Oxford | Activée |
| Anglais | Virgule après une locution introductive | Désactivée — « Finally she turned » est laissé tel qu'écrit |
| Anglais | Orthographe britannique ou américaine | Américaine |
| Danois | Grammatisk komma ou nyt komma | Grammatisk |
| Espagnol | Conventions de virgule de la RAE | Appliquées |
Le cas danois est le plus clair. Le danois a deux systèmes de virgules concurrents, tous deux sanctionnés par le Retskrivningsordbogen et mutuellement contradictoires : le grammatisk komma met une virgule avant chaque subordonnée, le nyt komma le plus souvent non. Imposer l'un ou l'autre sans demander est faux pour la moitié des manuscrits danois. La détection des virgules en danois a été volontairement laissée faible jusqu'à ce que cet interrupteur existe.
Entre le relecteur et votre écran se trouve une série de garde-fous mécaniques. Ils existent parce que chacun décrit quelque chose qui s'est réellement produit pendant le développement, et chacun est désormais un test qui échoue si cela se reproduit.
.,, pas de point doublé. Et quand le modèle réécrit la dernière phrase d'un paragraphe et en perd le point final — ce qu'il fait — le point est remis sans jeter la correction légitime qui l'accompagnait.Les garde-fous s'appliquent à toutes les sources, y compris déterministes. Une correction à base de règles n'est pas privilégiée simplement parce qu'une règle l'a produite.
La correction est l'une des quatre passes. Elles partagent tout le pipeline ci-dessus — découpage, relecture, garde-fous, chemin d'export — et diffèrent par le prompt et par ce qu'elles produisent.
| Passe | Ce qu'elle fait |
|---|---|
| Correction | Orthographe, ponctuation, grammaire, majuscules, mots dupliqués. La couche mécanique. |
| Révision stylistique | Style, rythme, formulation, redondance. Des suggestions plutôt que des corrections — il n'existe pas ici de virgule objectivement manquante. |
| Traduction | Le texte intégral vers n'importe quelle langue cible, puis une passe de polissage dans la langue cible, puis une relecture de fluidité paragraphe par paragraphe qui repolit tout ce qui est noté comme confus. Cloud uniquement — voir ci-dessous. |
| Analyse | Catalogue des personnages, catalogue des lieux et chronologie, fusionnés à travers tous les chapitres, plus un résumé en prose généré automatiquement et un texte de quatrième de couverture. |
Sélectionner ensemble la correction et la révision stylistique les fusionne en une seule passe par chapitre plutôt que de parcourir le manuscrit deux fois. Sélectionner plusieurs passes d'analyse fait de même.
Le pipeline est identique dans les quatre cas. La seule chose qui change est l'endroit où se fait l'inférence, et si le texte quitte votre machine.
| Modèle | Tourne sur | Le texte reste local |
|---|---|---|
| Local Betty — Qwen3.5 4B | Votre machine · ~3 Go, 8 Go de RAM libre | Oui |
| Custom Betty | Votre machine · n'importe quel GGUF que vous fournissez | Oui |
| External Betty | Votre propre clé d'API, le fournisseur de votre choix | Non |
| Betty in the Cloud — hébergée, UE | Le service hébergé de Bethaniel, payé au travail | Non |
Local Betty est le choix par défaut, et l'application est pleinement utilisable sans jamais avoir touché au réseau. Avant le téléchargement, le bouton Lancer dit combien de temps un roman devrait prendre sur la machine qu'il a devant lui. Les options cloud existent pour les machines qui ne peuvent pas faire tourner un modèle 4B à une vitesse utile — elles se choisissent travail par travail, et les conditions disent clairement ce qu'il advient du texte.
La seule exception est la traduction. Le modèle local y a été mesuré et n'était pas assez bon — une traduction faible est fluide, assurée et fausse, et un auteur qui ne lit pas les deux langues ne peut pas le voir — alors l'application refuse un travail de traduction sur un modèle local. La traduction ne tourne que sur Betty dans le cloud, sur un modèle bien plus gros que celui des passes de correction, ou via votre propre clé.
Il proposait autrefois deux à quatre agents éditeurs par segment, et plusieurs relecteurs, sur la théorie que des avis indépendants pouvaient être mis en commun. Ils ont été mesurés, et il n'y avait pas d'avis indépendants à mettre en commun.
Les corrections sont décodées de façon gloutonne — on demande au modèle la réponse unique la plus probable plutôt qu'un échantillon, parce que trouver une erreur est une question qui a une bonne réponse et non une question créative. Posez la même question de cette façon deux fois et vous obtenez deux fois la même réponse. Chaque agent supplémentaire relisait le même segment avec le même prompt et renvoyait une liste identique à l'octet près, que l'étape de fusion repliait ensuite en une seule.
Mesuré sur quatre langues et trois modèles : un éditeur et deux produisaient une sortie identique dans tous les cas — les mêmes corrections, les mêmes oublis, les mêmes signalements sur du texte propre — et l'un était 15 à 20 % plus rapide. Les options ont donc été retirées plutôt que laissées comme un réglage qui vous coûte du temps et de l'énergie pour rien. La seule exception est conservée : quand vous fournissez une feuille de style, un second agent tourne avec un prompt réellement différent, et celui-là peut être en désaccord.
Je pense que Betty est bonne. Je pense aussi qu'il est important d'être clair sur là où elle aide, là où elle n'aide pas, et sur ce à quoi vous vous engagez.
Betty est un outil, pas une professionnelle. C'est une aide à l'écriture — pas une correctrice, une relectrice ou une conseillère juridique qualifiée. Ses suggestions sont des points de départ, pas des verdicts. Le dernier mot sur chaque phrase vous revient.
Elle se trompera parfois. La langue dépend du contexte de façons réellement difficiles. Betty signalera de temps en temps quelque chose qui allait bien, manquera quelque chose qui n'allait pas, ou proposera un changement qui aggrave les choses. Considérez sa production comme un second avis, pas comme une correction définitive.
Local par défaut ; le cloud seulement si vous le demandez. Livrée à elle-même, Betty traite le texte uniquement sur votre propre matériel, et rien n'est transmis. L'exception est un travail dans le cloud — choisi au cas par cas et payé avant de s'exécuter : le passage édité part, chiffré, vers une infrastructure européenne qui ne l'écrit dans aucune base de données ni aucun journal. Dans les deux cas, vous gardez tous les droits sur votre manuscrit et sur le résultat édité, et rien de ce que vous écrivez ne sert à entraîner un modèle. Les conditions du cloud disent clairement ce qu'il advient du texte.
Tourner en local demande un matériel capable. Le modèle local a besoin de 8 Go de RAM libre pendant qu'elle travaille — en pratique, une machine de 12 Go ou plus, ou de 8 Go avec tous les autres programmes fermés — et d'environ 3 Go d'espace disque libre. La vitesse dépend de la partie graphique : un Mac Apple Silicon ou une carte NVIDIA avec 8 Go de mémoire vidéo corrige un roman en trois heures environ, ou moins, alors que sur le seul processeur cela prend la majeure partie d'une journée. Durées prévues selon la machine. Elle effectue un vrai travail de calcul — il n'existe pas de version légère. L'option cloud est faite pour ces machines-là : le modèle tourne dans le centre de données, et rien d'autre que l'application elle-même n'a besoin de tenir sur la vôtre.
Plateformes prises en charge. Betty est actuellement disponible pour macOS 12 ou ultérieur, Windows 10 (64 bits) ou ultérieur, et les systèmes Linux avec glibc 2.31 ou plus récent. Les autres plateformes ne sont pas prises en charge pour le moment.
Betty est gratuite, et compte le rester. Faire tourner Betty sur votre propre machine n'a ni limite d'utilisation, ni abonnement, ni période d'essai, et c'est cela, le produit. Il existe une option payante — un service cloud, facturé au travail, pour les machines qui ne peuvent pas faire tourner un modèle en local : 5 € pour 100 000 mots pour une correction ou une relecture finale, 12 € pour une traduction. Elle n'est jamais nécessaire pour utiliser Betty. Si quoi que ce soit change dans la version gratuite, cela sera annoncé ici avant d'entrer en vigueur, avec assez de préavis pour prendre une décision réfléchie.
Aucune garantie. Betty est fournie telle quelle. Je ne garantis ni l'exactitude, ni l'adéquation à un usage particulier, ni une disponibilité ininterrompue. Utilisez-la à votre discrétion.
Chaque affirmation de cette page accompagnée d'un chiffre provient d'un banc d'essai que quiconque dispose du dépôt peut relancer. Des textes appariés — un texte propre et le même texte avec une centaine d'erreurs placées à des positions de caractères connues — passent par le vrai pipeline, et ce qui en ressort est noté par rapport à ce qui a été placé.
Les textes fautifs sont construits, pas annotés : un générateur place chaque erreur d'après un plan par langue et refuse toute modification qui ne produit pas exactement une zone du type voulu, de sorte que la vérité de référence ne peut pas dériver du texte. Les passes sont notées différemment parce qu'elles échouent différemment — rappel et précision par rapport aux erreurs placées pour la correction, et chrF par rapport à des traductions humaines de référence, plus des vérifications de ratio de longueur et de mots non traduits, pour la traduction.
Les résultats, par langue, avec les oublis ventilés selon le type d'erreur manqué, sont sur la page des performances.