Journal technique

Journal technique — preuve de travail

Les clients n’achètent pas seulement du code — ils achètent votre capacité à démêler des problèmes difficiles. Cette page est mon journal d’ingénierie public : contraintes réelles, essais infructueux, et ce qui a vraiment fait avancer le projet. (The Hacking Project / THP fait partie de la façon dont j’affine ce métier.)

Mis à jour avril 2026 · Nouvelles entrées au fil des livraisons

Chaque article est rédigé en deux versions (FR/EN) dans le HTML ; l’affichage suit la langue du site.

Les pages satellites n’avaient pas de sélecteur de langue — le correctif

Callisto · Front / i18n · avril 2026

Contexte. L’accueil du portfolio utilise un modèle i18n hybride (français dans le HTML, i18n.json pour l’anglais, langue stockée dans localStorage). Les pages journal, services et mentions reprenaient la même barre visuellement mais sans script.js et sans sélecteur FR/EN. Si vous aviez choisi l’anglais sur l’accueil, le clic sur « Journal technique » ouvrait une coquille uniquement en anglais, sans retour vers le français dans l’interface — déroutant.

Ce qui posait problème

L’état de langue ne vivait que là où script.js s’exécutait (index.html principal), pas sur les routes secondaires.
updateDocumentTitleFromI18n pouvait écraser les titres des pages satellites avec le méta-titre de l’accueil — autre aspérité.

Ce que j’ai changé

Charger le même script.js sur build-log.html, services.html et mentions-legales.html, avec les liens de nav et le pied de page en data-i18n comme l’accueil, plus le sélecteur FR/EN.
Ajout de clés dans i18n.json (nav.home, nav.toggleAria, subpage.backToHome) et incrément du paramètre de cache JSON.
Limitation des mises à jour du titre document à l’accueil (présence de #heroSlides) pour que « Build Log | … » reste correct.

Résultat

Les visiteurs gardent une préférence de langue cohérente sur le site statique ; la navigation et le chrome suivent FR/EN comme partout ailleurs.

Enseignement. Si vous persistez la langue d’interface côté client, chaque route HTML qui partage le chrome doit charger le même bootstrap — sinon vous livrez une porte piégée.

Callisto · Front / i18n · April 2026

Context. The portfolio home uses a hybrid i18n model (French in HTML, i18n.json for English, language stored in localStorage). The journal, services, and legal pages reused the same nav visually but shipped without script.js and without the FR/EN control. If you had chosen English on the home page, clicking “Journal technique” landed you on an English-only shell with no way back to French from the UI — confusing and easy to mistake for “the whole site is EN only”.

What was going wrong

Language state lived only where script.js ran (main index.html), not on secondary routes.
updateDocumentTitleFromI18n could overwrite satellite page titles with the home meta title when i18n applied — another rough edge.

What I changed

Load the same script.js on build-log.html, services.html, and mentions-legales.html, with nav links and footer wired through data-i18n like the home page, plus the FR/EN switch.
Added keys in i18n.json (nav.home, nav.toggleAria, subpage.backToHome) and bumped the JSON cache query string.
Restricted document-title updates from i18n to the home page (presence of #heroSlides) so “Build Log | …” stays correct.

Result

Users keep one consistent language preference across the static site; navigation and chrome follow FR/EN everywhere (including full article bodies in both languages on this page).

Takeaway. If you persist UI language client-side, every top-level HTML route that shares chrome must load the same bootstrap — or you ship a trap door.

D’environ 5 s à ~1 s sur un appel API type OpenAI

Callisto · THP / backend · mars 2026

Contexte. Une petite fonctionnalité devait s’appuyer sur un modèle de langage pour classifier l’intention utilisateur avant d’enchaîner une logique plus lourde. La première version était « simple » : un appel HTTP, attendre la complétion complète, puis bifurquer. En pratique, la latence perçue tournait autour de cinq secondes — inacceptable pour un flux interactif.

Ce qui posait problème

J’attendais un JSON de complétion complète avant toute action dans l’interface — pas de streaming, pas de sortie anticipée quand la confiance était déjà suffisante.
Le prompt emportait du contexte redondant à chaque requête (instructions statiques répétées au lieu d’être mises en cache ou raccourcies).
Le travail en aval s’exécutait en série après le retour du LLM : le chronomètre continuait même une fois la partie modèle terminée.

Ce que j’ai changé

Passage au mode streaming de l’API et lecture du premier libellé à forte confiance à partir de jetons partiels — assez pour enchaîner sans attendre le dernier octet.
Instructions système stables regroupées dans un gabarit minimal et exemples réduits au strict nécessaire (few-shot, pas un manuel).
Là où la stack le permettait, E/S indépendantes en parallèle après la première fenêtre de jetons (ex. préchargement selon l’intention prédite).

Résultat

Le temps de bout en bout du « happy path » est descendu à environ une seconde en conditions typiques — pas de magie : mesurer, supprimer les attentes inutiles, refuser de bloquer l’UI sur une complétion complète quand un signal partiel suffit.

Enseignement. La maturité technique, ce n’est pas seulement connaître les API — c’est savoir lire la latence, remettre en cause les habitudes séquentielles, et livrer des correctifs incrémentaux que l’on peut prouver avec des chiffres.

Callisto · THP / backend focus · March 2026

Context. A small feature needed a language model to classify user intent before running heavier logic. The first version was “simple”: one HTTP call, wait for the full completion, then branch. In practice, perceived latency hovered around five seconds — unacceptable for an interactive flow.

What was going wrong

I was waiting for a full completion JSON before doing anything in the UI — no streaming, no early exit when confidence was already high enough.
The prompt carried redundant context on every request (static instructions repeated instead of cached or shortened).
Downstream work ran sequentially after the LLM returned, so the clock kept running even when the model part was done.

What I changed

Switched to the API’s streaming mode and parsed the first high-confidence label from partial tokens — enough to trigger the next step without waiting for the last byte.
Moved stable system instructions to a minimal template and stripped examples to what the classifier actually needed (few-shot, not a manual).
Where the stack allowed it, ran independent I/O in parallel after the first token window (e.g. prefetching data keyed by predicted intent).

Result

End-to-end time for the “happy path” dropped to about one second in typical conditions — not magic, just measuring, cutting wasted waits, and refusing to block the UI on a full completion when a partial signal is enough.

Takeaway. Seniority isn’t only knowing APIs — it’s knowing how to read latency, question sequential habits, and ship incremental fixes you can prove with numbers.

← Retour à l'accueil