Après l'automatisation : le framer, pas le frame, est là où vit encore le travail

Dan Shipper (Every) vient de publier After Automation, un essai qui mérite d'être lu en entier et qui mérite une réponse depuis la tranchée européenne du DevOps et de la plateforme. Sa thèse centrale est que plus on automatise avec l'IA, plus il y a de travail humain expert — pas moins. Every a 30 employés, a automatisé avec Claude Code et des agents asynchrones tout ce qu'il a pu, et n'a éliminé aucun poste. Le travail a changé de forme, il n'a pas disparu.

Je suis d'accord. Mais la partie de l'article qui mérite le plus d'attention — et qu'aucune feuille de route de "transformation IA" que j'ai revue cette année ne nomme — c'est la distinction entre le frame et le framer. C'est la ligne qui sépare les équipes qui comprendront ce qu'elles achètent au cours des deux prochaines années des équipes qui se réveilleront un matin avec un dashboard entre les mains.

Le paradoxe que mes clients vivent déjà sans le savoir

Shipper formule le paradoxe en une phrase nette : "Making expert work cheaper does not simply replace experts. It creates more situations where expert judgment is needed."

Je traduis dans mon monde. Quand on met Claude Code, des agents de revue de PR et des pipelines à base de LLM dans une équipe plateforme bancaire ou santé, je ne vois pas l'équipe rétrécir. Je vois :

• Plus de PRs ouvertes par unité de temps, parce que le coût marginal d'en ouvrir une baisse.
• Plus de décisions architecturales par semaine, parce que chaque PR force désormais une décision — sur la résidence des données, les autorisations, l'impact réglementaire — que la friction absorbait silencieusement avant.
• Plus de temps passé à définir ce qui vaut la peine d'être automatisé, parce qu'automatiser le mauvais travail est désormais bon marché et rapide — ce qui le rend plus dangereux, pas moins.

Le responsable plateforme qui pensait que l'IA allait réduire les effectifs se retrouve face à la question inverse : comment je passe à l'échelle le jugement senior nécessaire pour filtrer le volume que les agents produisent maintenant ? Cette question n'est pas une critique de l'IA. C'est la preuve qu'elle fonctionne.

C'est le même schéma que j'ai lu dans les chiffres d'ActionNex de Microsoft : 71 % de precision, 53 % de recall sur des incidents Azure réels. Le système marche assez bien pour être déployable, et pas assez pour être autonome. La conséquence n'est pas "moins de SREs" ; c'est des SREs avec une surface de décision plus grande, parce qu'ils relisent désormais des recommandations à une cadence qui n'existait pas avant.

Le frame, le framer, et pourquoi cette distinction est la seule qui compte

La partie la plus sous-utilisée de l'essai de Shipper est celle-ci :

The frame is not the framer. […] Humans know about what needs to be done, right now.

Je déballe. Un benchmark mesure la performance du modèle à l'intérieur d'un frame — un prompt précis, un dataset précis, une définition précise de "tâche accomplie". Quand un modèle sature ce frame, l'industrie déplace le frame : on ne mesure plus "écrire le code" mais "décider quand réécrire le code". Le nouveau frame retombe à 60 et tout le monde repart en panique sur signal.

Shipper appelle ça Zeno's Paradox of AI. Moi j'appelle ça quelque chose de plus opérationnel : le framer est le rôle qui survit, et c'est le rôle que la plupart des roadmaps ne nomment pas parce qu'elles ne savent pas comment le budgéter.

Trois conséquences pratiques qu'aucun pitch IA entendu cette année n'aborde directement :

1. Le frame du fournisseur expire avant son contrat. Si vous achetez une "plateforme IA pour les opérations" sur la foi d'une capacité qui fait la démo aujourd'hui dans un frame précis, le frame aura bougé avant la fin du cycle budgétaire. Ce que vous avez acheté, ce n'est pas la capacité — c'est la promesse que le fournisseur saura reframer avant vous. Souvent, il ne saura pas.

2. Le framer n'est pas un poste. C'est une fonction distribuée. Dans une équipe plateforme, le framer est celui qui décide quels workloads valent la peine d'être automatisés ce trimestre, sous quelles contraintes de compliance, d'énergie et de risque, avec quel budget d'erreurs acceptable. Ce n'est pas le ML lead. Ce n'est pas le VP Engineering seul. C'est la composition des deux avec le régulateur dans la salle — et c'est le rôle le plus sous-staffé que je vois aujourd'hui.

3. En secteurs régulés, le frame est un artefact réglementaire. C'est la partie que Shipper, en écrivant depuis un SaaS B2B, n'a pas besoin d'expliciter. Mais pour un client en banque, santé ou secteur public, le frame lui-même — ce qui compte comme "décision correcte", ce qui compte comme "PII", ce qui compte comme "incident à reporter" — est défini par le régulateur. Par définition, il ne peut pas être délégué à un modèle entraîné sur le frame d'hier. Le framer ici n'est pas optionnel. C'est le lieu où vit la légitimité du système.

L'analogie du tout-petit — et pourquoi en production elle est plus gênante qu'il n'y paraît

Shipper compare les agents actuels à un tout-petit : ils ont de l'agentivité, ils veulent des choses, ils poursuivent des objectifs autodirigés que personne ne leur a donnés. Les LLM, non. Ils exécutent les frames qu'on leur donne.

En production enterprise, cette distinction est plus gênante qu'il n'y paraît pour deux raisons :

• On veut justement que les agents n'aient pas d'agentivité. Un agent avec des objectifs émergents en environnement régulé, c'est un problème, pas une promesse. Le récit Silicon Valley d'une "AGI avec une volonté propre" est exactement l'inverse de ce qu'un CISO acceptera de signer. Donc la limite que Shipper nomme — "les modèles exécutent les objectifs des autres" — est, dans mon secteur, une feature, pas un défaut.

• Mais cela veut dire que le coût de bien spécifier l'objectif ne baisse pas, il monte. Si l'agent ne s'autodirige pas, chaque autorisation, chaque contrainte, chaque critère de succès doit venir d'un humain — et la qualité du résultat est plafonnée par la qualité du frame, pas par celle du modèle. Une équipe qui passe à l'échelle des agents sans passer à l'échelle la qualité de ses frames fabrique du slop à vitesse industrielle avec un certificat ISO agrafé à côté.

C'est la lecture que j'ajouterais à Shipper : le "framer" n'est pas seulement un rôle produit ou stratégie. En environnements régulés, le framer est le contrôle le plus mal documenté du système sociotechnique complet, et les auditeurs arriveront dessus avant 2027.

L'asymétrie qu'aucun fournisseur ne vous expliquera

Shipper observe que les modèles ne savent que sur du travail qui a déjà été fait. Les humains savent sur du travail qui doit être fait maintenant. Cette asymétrie a une conséquence procurement qui n'apparaît sur aucun deck :

Quand un fournisseur IA vous présente une nouvelle capacité, il vous montre la performance sur des captures du passé : du code déjà écrit, des incidents déjà résolus, des contrats déjà signés. Ce qu'il ne peut pas démontrer, c'est la performance sur le problème de ce trimestre, parce que ce problème n'est encore dans le training set de personne. Donc :

• L'écart entre performance de démo et performance en production n'est pas un bug du fournisseur. Il est structurel.
• Cet écart, c'est le framer humain qui le comble — et le fournisseur ne vous le vend pas, parce que ce n'est pas son produit.
• Coût réel du système = coût de la licence + coût du framer humain qui le maintient pertinent. La plupart des business cases ne budgétisent que le premier.

Si votre business case IA cette année n'a pas une ligne pour "headcount senior pour maintenir les frames à jour", le business case est incomplet. La ligne n'est pas énorme. Mais elle n'est pas nulle, et sans elle le système dérive.

Ce que je mettrais dans la roadmap ce trimestre

Pour une équipe plateforme ou ingénierie dans un secteur régulé, trois mouvements concrets en réponse à l'essai de Shipper :

1. Nommez le rôle de framer sur l'organigramme. Pas besoin de créer un nouveau poste. Mais quelqu'un de précis doit avoir écrit dans sa description de poste : "définit les frames sous lesquels opèrent nos systèmes IA, les revoit trimestriellement, et est le point de contact avec compliance quand le frame change." Si personne ne le porte par écrit, tout le monde le porte un peu et personne ne le porte bien.

2. Auditez l'asymétrie du training set. Pour chaque système IA en production, un tableau : quel frame fournisseur avez-vous acheté, sur quelles données il a été entraîné, quelles décisions métier ont changé depuis. La distance entre ces deux colonnes, c'est la dette technique invisible. Probablement plus grande que ce que vous attendez.

3. Budgétez le travail post-automatisation, pas l'avant. Le coût du système n'est pas le coût de son déploiement ; c'est le coût de le maintenir pertinent pendant que le frame bouge en dessous. Un agent de revue de PR déployé en janvier 2026 sur une codebase Python 3.11 monolithique n'est pas le même système en décembre, une fois que vous avez migré vers des microservices Go. Le frame a changé. Quelqu'un doit le redéfinir. Ce "quelqu'un" est une ligne budgétaire, pas un volontaire.

La ligne que je trace

Je suis on the record comme positif sur les LLM et les systèmes agentiques en production. On les déploie, on les facture, les clients me paient pour ça. Ce que je vois — et ce que l'essai de Shipper articule mieux que la plupart — c'est que le gain réel d'automatisation n'apparaît pas sur la ligne "FTEs réduits" du business case. Il apparaît sur les lignes "décisions par semaine qu'on ne prenait pas avant", "PRs par semaine qu'on n'ouvrait pas avant", "incidents par mois qu'on n'attrapait pas avant". Aucune de ces lignes ne coupe les coûts. Toutes augmentent la capacité. C'est la conversation honnête.

Et derrière tout ça, il y a toujours quelqu'un qui définit le frame : ce qui vaut la peine d'être décidé, ce qui vaut la peine d'être ouvert, ce qui vaut la peine d'être détecté. Ce quelqu'un n'est substituable par aucun modèle entraîné sur le passé, parce que la question bouge plus vite que le cycle d'entraînement. Si votre programme IA cette année n'a pas nommé le framer — pas seulement le frame — vous construisez un système qui vieillira au rythme du fournisseur, pas à celui de votre métier.

Le travail intéressant, comme d'habitude, se passe juste à côté de l'endroit où tout le monde regarde.

---

Sources :

• Dan Shipper, After Automation, Every, mai 2026. every.to/p/after-automation

Vous mettez agents et LLM en production dans un environnement régulé et vous ne savez pas qui porte le rôle de framer dans votre équipe ? Parlez à un CTO — on vous aide à séparer le frame du travail du framer avant que le régulateur ne le fasse à votre place.