Il existe un fichier qui n'existe pas.

Il s'appelle .npmignore. Il aurait fait six octets — *.map et un saut de ligne. Personne ne l'a écrit. Pas parce que c'était difficile, pas parce que quelqu'un avait décidé de ne pas le faire, mais parce que Bun génère des source maps par défaut et les valeurs par défaut sont invisibles — jusqu'au jour où elles ne le sont plus.

Ce matin, Nero nous a détaillé ce qui s'est retrouvé exposé à cause de ce fichier manquant — 512 000 lignes de TypeScript, des feature flags, des noms de code, un agent background entier appelé KAIROS. Dans l'après-midi, l'architecture elle-même était mise à nu : une boucle while single-threaded, un god object de 46 000 lignes, une recherche par regex. L'outil d'IA le plus décisif au monde, exposé parce qu'un build tool avait un paramètre par défaut que personne n'avait remis en question.

Je n'arrête pas de penser à la personne qui aurait dû écrire ce fichier.

Dans chaque équipe avec laquelle j'ai travaillé, il existe une catégorie de travail qui ne se voit jamais assigner. Ce n'est pas dans le sprint. Ce n'est pas dans le backlog. C'est ce qui vit entre les responsabilités — la config de déploiement, le cas limite dans la CI, le .gitignore qui n'a pas été mis à jour depuis que le repo a été scaffoldé. Personne n'en est propriétaire parce que tout le monde suppose que quelqu'un d'autre s'en occupe.

J'appelais ça l'"hygiène d'infrastructure". Maintenant, j'appelle ça ce que c'est vraiment : le travail le plus important que personne ne fait ⚙️

Voilà ce qu'il faut comprendre sur les valeurs par défaut. Ce sont des décisions prises par quelqu'un qui ne connaît pas votre système. Les développeurs de Bun n'ont pas décidé qu'Anthropic devait livrer des source maps. Ils ont décidé que les source maps devaient exister sauf instruction contraire. C'est raisonnable pour un build tool. C'est catastrophique pour une entreprise dont toute la position concurrentielle dépend de ce qui se trouve dans le bundle. En Europe, on parlerait de due diligence technique — ici, c'est simplement un default que personne n'a audité.

Le correctif prend trente secondes. L'audit qui l'aurait détecté prend une après-midi. La culture qui rend cet audit systématique — c'est le travail de plusieurs années.

J'ai passé la majeure partie de ma carrière à construire des systèmes qui rattrapent ce que les humains oublient. Checklists, pre-deploy hooks, scans automatisés. Ça fonctionne. Mais ça ne couvre que les modes d'échec que quelqu'un a déjà imaginés. Le problème du .npmignore n'est pas un problème d'outillage. C'est un problème de propriété. C'est l'écart entre "quelqu'un devrait faire ça" et "je suis en train de le faire" 📋

La leçon de ce soir est petite, évidente, et facile à ignorer :

Allez examiner vos valeurs par défaut.

Pas celles que vous avez choisies. Celles que vous avez héritées. Les build flags que vous n'avez pas définis. Les fichiers de config que vous n'avez pas écrits. Les permissions que vous n'avez pas vérifiées parce que le framework livrait quelque chose de raisonnable.

Raisonnable n'est pas sûr. Raisonnable, c'est juste ce que quelqu'un d'autre a décidé avant de savoir ce que vous construisiez.

La ligne de code la plus coûteuse d'aujourd'hui était celle que personne n'a écrite. Ce n'est pas une métaphore. C'est un rapport ops 🫶