SkanFact 9.8.7

Deux défauts trouvés en testant le Cabinet écran par écran, et les deux sont des trous de la
9.8.5 elle-même.

La colonne « Intitulé » n'a jamais porté le nom du compte. Le grand livre, la balance générale
et l'export CSV passaient (c, t) => t || '' au moteur : ils affichaient le tiers. Tant que
T-13 fabriquait un tiers en découpant le libellé, quelque chose s'affichait — « Agence Immobilière
Le Lac » en face du 606, faux mais visible. La 9.8.5 a rendu au tiers son honnêteté, et la colonne
s'est vidée : corriger la donnée ne corrige pas l'écran qui ne l'a jamais lue. Sur une balance
générale, « Intitulé » désigne le nom du compte — c'est la définition du document ; le tiers a son
écran à lui, la balance auxiliaire, qui le montre en première colonne. Un résolveur unique
(nomDeCompte) lit le plan du livre, retombe sur le plan comptable de référence, puis sur le tiers.
La balance auxiliaire garde le sien, et c'est l'exception nommée dans le test : elle échange
account et tiers avant d'appeler.

Le livre survivait à la suppression de son dossier : le correctif de la 9.8.5 n'a jamais tourné.
removeDossierFiles mélangeait deux conventions d'argument — la moitié des paquets construit son
index elle-même et attend un tableau, la ligne ajoutée pour les livres passait ce tableau à
livreDir, qui attend l'index. folderName y fait collisions.has(...) : sur un tableau ça
lève, le catch l'avalait, et le dossier des livres n'était jamais effacé. Aucun écran, aucun
message — une ligne dans main.log. Le défaut du « livre orphelin » que la 9.8.5 annonce corriger
était donc intact : l'exemple se rechargeait avec des paquets neufs et le livre de la version
d'avant. L'index se construit maintenant une fois, en tête, et sert aux deux moitiés ; un échec
d'effacement ne fait toujours pas échouer l'appelant, mais il est rendu au lieu de disparaître.

Et la leçon de méthode, la plus chère. Mon test appelait removeDossierFiles(dossier, idx) —
avec un index. Le seul appelant, lui, passe state.dossiers, un tableau. J'avais rencontré
collisions.has is not a function en écrivant ce test, et je l'ai « corrigé » en changeant le
test. Il prouvait donc que ma ligne marche quand on l'appelle comme elle veut être appelée :
un test qui appelle une fonction autrement que son unique appelant ne prouve rien de
l'application. Il passe désormais le tableau.

559 tests, 0 erreur de lint, cinq défauts réintroduits un par un font tomber leur test.

SkanFact 9.8.6

L'app du comptable ne se construisait plus. La 9.8.5 est complète et verte ; c'est sa
publication qui a échoué, du côté du Cabinet seulement, deux secondes après le début de l'étape.

La 9.8.4 avait ajouté à cette étape le même drapeau de type de release que l'étape de l'app
entreprise, « parce que deux étapes qui peuvent se contredire finissent toujours par se
contredire ». La raison était bonne, le geste non : l'étape du Cabinet passe un fichier de
configuration (-c build/cabinet.config.js), et -c.publish.releaseType=… vise la même option.
Le second gagne, et electron-builder est parti chercher un fichier de configuration nommé
.publish.releaseType=release — qui n'existe pas. L'étape de l'app entreprise n'a pas ce problème
parce qu'elle ne passe aucun fichier. Rien dans le nom des deux drapeaux ne laisse deviner qu'ils se
disputent quoi que ce soit, et la 9.8.4 n'a jamais été publiée : personne ne l'avait exercé.

Ce qui change :

• Le type de release du Cabinet se déduit du numéro de version, dans build/cabinet.config.js,
  à côté de son canal et pour la même raison (7.25.0 : une seule source de vérité). Il y était écrit
  'release' en dur : sur une bêta, l'étape aurait demandé une release pleine — sans conséquence
  tant que le job preparer crée la page (9.8.1), et faux le jour où ce ne serait plus lui.
• L'étape ne porte plus aucun -c.….
• Le garde-fou qui manquait : aucune commande electron-builder ne peut porter à la fois
  -c <fichier> et -c.<clé>=<valeur>. C'est lui qui aurait arrêté la 9.8.5 avant de brûler une
  publication.

Et une assertion retournée, quatorzième occurrence du motif : celle de la 9.8.4 exigeait deux
occurrences du drapeau dans le workflow. Elle décrivait le geste, pas la règle — la règle est que le
type de release de chacune des deux applications se déduit du numéro de version ; par quel
chemin ne regarde que le chemin.

Aucune ligne des deux applications ne change. 558 tests, 0 erreur de lint, trois défauts
réintroduits un par un font tomber leur test.

SkanFact 9.8.5

Un compte porte un nom de compte, et un tiers porte le nom du tiers.

Trouvé sur le terrain, en testant l'app Cabinet écran par écran avec Skander dans le rôle d'un
comptable. Le CSV d'un paquet porte deux colonnes distinctes — « Tiers » (qui) et « Libellé »
(quoi). Depuis la 9.2.0, le livre du dossier ne gardait que la seconde : la forme d'une ligne
n'avait pas de case pour le tiers. lignesDuLivre en inventait donc un à partir du libellé, et
assurerCompte nommait chaque compte d'après la première écriture qui le touchait.

Une seule ligne de code, six écrans faux :

• le lettrage groupait par FACTURE et non par client — une facture et son règlement, qui n'ont
  jamais le même libellé, devenaient deux « tiers » différents, et leur lettrage parfaitement juste
  était dénoncé comme faux. Seize alertes orange sur du travail correct ;
• la balance âgée rendait une ligne par facture sous une colonne « Tiers », et son pied comptait
  « 5 tiers » là où il y avait 5 factures ;
• la balance auxiliaire prenait le libellé comme numéro de compte ;
• le bilan et l'état de résultat étiquetaient chaque rubrique du nom d'une opération :
  le chiffre d'affaires de l'exercice s'appelait « Facture FAC-2026-014 — Clinique Les Jasmins » ;
• le grand livre montrait le plan comptable entier ainsi nommé — 401 « Achat LOC-2026-08 »,
  532 « Paiement salaire Ahmed Ben Salah mai 2026 » ;
• et la saisie, où c'était le pire : le sélecteur de compte recopiait ce nom dans le libellé
  de la ligne. Une facture de papeterie partait avec trois lignes « Achat LOC-2026-08 — Agence
  Immobilière Le Lac », validées, numérotées, définitives.

Ce qui change :

• tiers entre dans la forme d'une ligne de livre.json. C'est une décision de format, et le
  test du format tombe pour le dire (règle 9.7.0). Le test couvre désormais la forme d'une LIGNE,
  pas seulement le socle du livre : c'est par ce trou-là que le défaut est passé.
• PLAN_COMPTABLE déménage de core.js vers compta.js, et core.js le réexporte (un test compare
  les deux par identité d'objet). Le Cabinet ne charge pas core.js et avait besoin de NOMMER un
  compte — la règle de découpage de la 9.1.0 le veut là.
• assurerCompte nomme par le plan ; le libellé reçu n'est plus qu'un repli pour un numéro que
  le plan ne connaît pas.
• migrerLivre rend leurs noms aux comptes d'un livre écrit avant, pose la case tiers à vide,
  et ne touche à aucun chiffre. Posée à la LECTURE : un livre qu'on n'ouvre jamais n'est jamais
  réécrit pour rien. Elle ne renomme jamais un compte que le cabinet a nommé lui-même.
• Les livres d'un dossier partent avec le dossier. Un livre orphelin restait sur le disque et se
  rattachait au dossier suivant portant le même identifiant — ce qui arrivait au jeu d'exemple, dont
  les identifiants sont stables.

Limite à connaître : les lignes déjà écrites gardent une case tiers vide jusqu'à ce que leurs
paquets soient relus (« Relire les paquets reçus »). « (sans tiers) » est honnête ; un nom de tiers
recopié du libellé ne l'était pas. Et les écritures validées déjà parties avec un libellé faux ne
sont pas réécrites : une validée ne se modifie jamais, elle se contre-passe.

Pourquoi en stable et pas en bêta : la règle veut la bêta pour ce qui touche au moteur comptable
ou au format d'un fichier, et c'est le cas ici. Skander teste l'application en ce moment même et a
demandé la stable pour pouvoir continuer sur une version corrigée. L'ajout d'un champ à un format
est compatible (règle 9.7.0), la migration est pure et idempotente, et sept défauts réintroduits un
par un font tomber leur test.

SkanFact 9.8.3

Les boutons collés au contenu, et la sonde qui les voit.

Signalé par Skander : « sur l'app cabinet y'a plein de boutons qui sont mal espacés et collés au
contenu ». Il avait raison, et la cause est mesurable : les trois sondes de rendu du projet mesurent
un bouton tout seul — sa couleur, son débordement, l'alignement de sa colonne — et aucune ne
mesure sa distance à ce qui l'entoure. Or un bouton collé au titre du dessus est parfaitement
lisible, parfaitement dans la fenêtre, et parfaitement moche. C'est une propriété de la RELATION
entre deux éléments ; il fallait la mesurer comme telle.

Une quatrième sonde, dans harnais.js avec les trois autres et partagée par les deux
applications : pour chaque bouton visible, l'écart réel avec son voisin de gauche et de droite,
horizontal s'ils sont sur la même rangée, vertical s'ils sont empilés. 1 678 écarts mesurés, en
clair et en sombre, à 1440 et à 1280.

Ce qu'elle a trouvé, et qui est corrigé :

• Le retour « ← Dossiers » collé au nom du client — zéro pixel, sur les vingt-huit écrans d'une
  fiche. Le bouton a deux placements et un seul avait son espacement : dans l'app entreprise il vit
  dans une barre .actions qui porte son gap, dans le Cabinet il est posé seul au-dessus du
  titre. La règle vise donc le placement autonome, jamais le bouton en soi.
• « Voir 4 autres lignes » collé à la liste qu'il prolonge : un geste collé à ce qu'il prolonge
  se lit comme une ligne de plus, pas comme un bouton.
• Deux bulles « i » collées sur un même titre — deux explications, deux cibles, qui se lisaient
  comme un seul objet.
• « PDF » et « Modifier » dans la page Paie : 3,6 px, c'est-à-dire la largeur d'une espace entre
  deux balises du gabarit. La parade de la 7.29.0 existait mais ne visait que td.actions ; un
  correctif qui dépend d'une classe qu'on pense à mettre n'est pas un correctif. Il vise maintenant
  toute cellule, et nomme les deux grappes qui décident de leur propre densité.
• Les pictogrammes ↑ ↓ ⧉ ✕ de l'éditeur : leur densité venait elle aussi d'une espace du
  gabarit, c'est-à-dire de rien. Elle est désormais décidée.

Et un défaut que l'instrument a trouvé au passage, sans rapport avec l'espacement : sur l'onglet
Exercice livré la veille, le bilan actif et le bilan passif sont deux tableaux côte à côte dans
un .split, sans leur .scroll-x — exactement le défaut corrigé en 3.4.0 sur la fiche
d'affaire. Les trois tableaux des états financiers l'ont maintenant.

Aucune fonction nouvelle : uniquement de l'espacement, et l'instrument qui empêche qu'il se reperde.

SkanFact 9.8.1

La publication elle-même : la course qui a fait échouer la 9.8.0.

La 9.8.0 est complète et verte ; c'est sa publication qui a échoué, et l'application n'y est
pour rien. Le workflow construisait Mac et Windows en parallèle, et chacun des deux postes créait
la page de la release. Les deux ont demandé la liste des releases au même instant, n'ont rien
trouvé tous les deux, ont créé tous les deux — et le second a reçu 422 already_exists.
electron-builder rattrape ce refus quand il envoie un fichier, mais pas quand il crée la
release : le poste Windows est tombé, et comme rien ne disait le contraire, le poste macOS — déjà
bien avancé, et le plus cher des deux — a été annulé avec lui. La release v9.8.0 est restée avec
un seul fichier sur huit.

Ce que la 9.8.1 change, dans .github/workflows/release.yml :

• La page de la release est créée une seule fois, dans un job qui passe avant les constructions.
  Quand les deux postes démarrent, elle existe : ils ne font plus qu'y déposer leurs fichiers. La
  course n'existe plus, et une reprise après échec ne détruit rien (la release existante est
  reconnue, son titre et ses notes remis, ses fichiers conservés).
• Un échec sur un poste n'annule plus l'autre (fail-fast: false). Savoir si une panne touche un
  seul poste ou les deux est en plus ce qui désigne la cause.
• Le tag pointe enfin sur le commit construit (--target). Sans ce drapeau, GitHub posait le tag
  sur la branche par défaut du dépôt : v9.6.0 et v9.8.0 désignent tous les deux un commit de la
  9.4.1. Les installateurs publiés étaient justes — c'est git checkout v9.8.0 qui ne rendait pas
  la source publiée.
• Le titre et les notes sont posés dès la première seconde, au lieu d'apparaître après le premier
  fichier envoyé. Entre les deux, la page n'affichait que le numéro de version.
• EP_GH_IGNORE_TIME : electron-builder refuse de déposer dans une release publiée il y a plus
  de deux heures — et il le fait en écrivant « skipped publishing » puis en sortant vert. Le job
  réussit, la release reste vide, et personne ne le voit. C'est le pire des échecs : celui qui se
  présente comme un succès.

Aucune ligne de l'application n'a changé. Le numéro passe quand même, parce que le numéro est ce qui
dit lequel des deux paquets est celui qu'on a pu installer.

SkanFact 9.6.0

La déclaration du mois : les chiffres à recopier, et rien de plus.

SkanFact ne dépose rien et ne se connecte à aucune administration. Ce que fait cette version,
c'est préparer les chiffres que le comptable recopie sur le portail — et les rendre vérifiables.

• Chaque case se déduit des écritures validées, jamais saisie : un chiffre saisi à côté d'un
  livre finit toujours par le contredire. TVA collectée, déductible, crédit reporté, net à payer,
  crédit à reporter, droit de timbre, retenues opérées et subies, IRPP, total à décaisser.
• Chaque chiffre s'ouvre sur les pièces qui le font. Un chiffre qu'on ne peut pas ouvrir se
  croit ou ne se croit pas ; un chiffre qui montre ses écritures se vérifie.
• Une case dont la règle n'est pas connue vaut « — », jamais « 0,000 ». TFP, FOPROLOS, TCL et
  acomptes provisionnels : leur assiette et leur taux ne sont pas établis, et un zéro se recopierait
  sur un formulaire fiscal. Chacune dit pourquoi elle est vide, avec son À VÉRIFIER. Le jour où
  le plan du dossier porte un compte pour l'une d'elles, elle se calcule.
• Le crédit reporté se lit sur le compte, jamais dans un champ : une déclaration isolée qui
  l'ignore donne un net faux.
• Trois contrôles avant dépôt, qui nomment sans jamais bloquer : les pièces encore en brouillard
  (elles n'entrent dans aucun chiffre), le compte d'attente non soldé, et la TVA du mois pas encore
  soldée par son écriture.
• L'écriture du mois (TVA collectée / déductible → à décaisser, timbre et retenues compris)
  arrive au dernier jour du mois et en brouillard : c'est le comptable qui la valide. Elle ne
  crédite du compte de TVA déductible que ce qui est utilisé — le reste est le crédit à
  reporter, et il doit rester.
• L'état d'un mois : reçu → saisi → déclaré → payé. Les deux derniers sont des pense-bêtes, et
  ils se dé-pointent ; on ne peut pas payer ce qu'on n'a pas déposé, et l'écran le dit.
• Le détail par taux ne s'invente pas : il demande un sous-compte de TVA collectée par taux.
  Quand le dossier n'en a qu'un, le total reste juste et l'écran explique pourquoi il n'y a pas de
  répartition, au lieu d'un tableau à une ligne qui laisserait croire que tout est à 19 %.

Ce qui n'y est pas : le calendrier fiscal par régime. Les régimes à distinguer et les échéances
de chacun dépendent de réponses que le cabinet pilote n'a pas encore données, et les inventer
reviendrait à écrire du droit que personne n'a confirmé.

SkanFact 9.4.1

La révocation s'applique enfin. La clé qui permet au serveur de prouver que ses réponses
viennent bien de lui est embarquée dans cette version. Jusqu'ici elle valait null : une licence
révoquée depuis la console continuait de fonctionner chez le client, parce que l'application ignorait
— par construction, et c'était le bon défaut — toute réponse qu'elle ne pouvait pas vérifier.

• Ce qui change pour toi (client) : rien, sauf si ta licence est révoquée. Aucun message, aucune
  connexion obligatoire, aucun réglage. Une réponse du serveur n'est crue que si elle est signée,
  datée et adressée à ta licence ; sinon elle est ignorée, comme avant.
• La clé a été recréée le 17/09/2026 sur l'ordinateur de l'éditeur. Celle du 15/09 avait été vue
  hors de son poste : une clé privée qui a été vue est brûlée, on la jette et on recommence.

Et la console (api.skanfact.tn) sait vendre une licence de cabinet. La 9.4.0 avait appris à
SkanFact Cabinet à lire une clé de cabinet et à l'Éditeur de SkanFact à en signer une ; la console,
elle, ne connaissait que deux offres. Les trois moitiés d'une même vente sont maintenant d'accord.

• Un type à l'émission : « Entreprise » (une offre, un matricule, s'installe dans SkanFact) ou
  « Cabinet comptable » (l'empreinte du cabinet, un quota de dossiers hors SkanFact, s'installe dans
  SkanFact Cabinet). Chaque application refuse la clé de l'autre.
• Aucun prix n'est proposé pour un dossier de cabinet tant qu'il n'est pas réglé : les tarifs du
  Cabinet ne sont pas fixés, et un chiffre écrit « pour l'exemple » deviendrait un tarif.
• « Changer le quota » remplace « Changer d'offre » sur un cabinet : la date de fin ne bouge pas,
  seule la différence est facturée au prorata. Renouveler garde le quota.
• Le mail d'une clé de cabinet mène à Réglages → Mon cabinet → Licence, jamais aux Paramètres de
  SkanFact. La facture dit « SkanFact Cabinet — N dossiers ». La colonne de la console affiche le
  quota et combien de clients ce cabinet a parrainés.
• Une empreinte se compare désormais sans ses séparateurs : 3F9A-2C1E-… recopiée d'un message
  et 3f9a2c1e… rangée par la console sont le même cabinet. Un « G » tapé pour un « 6 » reste, lui,
  une faute qui se voit.

Prouvé : 27 défauts réintroduits un par un font tomber leur test. 458 tests, lint 0 erreur,
e2e:console (16 étapes), e2e:pont et e2e:licence verts.

SkanFact 9.4.0

SkanFact Cabinet devient payant — au-delà de trois dossiers, et seulement pour ceux qui ne sont pas
sur SkanFact. On vend des dossiers, jamais des postes : installe-le sur autant d'ordinateurs
que tu veux, c'est le même cabinet.

• Gratuit pour toujours pour tous les dossiers dont le client utilise SkanFact, quel qu'en soit
  le nombre — plus trois dossiers hors SkanFact. Un cabinet dont les soixante clients sont sur
  SkanFact ne paie jamais rien.
• Ce qui peut attendre une licence, c'est la validation d'une écriture. Rien d'autre. Lire un
  livre, importer un paquet, saisir, exporter tes écritures, relancer un client : toujours ouvert.
  Jamais de données en otage — ce sont les pièces de tes clients qui dorment ici.
• L'écran nomme chaque dossier compté, avec sa raison. Ne comptent pas : un dossier archivé, un
  dossier sans écriture validée depuis douze mois, un client sur SkanFact, et un client dont la
  licence payée a expiré il y a moins de douze mois — on ne te fait pas payer un retard qui
  n'est pas le tien.
• Le doute profite au cabinet : un paquet fabriqué avant cette version ne dit pas si son client
  a une licence. Dans ce cas, le dossier ne compte pas, et l'écran explique pourquoi.
• La clé est attachée à l'empreinte de ton cabinet — celle que tu dictes à tes clients. Elle te
  suit quand tu changes d'ordinateur, à condition d'avoir repris ton cabinet par ta clé de
  secours. Un cabinet recréé à neuf a une autre empreinte.
• Bandeau à trois tons dans la barre latérale, ligne « À faire » quand le quota est dépassé, et
  « Demander une licence » qui prépare le message. Ce qui part : ton empreinte, le nombre de
  dossiers comptés, la version. Jamais un nom de client.

Côté SkanFact (l'application des entreprises) : le paquet mensuel porte désormais l'état de
ta licence — l'état, sa date de fin et si elle a été payée, rien d'autre, jamais la clé. C'est ce qui
permet à ton comptable de ne pas payer pour toi. Et une clé de cabinet ne peut plus déverrouiller une
application d'entreprise, ni l'inverse.

SkanFact 9.2.2

La fiche d'un dossier, dans le Cabinet, tient enfin sur un écran. Tout était sur la même
page : l'identité, le graphique, les mois, la comptabilité entière, les paquets, les relances —
sur un vrai dossier, le seul bloc Comptabilité faisait une page à lui seul, posé au milieu.

• Un en-tête avec le nom, l'identité sur une ligne, et l'état du dossier en une phrase :
  « 3 mois reçus · 2 manquants · dernier paquet le 06/09 · CA 2026 : 86 630 DT ». Le bouton
  Relancer passe en premier quand il manque quelque chose.
• Trois onglets : Suivi (les mois, les relances, la note — l'écran du quotidien),
  Comptabilité (livre-journal, grand livre, balance, lettrage, reprise), Paquets (les paquets
  reçus avec leurs actions, et le graphique de chiffre d'affaires qui en vient).
• Les alertes restent au-dessus des onglets, quel que soit celui qu'on regarde, et mènent
  aux paquets concernés.
• L'onglet est dans l'adresse : « précédent » y revient, et une autre page peut ouvrir un
  dossier directement sur sa comptabilité.
• Imprimer imprime la fiche entière, comme avant.

Et le jeu d'exemple du Cabinet livre de vrais paquets. Ses cinq dossiers n'avaient que des
chiffres : aucun fichier, donc « aucun paquet ne contient d'écritures » sur la page qui doit
montrer un exercice ouvert. Ils reçoivent maintenant de vrais .skanpack — journaux, écritures
en partie double, balance, TVA — tirés du jeu de démonstration de SkanFact, recalés sur le mois
courant, scellés pour ta clé, et importés par la même porte qu'un paquet reçu par mail. Ce que
l'exemple montre est ce que l'application fait : livre-journal, grand livre, balance, lettrage,
pièces vérifiées. Effacer l'exemple efface aussi ses fichiers.

SkanFact 9.2.0

Le livre du dossier, et le paquet signé. Côté cabinet, chaque dossier a
désormais SON livre comptable : les écritures qu'on y valide, celles qu'on y
saisit, les lettrages. Et le paquet mensuel est enfin signé par le client qui
l'envoie.

Le paquet est signé — le trou que trois relectures extérieures ont pointé

Jusqu'ici, un paquet était chiffré mais pas signé, et ce n'est pas la même
chose. Le chiffrement dit « seul mon comptable peut lire ceci ». Il ne dit pas
« ça vient bien de moi » — et comme il n'utilise que la clé publique du cabinet,
celle que ton comptable donne à tous ses clients, n'importe qui la tenant pouvait
lui envoyer un paquet à ton nom. Il l'aurait importé sans un mot.

• SkanFact crée maintenant une paire de clés au premier envoi, dans le dossier
  de ton entreprise (jamais dans tes données, donc jamais dans un export ni dans
  le paquet), et signe le manifeste de chaque paquet avec elle.
• Le cabinet vérifie, puis épingle ta clé au premier paquet signé. Tout ce qui
  suivra lui sera comparé : un paquet signé par une autre clé est refusé en
  nommant les deux empreintes, et la reprise passe par l'empreinte dite de vive
  voix — jamais par une acceptation automatique.
• Un paquet d'une version antérieure reste accepté, marqué « origine non
  prouvée ». La tolérance s'éteint d'elle-même client par client, dès qu'un
  premier paquet signé arrive.

Le livre du cabinet

• Un fichier par dossier et par exercice, chiffré, avec son entête lisible :
  un livre retrouvé sur une clé USB dit de quel client et de quelle année il parle
  avant qu'on cherche son mot de passe. Il part toujours avec la copie externe
  — un paquet perdu se redemande au client, un livre perdu non.
• Créer le livre à partir des paquets reçus, en un bouton. Rejouer ne double
  rien : un mois renvoyé remplace ses brouillards et ne touche jamais une
  écriture validée — l'écart est calculé et affiché, et c'est le comptable qui
  tranche.
• Reprendre un dossier venu d'un autre cabinet : exercice, plan de comptes,
  balance d'ouverture (saisie ou importée d'un CSV), avec l'écart d'équilibre en
  direct pendant la saisie et un refus net si elle ne tombe pas juste.
• Valider une écriture lui donne son numéro, définitivement. Une écriture
  validée ne se modifie plus : on la contre-passe, à la date du jour où l'on
  corrige. C'est ce qui fait qu'un livre relu dans deux ans dit la vérité de ce
  qui a été fait.
• Le brouillard se voit (italique, fond estompé, pastille à la place du
  numéro) et n'entre dans aucune balance tant qu'on ne le demande pas.
• Le lettrage relie une facture et son règlement, et refuse de solder ce qui
  ne se solde pas : un lettrage qui laisse un reste affirme qu'une facture est
  payée alors qu'il reste quelque chose.
• Chaque geste laisse une trace dans la piste d'audit du livre, qui n'est jamais
  purgée, et un livre ouvert sur un autre ordinateur ne s'écrase pas.

Le format du livre suit la mesure du test de charge de la 9.1.0 : corps binaire,
pas base64. Rien de tout cela ne change quoi que ce soit dans SkanFact côté
entreprise, sauf la signature du paquet — qui se fait toute seule.

Aussi dans cette mise à jour : la 9.1.0 et la 9.1.1

Elles n'ont jamais été publiées séparément. Si tu viens de la 9.0.0, tu reçois
donc aussi :

• Une formule cachée dans un export CSV ne s'exécute plus (9.1.1). Un tableur
  exécute une cellule qui commence par =, +, - ou @ : le libellé d'une
  ligne de facture partait tel quel dans le journal envoyé au comptable. Les
  quatre exports des deux applications sont protégés, et aucun montant ne bouge.
• « Émettre » ne peut plus donner deux numéros (9.1.0) : deux clics rapides
  en consommaient deux et trouaient la numérotation de tes factures.
• Les trois onglets de comptable de la page Comptabilité (grand livre,
  balance, états financiers) deviennent une option, décochée par défaut — SkanFact
  s'arrête à ta gestion. Rien n'est supprimé : Écritures, TVA, clôtures et l'envoi
  au comptable restent là, et la case se recoche dans « Tous les modules ».
• « Exonéré de timbre fiscal » sur la fiche client, et un seuil de retenue à
  la source réglable, à 0 (donc muet) tant que ton comptable ne t'a pas donné le
  chiffre (9.1.1). Tes factures déjà émises ne bougent pas.
• Une bulle d'aide en écrasait une autre depuis huit versions : en cliquant
  « Offre » dans tes Paramètres, tu lisais une explication écrite pour autre chose.
• Un journal technique borné, qui ne grossit plus sans fin, et une erreur de
  l'interface qui y laisse enfin une trace.