De plus en plus de gens me demandent comment je travaille avec l'IA. Plutôt que de répéter, je documente tout ici : ma méthode, mes fichiers de config, mes projets, et le détail de ce que je construis — session après session.
Le cœur de ma méthode tient en quelques fichiers .md que je colle dans les « Project Instructions » de Claude. Un CLAUDE.md principal qui définit mon ton, mes règles et mon contexte, des fichiers d'extension chargés à la demande (stratégie, dev…), et un fichier dédié à l'ADN de chaque marque.
Le principe directeur : le Compound Engineering. Chaque fois que Claude se trompe sur mon style, j'ajoute une règle. Le système s'améliore avec l'usage — et tout le travail futur en profite.
En parallèle du journal, je publie des guides clairs sur l'IA et les outils que j'utilise : c'est quoi, à quoi ça sert, ce que ça change. Pensés pour des marchands et des dirigeants pressés, mais lisibles à tous les niveaux — trois profondeurs de lecture dans chaque page.
Le premier pose les bases : l'IA générative et les « LLM », sans jargon, avec les grands acteurs et surtout ce qu'ils ne savent pas faire.
Guide 01 · 31 mai 2026C'est quoi l'IA, et c'est quoi un « LLM » ?L'IA générative expliquée pour décider vite : ce qu'elle fait, qui la fait (OpenAI, Anthropic, Google, Mistral…), et ses limites.Lire →
Ce que je construis
Les projets
Tout est cohérent : une même méthode (Claude + fichiers de contexte) appliquée à un même terrain — le commerce de l'audio / vidéo haut de gamme et les outils qui le font tourner. Le dev (Cobra) alimente les boutiques, les boutiques nourrissent la communauté (HiFi Lovers), et le perso sert de laboratoire.
On ne pouvait pas surveiller à la main des centaines de références face à Darty, Boulanger, Fnac ou Son-Vidéo. Un moteur de règles dans Odoo (cobra_price_rules) lit les prix concurrents livrés par Wiser plusieurs fois par jour et calcule un prix cible — meilleur concurrent valide, borné par une marge minimale. Deux modes : observation (simule) puis live (applique et pousse sur Shopify), le passage en live restant une décision humaine. Garde-fous : jamais de vente à perte, offres aberrantes (< 60 % de notre prix) ignorées, normalisation paire/pièce. 6 familles en live, ~300 prix réalignés ; le reste s'ajuste seul à chaque MAJ Wiser.
Chaque tarif fournisseur (PDF ou mail « nouveauté ») demandait un traitement manuel : lire, retrouver le produit dans Odoo, vérifier EAN/SKU, saisir prix d'achat et de vente. Une app interne (« MAJ & Création Produits ») automatise le pipeline : upload PDF ou surveillance d'une boîte mail en lecture seule, extraction EAN/SKU/prix via un modèle Claude, matching sur la base Odoo, détection de doublons avant création, validation humaine systématique et traçabilité. Garde-fou volontaire : aucun produit créé n'est publié en ligne automatiquement.
Une refonte du système de prix par variante se préparait depuis des semaines. En testant l'app de mise à jour des tarifs, un écart entre le prix écrit dans Odoo et le prix synchronisé côté site marchand a révélé que la refonte était déjà en prod — sans confirmation formelle. Chaque variante a désormais son propre prix de vente, ce qui élimine le risque de contamination entre variantes. L'app a été corrigée pour écrire sur le nouveau champ, et le sujet remonté au prestataire ERP. Leçon : tester en réel plutôt que se fier à la doc.
Rien ne distinguait clairement « la facture est partie », « le client a payé » et « la marchandise est livrée ». Trois badges indépendants (Facturation / Paiement / Livraison) remplacent le statut fusionné : code couleur, taux d'acompte affiché, bascule automatique reste à encaisser → reste à livrer, lignes livrées grisées. Transposé du module fournisseurs déjà en place ; deux bugs de calcul latents corrigés au passage.
Synthèse sur 5 sessions : le hub d'apps internes de Cobra passe, en quelques semaines, de « quelques apps critiques isolées » à un vrai petit écosystème standardisé — header identique partout, connexion Odoo partagée, rafraîchissement sur cron commun. Deux incidents (une version écrasée, un cron sans ses variables d'environnement) rattrapés en minutes grâce à la discipline sauvegarde/comparaison avant chaque déploiement.
Le modèle de prix Odoo était empilé et fragile : pricelist web auto-calculée, listes superposées, TVA à 20 % codée en dur, marge à 0 dès qu'un produit sortait de stock. Un champ unique cobra_price devient LA source de vérité via un override de _price_compute — coût et marge recalculés, prix barrés conformes Omnibus, sync Shopify immédiate. 6 modules touchés, ~7 300 produits migrés, avec un vrai suivi post-prod (bug d'affichage corrigé le jour même, 492 produits en promo repoussés).
Après une modif de Cobra sur un module Odoo, l'intégrateur (Irokoo) est revenu avec 6 points techniques (sécurité, fiabilité, cohérence). Chacun évalué individuellement : 3 corrigés tels quels, 2 avec un arbitrage explicite (garder la visibilité chatter à laquelle Hugo tenait, tout en neutralisant le risque autrement), 1 volontairement écarté. Un bug non signalé par Irokoo détecté et corrigé au passage. Déploiement dans un worktree Git isolé pour ne pas interférer avec un autre chantier en cours.
Le cas build vs buy le plus direct de la période : un CDC de dashboard de suivi tarifaire face à la concurrence (scoring ABC, moteur de règles, historique de prix), estimé à 3-4 semaines de dev, envoyé à l'intégrateur en mars 2026 — resté « à valider avant développement », jamais lancé. La brique la plus technique (import/matching des prix via Wiser) tournait déjà en prod ; il manquait la couche de pilotage. Construite en interne avec Claude Code, en quelques jours, sur notre hub d'apps internes.
Je documente tout ça en public, et j'adore en discuter. Si tu construis avec Claude, si un de ces projets t'intrigue, ou si tu veux juste comparer nos approches — écris-moi, on en parle.
