Threads X hebdomadaires — ProbatioVault¶
Thread epingle — Index¶
Je partage chaque semaine un fil technique sur mon usage de l'IA en prod.
Pas de hype, du code, des mesures, des retours concrets.
Voici les fils publies :
===
1/ Le cerveau positronique — des guardrails architecturaux pour Claude Code (hooks UserPromptSubmit) https://x.com/2geek4you1/status/2023033966694154397
===
2/ FAISS + Ollama — recherche semantique de contexte pour agents (embeddings locaux, zero cloud) https://x.com/2geek4you1/status/2025179921568395284
===
3/ J'ai arrete d'utiliser les LLM pour juger les LLM — verdict deterministe vs LLM-as-Judge https://x.com/2geek4you1/status/2028447587846508721
===
4/ Partager 200 000 photos avec ma famille — pipeline Lightroom Classic → galerie self-hosted https://x.com/2geek4you1/status/2030330450812526929
===
5/ Mon IA rapproche mes factures automatiquement — Apple Mail + embeddings + Fizen + scoring deterministe https://x.com/2geek4you1/status/2032731472587579673
===
6/ 111 stories, 7 repos, 0 humain dans la boucle — workflow de gouvernance IA complet en 11 etapes https://x.com/2geek4you1/status/2038263293635092934
===
7/ One Ring — je pilote 3 workflows IA en parallele depuis mon iPhone via Signal https://x.com/2geek4you1/status/2040323352674402308
===
8/ Prolog detecte un bug dormant entre app et backend — l'IA rend les methodes formelles accessibles a tous les projets https://x.com/2geek4you1/status/2043252967235547639
===
9/ Comment j'ai perdu une soiree — je voulais dejeuner chez mon voisin, le LLM m'a propose de construire une fusee pour m'y rendre https://x.com/2geek4you1/status/2045599227468710097
===
10/ Mon IA pilote une migration d'entreprise — pas le code, le projet https://x.com/2geek4you1/status/2050203949001474446
===
11/ 112 commits, 0 feature — IP iteration appliquee au dev assiste par IA, dette transverse et consolidation volontaire
===
Je mettrai ce fil a jour au fur et a mesure. Follow pour la suite.
Thread #1 — Le cerveau positronique (hooks Claude Code)¶
Date : Semaine 1 Theme : Guardrails architecturaux via UserPromptSubmit hooks
Je vous parle beaucoup d'IA ces derniers temps, mais je partage peu de code concret.
Aujourd'hui, un petit detail de Claude Code que je n'ai pas vu dans les tutos qui circulent sur X.
C'est pourtant une fonctionnalite puissante pour fiabiliser vos agents. 🧵👇
===
🎯 Vous voulez imposer une regle inviolable a Claude.
Exemple : "Ne jamais supprimer de fichiers sans confirmation explicite."
Comment garantir que cette regle sera TOUJOURS respectee, meme apres 100 messages ?
3 approches, 3 niveaux de robustesse.
===
📌 Option 1 : Rappeler la regle en debut de session
"Rappel : ne jamais supprimer de fichiers sans confirmation."
Problemes : → Dilution : la regle perd son influence au fil des echanges → Compression : sur les tres longues sessions, elle peut etre resumee... et perdue
===
📌 Option 2 : Mettre la regle dans CLAUDE.md (system prompt)
Avantage : le system prompt n'est jamais compresse. La regle est preservee.
Probleme : la dilution persiste. Au message 100, la regle est toujours la mais "loin" du contexte actif. Son influence diminue.
===
💡 Option 3 : Le cerveau positronique
Inspiration : Isaac Asimov. Dans ses romans, les robots ont des regles si profondement ancrees qu'ils ne peuvent physiquement pas les violer.
Objectif : reproduire ce comportement. Des regles ARCHITECTURALES, pas optionnelles.
===
🔧 Implementation : le hook UserPromptSubmit de Claude Code.
Ce hook s'execute a CHAQUE message utilisateur, AVANT que Claude ne reflechisse.
Il injecte vos regles critiques dans le TOUR ACTUEL — celui que Claude traite maintenant. Pas dans l'historique. Dans le present.
===
Pourquoi c'est robuste :
✅ Anti-dilution → regles toujours "proches" car reinjectees a chaque tour ✅ Anti-compression → le tour actuel n'est jamais compresse ✅ Independant → execute par le systeme, pas par Claude
Guardrails architecturaux. 🛡️
===
⚙️ Configuration (.claude/settings.json) :
{
"hooks": {
"UserPromptSubmit": [{
"hooks": [{
"type": "command",
"command": "cat RULES.md"
}]
}]
}
}
UserPromptSubmit = declenche a chaque message utilisateur, avant traitement.
===
📄 Resume :
- .claude/settings.json → hook sur UserPromptSubmit
- RULES.md → vos regles critiques (~150 tokens)
- A chaque message, le hook injecte RULES.md
Cout : ~150 tokens/message. Negligeable pour des guardrails inviolables.
===
📚 Documentation Claude Code Hooks : docs.anthropic.com/en/docs/claude…
Les hooks transforment Claude d'un assistant qui "essaie" de suivre les regles en un systeme ou les regles sont ARCHITECTURALEMENT garanties.
C'est la difference entre prompting et engineering. 🛡️
Thread #2 — FAISS + Ollama (recherche semantique de contexte)¶
Date : Semaine 2 Theme : Donner le bon contexte a un agent via embeddings vectoriels
Nouveau fil IA, plus technique que la semaine derniere…
🧵 Comment donner le bon contexte a un agent ?
Sur un projet de 100+ user stories, l'agent doit trouver les 5 stories connexes pertinentes pour sa tache.
Le defi : ni trop (noyade), ni trop peu (hallucinations).
Fil 👇
===
Les contraintes :
• 100+ stories × 10 pages de specs = impossible a tout charger • Meme avec des contextes tres larges, l'info importante serait noyee
Objectif : contexte minimum et suffisant
===
Solution naive + echec
Premiere idee : grep par mots-cles ?
❌ "auth" → 40 resultats (MFA, sessions, RBAC...) ❌ "validation" → 35 resultats (Zod, Yup, formulaires...)
Le grep textuel rate les synonymes et concepts proches.
===
Solution : recherche semantique par embeddings
- Vectoriser chaque story
- Comparer la similarite geometrique (k-NN)
- Retourner les top 5 les plus proches
Dans nos cas : trouve "authentification biometrique" meme avec query "securite login"
===
Stack technique
• Ollama local (MacBook) + nomic-embed-text (768 dims) • FAISS (indexation vectorielle, 160 stories) • < 2s pour generer top 5 en local sur MacBook
Pas de GPU server necessaire. Zero dependance cloud.
===
Workflow :
- Indexation : 160 stories → 160 vecteurs (768 dims)
- Query : "migration donnees RGPD" → vecteur
- k-NN search : top 5 stories similaires
- Injection contexte agent
L'agent recoit uniquement ce qui compte.
===
Exemple reel :
Query : "Validation double signature mineurs"
✅ Retourne PD-82 (PRE double validation) ✅ Retourne PD-240 (RGPD mineurs)
Un grep "validation" aurait noye dans 35 resultats non pertinents.
===
Impact (mesure sur ~20 sprints) :
• Dependances oubliees nettement reduites • Agents mieux informes = code coherent • Contexte pertinent sans saturation
Le resultat : bon contexte → moins d'erreurs.
Thread #3 — J'ai arrete d'utiliser les LLM pour juger les LLM¶
Date : Semaine 3 Theme : Verdict deterministe vs LLM-as-Judge
J'utilisais un LLM pour juger les outputs de mes autres LLM. Le fameux "LLM-as-Judge".
J'ai fini par enlever cette brique pour mes quality gates de prod.
Petit retour d'experience. 🧵
===
Mes agents IA produisent specs, plans, code. A chaque etape, une quality gate decide GO ou NON_CONFORME.
Au debut, un LLM rendait ce verdict. Pas tres stable : meme input, verdict different. Le ton du prompt jouait. Et ca arrondissait souvent les angles.
===
Avec le temps, j'ai realise qu'on melangeait deux choses :
L'analyse : identifier des ecarts, classer des severites. La, un LLM m'aide vraiment.
La decision : GO ou NON_CONFORME. Pour une gate bloquante, je prefere que ca repose sur une regle fixe.
===
Du coup, j'ai separe les roles :
P1 : Un LLM identifie les ecarts (BLOQUANT, MAJEUR, MINEUR) P2 : Un 2eme LLM confronte l'analyse P3 : Synthese structuree P4 : Un petit script Python rend le verdict final.
===
La logique tient en ~50 lignes :
Base = 10 -2 par BLOQUANT -1 par MAJEUR -0.25 par MINEUR
Tous >= 8 → GO Moyenne >= 7, un < 8 → RESERVE Moyenne < 7 ou un < 6 → NON_CONFORME
Ce n'est pas "plus intelligent". C'est juste plus previsible.
===
Autre truc que ca a regle : les boucles infinies.
Avant : l'agent corrige, le LLM re-evalue, les scores bougent un peu, puis ca peut repartir pour un tour.
Maintenant, si le delta entre 2 iterations est nul, j'escalade. Max 3 tours.
===
L'image la plus simple que j'ai trouvee :
On demande pas a un thermometre de decider s'il faut allumer le chauffage.
Le thermometre mesure. Le thermostat decide.
LLM = thermometre. Script = thermostat.
===
~160 stories en prod avec ce setup.
Depuis, j'ai des verdicts plus faciles a relire, moins de boucles, et un YAML trace pour chaque decision.
50 lignes de Python. Rien de sorcier, et c'est justement le point.
===
Si vous utilisez des LLM en prod, mon retour c'est : laissez-les analyser.
Et si vous avez une decision critique a prendre derriere, une regle deterministe alimentee par cette analyse peut etre plus confortable a exploiter.
En tout cas, chez moi, ca marche mieux comme ca.
Thread #4 — Partager 200 000 photos avec ma famille (sans leur donner Lightroom)¶
Date : Semaine 4 Theme : Pipeline self-hosted Lightroom Classic → galerie familiale via bridge JSON
J'ai 200 000 photos dans Lightroom Classic.
Ma famille voulait y acceder. Sans installer Lightroom. Sans payer d'abonnement. Depuis leur telephone.
J'ai construit un pipeline qui exporte tout vers une galerie self-hosted. Open source. 🧵
===
Chez moi, la galerie c'est Immich (self-hosted, sur mon NAS). Mais le pipeline n'a rien de specifique a Immich.
Il produit des JPEG et les copie sur un montage reseau. Derriere, ca peut etre Immich, Photoprism, Synology Photos, ou un simple dossier partage.
===
Je veux que ma famille voie les versions retouchees. Et si je retouche une photo plus tard, que le JPEG partage se mette a jour. Sans doublon.
Le plus simple : tout passer par l'export Lightroom. Chaque photo produit un seul JPEG, toujours a jour.
===
Sauf que Lightroom embarque Lua 5.1 dans un sandbox tres restreint. Pas de SQLite, pas de reseau, pas de binding natif.
Pour faire communiquer un worker Python et le plugin LR, on a opte pour un bridge JSON : des fichiers echanges dans un repertoire partage.
===
Le worker Python surveille les modifications, ecrit la liste des exports a faire.
Le plugin LR lit cette liste, trouve la photo dans le catalogue, exporte en JPEG, ecrit le resultat.
Le worker recupere les JPEG et les copie vers le NAS.
===
Chaque photo suit une machine d'etats :
PENDING → RENDERING → RENDERED → SYNCED → DONE
Le NAS tombe ? Les photos s'accumulent en attente et la copie reprend quand le montage revient. Aucune intervention.
===
En pratique : Lightroom exporte ~1 photo/seconde (c'est sa limite, mono-thread).
200 000 photos = ~55h. Le pipeline tourne en arriere-plan, reprend apres un reboot, et avance tout seul.
Ma famille a deja acces aux premieres photos pendant que le reste s'exporte.
===
Le projet est open source (Unlicense — domaine public) :
gitlab.com/phydya-oss/lr-immich-sync
Si vous avez un workflow Lightroom + NAS + galerie photo, ca peut vous servir. Et les MR sont ouvertes.
Thread #5 — Mon IA rapproche mes factures automatiquement¶
Date : Semaine 5 Theme : Pipeline compta locale — Apple Mail + embeddings + scraping Fizen + scoring deterministe
Je suis gerant d'une EURL. Chaque mois, meme corvee : ouvrir le releve bancaire, chercher la facture dans mes mails, la telecharger, la deposer dans mon outil comptable.
206 ecritures. A la main. J'ai automatise tout ca. 🧵
===
Le probleme concret :
Mon comptable attend les justificatifs dans Fizen (outil comptable en ligne).
Pour chaque ligne du releve — "OVH 327,66 EUR" ou "PayPal 34,95 EUR" — je dois retrouver le bon mail, telecharger la PJ, et l'uploader.
Ca prend des heures. Chaque mois.
===
Approche naive : chercher "OVH facture" dans Apple Mail.
❌ PayPal paie Apple, Netflix, Infomaniak... un expediteur, dix fournisseurs ❌ "Facture" pas toujours dans l'objet — parfois "recu", "receipt", "invoice" ❌ Le montant est parfois dans la PJ, pas dans le mail
===
La solution : un pipeline en 4 etapes, tout en local.
- Exporter mes mails (Apple Mail → JSON via JXA)
- Les indexer (embeddings BGE-M3 + Qdrant)
- Scraper mes ecritures bancaires (Fizen via Playwright)
- Rapprocher : scoring deterministe + extraction des PJ
===
Etape 1 — Export mail.
Un script JXA (JavaScript for Automation, natif macOS) parcourt toutes les boites Apple Mail. Chaque mail devient un objet JSON : expediteur, date, sujet, corps, pieces jointes.
~10 000 mails indexes. En batch pour ne pas bloquer Mail.
===
Etape 2 — Index de recherche hybride.
Chaque mail vectorise avec BGE-M3 via Ollama sur GPU local → Qdrant.
Deux signaux fusionnes (Reciprocal Rank Fusion) : • Dense (embeddings) — "recu paiement" ≈ "facture" • Sparse (BM25) — montants exacts, numeros de facture
< 2s par requete.
===
Etape 3 — Ecritures bancaires.
Fizen est une SPA sans API. Playwright scrolle les operations (infinite scroll) et extrait chaque ligne : date, montant, tiers.
Piege : le scroll est sur un div interne, pas window → mouse.wheel sur le bon conteneur.
206 ecritures en ~2 min.
===
Etape 4 — Le rapprochement.
Pour chaque ecriture, le pipeline : 1. Cherche dans l'index mail (query semantique + filtres date) 2. Extrait le montant du sujet, du corps, ou de la PJ (pdfplumber) 3. Score sur 100 points, bareme fixe. Pas de LLM dans la decision.
===
Le bareme :
Montant exact → +40 pts Date coherente → +20 pts Expediteur match → +20 pts 2+ ex-aequo → -30 pts
≥ 70 → AUTO (rapprochement automatique) 45-69 → PROPOSE (a confirmer) < 45 → NO_MATCH
===
Avec la recherche mail seule : ~26% de rapprochement automatique. Correct, mais insuffisant.
Pour les factures sans mail — portails web, PDF a telecharger — j'ai recupere les PDF et les ai classes par tiers. 29 fournisseurs, 346 PDFs.
===
Le pipeline rapproche ces PDF aux ecritures par le meme scoring : montant extrait via pdfplumber, date, nom du tiers.
Adobe, OVH, Amazon, TotalEnergies, URSSAF, GitLab... chaque fournisseur dans son dossier.
===
Le cas PayPal illustre la difficulte.
Sur le releve : "Paypal Europe S.a.r.l." pour TOUT — Apple, Netflix, Infomaniak, Ottocast...
Des regles par tiers (YAML) ajoutent des queries supplementaires et des synonymes d'expediteur.
===
Stack complete :
• Python + Playwright (scraping) • JXA macOS (export mail) • Ollama + BGE-M3 sur GPU local (embeddings) • Qdrant (recherche vectorielle) • pdfplumber (montants dans les PJ) • Scoring deterministe (~80 lignes)
Zero cloud.
===
Resultat sur 250 ecritures (hors remunerations, frais bancaires, virements internes) :
✅ 217 VALIDATED — 87% 🔶 33 a traiter manuellement
La corvee mensuelle de 3-4h → ~15 minutes.
Thread #6 — 109 stories, 7 repos, 0 humain dans la boucle d'execution¶
Date : Semaine 6 Theme : Workflow de gouvernance IA complet — 11 etapes, multi-agents, quality gates deterministes
Je developpe un SaaS technique seul. Crypto, compliance, mobile, infra.
109 user stories livrees en 3 mois. 7 repos.
J'ai construit un workflow ou l'IA specifie, implemente, se relit, et se corrige — et ou je garde la main sur les decisions. 🧵
===
Le probleme de depart : je suis seul. PO, dev, QA, reviewer — c'est moi.
Une story bien faite, c'est une spec, des tests, un plan, du code, une review, un REX. Ca implique 4 ou 5 personnes.
Avec l'IA, on peut multiplier les roles. Mais pas n'importe comment.
===
Le piege classique, c'est le "vibe coding" : prompt, code, merge.
Ca marche pour un script. Pas pour un systeme conforme, auditable et sur. Croire qu'on peut construire un produit fiable comme ca, c'est le vrai piege de l'IA.
Il me fallait de la rigueur. Pas de la vitesse.
===
Rien de nouveau : spec, review, gate, recette, REX. De la gestion de projet classique.
11 etapes. Chaque story les traverse toutes, sans exception.
Principe fondateur : celui qui produit ne juge jamais son propre travail.
===
Le principe prend forme concretement.
ChatGPT redige la spec et les tests. Claude les confronte. Un script tranche. Quality gate. Claude planifie. Nouvelle gate.
Puis le plus interessant : l'etape 6.
===
Etape 6 : implementation multi-agents.
Claude decompose en modules. Un agent par module, perimetre strict, invariants a respecter.
L'agent secu ne voit pas le metier. L'agent tests ne touche pas la prod. Ils ne se parlent jamais. Claude assemble — sans pouvoir sortir du cadre.
===
Apres, le code passe en acceptabilite (etape 7) : ESLint, TypeScript, Sonar en local, puis des reviews LLM croisees — code, tests, securite.
Gate finale (etape 8). Le verdict est deterministe (thread #3). Si c'est NON_CONFORME, on corrige et on repasse. Max 3 tours.
===
Les chiffres sur les 29 stories ou j'ai tout mesure :
532 ecarts detectes par les gates avant merge. 76% de GO au premier passage sur la gate finale. Score moyen : 8.5/10.
5.3 heures par story en moyenne. De l'expression de besoin au merge.
===
Mais le vrai gain, c'est l'apprentissage.
Chaque story finit par un REX. Les erreurs deviennent des "learnings", indexees par embeddings (thread #2), reinjectees dans les stories suivantes.
Story 29 : 38% plus rapide que la story 1. 36% d'ecarts en moins.
===
Exemple. Story de signature crypto avec un HSM.
L'agent genere createVerify('SHA3-384').update(hash). Sauf que le HSM signe en raw — createVerify re-hashe. Double hash. Signature invalide.
La gate l'a attrape. Le learning a ete indexe. Plus jamais revu.
===
Claude ne pilote pas le workflow. Il propose. C'est Jira qui decide.
19 statuts, 24 transitions. Claude demande la suivante. Jira verifie. Si l'etat ne le permet pas : refuse.
Impossible de sauter une etape. Le LLM est non fiable mais utile. La FSM est deterministe.
===
L'IA execute. Moi, je tranche : direction, arbitrages, escalades.
Le workflow est declaratif. Remplacer ChatGPT par Gemini pour les specs ? Je change l'assignee dans Jira. Zero code.
288 stories au total. Backend, mobile, infra, doc — meme workflow.
===
Et pour que tout ca tienne dans la duree : le cerveau positronique (thread #1). 7 regles injectees a chaque gate, inviolables. L'agent qui triche, le workflow s'arrete.
Ca a l'air rigide. Ca l'est. C'est le but.
===
Ce que ca ne fait pas : de la magie. 14 stories finies "Done with anomaly". 3 rejetees. Sonar attrape encore des choses apres les gates.
Mais chaque anomalie est tracee, transformee en regle. Le systeme ne fait pas la meme erreur deux fois. Moi si.
===
Les threads precedents etaient des briques : guardrails (#1), contexte semantique (#2), verdict deterministe (#3).
Ce thread, c'est le mur. Le reste, c'est du prompting.
===
Ce que 109 stories m'ont appris : gerer un projet avec des LLM ou des humains, memes regles.
Un LLM relit 12 artefacts, verifie 40 invariants, produit un REX — sans negocier.
Il ne remplace pas les ingenieurs. Il remplace la fatigue.
Thread #7 — One Ring (pilotage multi-stories depuis iPhone)¶
Date : Semaine 7 Theme : Orchestration multi-sessions Claude Code via Signal + cmux + polling adaptatif
Je suis en deplacement toute la semaine. TGV, hotels, reunions.
Mon workflow IA tourne sur mon Mac. 3 projets, 7 repos. Pas de Mac avec moi.
Il me faut piloter mes agents depuis mon telephone — malgre les coupures reseau du TGV. 🧵
===
Signal. Chiffre de bout en bout. Marche en 3G. Pas besoin de navigateur.
J'envoie des commandes. Un script bash sur mon Mac les recoit, les route vers le bon agent, et me repond.
Inspire du Seigneur des Anneaux.
===
💍 One Ring — bash pur, zero token, route les messages ⚔️ Ringbearers — un Claude Code par story 🔮 Palantir · 🔨 Forgeron · 📜 Scribe
Tout dans un workspace cmux : "Terre du Milieu". 1 tel. N stories.
===
Le One Ring voit tout. Mais il n'a AUCUN droit. Pas de code, pas de Jira, pas de GitLab.
C'est du bash pur. Zero LLM, zero token. 1300 lignes deterministes qui routent des messages.
Le chef d'orchestre n'a pas besoin d'etre intelligent. Il doit etre fiable.
===
Un workspace cmux, un onglet par agent :
💍 One Ring · 🔮 Palantir · ⚔️ PD-285 · ⚔️ PD-286...
Polling adaptatif (5s actif, 30s au repos). Bloque ? Question extraite → Signal + notification cmux.
Je reponds. Navigation picker automatique. Le Ringbearer continue.
===
Ce que je vois sur Signal :
🔔 One Ring — 3 stories
PD-285 (backend) — Step 6 PD-286 (app) — Step 1 PD-287 (infra) — ⚠️ ESCALADE
"Faut-il un stub ou attendre le merge ?"
→ Je tape "1". Le Ringbearer reprend.
===
21 commandes. Noms LOTR :
"scribe spec PD-103" → le Scribe envoie le fichier en PJ "vision" → la Palantir scrute l'horizon "forge PD-103" → le Forgeron repare le pipeline
Case-insensitive. Un seul Ringbearer actif ? Juste ta reponse suffit.
===
Crash ? Restart auto (max 2). Jira Done ? Fermeture auto.
💀 "Le Porteur a chute dans la Moria. Gandalf doit intervenir." 🏔️ "L'Anneau est detruit dans les flammes de la Montagne du Destin." 🌋 "The Ring has been destroyed. Sauron is defeated."
===
La Palantir : session Claude Code dediee a la veille. Lancee avec le One Ring, se relance seule.
Article en marchant ? "veille https://..." sur Signal. Elle analyse, je discute. 🔮
===
Le Forgeron 🔨 — pipeline rouge apres merge ?
Il collecte les logs, corrige, commit, push, attend le nouveau pipeline. Max 3 tours.
3 echecs : "Le Forgeron n'arrive pas a reparer. Gandalf doit intervenir."
===
Chaque session enregistre TOUT ce qui s'affiche (capture periodique → fichier log).
Au retour d'experience, on parcourt le log complet. Les erreurs rattrapees silencieusement par Claude ? Elles sont la. Jamais perdues.
===
Ce qui marche :
N stories en parallele. Crash → restart auto. Jira Done → fermeture auto. Escalade → Signal + notification cmux. Pickers pilotables. Terminal log complet.
Palantir, Forgeron, Scribe, Vision — tout depuis Signal. 21 commandes.
===
v1 : tmux scraping. Fragile.
v2 : cmux (terminal macOS natif). Socket API. Pickers pilotables. Polling adaptatif. Notifications sidebar. Fallback tmux auto.
===
Stack : cmux (Socket API) + signal-cli + claude-peers-mcp + bash.
Zero cloud. Tout sur le MacBook.
===
Mardi, TGV Paris-Lyon. 3 stories avancent en parallele sur mon Mac a la maison.
Gate 3 RESERVE sur PD-103. Je reponds "iterer v3" sur Signal. Le Ringbearer corrige et relance.
Le goulot n'est plus ma presence. C'est les tokens API.
===
Threads precedents : guardrails (#1), embeddings (#2), verdict deterministe (#3), workflow (#6).
Le One Ring orchestre. Le Palantir veille. Les Ringbearers bossent. Le Forgeron repare.
Moi, je marche. 🚶
Thread #8 — Prolog detecte un bug dormant (methodes formelles accessibles)¶
Date : Semaine 8 Theme : Verification formelle legere avec Prolog — detection de contradictions inter-specs, et pourquoi l'IA rend les methodes formelles accessibles a tous les projets URL : https://x.com/2geek4you1/status/2043252967235547639
Les methodes formelles etaient un luxe academique. TLA+ chez AWS, Coq pour l'Airbus A380, Prolog pour le metro Paris.
Trop cher pour un SaaS de 20 stories.
L'IA vient de casser ce plafond. Pas parce qu'elle code a ma place.
Parce qu'elle traduit mes specs en logique. 🧵
===
Avant la these, un cas concret vecu la semaine derniere.
Dans mon backlog, un bug dormait. Pas dans le code. Dans la coherence entre deux specs.
Les deux etaient correctes a leur naissance. Ne l'etaient plus. Et aucun de mes garde-fous ne l'avait vu.
===
Deux stories, ecrites a quelques mois d'intervalle.
Story backend (upload d'evidence) : taille max 100 MB. Story app iOS (upload de document) : taille max 100 MB.
Coherent. Les deux specs se parlaient. Ma regle d'architecture SYSTEME >= BACKEND >= CLIENT etait respectee.
===
Quelques semaines plus tard, iteration sur l'app : on veut permettre les videos. Une video mobile depasse facilement 100 MB.
La spec de l'app passe a 500 MB. Gate de la story OK. Merge.
Le backend, lui, n'a pas bouge. Ma regle d'architecture est maintenant violee. En silence.
===
A ce moment precis, le bug entre en existence.
L'app acceptera des fichiers que le backend refusera. Mais il dort — personne ne s'en rendra compte avant le premier test bout-en-bout avec une video > 100 MB.
Les gates de ma story sont locales. Elles ne voient pas l'ailleurs.
===
Le probleme est plus subtil qu'un "deux agents qui ne se parlent pas".
Les specs etaient coherentes a leur naissance.
Ce qui casse la coherence, c'est une evolution locale qui n'a jamais declenche la verification globale qui aurait du l'accompagner.
===
Un script Python lit chaque besoin Markdown et en sort des predicats logiques.
Une contrainte devient :
constraint(backend_upload, 'upload.max_size', 100, mb, size_max).
constraint(app_upload, 'upload.max_size', 500, mb, size_max).
62 stories. 1865 predicats extraits.
===
Ces predicats, je les charge dans Prolog — le langage des annees 70 que plus personne n'utilise.
5 lignes pour detecter toute la classe du bug :
contradiction(S1, S2, P, V1, V2) :- constraint(S1, P, V1, U, K), constraint(S2, P, V2, U, K), S1 @< S2, V1 = V2.
===
Le piege : deux stories peuvent parler de la meme chose avec des mots differents.
"TSA", "horodatage qualifie", "timestamp authority" — trois mots, une realite.
Avant de comparer, j'ai 530 lignes de terms.yaml qui normalisent tout vers des concepts canoniques.
===
Premier lancement avec l'ontologie propre. Prolog compare l'ensemble du corpus, 1865 predicats. En 200 ms, il sort ca :
CONTRADICTION constraint_mismatch: upload.max_size: backend = 100 mb app_ios = 500 mb
Bug dormant, attrape. Avant le premier test bout-en-bout.
===
Pour etre honnete :
Mon pipeline detecte les conflits SYNTAXIQUES. Deux valeurs differentes sur la meme contrainte. C'est tout.
Il ne raisonne pas encore sur les implications logiques entre invariants. Mon pipeline fait 30%.
===
Le blocage n'est pas dans Prolog : il raisonne sur des implications depuis 50 ans.
Le blocage est dans l'extracteur : il faudrait qu'il comprenne qu'une phrase en francais est une implication logique, pas juste un tag.
C'est une montee en abstraction sur laquelle je travaille
===
Mais meme a 30%, ce pipeline n'aurait pas pu exister sans l'IA !
Les methodes formelles — Prolog, TLA+, Alloy — sont excellentes depuis 40 ans. Elles sont utilisees chez AWS, Azure, l'A380.
Pas ailleurs. Pourquoi ? Parce qu'elles coutent trop cher.
===
Le cout n'est pas dans le solveur. Prolog execute 1865 predicats en 200 ms.
Le cout est dans la TRADUCTION : prendre un cahier des charges en francais et en extraire des predicats formels.
Historiquement : un ingenieur specialise, plusieurs semaines par projet.
===
L'IA divise ce cout par 100.
Mon extracteur Python — qui lit les Markdown et sort des predicats Prolog — je l'ai code en 2 jours avec un LLM. Sans IA, j'aurais mis 2 semaines.
Et je ne l'aurais pas fait. Pas pour une application non critique, ca n'en valait pas la peine !
===
Le vrai basculement :
Les methodes formelles n'etaient pas reservees aux projets sensibles parce qu'eux seuls en avaient besoin. Elles y etaient reservees parce qu'eux seuls payaient le cout d'entree.
L'IA divise ce cout par 100. Elle change qui peut se payer la rigueur.
===
Pensee a @Akanoa qui m'a souffle cette idee avec son utilisation de TLA+
Thread #9 — Over-engineering par l'IA (biais sycophantique)¶
Date : Semaine 9 Theme : Un LLM qui construit un mille-feuille d'architecture au lieu de regarder l'existant — biais sycophantique en conversation longue URL : https://x.com/2geek4you1/status/2045599227468710097
J'ai demande a un LLM comment mieux indexer mes 128 fiches de veille technique.
4 tours de conversation plus tard, il me proposait un "moteur cognitif industriel" a 5 couches avec knowledge graph, reranker neural et classifier d'intention.
J'ai tout jete. Voici pourquoi. 🧵
===
Mon probleme tenait en une phrase :
J'ai 128 fiches de veille technique en Markdown. Quand je demarre un nouveau projet, elles ne sont pas exploitees. Je les avais ecrites, archivees, et oubliees.
Je voulais qu'elles soient retrouvees automatiquement quand le sujet revient.
===
La problematique:
Il avait acces a tout mon workspace : mes scripts, mes index, mes fichiers de config.
Il n'a jamais regarde. Pas une seule fois.
A la place, il a invente une architecture complete en partant de zero. De plus en plus complexe a chaque tour.
===
Le moment ou j'ai compris : Au tour 3, il m'a parle de conformite RGPD.
Pour une base documentaire locale. Sur mon disque dur.
La, j'ai su qu'il brodait. Il ne regardait pas mon contexte. Il construisait un mille-feuille de bonnes pratiques generiques.
===
C'est un biais documente : en conversation longue, les LLM amplifient la direction au lieu de la recentrer.
Si tu parles d'architecture, il propose plus d'architecture. Si tu t'enthousiasmes, il s'enthousiasme davantage.
Ca s'appelle le biais sycophantique.
===
Ce que j'ai fait a la place :
5 scripts Python. Chacun est un clone d'un script existant avec un parser different. Pas de serveur a maintenir. Pas de base graph a alimenter. Pas de classifier a entrainer.
Un fichier, un probleme, un commit.
===
La lecon :
Un LLM ne sait pas quand s'arreter.
Quand il te repond, pose-toi une question : "A quel probleme repond-il ?"
Si la reponse ne colle pas au probleme initial : c'est de l'over-engineering.
L'over-engineering le plus dangereux est celui qui a l'air intelligent.
Thread #10 — Mon IA pilote une migration d'entreprise¶
Date : Semaine 10 Theme : Architecture IA pour piloter un projet complexe — une cinquantaine d'interlocuteurs, objets metier interdependants, checks deterministes sur Markdown
Mon IA ne code pas. Elle m'aide à piloter une migration financière : une cinquantaine d'interlocuteurs, 7M d'écritures comptables, 12 objets métier interdépendants. Son utilité : repérer les problèmes avant qu'ils n'arrivent. 🧵
===
Le vrai problème d'un projet complexe : personne ne voit les effets domino. Un retard sur les tiers clients bloque la facturation. Qui bloque la balance. Qui bloque les tests. Qui menace le go-live. Et on s'en rend compte… trop tard.
===
Pour voir ces problèmes de manière proactive, j'ai construit un système de pilotage appuyé sur l'IA. J'archive mes notes de réunion. Je trace les mails importants. J'alimente une base de connaissance projet.
===
Le lendemain, un rapport m'attend avant mon café : urgences recalculées actions en retard remontées incohérences détectées Je n'ai rien lancé. J'ai simplement capitalisé ce que je savais.
===
Le projet est modélisé en Markdown : 12 objets métier 37 décisions tracées 69 actions ouvertes 33 risques suivis 12 jalons Un référentiel versionné, exploitable automatiquement. L'IA travaille sur une structure claire, pas sur des notes dispersées.
===
Premier réflexe : un outil de mémoire sémantique. Utile pour retrouver : "Qui a décidé quoi sur la facturation en mars ?" Mais insuffisant. Un moteur de recherche ne voit pas qu'une action traîne depuis 24 jours. Il ne voit pas qu'un go-live commence à dériver.
===
Il a fallu ajouter trois couches : Vérification — des scripts contrôlent les incohérences Temps — un moteur d'urgence priorise les sujets et propage les retards Orchestration — des commandes assemblent le tout en workflows
===
La couche vérification : 2 000 lignes de Python. Zéro IA. 🔴 [BLOQUANT] — D-007 : décision sans date, stale depuis 14 jours 🟠 [ALERTE] — A-010 : action en retard de 24 jours 🟡 [INFO] — OBJ-007 : dépendance amont non résolue Les alertes reposent sur des règles explicites.
===
La couche temps : chaque item a un score d'urgence. Décision ouverte depuis 7 jours = MOYENNE 14 jours = HAUTE Jalon dans 5 jours avec actions non faites = CRITIQUE Si le Run 1 est menacé, les actions liées montent aussi en priorité.
===
Le rapport arrive chaque matin automatiquement (Claude Code scheduled tasks). Météo projet. Tendance vs veille. Aujourd'hui : 🌧️ À risque 8 objets en ORANGE sur 12 5 actions en retard 3 décisions à trancher 30 secondes de lecture. Je sais où intervenir.
===
Le cas qui m'a convaincu : deux réunions espacées de trois semaines. En réunion A, on acte que la TVA est un flux unique. En réunion B, on découvre que c'est trois flux distincts. Personne ne relie cela à la décision d'origine.
===
Les contrôles, si. Le rapport du lendemain remonte l'incohérence : configuration retardée fichiers de migration bloqués premier jalon de test menacé Avant le comité projet suivant.
===
C'est autour des réunions que le gain de temps est le plus visible. Avant : un brief avec décisions ouvertes, risques actifs, questions à trancher. Après : mes notes brutes sont restructurées en décisions, actions, risques, points ouverts. Je relis. Je corrige. Je diffuse.
===
Chaque décision a un champ SOURCE : HUMAN — décision prise sans IA HUMAN-IA-INPUT — décision humaine éclairée par l'IA Sur 37 décisions : 33 purement humaines 4 éclairées par l'IA Aucune décision prise par l'IA seule.
===
L'IA peut aider à piloter un projet. Mais pas en mode chat. Pour être utile au pilotage, il lui faut trois choses : comprendre la sémantique du projet avoir conscience de l'urgence restituer l'information de manière synthétique
===
Une mémoire structurée. Un moteur temporel. Des workflows. 30 secondes de lecture. L'IA ne sert pas seulement à produire du code. Elle sert à piloter ce qui est trop complexe pour un tableur, trop mouvant pour un planning figé, trop vaste pour une seule tête.
Thread #11 — 112 commits, 0 feature (IP iteration avec IA)¶
Date : Semaine 11 Theme : Innovation & Planning iteration appliquee au dev assiste par IA — dette transverse, sparadraps de sprint, consolidation volontaire
J'ai une certif SAFe. Un réflexe m'est resté : à cadence régulière, lever la tête du guidon.
En dev assisté par IA, je fais pareil. J'ai bloqué 15 jours sans user story.
4 repos. 112 commits. 0 feature. Voilà ce que j'ai trouvé. 🧵
===
Quand l'IA produit, ça va vite. Les stories se ferment, le backlog avance.
Mais à chaque sprint, des miettes restent. Un raccourci ici, un contournement là. Rien de grave sur le moment. Sauf que ces miettes s'accumulent. Et personne ne les voit passer.
===
Mon pipeline backend bloquait de temps en temps. Jest ne rendait pas la main.
Réflexe en sprint : --forceExit. Le pipeline repasse au vert, on continue.
Le flag a tenu 3 semaines. Pendant la pause, 7 commits pour remonter au vrai bug : des timers pas nettoyés dans un worker. Fix en 2 heures. Mais il fallait les prendre, ces 2 heures.
===
De la duplication sur 8 fichiers backend. -279 lignes après refactor.
Chaque agent IA implémente son module dans son coin. Il ne sait pas que le module d'à côté fait exactement la même chose.
L'IA ne mutualise pas. Elle livre. C'est toi qui vois que 3 fichiers font pareil.
===
8 commits d'infra : unifier des certificats SSL qui divergeaient entre vhosts, fixer certbot qui oubliait de recharger nginx après renouvellement. Le genre de trucs qui marchent jusqu'au dimanche soir.
23 commits de CI : un process qui ne se tuait pas proprement au redéploiement. Un smoke test qui tapait / au lieu de /health — et qui passait quand même.
===
173 fiches de veille auditées. Des liens cassés. Un build PDF qui prenait 30 minutes parce qu'il incluait de la doc auto-générée que personne ne lit.
La doc, c'est le premier truc qu'on laisse pourrir. Et le premier qu'on regrette quand on cherche une info.
===
Le pattern est toujours le même.
Un raccourci pris en sprint. Raisonnable sur le moment. Qui s'accumule. Qui finit masqué par un flag, un mock, un contournement. Qui devient un vrai problème quelques semaines plus tard.
Et aucune gate ne va le voir, parce que c'est de la dette transverse. Elle vit entre les stories, pas dedans.
===
L'IA accélère la production. Elle accélère aussi l'accumulation.
Elle ne va jamais te dire "on devrait consolider avant de continuer". Elle ne remet pas en question un --forceExit qui marche. Elle ne voit pas que l'infra dérive.
Produire vite sans consolider, c'est emprunter. La pause, c'est rembourser.
===
112 commits. -279 lignes. 7 commits pour un sparadrap de 3 semaines. Un smoke test qui mentait.
Si vous bossez avec de l'IA : bloquez un cycle de temps en temps. Pas pour innover. Pour regarder ce qui s'est accumulé pendant que vous alliez vite.