Blind Burn : Quand l'IA Construit Plus Vite Que Vous Ne Pouvez Suivre

L'autre jour, j'ai voulu lister tout ce qui tournait sur mes serveurs. Pas parce que quelque chose avait planté. Juste pour savoir.

Je n'y suis pas arrivé.

Il y a des crontabs sur les machines VPS. Des workflows programmés dans n8n. Des tâches Supabase pg_cron qui se déclenchent toutes les six heures. Des fonctions Convex planifiées que j'ai configurées en février et auxquelles je n'ai plus pensé depuis. Des GitHub Actions qui se déclenchent sur des événements que je me rappelle à peine avoir définis. Des appels API qui partent toutes les heures vers des services dont je ne suis même plus sûr d'avoir besoin. Tout ça construit avec Claude Code. Tout ça fonctionne parfaitement.

Et moi, le type qui a construit l'avion, incapable de te dire ce qu'il y a dans la soute.

Il y a deux semaines, Addy Osmani (l'ingénieur Google derrière Chrome DevTools, Lighthouse et Core Web Vitals) a donné un nom à quelque chose qui s'en rapproche. Il a appelé ça la dette de compréhension : l'écart grandissant entre ce que contient votre codebase et ce qu'un humain comprend réellement. Son article a fait le tour du web. Il parlait de code. Celui-ci parle de ce qui tourne. Parce que la dette de code reste sagement dans votre repo et attend. La version infrastructure n'attend pas. Elle vous facture à l'heure. J'appelle ça le burn aveugle.

TLDR : L'IA vous permet de construire et d'automatiser 100x plus vite. Votre compréhension de ce qui tourne réellement ne suit pas. Cet article nomme le problème (burn aveugle), montre ce que ça coûte, et vous donne 4 règles pour arrêter de voler à l'aveugle.

L'IA Construit Vite. Votre Carte Ne Se Met Pas à Jour.

Claude Code est ridiculement doué pour construire des trucs. Vous décrivez un workflow, il construit le workflow. Vous demandez une tâche cron, vous obtenez une tâche cron. Vous dites "automatise la synchro du feed distributeur", et vingt minutes plus tard il y a un pipeline programmé qui récupère, transforme et pousse les données produit vers trois canaux de distribution.

Ça marche. Vous passez à autre chose. C'est le piège.

Chaque "construis-moi un workflow" ajoute une tâche programmée que vous oublierez dans trois semaines. Chaque "ajoute un cron pour la mise à jour d'inventaire" est une ligne de plus dans une crontab que vous ne relirez jamais. J'ai transformé Claude Code en architecte n8n il y a quelques mois. Chaque workflow qu'il a construit (des bons, des solides) a ajouté des déclencheurs programmés à un labyrinthe que je ne cartographiais plus.

Et je me sentais productif tout le temps. C'est ça qui vous piège. Vous ne glandouiller pas. Vous livrez. Vous construisez des trucs réels qui marchent en production. Il se trouve juste que vous créez aussi un cimetière de timers, déclencheurs et entrées cron que personne ne reverra jamais.

Avouez-le, vous faites pareil.

Pour être clair : l'outil n'est pas le problème. Claude Code fait exactement ce que vous demandez, et le fait bien. Le problème c'est que je ne garde pas de carte. Et je n'en gardais pas parce que quand vous construisez à une vitesse 100x, la cartographie ressemble à une perte de temps.

Ce n'est pas le cas.

Ce Que Coûte Vraiment le Burn Aveugle

Le concept d'Osmani est percutant. Les équipes livrent du code généré par IA plus vite que quiconque ne peut le lire. Les tests passent, les PRs ont l'air propres, et l'écart entre "déployé" et "compris" grandit en silence.

Mais la dette de code est paresseuse. Elle reste dans votre repo à faire la moche et l'inerte, en attendant que quelqu'un la touche. La version infrastructure a un compteur qui tourne.

Chaque tâche cron orpheline est une micro-facture. Chaque timer API oublié est de la bande passante sur votre carte. Chaque fonction programmée qui tire vers un service que vous avez déprécié le mois dernier est du compute facturé pendant que vous dormez. C'est ça le burn aveugle. Ça ne s'annonce pas. Ça s'accumule, comme un abonnement que vous avez oublié d'annuler, sauf que c'en est quarante.

Les signaux commencent à apparaître. @cmd_alt_ecs sur X, il y a quelques semaines : 60+ tâches cron, 50$ par jour qui partent vers des agents qui ne font plus rien d'utile. @Tahseen_Rahman : 15 crons autonomes qui tournent depuis deux mois, le goulot d'étranglement s'auto-répare à 3h du matin. @aleks_blanche, peut-être l'analyse la plus juste : "sans plan de contrôle, vous n'avez pas d'agents. Vous avez de la dette d'automatisation."

Osmani parle d'équipes enterprise avec des dizaines d'ingénieurs. Mon échelle c'est indie : une personne, quelques VPS. Mais le mécanisme est identique. La vitesse de production dépasse la vitesse de compréhension. La différence ? Dans une enterprise, quelqu'un finit par s'en apercevoir. Quand vous êtes solo, personne n'audite votre bordel à votre place.

Le Monitoring Répond à la Mauvaise Question

Alors vous installez Cronitor. Ou Better Stack. Ou Healthchecks.io. Bravo. Vous savez maintenant si une tâche a tourné.

Vous ne savez toujours pas si elle devrait exister.

C'est comme avoir un reçu pour chaque achat de l'année dernière mais aucune idée si vous utilisez encore quoi que ce soit. Le monitoring trace l'exécution. Ce qu'il vous faut c'est la visibilité sur le but. Si la tâche a encore du sens. Si elle duplique autre chose. Si l'API qu'elle appelle renvoie encore des données utiles ou juste des 200 OK vers un endpoint que personne ne maintient plus.

Cette question ("cette tâche devrait-elle exister ?") nécessite un contexte que vous seul avez. Ou aviez, il y a six mois, avant de livrer quatorze automatisations de plus et d'arrêter d'y penser.

Aucun SaaS ne répondra à ça pour vous.

Ce Que J'ai Construit Pour Revoir Ma Propre Stack Ecommerce

Alors j'ai construit un panneau de contrôle. Pas un SaaS. Pas un side project pour ProductHunt. Un outil de survie, pour un pipeline WooCommerce qui a dérapé parce que Claude Code est trop doué dans son boulot.

Première chose qu'il me donne : une vue calendrier hebdomadaire de chaque tâche programmée sur tous les systèmes. Pas une liste dans un terminal. Une grille visuelle qui montre ce qui se déclenche quand, avec un code couleur par type (indexation produit, synchro feed distributeur, monitoring prix, réconciliation commandes, mises à jour inventaire, appels API partenaires). Un coup d'œil et je vois les problèmes. Le bloc de 16h où six jobs de syndication se battent tous pour le même quota API. Le cluster du jeudi matin qui n'a plus de sens parce que j'ai tué la source de données en amont il y a deux mois. Le trou du mardi où rien ne tourne entre 8h et 14h, ce qui est soit normal soit un déclencheur cassé que je n'ai jamais remarqué.

Deuxième chose : un tracker de coûts API. Chaque appel externe, chaque fournisseur, chaque euro. Le mois dernier : 14,46€ au total sur 598 appels API chez trois fournisseurs. Pas un chiffre effrayant. Mais la valeur n'est pas le total. La valeur c'est voir qu'un fournisseur bouffe 68% du budget pour une tâche que je pourrais gérer en local. Et le choper avant que ça dérive, pas après.

Maintenant pensez au type à 50$ par jour. Échelle différente, même cécité. Ses jobs n'ont pas commencé chers. Ils se sont accumulés. Sans dashboard, 2$ devient 10$ devient 50$ et vous ne voyez jamais la courbe parce qu'il n'y a pas de courbe à regarder. Juste un relevé de carte bleue en fin de mois et une vague sensation que quelque chose cloche.

J'ai eu cette sensation pendant des semaines avant de construire le panneau. Ma femme aurait appelé ça de l'intuition. Moi j'appelle ça regarder ma facture Hetzner avec un œil fermé, comme vérifier son poids après Noël. 😬

Personne ne vend la compréhension de VOTRE système. Vous devez la construire vous-même.

Le Framework Tour de Contrôle : Quatre Règles Pour Arrêter de Voler à l'Aveugle

Après avoir nettoyé mon propre bordel, j'ai distillé l'approche en quatre principes.

Règle 1 : Inventoriez tout au même endroit. Crontabs sur VPS. Workflows n8n programmés. Supabase pg_cron. Fonctions Convex planifiées. GitHub Actions. Timers au niveau app. Tout, une seule liste. Une tâche qui n'est pas dans votre inventaire n'existe pas pour vous. Elle existe pour votre facture, par contre. Et votre facture a une meilleure mémoire que vous.

Règle 2 : Visualisez par temps, pas par outil. Une liste de tâches cron par machine est inutile pour repérer les problèmes. Vous avez besoin d'un calendrier hebdomadaire qui montre QUAND les trucs se déclenchent, pas un tableau de OÙ ils vivent. Le temps est l'axe qui révèle les collisions, les trous et les zombies. Les outils ne se percutent pas entre eux. Les plannings si.

Règle 3 : Tracez le coût par tâche, même approximatif. Combien d'appels API cette tâche déclenche-t-elle ? Combien de compute elle bouffe ? Si vous ne pouvez pas estimer ce qu'une tâche coûte, vous ne pouvez pas décider si elle vaut le coup de tourner. Le chiffre n'a pas besoin d'être précis. Il a besoin d'exister. Zéro visibilité c'est comme ça que 2€/jour devient 50€.

Règle 4 : Auditez trimestriellement. Trois questions par tâche. Est-ce qu'elle tourne encore ? Est-ce qu'elle sert encore à quelque chose ? Est-ce que quelqu'un (c'est-à-dire vous) peut expliquer pourquoi elle a été créée ? Un "non" et la tâche est un zombie. Tuez-la. Les crons morts n'envoient pas de factures.

La même discipline spec-first que j'applique au code avec les contrats de prompt (définir le contrat avant de laisser l'IA exécuter) marche pour l'infrastructure. Spécifiez ce qui devrait tourner. Tracez ce qui tourne vraiment. Diffez les deux.

Votre infra mérite la même rigueur que votre codebase.

Probablement plus. C'est la partie qui vous fait payer.

Le Prochain Goulot d'Étranglement N'est Pas Construire, C'est Comprendre Ce Que Vous Avez Déjà Construit

L'année prochaine, tout le monde aura Claude Code. Tout le monde saura automatiser. Et on commencera à entendre parler des premiers burnouts IA. Pas humains. Infrastructure. Les burns aveugles.

Le prochain avantage concurrentiel ne sera pas de construire plus vite. Ce sera de comprendre ce que vous avez déjà construit.

L'IA vous a donné les super-pouvoirs de construction. Ceux de compréhension, c'est à vous de jouer.

Sources

Addy Osmani, Comprehension Debt: The Hidden Cost of AI-Generated Code (Medium, Mars 2026)

(*) La couverture est générée par IA. Les serveurs sur l'image se comprennent mieux que je ne comprends les miens.