Ce qu'est vraiment une release de 127 commits

Il existe une version de cet article qui se contente d''énumérer tout ce que contient GeekBye v1.7.0 — un écran d''accueil repensé, un flux de calibration, une barre latérale repliable, de nouveaux réglages, et ainsi de suite. Elle serait exacte et ne vous apprendrait rien. Parce que l''histoire honnête d''une release de 127 commits, ce n''est pas la liste. C''est la forme.

Voici la forme. Cent vingt-sept commits, ça sonne comme cent vingt-sept petites choses. Ce n''est presque jamais le cas. v1.7.0, c''étaient deux grosses fonctionnalités, construites en parallèle sur des branches de longue durée pendant environ onze jours, tressées ensemble à la fin. Comprendre une grosse release, c''est comprendre ces deux fils — et le seul endroit où nous avons construit quelque chose au mauvais emplacement et où il a fallu l''arracher en plein vol.

Premier fil : la calibration

Le premier fil, c''était la calibration — une évaluation vocale par IA de vos compétences de communication. Vous démarrez un appel en direct avec un « coach de carrière » IA, vous traversez un ensemble structuré de phases (échauffement, comportemental, communication technique, réponse sous pression, fixation d''objectifs), et à la fin vous êtes noté sur six dimensions : confiance, clarté, précision, engagement, sang-froid, pertinence. En dessous, il mesure aussi des métriques concrètes de la parole : votre débit, la fréquence des mots de remplissage, si vos pauses se lisent comme stratégiques ou hésitantes.

Le résultat n''est pas une note, c''est un point de départ. La calibration produit vos forces, vos axes de progression et — surtout — une difficulté recommandée pour commencer à vous entraîner. Elle calibre où le produit doit venir à votre rencontre. Chaque compétence revient sous forme de carte de feedback dépliable avec un résumé, une suggestion concrète et une phrase citée mot pour mot de votre propre appel en guise d''exemple. C''est la fonctionnalité sur laquelle repose tout le reste de l''expérience d''entraînement.

Deuxième fil : une fenêtre entièrement nouvelle

Le deuxième fil, c''était une refonte premium — et l''appeler refonte la sous-estime. Ce n''était pas un habillage des écrans existants ; c''était en pratique une seconde fenêtre d''application, développée en six phases explicites : une barre latérale repliable façon Notion, un menu déroulant d''en-tête qui a remplacé l''ancienne liste des sessions, une navigation façon navigateur avec historique et fil d''Ariane, et des reconstructions premium de l''Accueil, des Profils, des Réunions et des Réglages.

Deux grosses fonctionnalités. Voilà ce qu''étaient réellement 127 commits. Et le plus dur pour les livrer, ce n''était pas d''écrire l''une ou l''autre — c''était le tressage. Les deux branches étaient interdépendantes ; l''une a été fusionnée dans l''autre, et la branche de calibration a dû importer la branche main quatre fois distinctes juste pour ne pas dériver pendant que la refonte bougeait en dessous. Le nombre de commits n''est pas le coût d''une grosse release. Les branches de longue durée et l''ordre d''intégration, si.

La partie qui vaut la lecture : nous avons construit la calibration au mauvais endroit

Voici l''erreur, et c''en est une bonne parce qu''elle est très courante.

GeekBye a une règle d''architecture ferme : toutes les opérations d''IA vivent sur le backend. Le client est une coquille fine qui parle à un serveur. Tout le monde le savait.

Et pourtant la calibration a d''abord été construite dans la base de données locale du client. Une table dédiée, une migration de base de données, un dépôt de 254 lignes, des handlers IPC et une banque de 515 lignes de questions d''évaluation — le tout vivant sur la machine de l''utilisateur. Ça marchait. Ça violait aussi discrètement le contrat sur lequel toute l''app est bâtie.

Trois jours plus tard, un commit a supprimé 680 lignes réparties sur huit fichiers pour tout déplacer vers le backend, où les données de calibration sont devenues un vrai modèle côté serveur, et où la logique des questions et la notation sont devenues une affaire du serveur. Un autre commit a supprimé purement et simplement la banque de questions de 515 lignes du client. Le diff est presque drôle : une insertion, six cent quatre-vingts suppressions.

Personne ne s''est mis à écrire 680 lignes de code jetable. C''est arrivé comme ça arrive toujours : le raccourci côté client est juste là, c''est plus rapide de prototyper en local, et « on le déplacera vers le backend plus tard » semble inoffensif. Mais quand votre architecture vous dit déjà où vit la source de vérité, le construire ailleurs n''est pas un raccourci — c''est du retravail que vous vous êtes planifié à l''avance. La leçon qui est restée : mettez-le là où le contrat le dit, du premier coup, même quand la version locale est plus rapide à monter.

Le bug que seule l''intégration pouvait trouver

Un dernier reçu, parce que c''est le mode de défaillance signature des grosses releases. Une fois la calibration et la nouvelle navigation reliées et réellement en marche, l''app s''est mise à déclencher une limite de débit — des HTTP 429 — sans raison apparente.

La cause était purement d''intégration. Le statut de calibration était récupéré au niveau du composant, donc chaque navigation le re-récupérait — et le strict mode de React, qui invoque volontairement les effects deux fois en développement pour faire remonter les bugs, l''a redoublé. Résultat : quatre à huit requêtes de calibration identiques déclenchées à chaque changement d''écran, assez pour faire sauter le limiteur de débit du serveur. Le correctif a consolidé le fetching en deux ou trois appels au montage.

Vous n''auriez pas pu trouver ce bug en testant la calibration seule, ni la navigation seule. Il n''existe qu''à la couture — là où se rencontrent deux fonctionnalités indépendamment correctes. C''est la taxe que prélève une grosse release : le dernier kilomètre, ce n''est pas de construire les fonctionnalités, c''est de découvrir tout ce qui ne casse que lorsqu''elles sont enfin dans la même pièce.

Trois choses qu''une grosse release nous a apprises

1. Une release de 127 commits, c''est deux ou trois grands thèmes, pas cent petits. Trouvez les fils. Le travail — et le risque — vit dans la façon dont ils se tressent, pas dans le nombre.
2. Mettez la source de vérité là où le contrat dit qu''elle vit, du premier coup. Nous avons supprimé 680 lignes en relocalisant la calibration du client vers le backend. Le raccourci local est du retravail planifié à l''avance ; l''architecture vous avait déjà donné la réponse.
3. L''intégration fait remonter des défaillances que l''isolement ne peut pas. La tempête de 429 vivait à la couture entre deux fonctionnalités correctes et n''est apparue qu''une fois qu''elles tournaient ensemble. Budgétez une passe d''intégration, pas seulement des tests par fonctionnalité.

C''est un cousin de l''ère v1 d''une histoire que nous raconterions à nouveau à une bien plus grande échelle — voyez ce qu''exige vraiment une version 2 : 206 commits d''états honnêtes (v2.0.0), où la même vérité du « un grand nombre, ce sont en réalité quelques grandes idées » se déploie sur toute la réécriture de v2. Pour le chapitre précédent de l''histoire de v1, comment diffuser un rapport en direct sans le scintillement (v1.6.13) ; et pour tout l''arc, l''anatomie d''une livraison logicielle jusqu''à la perfection.