J'ai Arrêté de Créer des Workflows IA. J'ai Commencé à Construire un Rempart. Claude Code a Fait le Travail.
23h42, retour de dîner, coup d'œil rapide sur mes mails. Merde. Infisical en panne. Alors que je commence à pester, sept minutes plus tard, deuxième mail. « [INFRA] Infisical est de nouveau opérationnel. »
C'est là que j'ai tilté. J'avais construit une Stack Vivante.
TLDR. Tout le monde panique à l'idée que l'IA va griller leur boulot. Pendant ce temps, une poignée de builders qui pensent en systèmes transforment cette même technologie en avantage décisif. Pas un workflow. Pas un assistant. Une stack vivante, qui se répare toute seule, qui s'enrichit pendant qu'ils dorment. Six mois de retard pour quiconque essaie de copier.
Six mois à coder tous les jours avec Claude Code, et j'avais fini par construire quelque chose qui n'est plus un workflow. Pas une config n8n améliorée. Pas un assistant qui écrit du code pour moi. Pas encore une démo d'agent. J'avais construit quelque chose de plus complexe. Ça se répare tout seul. Ça s'enrichit tout seul. Ça apprend mes patterns. Et ce truc ? Personne ne peut le copier en un week-end.
J'ai bien dormi.
La Première Fois Que Je L'Ai Vu S'Auto-Réparer
Le monitoring a détecté le timeout. Un trigger que j'avais câblé des mois plus tôt s'est déclenché, a ouvert une session Claude Code avec les logs du service défaillant en contexte, et l'agent a pris le relais. Lu les logs. Repéré un container bloqué-mais-pas-crashé. L'a redémarré. Confirmé que c'était vert. Envoyé l'email de résolution.
Il y a six mois, ce même incident m'aurait bousillé la soirée. Café. Panique. Une heure à comprendre pourquoi le gestionnaire de secrets fait la gueule, vingt minutes de plus à identifier quel container est le vrai coupable, dix minutes de regret en tapant la commande docker restart dans le mauvais terminal.
Ça a continué après ça. Même pattern. Le trigger se déclenche, l'agent enquête, le fix est appliqué, je lis le rapport plus tard. Une fois que tu vois ça tourner quelques fois, tu arrêtes d'appeler ce que tu as un « setup ».
Ce Que J'Ai Vraiment Construit en 6 Mois
Je ne me suis pas assis le premier jour pour architecturer tout ça. J'ai juste continué à construire des trucs pour mon setup e-commerce, jour après jour, avec Claude Code comme seul IDE que j'ouvre.
La surface actuelle :
Un pipeline d'ingestion de catalogue produits qui récupère le feed CSV d'un distributeur chaque matin, normalise le bordel (différents fournisseurs, différents noms de champs, prix dans trois devises, poids en deux unités, et un fournisseur qui utilise encore l'encodage Windows-1252 en 2026), et pousse les lignes nettoyées dans WooCommerce.
Des scrapers de prix concurrents, une demi-douzaine, chacun trackant un sous-ensemble spécifique de SKUs sur les storefronts rivaux. Ils gèrent les WAFs, font expirer les données obsolètes, et alimentent un dashboard que je regarde vraiment.
Génération de contenu social pour Threads et Instagram, liée aux sorties produits. Le système récupère chaque nouveau SKU, rédige des variantes de copy, génère la vidéo promo, et met tout en file d'attente dans une API partenaire pour la programmation.
Dashboards de tendances. Monitoring d'inventaire. Intégration pipeline de commandes. Webhooks API partenaires. Transcription des appels fournisseurs (oui, je les enregistre, avec consentement, calmez-vous). Et la couche infra en dessous : Docker, reverse proxies, rotation des secrets, jobs de backup, alerting.
Tout ça sur quelques VPS. Tout ça construit de manière incrémentale. Tout ça en dialogue avec Claude Code tous les jours.
Hier ça plantait un jour sur deux. Aujourd'hui ça marche neuf jours sur dix.
Je ne lance plus rien manuellement. Je n'ouvre même plus la plupart des dashboards. Je vois juste arriver les résumés, je jette un œil, et soit je les ignore soit je pousse une capture d'écran à Claude Code si quelque chose semble bizarre.
Un workflow ne fait pas ça. Un workflow reste là jusqu'à ce que tu le déclenches.
Pourquoi C'est un Fossé, Pas un Workflow
Il y a un article percutant sur Medium de février intitulé « AI Killed the Feature Moat ». L'argument : en 2026, n'importe qui avec Cursor et un week-end peut cloner tes fonctionnalités. Les fossés qui survivent ne sont pas fonctionnels. Ce sont des trucs comme le SEO, la marque, le goût, la vitesse, les données, la confiance. Six catégories. Et l'article nomme trois propriétés qu'ils partagent tous : dépendance temporelle, dépendance à l'expérience, résistance à la réplication.
C'est le cadre business. Je veux voler ces trois propriétés et les zoomer au niveau de l'opérateur.
Ce que j'ai construit n'est pas un fossé business. Ça ne me protège pas des concurrents qui veulent mes clients. C'est un fossé personnel. Ça protège ma capacité à livrer plus, plus vite, avec moins de stress que la version de moi d'il y a six mois. L'asymétrie est interne, pas externe. Pour un solo, c'est la seule asymétrie qui compte au quotidien.
Trois propriétés font d'une stack personnelle un fossé plutôt qu'un workflow. J'appelle tout ça la Stack Vivante. SV. Oui, je sais, je suis nul pour nommer les trucs.
Co-évolution
C'est la partie à laquelle je ne m'attendais pas.
Au bout de trois mois, j'ai remarqué que Claude Code suggérait des fixes qui matchaient mon style sans que je le lui demande. Une convention de nommage que j'avais définie dans un commit jetable des semaines plus tôt continuait d'apparaître dans le nouveau code. Une façon spécifique de gérer les erreurs (return early, log structuré, jamais de throw silencieux) était reproduite spontanément. Je ne l'avais pas mis dans un CLAUDE.md. C'était juste dans le codebase, dans les patterns, dans l'historique des commits. Le modèle l'a capté en étant là.
Après assez de mois comme ça, les suggestions arrêtent de ressembler à de l'output IA générique. Elles commencent à ressembler à une extension de ton propre historique de décisions. Pas magique. Juste de la descente de gradient sur tes propres choix, accumulés.
Cette co-évolution marche mieux avec des outils simples et observables. Une raison pour laquelle je suis parti CLI-first au lieu de monter une forêt de serveurs MCP : les CLIs laissent une trace. Chaque commande dans l'historique du shell. Chaque flag dans le commit. L'agent voit ce qui a marché hier et enchaîne les mêmes patterns demain. J'ai creusé pourquoi les CLIs battent MCP pour les agents ailleurs. Version courte : les outils simples qui se composent battent les outils brillants qui abstraient.
Auto-accumulation
Chaque run de scraper ajoute des lignes à une base privée. Chaque check de prix concurrent enrichit ma vision du marché. Chaque produit que j'ingère, chaque post social qui sort, chaque appel fournisseur que je transcris, tout ça s'empile. Six mois plus tard, j'ai un corpus de décisions, snapshots et patterns qui n'existe nulle part ailleurs.
C'est la partie que personne ne peut reconstruire en un week-end.
L'architecture ? Bien sûr. N'importe qui avec trois mois et une carte de crédit peut cloner l'architecture. Docker, scrapers, Claude Code en boucle, stack de monitoring. Rien n'est secret. Les articles de blog existent. Les repos existent.
Mais les données sont à moi. Six mois de scraping discipliné sur mes verticales. Six mois de résultats de lancements produits liés à des variantes de copy spécifiques. Six mois de quels fournisseurs livrent propre et lesquels embarquent de la merde dans leurs feeds. Six mois de matière, s'accumulant à une seconde par seconde, peu importe la richesse de ton concurrent.
L'architecture c'est la tasse. Les données c'est ce qu'il y a dans la tasse. Acheter une tasse plus fancy ne te fait pas rattraper.
Auto-réparation (Deux saveurs)
Saveur une : full auto. La section 1 s'est déjà passée, tu l'as lue. Le monitoring détecte une panne, Claude Code enquête, le fix est appliqué, je reçois l'email. Pas de drame.
Saveur deux : trigger humain minimal. Je pousse une capture d'écran d'une erreur dans une session Claude Code, trois lignes de contexte, et ça y va. Lit les logs, parcourt l'arbre de dépendances, propose un fix ou en applique un. Dans certains cas il va provisionner un peu de ressource VPS si le problème est lié à la capacité. (Pas encore routinier pour moi. Je fais attention avec le bouton « appliquer » sur les changements d'infra.)
Hector Flores a démontré un setup d'auto-réparation enterprise plus tôt cette année, Azure MCP plus IA agentique, et a rapporté 70% des incidents de production résolus sans intervention humaine. C'est un environnement avec du staff complet avec des ingénieurs plateforme et SRE d'astreinte. Moi je suis un mec avec quelques VPS et un abonnement Claude Code. Je ne suis pas à 70% sur toutes les classes d'incidents. Mais sur les types de pannes qui me bousillaient les week-ends (containers bloqués, tokens expirés, cron jobs cassés, disques pleins), je suis assez proche. Setup différent, courbe similaire.
La couche de contrats en dessous de tout ça est ce qui rend l'auto-réparation fiable plutôt qu'auto-corrompante. J'ai creusé l'approche basée contrats que j'enroule maintenant autour de chaque session Claude Code plus tôt. Sans ça, tu laisses un LLM réécrire ton infra de prod à 23h. Aïe.
Trois propriétés. Dépendance temporelle, dépendance à l'expérience, résistance à la réplication. Le cadre original était les fossés SaaS. Ils se mappent aussi proprement à un opérateur seul avec quelques serveurs et un abonnement.
C'est la différence entre un workflow et une Stack Vivante.
D'Opérateur à Pilote
Une métaphore pour les non-devs qui lisent ça.
Marcher. C'est ChatGPT en 2023. Tu es le système d'exploitation. Tu tapes tout. Chaque pensée, chaque prompt, chaque reformulation. Le modèle reste là à attendre. Tu bouges le monde en bougeant tes doigts.
Faire du vélo. C'est là où la plupart des gens en sont maintenant. Tu ajoutes un agent. Tu lui donnes des inputs, il produit des outputs, tu les assembles à la main. Plus rapide que marcher. Toujours très toi qui fais le steering et le pédalage.
Conduire. C'est là où je suis après six mois. Tu construis la voiture autour de toi. L'infra c'est le châssis. Les agents c'est le moteur. Les données c'est le carburant. Tu as un coffre (les assets que tu as accumulés). Tu as des sièges passagers (des sous-agents qui gèrent des tâches spécifiques). Et critique, tu as le régulateur de vitesse. Tu peux lâcher le volant par moments. Pas pour décrocher. Pour aller plus loin avec moins de toi dans la boucle.
Karpathy a popularisé une métaphore différente mi-2025. LLM est un CPU, fenêtre de contexte est la RAM, tu es l'OS. Techniquement propre. Je l'ai citée moi-même. Mais ça cast le builder comme le système nerveux. Toi en tant qu'OS signifie que tu ne peux jamais dormir.
La métaphore de la voiture ouvre une question différente : qu'est-ce qui se passe quand tu arrêtes de conduire ? Tu la gares. Tu l'éteins. Tu vas te coucher. Avec le cadrage OS, tu ne peux pas. Avec le cadrage voiture, tu dois te demander si le système tourne sans toi.
C'est le test de maturité. Pas « à quel point ton prompt est clever ». Pas « combien de serveurs MCP tu as ». C'est : qu'est-ce qui se passe à 23h42 quand quelque chose casse et que tu es à table ?
En février 2026, Karpathy lui-même a shifté le cadrage. Il a posté que le vibe coding était passé de mode et a proposé l'ingénierie agentique à la place, définie grosso modo comme orchestrer des agents qui font le code plutôt que de le taper directement toi-même. C'est un vrai shift. Le vibe coding c'était taper vite et faire confiance au modèle. L'ingénierie agentique c'est construire des échafaudages autour du modèle pour qu'il puisse faire tourner des jobs.
J'ajouterais une couche de plus au-dessus. Vibe coding (fév 2025) → ingénierie agentique (fév 2026) → stacks niveau infrastructure qui survivent à ton absence (maintenant). Préoccupations différentes, empilées. Le vibe coding te donne une fonctionnalité. L'ingénierie agentique te donne un projet. La Stack Vivante te donne un mardi soir où le système gère ses propres pannes pendant que tu finis de dîner.
Ce Qui Meurt Dans Cette Transition
Il faut être honnête sur ce à quoi tu renonces.
Le gros : compréhension exhaustive du code.
Six mois de travail Claude Code incrémental signifient qu'il y a des coins de mon système que je ne lis plus ligne par ligne. Je sais ce qu'ils font. Je ne me rappelle pas toujours exactement comment. La signature de fonction est familière, le test passe, les logs ont l'air corrects, mais si tu me demandais de whiteboard l'implémentation de mémoire, je galérerais. Certains fichiers je ne les ai littéralement jamais ouverts à la main.
Ça me faisait peur avant. Maintenant je traite ça comme le prix d'entrée.
Tu échanges le contrôle minute par minute contre du temps. Tu échanges la lisibilité locale contre l'asymétrie temporelle globale. Pour un solo, cet échange est généralement positif. Tu n'as pas vraiment besoin de te rappeler chaque ligne. Tu as besoin que le système continue de tourner pendant que tu dors. Pour une équipe, c'est plus dur. La compréhension partagée s'érode quand personne ne possède complètement le code, et cette érosion se montre dans la douleur d'onboarding six mois plus tard. (Si tu diriges une équipe d'ingénieurs et que ce paragraphe t'a fait tiquer, tu n'as pas tort. Tradeoff différent. Jeu différent.)
Il y a un caveat plus petit : risque plateforme. Toute la stack tourne sur des instances VPS Hostinger. Solide pour moi, mais comme tout truc cloud, l'ordinateur de quelqu'un d'autre. Si Hostinger triple ses prix demain, ou réécrit ses CGU pour bannir les scrapers, ou a juste une mauvaise semaine, le système tremble. La défense c'est la portabilité des données. Garder la couche infra fine et la couche logique épaisse. Si l'infra devient hostile, tu migres le châssis. Le moteur et les données suivent.
C'est l'échange. Moins de contrôle, plus de temps. Moins de lisibilité locale, plus d'asymétrie d'accumulation. Ton concurrent peut copier l'architecture en trois à quatre mois. Ton concurrent ne peut pas copier six mois de tes données spécifiques et de ton historique de décisions spécifiques. Pas en un week-end. Pas en un trimestre. Et si tu continues, pas en un an non plus.
L'échange c'est le fossé.
Il y a six mois, une panne à 23h42 m'aurait détruit la soirée.
Ce soir, dîner.
La Stack Vivante.
Sources
- AI Killed the Feature Moat. Here's What Actually Defends Your SaaS Company in 2026. Steven Cen, Medium, fév 2026.
- Vibe coding is passé. Karpathy has a new name for the future of software. The New Stack, fév 2026.
- Hector Flores, Self-Healing Infrastructure with Agentic AI. Fév 2026.
Cet article peut contenir des liens d'affiliation. Je peux toucher une petite commission si vous achetez via ces liens. Ça ne change rien pour vous, le prix est le même, et ça aide à soutenir mon travail.