Ce qu'exige vraiment une version 2 : 206 commits d'états honnêtes

La plupart des sorties « version 2 » sont un tas de nouvelles fonctionnalités avec un plus gros chiffre dessus. La v2 de GeekBye était l''inverse. Elle n''a apporté presque aucune nouvelle capacité visible pour l''utilisateur. Ses 206 commits visaient une seule idée, peu glorieuse :

L''app ne doit jamais vous montrer un état qui n''est pas vrai.

Ça semble évident jusqu''à ce que vous comptiez le nombre de façons dont une app de bureau ment en silence. Elle affiche une coche sur un envoi encore en vol. Elle dit « connecté » sur un socket mort il y a une minute. Elle reste muette pendant que votre transcription part à la poubelle. Rien de tout ça n''est un plantage. C''est pire qu''un plantage, parce que l''app a l''air d''aller bien tout en ayant tort — et vous ne le découvrez que plus tard, quand l''enregistrement dont vous aviez besoin n''est pas là.

La v2, c''est la sortie où nous sommes partis à la chasse de chacun de ces petits mensonges.

Le mensonge qu''on détestait le plus : l''envoi qui « a marché »

GeekBye peut sauvegarder vos enregistrements sur Google Drive. En v1, la connexion à Drive était traitée comme un détail en arrière-plan — si ça marchait, tant mieux ; si ça ne marchait pas, l''échec était presque invisible. L''app continuait à avoir l''air connectée. Vous supposiez que vos enregistrements étaient en sécurité. Parfois, ils ne l''étaient pas.

La v2 a reconstruit tout ça autour d''états de connexion honnêtes. Drive est désormais toujours dans l''un de quelques états explicites et véridiques — connecté, en reconnexion, déconnecté — et l''app diffuse chaque changement de cet état à toute l''interface à l''instant même où il se produit. Quand la connexion est coupée, une bannière globale de reconnexion vous le dit, partout, clairement. L''app ne fait plus semblant qu''un envoi a réussi alors que non. Si votre sauvegarde ne peut pas se faire maintenant, vous le savez maintenant — pas la semaine prochaine, quand vous irez chercher le fichier.

En dessous, c''est une petite architecture, pas un slogan : une seule source de vérité pour la connexion, un événement qui se déploie vers chaque partie de l''interface quand il change, et une bannière qui lit directement dans cet état. Il n''existe aucun chemin où la connexion est coupée et l''interface a l''air active, parce que les deux lisent le même fait.

Le mensonge de l''enregistrement perdu

Le deuxième grand correctif d''honnêteté, c''était la récupération des enregistrements. La transcription en temps réel a besoin d''une connexion vivante. En v1, si cette connexion avait un hoquet en pleine session — un clignotement Wi-Fi, un tunnel, une reconnexion VPN — l''audio pendant le trou pouvait tout simplement disparaître. La transcription avait un trou, et rien ne vous prévenait.

La v2 a changé le contrat : l''audio est conservé en local pendant une coupure de connexion et réconcilié ensuite. Quand le lien tombe, GeekBye garde l''audio en sécurité sur votre machine ; quand il revient, cet audio en tampon est envoyé et recousu dans la transcription au bon endroit. Trente mauvaises secondes de réseau ne vous coûtent plus trente secondes de réunion. C''est le socle sur lequel les sorties de fiabilité ultérieures ont directement bâti — la mécanique de reconnexion-et-tampon de pourquoi votre notetaker IA s''arrête sur un mauvais Wi-Fi est la même idée, durcie.

Le mensonge de la tempête de popups

Il y a une malhonnêteté plus subtile dans la façon dont les apps signalent les problèmes : elles les sur-signalent. Un seul moment réseau instable peut déclencher la même erreur cinq fois, et soudain vous avez une pile de notifications rouges identiques qui enterrent le seul message qui compte. Ce n''est pas honnête non plus — c''est du bruit qui se fait passer pour de l''information.

Alors la v2 a ajouté la limitation des notifications par catégorie et le routage des erreurs. Les erreurs sont regroupées selon ce qu''elles sont vraiment, et chaque catégorie est limitée en fréquence pour qu''un seul problème sous-jacent produise un message clair, pas un tir de barrage. Un souci de limite de débit se route vers un message de limite de débit ; un souci de connexion se route vers un message de connexion. L''app vous dit ce qui est vrai, une fois — la même discipline qui a plus tard empêché un 429 de se faire passer pour une déconnexion dans le jour où notre app s''est DDoS elle-même.

Le chiffre 206, c''est tout l''intérêt

États honnêtes, bannière de reconnexion, récupération des enregistrements, routage des notifications — ça fait quatre idées. La sortie, c''étaient 206 commits. Où est passé le reste ?

Dans la longue traîne peu glorieuse qu''exige réellement « ne jamais afficher un faux état ». Chaque endroit où l''ancienne interface pouvait se désynchroniser de la réalité a dû être trouvé et recâblé pour lire dans la vérité au lieu d''une copie périmée. Chaque chemin de reconnexion a dû être forcé à mettre à jour l''état partagé au lieu de deviner en local. Des dizaines de petits correctifs de fiabilité à travers l''enregistrement, la transcription et les envois — chacun refermant un trou précis où l''app pouvait avoir l''air juste tout en ayant tort.

Voilà ce que coûte une vraie « version 2 » quand le but est la confiance plutôt que les fonctionnalités. Il n''y a pas un seul commit vedette. Il y en a 206 petits, et la sortie ne donne l''impression d''être une seule chose — le calme — que parce que les 206 tirent dans la même direction.

La sortie a failli ne pas partir

Voici l''anecdote de guerre, et elle est bonne, parce qu''elle parle de notre propre app qui nous ment à nous.

Quand vous préparez une sortie, un script de changement de version tamponne le nouveau numéro dans tout le projet. En v2.0.0, il a mis à jour la version de l''app — mais le package-lock.json, le registre exact des dépendances de npm, est resté pointé sur l''ancienne version, 1.9.0. En local, tout allait bien ; personne ne réinstalle les dépendances juste pour compiler. Mais la CI exécute npm ci, et le boulot entier de npm ci est de refuser de continuer si le lockfile est en désaccord avec le manifeste. C''est une fonctionnalité de rigueur — et elle a fait exactement ce qu''elle devait, en faisant échouer la compilation de la plus grosse sortie qu''on ait jamais préparée.

Puis un deuxième, plus sournois, a émergé en dessous. Un npm plus récent avait élagué une dépendance transitive optionnelle — le paquet encoding que tire node-fetch — du lockfile, jugée inutile. Sauf que l''installation propre de notre CI en avait besoin, donc l''installation s''est cassée d''une manière qui n''avait rien à voir avec notre code et tout à voir avec le registre subtilement faux.

Les deux étaient des correctifs d''une ligne : resynchroniser le lockfile à la vraie version, restaurer l''entrée élaguée. Les deux sont aussi des exemples parfaits et humbles de la chose même dont parlait la v2 — un état qui prétendait être vrai et ne l''était pas. Le lockfile est censé être le registre honnête de ce dont l''app dépend. Quand il a dérivé de la réalité, la compilation a fait exactement ce que notre app fait maintenant pour les utilisateurs : elle a refusé de faire semblant que tout allait bien. Livrer une sortie de fiabilité s''avère être un problème de fiabilité jusqu''au bout.

Trois choses que la v2 nous a apprises

1. Les pannes dangereuses sont les silencieuses. Un plantage s''annonce lui-même. Un faux « connecté », un envoi réussi fantôme, une transcription avec un trou invisible — ceux-là vous coûtent de la confiance précisément parce que rien n''a l''air d''aller mal. Chassez les mensonges silencieux.
2. L''honnêteté est une architecture, pas un message. Vous ne pouvez pas visser « dis la vérité » sur une interface sous forme de bannière. La bannière doit lire dans la même unique source de vérité que tout le reste, sinon elle devient une chose de plus qui peut se tromper. Un fait, déployé — jamais deux copies qui peuvent diverger.
3. Une version 2 qui mérite son chiffre est en grande partie invisible. Si votre v2 est une liste de fonctionnalités, c''est une v1.5 avec du marketing. Une vraie v2, ce sont 206 commits que personne ne peut désigner individuellement, s''additionnant en un produit qui, tout simplement, arrête de vous mentir.

La v2.0.0 de GeekBye est le socle sur lequel chaque sortie depuis a bâti. Pour ce que ce socle porte, voyez pourquoi votre notetaker IA s''arrête sur un mauvais Wi-Fi, le jour où notre app s''est DDoS elle-même (v2.0.1) et la transcription en direct quand le pare-feu bloque les WebSockets (v2.0.8). Pour le calme au service duquel tout cela était, les nouveautés de GeekBye v2.