Claude devenant suffisamment abordable pour être le modèle par défaut derrière les outils de développement n'a pas atténué la demande. Cela l'a explosée. Jevons, en temps réel. L'utilisation continuait d'augmenter... jusqu'à ce que certaines API soient mises sur liste noire hier. C'est le moment qui compte.

C'est le matin où vous ouvrez votre application et c'est... éteint. Même invite. Même utilisateur. Ambiance différente. Les métriques dérivent. Les tickets de support explosent. Pas de journal des modifications. Parce que votre "modèle" est une dépendance importée avec des contrôles d'exportation + un bouton de tarification. Ils peuvent réduire, dégrader ou re-tarifer l'inférence à leur rythme, et vous gérez le désordre en aval. Aussi : "open source FTW" ne termine pas le travail. Les poids n'aident pas si vous ne pouvez pas prouver ce qui fonctionnait la semaine dernière. Alors, quelle est votre stratégie quand votre application change du tout au tout du jour au lendemain, que tout le monde suppose que c'était de votre faute, et que vous ne pouvez même pas indiquer ce qui a changé ?

« Les emplois sont des ensembles de tâches » suppose que l'automatisation supprime le travail. En réalité, cela gonfle la production. Des tâches moins chères → 10x plus d'expéditions : plus de campagnes, plus d'expérimentations, plus d'itérations de produits, plus d'outils internes, plus de points de contact avec les clients. Ainsi, la part non automatisable ne devient pas seulement « plus précieuse ». Elle devient le point de blocage : approbations, décisions, contrôle qualité, culpabilité. Les revenus du travail peuvent augmenter tandis que tout le monde se sent plus occupé, car les machines n'ont pas supprimé le travail. Cela a multiplié les tentatives et a déversé la taxe de coordination sur ceux qui ne peuvent pas dire non.