Du processus manuel à l’outil fiable.

Murdeau fabrique en Bretagne, depuis 2009, un système breveté de récupération d’eau de pluie « modulaire & intelligent », des réservoirs aériens empilables, sans terrassement, durables et recyclables. « Pas de terrassement, pas de bitume à enlever », pour reprendre la phrase du site lui-même.

C’est un produit industriel structurellement complexe : trois modules de base, une modularité sans limite, des configurations qui dépendent de la surface de toiture, du volume d’eau visé, et de l’espace disponible chez le client. Les outils e-commerce généralistes sont inadaptés dès qu’on essaie d’exprimer « plusieurs configurations avec des géométries différentes » pour le même besoin.

J’ai travaillé onze ans chez Murdeau, de 2014 à 2026, en tant que développeur et designer, avant de lancer Horiot Studio. Je continue aujourd’hui à travailler pour eux comme partenaire externe, une relation de confiance construite sur la durée, avec une connaissance profonde du produit et de ses contraintes techniques.

Prochain chantier envisagé : une webapp en réalité augmentée pour placer une configuration à l’échelle dans son propre jardin, et rendre l’encombrement réel du système tangible avant l’achat.

Le site Murdeau existant ne tenait plus, ni la vitrine, ni la mécanique commerciale derrière. Un produit structurellement complexe (trois modules, une modularité sans limite, trois façons d’arriver à une configuration), et une équipe qui gérait l’inventaire, les commandes et le réseau de distributeurs à coups de tableurs et d’emails.

Le projet remplace le site par une plateforme complète : vitrine, configurateur propriétaire en volume, tunnel e-commerce Stripe et back-office métier, sur www.murdeau.bzh.

Le cœur du projet. Le configurateur ne part pas d’un catalogue à feuilleter, il part du problème du client. Par besoin : surface de toiture, pluviométrie, usages, et une « capacité recommandée avec justification ». Par volume cible : plusieurs géométries pour l’atteindre. Par contrainte d’espace : les solutions viables classées par capacité, et si rien ne rentre, il le dit.

Les trois modes convergent vers un builder 3D qui rend la configuration, calcule le prix, liste modules et accessoires, puis bascule vers le panier ou vers un devis pré-rempli selon la complexité du projet.

Une configuration s’étend sur trois axes, seuls ou combinés : en hauteur, en empilant les modules sur une colonne jusqu’à 3,90 m, en largeur et en profondeur, en disposant les colonnes en grille.

Sous le capot, le moteur encode les règles physiques du produit : socle 100 L obligatoire en pied de colonne, 1 600 L et 3,90 m maximum par colonne, toutes les colonnes à la même hauteur parce que l’eau s’équilibre entre modules connectés. Il explore les dispositions en grille, note chaque candidat, et déduit de la géométrie le nombre de kits de jonction nécessaires.

Pour les configurations standards, un checkout Stripe complet : paiement, facture, accusé de commande, date de livraison estimée. Pour les projets atypiques, un devis structuré, déjà pré-rempli avec la configuration retenue : la conversation commerciale reprend là où le configurateur s’est arrêté.

Côté Murdeau, un back-office unifié remplace les tableurs : inventaire par module avec alertes de seuil, commandes Stripe et devis signés dans une vue unique, distributeurs géolocalisés pour router chaque prospect vers le plus proche, et un tableau de bord d’activité. Le configurateur attire et qualifie, l’e-commerce encaisse, le back-office opère.

Le même principe, en version générique et ouverte à l’essai, est devenu le configurateur carport & pergola de l’atelier.

Murdeau tient en trois pièces : un socle de 100 L, un réservoir de 500 L et un réservoir de 250 L. La page produit en donne toutes les cotes, mais le visiteur doit encore imaginer le montage, et surtout ce qui se passe quand il pleut : les réservoirs communiquent, le niveau monte partout à la même hauteur, et le surplus repart dans la descente.

La page Découvrir montre tout cela au lieu de le décrire. Une seule scène 3D, la même installation du début à la fin, qui se construit et se remplit au fil du scroll.

Le socle arrive seul, ses cotes se tracent le long de traits bleus (1,21 m, 41 cm, 24 cm). Le 500 L s’emboîte dessus, le 250 L coiffe la colonne : 850 L sur 2,07 m. Six colonnes se rangent ensuite côte à côte, de 350 L sur 0,85 m à 1 600 L sur 3,90 m, avant que le mur s’allonge à cinq colonnes, 4 250 L sur 6,05 m.

Puis la lumière baisse, la caméra s’approche du collecteur posé sur la descente de gouttière. La poignée verte fait un demi-tour, la cartouche sort et montre son tamis inox, maille 1 mm, puis rentre. La pluie commence : les feuilles continuent dans la descente, l’eau propre part vers le réservoir.

Une seule colonne reçoit l’eau, et pourtant le niveau monte partout à la même hauteur. Il s’arrête juste sous la sortie du collecteur. Au-delà, la pluie continue simplement dans la descente : la conduite est ouverte en coupe et des reflets y défilent dans le sens de l’écoulement, du toit vers le réservoir tant qu’il se remplit, puis vers le pied de la descente une fois plein.

Les modules sont des modèles légers, de 50 à 230 Ko chacun, teintés dans le beige RAL 1015 de la gamme. Les trois pièces ont aussi été reconstruites dans Blender d’après les cotes publiées par Murdeau.

Le collecteur 3P suit la fiche du fabricant : 260 × 270 × 134 mm, sorties de 75, 50 et 32 mm. Corps, adaptateurs, réducteur et cartouche sont des pièces séparées. La poignée et le panier filtrant tournent et sortent ensemble, sur un pivot commun.

Le site tournait déjà avec React et un défilement doux : la page reste une route Next.js, avec React Three Fiber, plutôt qu’un second moteur de scroll qui se battrait avec le premier. La progression du scroll est lue une fois par image et pilote toute la chronologie, testée à part.

Sous l’histoire, un récapitulatif statique, rendu côté serveur, reprend les quatre pièces et leurs chiffres, six arguments déjà publiés sur le site, et le bouton « Composer mon Murdeau ». Avec les animations réduites, les reflets restent immobiles et le trop-plein apparaît d’un coup. La page est le premier lien du menu de murdeau.bzh.

L’app commerciale. Une PWA interne sur invitation, posée sur Next.js 15 et Cloudflare Workers, qui remplace un flux Excel, email et PDF à la main par un seul écran de travail : catalogue, partenaires aux tarifs différenciés par pays, commandes, confirmations PDF brandées, agenda des salons, statistiques. Trois rôles appliqués côté serveur (admin, sales, PR). Le MVP sert à l’équipe sur les salons, et les ajouts suivants sont venus de l’usage réel plutôt que du cahier des charges initial.

L’ensemble Shopify. Pas une section isolée mais un système de briques sur mesure qui vivent dans l’éditeur du thème : une page produit plus éditoriale, nourrie par les metafields, des modules frontend (badges de réassurance, footer de marque) et une section hotspots pour ancrer des points interactifs sur une image éditoriale de la montre.

Le lancement de la Chapter 4 · Tourbillon T.V.D.. Une page de révélation au scroll, en chapitres, sobre et premium, intégrée à l’écosystème de la marque pour être publiée et exploitée par l’équipe. En ligne sur ba111od.com.

Un outil métier, une boutique et une expérience de lancement, pour la même marque : c’est le genre de relation où l’on connaît le produit assez bien pour proposer avant qu’on demande, et où chaque chantier profite de ce que le précédent a appris.

BA111OD Sales est une Progressive Web App interne sur invitation, utilisée par l’équipe sur les salons horlogers pour préparer les commandes des détaillants, piloter l’agenda des salons et suivre l’activité. Équipe restreinte, desktop-first, interface en anglais.

Le point de départ : un catalogue complexe, des partenaires aux tarifs différenciés par pays, et des confirmations de commande produites à la main dans un flux Excel + email + PDF. Aucun outil du marché ne rentrait dans les contraintes sans compromis sur la personnalisation ou le coût.

Trois rôles appliqués côté serveur sur chaque route (admin, sales, et un rôle PR limité à l’agenda), pas d’inscription libre, aucune page commerciale exposée publiquement.

Le catalogue s’importe depuis un export CSV Shopify : prévisualisation, erreurs et warnings, puis synchronisation. Les SKUs absents sont désactivés, jamais supprimés, et les commandes passées restent intactes. Les fiches affichent le prix payable en CHF et le prix retail selon le pays du partenaire, avec recherche par SKU ou nom et filtres par chapitre.

Une commande peut être amorcée avant qu’un partenaire soit attribué, complétée plus tard, réouverte à tout moment. Elle sort en PDF brandé BA111OD, partageable directement depuis l’app.

Le PRD cadrait le MVP. Depuis, l’usage réel de l’équipe a fait émerger un second cercle, livré itérativement : un agenda salon en vue semaine (créneaux reprogrammables au drag-drop, statuts confirmé / à confirmer / no-show, couleurs par type de rendez-vous), des statistiques d’activité par période et par partenaire, et un onglet feedback avec changelog intégré et fil de notes partagé.

Les ajouts post-PRD viennent de l’usage, ce qui est, honnêtement, le meilleur indicateur qu’on a shippé la bonne première version.

Next.js 15 (App Router) en TypeScript, déployé sur Cloudflare Workers via OpenNext, Postgres managé pour les données, stockage objet pour les PDF. Les autorisations s’appliquent au plus près des données, pas seulement dans le code applicatif. Une revue de sécurité interne (code, déploiement, auth, dépendances) fait partie du cycle de livraison.

Chez BA111OD, le travail Shopify ne se limite pas à une seule section. Il s’agit d’un ensemble de briques sur mesure pensées pour faire évoluer l’expérience de marque directement dans le thème : page produit, modules éditoriaux, zones interactives.

Un socle Shopify plus cohérent. L’objectif était de sortir des blocs standards pour construire un langage plus aligné avec la marque, plus précis dans le rythme, et plus souple côté édition.

Des sections pensées pour durer. Chaque module est conçu pour vivre dans l’éditeur Shopify, être réutilisé, déplacé et ajusté sans repartir de zéro.

Une logique produit + contenu. Le travail ne porte pas seulement sur la fiche produit : il relie aussi les éléments éditoriaux autour de la montre, pour que l’expérience reste homogène d’une page à l’autre.

• Product section : refonte de la section produit principale, avec galerie, lecture des variantes et contenu enrichi
• Frontend sections : modules éditoriaux complémentaires pour prolonger l’identité BA111OD dans le thème
• Hotspots : section interactive permettant d’ancrer des points d’intérêt directement sur une image

Un ensemble Shopify plus mature, plus éditorial, et surtout plus cohérent, où les différentes sections peuvent fonctionner comme un vrai système plutôt que comme des blocs isolés.

La page produit demandait plus qu’un template e-commerce classique. Il fallait mieux présenter la montre, mieux hiérarchiser les informations, et donner à la lecture un rythme plus fidèle à l’univers BA111OD.

Une section produit repensée comme une vraie expérience. La composition articule galerie, panneau produit, variantes, contenu de marque et appels à l’action dans un ensemble plus maîtrisé.

Une lecture enrichie par les données produit. La section va chercher automatiquement le titre, les images, le prix, les variantes et plusieurs informations issues des metafields pour nourrir la page sans ressaisie.

Un contenu plus vivant. Spécifications en accordéons, produits liés, disponibilité, options de paiement, vidéo, description et barre CTA mobile : tout est pensé pour garder une page dense mais lisible.

La page produit n’est plus une simple fiche. Elle devient un espace qui vend mieux la montre, tout en restant administrable depuis Shopify.

Toutes les sections n’ont pas besoin d’être spectaculaires pour être utiles. Certaines ont un rôle plus discret : rassurer, signer, structurer une page, et prolonger l’identité de marque sans bruit.

Une barre de badges configurable. Un module léger pour faire remonter des messages de confiance, expédition, garantie, Swiss Made, retours, avec contrôle des couleurs, du texte et des espacements.

Un footer de marque éditorial. Une section minimale, centrée sur le nom BA111OD, encadrée par des lignes décoratives pour fermer une page avec plus de tenue visuelle.

Des briques simples à réutiliser. Ces modules sont faits pour s’insérer facilement dans le thème, être ajustés depuis l’éditeur, et renforcer la cohérence générale sans alourdir les pages.

Des sections frontend discrètes mais utiles, qui donnent plus de soin et de continuité à l’expérience BA111OD dans Shopify.

Pour le lancement de la Chapter 4 · Tourbillon T.V.D., l’objectif n’était pas seulement de publier une page produit. Il fallait créer une montée en tension, faire entrer la montre progressivement dans le champ, et donner à l’ensemble une présence plus éditoriale que promotionnelle.

Une expérience de révélation. La page accompagne la découverte au fil du scroll, avec un rythme plus proche d’un chapitre que d’un catalogue. On avance par séquences : matière, détails, calibre, caractère.

Une page pensée pour la marque. L’ensemble reste sobre, premium et lisible. L’animation soutient le regard au lieu de le distraire, pour laisser la montre et son univers visuel prendre toute la place.

Un format réellement activable. Le projet a été intégré dans l’écosystème BA111OD pour pouvoir vivre comme une vraie page de lancement, publiable et exploitable par l’équipe.

• Une narration en chapitres au scroll pensée comme une révélation progressive, pour installer la montre avec plus de présence et de tension.
• Des panneaux éditoriaux plein écran composés pour faire alterner image, respiration et messages clés dans un registre plus premium.
• Une expérience de lancement pleinement intégrée à l’univers de la marque, aujourd’hui en ligne comme une page signature BA111OD.

Une landing de lancement désormais en ligne, conçue pour donner plus de présence à la Chapter 4 et transformer la découverte du modèle en expérience de marque.

Une section Shopify sur mesure pour mettre en valeur des produits clés dans la boutique BA111OD. L’équipe marketing place des hotspots cliquables directement sur une image éditoriale de la montre ; chaque hotspot ouvre un tooltip avec un titre, une description et une image optionnelle.

La section telle qu’elle tourne en production, intégrée ici avec son vrai HTML, CSS et JS, extraits tels quels du thème Shopify.

Essayez :

• Cliquez sur un + → le tooltip s’ouvre, le bouton pivote vers ×
• Cliquez à nouveau, Esc, ou le bouton de fermeture → ça referme
• Bascule Desktop / Mobile : sur mobile, les tooltips passent en bottom sheet plein écran

Le schema de la section expose l’image de fond (desktop et mobile), la hauteur, la couleur d’accent, la couleur des icônes, et des blocs hotspot avec position en % (desktop et override mobile), titre, description et image de tooltip.

Le rendu utilise des custom properties CSS injectées par Liquid. Le JavaScript est vanilla, ~240 lignes, zéro librairie : event delegation, IntersectionObserver pour l’animation d’entrée staggerée, positionnement du tooltip qui préfère le dessous et bascule au-dessus s’il manque de place. Sous 600 px, même composant, même API, mais le tooltip devient une bottom sheet avec overlay sombre, géré en CSS et une poignée de branches JS.

Accessibilité : aria-expanded / aria-controls sur les paires bouton / tooltip, fermeture par Esc, retour de focus à la fermeture, prefers-reduced-motion désactive l’animation.

Une section activable depuis l’éditeur de thème, sans impact sur les performances du site. L’équipe marketing crée une page éditoriale, ajoute des hotspots, édite positions et contenus, sans intervention technique.

Un manifeste d’une page, en ligne sur atelier-des-choix.ch. L’enjeu n’était pas la quantité de pages mais le ton : un texte qui se lit comme une conversation posée, découpé en une dizaine de chapitres qui s’enchaînent. Les deux approches (coaching et mentoring), les étapes d’un accompagnement, les bénéfices, un « pour qui », une présentation de Daniela, une section pour les parents, le contact.

Le design assume le registre éditorial, titres en Instrument Serif, italiques colorées, larges respirations, une palette douce tirée de l’univers du cabinet. Une énergie « magazine » plutôt que « site de prestation ».

Chaque texte, chaque portrait et même les quatre couleurs de la palette sont éditables depuis une interface d’administration, sans toucher au code, avec un cycle brouillon, aperçu, publication et un guide en français. Astro pour le rendu, un CMS sur le edge Cloudflare pour le contenu. Daniela fait évoluer le site seule, c’était la condition du projet.

Daniela Leone accompagne des adolescents et de jeunes adultes à Neuchâtel. Son métier est fait d’écoute et de nuance, et son site devait l’être aussi : ni plaquette corporate, ni page de vente agressive, mais un texte qui se lit comme une conversation posée.

L’enjeu n’était pas la quantité de pages, c’était le ton. Une seule page, pensée comme un manifeste, qui déroule qui elle est, pour qui elle travaille, et comment se passe un accompagnement.

Tout vit sur une page unique, composée d’une dizaine de chapitres qui s’enchaînent : un hero éditorial, les deux approches (coaching et mentoring), les étapes d’un accompagnement, les bénéfices, un « pour qui », une présentation de Daniela, une section pour les parents, et le contact.

Le design assume le registre éditorial : titres en Instrument Serif, italiques colorées, larges respirations, une palette douce (crème, gris profond, vert sauge, rose) tirée de l’univers du cabinet. L’objectif visuel, une énergie « magazine » plutôt que « site de prestation ».

Chaque texte, chaque portrait, et même les quatre couleurs de la palette sont éditables par Daniela depuis une interface d’administration, sans toucher au code. Le contenu passe par un cycle brouillon, aperçu, publication, et un guide en français l’accompagne pas à pas. Le site lui appartient vraiment, elle le fait évoluer seule.

• Astro : rendu serveur du site, composition par chapitres
• EmDash : CMS, tout le contenu visible vient de l’admin
• Cloudflare Workers : runtime edge, avec D1 (base) et R2 (médias)

Un site qui ressemble à son métier : sobre, incarné, sans bruit. Une page unique qui pose une voix, et une cliente autonome pour la faire vivre dans le temps.

Provefab tourne comme un service sur un Mac. On pose l’étiquette provefab sur une issue GitHub, Provefab la prend en charge au passage suivant (toutes les trois minutes par défaut) et ouvre une pull request qui arrive au vert, relue par un second modèle, avec ses preuves. La pull request attend ensuite un clic humain.

Le code est écrit par des agents IA existants, Claude Code, Codex ou Pi, chacun par sa propre CLI non modifiée, connecté avec votre abonnement ou votre clé d’API. Jev, le classifieur de TypeSafe, évalue chaque issue (nature, difficulté, périmètre, risque de relecture) pour que chaque étape tourne sur le modèle le moins cher capable de la faire : d’abord les abonnements, puis les clés d’API par ordre de prix, avec des prix mis à jour chaque jour.

Tout ce qui tranche l’issue est du Rust déterministe : les checks du dépôt (formatage, lint, tests, vos propres commandes), le commit, le push et la pull request. Pendant l’implémentation, chaque appel d’outil de l’agent passe par un garde-fou. La relecture est confiée à un modèle d’un autre fournisseur que celui qui a écrit le code.

Provefab parle sur GitHub, dans des commentaires qui commencent toujours par « Posted by Provefab », et suit l’avancement par étiquettes : à faire, question posée, pull request ouverte, fusionnée, ou arrêtée avec la raison. L’étiquette est l’autorisation : c’est elle qui permet aux agents de passer du temps sur le texte d’une issue.

Le cœur est publié sous licence FSL. Une édition Pro ajoute un second relecteur, des politiques de fusion et des rapports de coût par dépôt et par modèle.

Le risque de l’IA dans le code n’est pas qu’elle écrive mal, c’est qu’on ne sache pas ce qui a été vérifié. Provefab tient une ligne simple : un modèle peut proposer, seul un contrôle déterministe peut accepter, et un humain garde le dernier clic. C’est la même discipline que j’applique aux outils livrés aux clients.

Vault Tools est une suite d’outils de traitement de fichiers qui tourne entièrement dans le navigateur : « Convert. Compress. Transform. All in Your Browser. »

La plupart des convertisseurs gratuits en ligne envoient vos fichiers sur un serveur tiers. Pour un avocat avec des pièces confidentielles, un designer avec des maquettes non publiées, un développeur avec des données sensibles, ce modèle est inacceptable. Vault Tools prend le contre-pied : vos fichiers ne quittent jamais votre machine.

WebAssembly comme moteur de traitement. Conversion d’images, fusion de PDF, génération de hash, parsing JSON, tout est compilé en WASM et s’exécute chez le visiteur. Aucun backend de traitement, aucun compte, aucun fichier téléversé. La promesse est architecturale, pas juridique : « Your files stay on your machine » se vérifie dans l’onglet réseau des DevTools, pas dans des CGU.

Plus de quarante outils en cinq catégories : image (conversion, compression, EXIF, favicon, filigrane…), PDF (fusion, division, réorganisation, métadonnées…), développeur (hash, QR, UUID, JWT, cron…), texte et données (JSON, CSV, Markdown, diff, regex…), fichiers (checksum, ZIP…). Gratuit, financé par de la publicité non intrusive : pas d’abonnement, pas de limite de taille, pas de paywall sur les exports.

Vault Tools incarne une position technique que je tiens : le traitement côté client est sous-utilisé. WebAssembly a rendu possibles des usages qu’on envoyait par réflexe sur des serveurs, par habitude, par flemme d’infrastructure, ou parce que les frameworks serveur-first rendent l’option invisible. Vault Tools est la démonstration qu’on peut faire beaucoup plus dans le navigateur que l’industrie ne le suggère.

Une proposition commerciale classique, c’est un PDF en pièce jointe. Il meurt dans une boîte mail : les retours éclatés dans un fil d’emails, les versions qui se confondent (proposition_v3_final_OK.pdf), le prix séparé du cadrage.

Ce système prend le contre-pied. Chaque prospect reçoit une URL et une passphrase, par des canaux séparés, et retrouve dans un espace privé le cadrage, le plan, le prix et parfois une démo, au même endroit. C’est l’étape 03 de mon approche, et un produit à part entière.

Une proposition de démonstration est ouverte, pour une maison de céramique fictive, Maison Verel : proposals.horiot.studio/demo, code d’accès atelier. Vous y verrez la gate, le contenu, les retours ancrés et le devis, exactement comme un prospect. La soumission des retours y est désactivée côté serveur ; l’interface reste entière.

Privé, réellement. Tant que l’accès n’est pas déverrouillé, le contenu n’est jamais sérialisé dans la réponse. Ce n’est pas un overlay sur une page déjà chargée : le serveur ne livre rien, et chaque endpoint sensible refait sa propre vérification.

Des retours au bon endroit. Le prospect commente une section ou une ligne du devis. Ses réponses sont persistées et pré-remplies à la visite suivante, chaque soumission me notifie, et je relis tout dans un espace d’administration séparé. L’itération se fait dans la proposition, pas dans un fil d’emails.

Versionné comme du code. Chaque publication est un instantané. Un prospect qui revient après une révision voit un bandeau « Mis à jour » et un diff de ce qui a changé ; ses retours restent épinglés à la version qu’il commentait.

Un devis, deux rendus, zéro dérive. Un seul bloc de pricing alimente le rendu à l’écran et le devis A4 en PDF, calculés par le même module. L’administration convertit ensuite un devis accepté en facture, sur la même numérotation que le reste de l’activité.

Ce système incarne une conviction : l’expérience commerciale fait partie du travail. Le soin qu’un prospect voit dans sa proposition est celui qu’il retrouvera dans son projet. Et c’est le cycle complet de l’atelier : un outil construit pour mon usage, éprouvé en conditions réelles, chaque proposition que j’envoie passe par lui.

linelapse ouvre un dépôt git et le montre comme une carte. Chaque dossier est une case dont la taille suit ses lignes de code vivantes et dont la couleur dit leur âge moyen, du jaune pour le code récent au violet pour le code ancien. Une frise permet de glisser sur toute l’histoire du dépôt. Sur le noyau Linux, cela représente 77 605 commits, de 2005 à 2026.

On y voit des dossiers naître, grossir et vieillir : le pilote graphique d’AMD qui devient le plus gros dossier de drivers/gpu, le Rust qui apparaît en jaune vif, des architectures qui virent au violet.

La provenance. Un panneau classe les sources des lignes à l’écran : l’arbre du mainteneur cité dans chaque merge (« netdev/net-next », « drm/drm »…), la branche fusionnée ou l’auteur d’un commit direct. Il se met à jour pendant la lecture. Un clic sur une source n’allume plus que son territoire, avec l’âge de ses propres lignes.

La demi-vie. Le temps au bout duquel la moitié des lignes écrites dans un dossier ont disparu, calculé avec l’estimateur de Kaplan-Meier. Une ligne de Linux a une demi-vie de 6,8 ans, une ligne de drivers/gpu de 14,6 ans.

Les langages. Une touche colore la carte par langage dominant : le Devicetree occupe les architectures ARM, la documentation et les données ressortent à part.

Rust, avec GPUI, le framework d’interface de l’éditeur Zed, qui dessine tout sur le GPU. L’indexeur lance un git log par cœur, donne à chaque ligne un commit de naissance et un commit de disparition, puis compresse ces événements. Sur Linux : 32 s d’indexation, un cache de 126 Mo, 120 images par seconde et un saut vers n’importe quel commit en moins de 0,3 ms.

Une commande compare l’index aux vrais fichiers de git : zéro écart sur 97 316 fichiers. Les vidéos se rendent hors écran, sans fenêtre, et l’outil se compile et se vérifie sous macOS comme sous Linux.

Avant d’écrire la moindre interface, j’ai mesuré ce qui pouvait tout arrêter : le coût d’un index ligne par ligne sur l’historique complet de Linux. Le prototype a répondu en quelques minutes, l’outil a suivi.

Construit avec des agents (Claude Code), encadré par des tests qui comparent chaque calcul à un recalcul exhaustif, une CI et des vérifications sous Linux. Le code est sous licence MIT.

L’atelier en direct affiche l’activité réelle d’Horiot Studio. Rien n’est mis en scène : un commit apparaît sur la page au moment où il est fait, une mise en ligne dans les cinq minutes.

Ces projets font partie de l’activité du studio, donc de la page. Ils apparaissent sous le nom « Projet confidentiel ». Les projets publics sur GitHub s’affichent sous leur vrai nom, et je peux rendre visible un projet privé quand il est prêt à être montré.

Le trajet d’un commit. Un hook git global, installé une fois sur ma machine, se déclenche à chaque commit, dans tous les dépôts. Il lance en arrière-plan un petit programme en Rust qui envoie le dépôt, le message et l’heure en HTTPS, avec un jeton. Le commit lui-même n’attend pas : 0,04 s mesurées. Le Worker vérifie l’auteur, enregistre le commit dans une base D1, puis un Durable Object le pousse par WebSocket aux pages ouvertes, déjà anonymisé.

Les autres sources. Une GitHub App reçoit les push signés de mes dépôts GitHub : elle confirme les commits et indique si un dépôt est public ou privé. Toutes les cinq minutes, une tâche planifiée lit en lecture seule les déploiements de production Cloudflare (Pages et Workers) : ce sont les mises en ligne. Au lancement, un import a repris les douze derniers mois.

L’anonymisation. Un projet s’affiche sous son nom s’il est public sur GitHub ou si je l’ai rendu visible. Tout le reste devient « Projet confidentiel », regroupé par jour. Ni le nom, ni le message, ni l’URL d’un projet confidentiel ne figurent dans la page, dans les infobulles ou dans le flux en direct : des tests le vérifient à chaque modification. Pour la même raison, une mise en ligne confidentielle n’affiche jamais de délai depuis la précédente, qui permettrait de relier deux livraisons.

Les choix. Un Worker plutôt qu’un conteneur : un conteneur endormi met une à trois secondes à répondre, et la plupart des visiteurs arrivent sur une page que personne n’a ouverte depuis un moment. Le rendu se fait côté serveur en Rust : la page arrive complète, le navigateur n’a rien à calculer. Le direct passe par un Durable Object, qui garde les connexions WebSocket ouvertes. Les polices sont hébergées par le Worker lui-même, sans service tiers.

Un jeu est le projet le moins raisonnable qu’on puisse montrer dans un portfolio, et c’est pour ça qu’il y est. Il faut une boucle complète, un état qui tient dans la durée, une interface qui se comprend sans notice, et de la finition. Chaque jeu ici a été construit autour d’une contrainte technique choisie à l’avance, puis fini.

Cold Star. Un jeu incrémental de science-fiction dans la filiation d’A Dark Room : on ranime un réacteur, on bâtit une station, on part vers une galaxie générée. Rust compilé en WebAssembly, avec un moteur pur et déterministe comme invariant central.

Orbit Hop. Un tap : le vaisseau quitte son orbite et doit se poser sur la planète suivante. Une partie du jour partagée par tout le monde, trois essais, un mode sans fin. Un seul fichier HTML, sans build ni dépendance, jouable depuis l’écran d’accueil du téléphone.

Les deux vont à l’opposé l’un de l’autre : un workspace Rust strictement découpé d’un côté, quarante kilo-octets de canvas de l’autre. Ce qui se retrouve dans les deux, c’est la méthode : séparer la simulation de l’affichage, rendre chaque partie reproductible, et livrer quelque chose de fini plutôt qu’un prototype.

Cold Star est un jeu incrémental minimaliste qui tourne entièrement dans le navigateur. Le pitch, repris du dépôt : « A minimalist sci-fi incremental game about a small light in a very large dark, and the cost of keeping it lit. »

On se réveille sans énergie dans le noir de l’espace. On ranime un réacteur défaillant, on rassemble un équipage, on bâtit une station, puis un vaisseau, et on part vers une galaxie générée procéduralement : seize systèmes, des surfaces planétaires, des contacts qu’on peut héler, négocier ou affronter. Trois origines convergent en milieu de partie, chacune vers plusieurs fins. « It starts as a single button in the dark. It ends as a galaxy. »

Le jeu s’inscrit dans la filiation d’A Dark Room : un récit porté par la divulgation progressive de l’interface, presque sans exposition. L’instrument se réchauffe à mesure qu’on le ranime : sa couleur et sa chaleur sont de l’état de jeu réel, pas de la décoration.

Rust compilé en WebAssembly, rendu avec Dioxus, dans un workspace à séparation stricte : sim, le moteur pur et déterministe, sans I/O ni unsafe ; content, les données de jeu validées en fichiers RON ; app, une vue en lecture seule au-dessus de l’état.

L’invariant central : advance(n) == n × advance(1). Avancer d’un tick ou de mille produit exactement le même état. C’est ce qui rend triviaux les sauvegardes par instantané, les liens de partage encodés en base64 et le rattrapage hors-ligne.

Cold Star pousse à l’extrême une conviction technique : une simulation pure et déterministe paie ses dividendes partout. C’est aussi un terrain où éprouver Rust → WASM sur un produit fini, interactif et stateful, une boucle de jeu complète plutôt qu’une API sans état.

Le jeu est feature-complete pour l’arc qu’il dessine, et volontairement ouvert à l’extension : contenu, équilibrage, rencontres, polish.

Le vaisseau tourne autour d’une planète. Un tap le libère le long de la tangente ; s’il traverse la bande de capture de la planète suivante, il se met en orbite et on recommence. Passer près du centre donne un PERFECT et fait monter la série. Rater, c’est partir dans le vide.

C’est un jeu de timing, pas de réflexes : la ligne s’allume quand l’angle est bon, et tout le reste consiste à ne pas se précipiter.

• La partie du jour : les mêmes planètes pour tout le monde, trois essais, puis un résumé en emojis à partager, comme un Wordle spatial.
• Le mode sans fin : planètes aléatoires, un seul objectif, battre son record.
• Sur l’écran d’accueil : le jeu s’installe comme une application depuis Safari ou Chrome et se lance plein écran.

Tout le jeu tient dans un fichier HTML d’une quarantaine de kilo-octets : le rendu sur canvas, la physique des orbites, les menus, le partage. Pas de framework, pas d’étape de build, pas de dépendance ; le déploiement est une copie sur Cloudflare Pages.

La partie du jour découle d’une graine dérivée de la date, donc la suite de planètes est identique pour chaque joueur sans serveur ni compte. Les réglages (bande de capture, vitesse d’orbite, cadence des planètes) ont été ajustés par des séries de parties jouées en headless, avec les décisions notées à chaque tour.

Orbit Hop est le contrepoint de Cold Star : la même exigence de finition, avec la contrainte inverse. Là où Cold Star découpe un workspace Rust en trois crates, ici tout doit tenir dans une page, et rester agréable au pouce.

Un marché financier est une source de données exigeante : des millions d’événements par séance, dans un ordre qui compte, avec des pièges à chaque ligne. C’est un bon terrain pour éprouver ce qu’un outil de données doit garantir : ne jamais réordonner en silence, rejouer à l’identique, dire clairement ce qu’il ne sait pas.

QuantLab. Une plateforme Rust et Python qui rejoue un carnet d’ordres événement par événement, simule l’exécution d’ordres avec latence et file d’attente, et confie les statistiques à Python. Deux exécutions identiques produisent la même empreinte.

Riptide. Un terminal Rust branché sur Binance Futures : carnet d’ordres reconstruit en direct, ruban des transactions, métriques de flux et cinq types d’alertes, avec un panneau de stratégie en paper trading.

Les mêmes exigences valent pour un tableau de bord d’entreprise : une donnée qu’on peut rejouer et auditer vaut mieux qu’un chiffre qu’on doit croire sur parole.

QuantLab est une plateforme de recherche hybride Rust et Python. Elle rejoue des données de marché au niveau de l’ordre individuel (flux MBO de Databento), reconstruit le carnet file d’attente par file d’attente, en tire des indicateurs de microstructure et simule l’exécution d’ordres. Python prend ensuite le relais pour les statistiques, les modèles simples et les graphiques.

Le moteur Rust est la source de vérité : ordre des événements, état du carnet, indicateurs, exécutions simulées. Python ne consomme que des fichiers CSV stables.

Le moteur ne trie jamais les données en silence : il traite l’ordre du fichier et rejette par défaut tout recul d’horodatage ou de séquence. Les indicateurs ne sont émis qu’à la fin d’un événement complet. Deux exécutions sur les mêmes données, avec la même configuration, produisent la même empreinte, vérifiable dans le résumé de sortie. Les découpages de recherche sont chronologiques : on ne mélange jamais le temps.

La simulation d’exécution tient compte de la latence, de la profondeur consommée, de la file d’attente devant l’ordre, des exécutions partielles et des frais. Les icebergs sont détectés sur des indices observables et étiquetés pour ce qu’ils sont : possibles, pas certains.

Les captures montrent le tableau de bord de recherche local sur le contrat NQ, en février 2026, sur un échantillon de 19 séances.

QuantLab pousse la conviction de Cold Star sur un terrain plus exigeant : un moteur déterministe qu’on peut rejouer paie ses dividendes partout. Sur des données de marché, c’est la différence entre un résultat et une coïncidence.

Riptide se branche sur Binance Futures, reconstruit le carnet d’ordres complet et affiche tout dans le terminal : le carnet et ses barres de profondeur, le ruban des transactions, les métriques de flux (CVD, delta sur 1, 5 et 15 minutes, déséquilibre, VWAP) et deux histogrammes à la minute.

Le carnet est synchronisé comme Binance le demande : les mises à jour sont mises en tampon, un instantané est chargé, puis chaque mise à jour doit prolonger exactement la précédente. Au moindre trou dans la séquence, Riptide se reconnecte plutôt que d’afficher un carnet faux.

Riptide signale en temps réel les transactions anormalement grosses, les murs d’absorption (un ordre posé qui encaisse plus de deux fois sa taille), les icebergs (un niveau qui se recharge avec une taille proche en moins de 500 ms), les divergences entre prix et flux net, et les bascules rapides du déséquilibre du carnet.

Un panneau de stratégie tourne en paper trading : il évalue des conditions d’entrée, affiche pourquoi il ne prend pas position et simule les positions sans jamais passer d’ordre réel. Un second programme rejoue une session enregistrée de façon déterministe, à partir des alertes et du ruban.

Riptide est la version temps réel de la question que pose QuantLab : que dit vraiment le carnet ? Quand Binance a scindé ses flux, celui des transactions s’est tu, sans erreur. Le correctif ouvre un flux par source et traite la fermeture de l’un comme une panne de l’ensemble. Un outil de données doit échouer bruyamment, jamais en silence.

Arête, sur arete.horiot.studio, est la plus complète : une maison horlogère fictive avec sa vitrine, son configurateur 3D, la réservation d’une pièce, et derrière, l’Atelier, l’outil de l’équipe commerciale (commandes, distributeurs, prospects, agenda salon). Un seul catalogue alimente le site et les commerciaux.

Chaque démo est un produit générique et fonctionnel, sous ma propre marque : le client final configure son produit en 3D, voit un prix indicatif, et le fabricant recevrait une demande qualifiée avec le plan coté. Les catalogues et les prix sont fictifs mais cohérents ; tout s’adapte ensuite aux gammes, aux tarifs et à la charte de l’entreprise. Rien ne part quand on clique sur « Envoyer ma demande » : un panneau montre ce que le fabricant recevrait. La boutique e-commerce suit le même principe avec un panier et une commande simulés à la place de la demande de devis.

Carport et pergola. Le premier de la série : 3D et plan technique dans la même fenêtre, zones de neige par code postal.

Portail et clôture. Portail, portillon et clôture assortis, le portail s’ouvre en 3D, motifs de découpe laser.

Cave à vin enterrée. Coupe 3D sous la maison, visite de l’intérieur, réservation de dalle sur le plan.

Escalier sur mesure. Droit, quart tournant ou hélicoïdal, contrôle de trémie et d’échappée, montée à la première personne.

Piscine conteneur. Hors-sol, semi-enterrée ou enterrée dans le jardin, fiche chantier avec formalités, taxe et grutage.

Boutique e-commerce. Fauteuil, t-shirt et bague configurables en 3D, panier simulé, visuel téléchargeable et widget à intégrer sur une boutique existante.

Un configurateur se juge sur du concret, pas sur une promesse. Six métiers, six vocabulaires, six géométries : la même méthode à chaque fois (un domaine pur et testé, des rendus qui lisent la même source, un prix en fonction pure), et la preuve qu’elle tient sur des produits très différents.

Quand j’écris à un fabricant de carports ou de pergolas que je ne connais pas, je peux décrire un configurateur, ou lui en mettre un entre les mains. Cette démo est le second choix.

C’est un produit générique, fonctionnel, sous ma propre marque : le client final configure son abri, voit un prix indicatif, et le fabricant reçoit une demande qualifiée avec le plan. Tout s’adapte ensuite au catalogue, aux tarifs et à la charte de l’entreprise. demos.horiot.studio regroupe ces produits à essayer ; celui-ci a été le premier, quatre autres ont suivi (voir les démos).

Six étapes en accordéon, toutes modifiables, aucune impasse. À tester en particulier :

• 3D ou Plan : le plan technique (élévation, vue de dessus, cotes, cartouche) est un second rendu à part entière, pas une 3D au rabais.
• Le code postal : il affiche la zone de neige du département (NF EN 1991-1-3/NA), à titre indicatif.
• Envoyer ma demande : rien ne part. Un panneau montre ce que le fabricant recevrait, configuration, prix, plan et coordonnées.

Un module de géométrie pur transforme la configuration en primitives (poteaux, poutres, chevrons, toiture, lames, cotes). C’est le seul contrat que connaissent les deux rendus : la 3D et le plan lisent les mêmes positions, ils ne peuvent pas se contredire. La 3D (Three.js) n’est chargée qu’à la première activation ; le plan est du SVG pur.

Le prix suit la même logique : une fonction pure, des montants fictifs mais cohérents, détaillés ligne par ligne. Brancher le vrai catalogue d’un fabricant revient à remplacer une table de tarifs. La configuration vit dans l’URL sous forme d’un hash court, partageable par email. Le site est entièrement pré-rendu, sans code serveur ; le jour où un prospect veut un pilote réel, l’envoi vers sa boîte mail ou son CRM est à un fichier de distance.

Le configurateur Murdeau m’a appris ce qu’un configurateur doit faire pour vendre : partir de la question du visiteur, donner un prix tout de suite, livrer à l’entreprise une demande qu’elle peut traiter. Cette démo en est la version générique, pour un métier qui a le même besoin. Elle applique le principe de la maison à la prospection elle-même : on décide sur du concret, pas sur une description.

Tout commence par la vitrine, qui se lit comme un film. On part du Weisshorn à 5 650 m, l’altitude défile, les courbes de niveau apparaissent, puis la montagne se pose sur le fond de la montre : ses courbes réelles, relevé swissALTI3D, gravées à 55 microns. La caméra glisse ensuite sur la carrure et le cadran, jusqu’à l’invitation à composer sa propre Cabane.

Le visiteur compose alors sa pièce : finition, cadran, lunette, bracelet, gravure. Chaque choix redessine la montre en 3D et le prix suit. La configuration tient dans un lien, à partager ou à rouvrir, et se termine par une réservation qui nomme la pièce exacte.

Pour une pièce que le configurateur ne propose pas, le client ouvre un dossier sur mesure : un brief guidé, repris de sa configuration, avec ses images de référence. Il suit ensuite son dossier sur une page à lui, valide la proposition de la maison et verse l’acompte, ou demande une modification.

La réservation prend sa place dans la file d’attente de l’Atelier, une PWA pensée pour la tablette d’un commercial en salon : commandes et bon imprimable, distributeurs, allocation de la saison entre leurs quotas et la liste d’attente des clients directs, pipeline de prospects, agenda des rendez-vous et de la presse, chiffres de la saison, et les dossiers sur mesure, que l’équipe chiffre et annote sur une planche face et fond. Deux rôles, commerciale et presse, chacun ne voit que son périmètre.

• Notes du studio : activez-les dans la barre du haut, elles expliquent à chaque écran ce qui est en jeu pour une marque.
• Le passage de relais : réservez une pièce, la confirmation vous donne votre vraie place dans la file ; ouvrez l’Atelier, votre réservation y attend son tour, et « Simuler un désistement » fait avancer la file.
• La tablette : sur ordinateur, l’Atelier peut s’ouvrir dans un cadre tablette ; il s’installe aussi comme une application.
• Le sur mesure : envoyez un brief depuis le configurateur, répondez-y dans l’Atelier avec une planche annotée, puis validez la proposition côté client.

La maison, ses revendeurs et ses chiffres sont fictifs, et rien ne quitte votre navigateur. Tout s’adapte à la collection, aux tarifs et à la charte d’une marque, comme les autres démos.