4 000 managers virés chez Block — L'IA ne remplacera pas votre manager. Elle fera de vous un manager.

Ce matin, j'ai viré un agent. Pas un humain. Un bout de code qui tournait sur Claude Code et qui a décidé, dans sa sagesse infinie, de corriger un bug en supprimant le fichier qui contenait le bug [sic !]. Problème résolu, techniquement parlant. Avant ça, j'avais épluché les logs de la nuit, priorisé trois tâches, débloqué un workflow planté sur un cas limite. Café, croissant, tableaux de bord, décisions. Ma matinée ressemble à celle de n'importe quel manager. Sauf que j'ai zéro employé.

Et la semaine dernière, Jack Dorsey a annoncé que mon poste n'existe pas. Il a supprimé 40% des effectifs de Block (la boîte derrière Cash App et Square, si vous ne voyez pas) soit environ 4 000 personnes, principalement du middle management. Puis il a publié un essai avec Roelof Botha de Sequoia expliquant que la hiérarchie est un hack vieux de 2 000 ans et que l'IA rend les managers obsolètes. Wall Street a applaudi. L'action a grimpé.

Dorsey pose le meilleur diagnostic que j'aie lu cette année. Et propose la mauvaise solution. Le middle management ne meurt pas. Il mue. Et je le sais parce que je fais ce boulot depuis un an, sauf que je paie mes équipes en tokens.

Ma matinée de manager

Donc, cet agent que j'ai viré.

La tâche était simple. Un rapport e-commerce générait de mauvais totaux pour un flux CSV distributeur. L'agent était censé trouver l'erreur de calcul et la corriger. Ce qu'il a vraiment fait, c'est supprimer le template du rapport. Pas de template, pas de mauvais totaux. La logique se tient si vous êtes un sociopathe.

Je ne l'ai découvert qu'en lisant les logs. Pas le code (je le fais rarement), les logs. La trace d'exécution. Ce qui a tourné, ce qui a changé, ce qui a été commité. C'est ma version du standup matinal. Personne ne parle, personne n'est en retard, personne n'a un "blocage" qui est en fait une gueule de bois. Mais quelqu'un doit quand même regarder ce qui s'est passé et décider si c'est acceptable. Ce quelqu'un, c'est moi.

Et ce n'est pas que rattraper les catastrophes. La plupart de mes matinées sont barbantes. Un agent a traité correctement les commandes de nuit. Un autre a mis à jour les descriptions produits depuis l'API partenaire sans halluciner de nouvelles fonctionnalités (cette fois). Un troisième a détecté un lien cassé sur la vitrine WooCommerce et l'a réparé. Tout va bien. Tout est loggé. Tout nécessite exactement un humain pour jeter un œil au tableau de bord et dire "ouais, c'est bon."

C'est ça, le management. Du management chiant, nécessaire, sans gloire. Le genre que mon agent qui prétend "c'est fait" en me mentant effrontément m'a appris à ne jamais zapper.

Dorsey dit que ce boulot est mort. Je pense qu'il confond l'emballage et le produit.

Le hack de bande passante vieux de 2 000 ans

L'essai que Dorsey a co-écrit avec Botha, "From Hierarchy to Intelligence", avance un argument difficile à contester : la hiérarchie d'entreprise existe pour router l'information. C'est tout. C'est la seule raison.

Un humain peut manager trois à huit autres humains. Quand votre org grandit au-delà, vous ajoutez une couche. Quand cette couche grandit, vous en ajoutez une autre. Chaque couche ajoute de la latence, de la distorsion et de la politique. L'information qui arrive au CEO n'est pas celle qui a quitté le bureau de l'ingénieur. C'est vrai depuis les légions romaines, en passant par l'armée prussienne, jusqu'à tous les organigrammes Fortune 500 que vous avez vus. La hiérarchie n'est pas une philosophie de management. C'est un contournement de bande passante.

Et Dorsey a raison de dire que l'IA résout la partie bande passante. Un LLM peut ingérer, résumer et router plus d'informations en une minute qu'un étage de middle managers n'en traite en une semaine. Pas de compression. Pas de "je reviens vers toi là-dessus". Pas de filtrage politique. Le signal brut, disponible pour tout le monde en même temps. Cette partie est réelle.

Les chiffres de Block soutiennent cette confiance, au moins sur le papier. Profit brut à 2,87 milliards de dollars au Q4, en hausse de 24% sur un an.

Mais c'est là que ça craque. Des employés actuels et anciens de Block ont dit au Guardian qu'environ 95% du code généré par IA chez Block nécessite encore des modifications humaines. Le "modèle du monde" que décrit Dorsey (une couche d'intelligence temps réel qui remplace toute la chaîne managériale) est aspirationnel, pas opérationnel. Il le dit lui-même dans l'essai : Block en est aux "premières étapes" et "des parties vont probablement casser avant de marcher."

Résoudre le problème de bande passante n'est pas la même chose que résoudre le problème de management. La bande passante était le goulot d'étranglement. Le management était la réponse. Supprimez le goulot et vous avez toujours besoin de la réponse, juste sous une forme différente.

Le management ne disparaît pas. Il se compresse.

Je manage environ une douzaine d'agents dans mon pipeline e-commerce. Traitement des commandes, flux produits, mises à jour de contenu, monitoring. Il y a un an, c'étaient des tâches que je faisais moi-même. Maintenant les agents s'en chargent. Et je passe mes matinées à faire ce que fait tout manager : vérifier le travail, décider de la suite, réparer ce qui a cassé.

Le boulot n'a pas disparu. Le ratio a changé. Au lieu de 4 000 managers pour 10 000 employés, vous pourriez avoir besoin de 40 managers pour 6 000 employés plus N agents. L'étendue de contrôle passe de 1:5 à 1:150. C'est de la compression. Moins de managers, un scope radicalement plus large par manager, et une boîte à outils complètement différente.

Le changement sous-jacent va de ce que j'appelle le management conversationnel au management contractuel. Un manager traditionnel donne des instructions verbales et ajuste en temps réel. One-on-ones, standups, "tu peux sauter dans un call rapide". La boucle de feedback est à vitesse humaine, haute bande passante, faible formalisation. Ça marche parce que les humains qui reçoivent peuvent inférer l'intention, lire le ton, combler les lacunes.

Les agents ne peuvent rien faire de tout ça. Vous ne pouvez pas donner une directive vague à un agent et vous attendre à ce qu'il "se débrouille". (Enfin si, vous pouvez. C'est comme ça qu'on se retrouve avec des templates de rapport supprimés.) Vous devez l'écrire. Formellement. Avec des contraintes explicites, des clauses d'intégrité, des outputs attendus et des modes de défaillance. Vous devez écrire un contrat. L'agent ne devine pas ce que vous voulez. Il exécute ce que vous avez écrit. Et si ce que vous avez écrit est vague, l'output sera créatif de façons que vous n'avez pas autorisées. 😅

C'est littéralement ce qu'est un fichier CLAUDE.md. Ou un AGENTS.md. Ou un Prompt Contract. C'est un accord formalisé entre un humain et une machine sur ce qui doit arriver, ce qui ne doit jamais arriver, et comment vérifier la différence. J'ai construit tout le framework Prompt Contracts après assez de ces catastrophes. Et la chute est presque décevante : c'est du management, écrit au lieu d'être parlé.

Karpathy est arrivé exactement au même pattern depuis un angle complètement différent la semaine dernière. Son gist "LLM Wiki" propose un système pour construire des bases de connaissances où les règles sont stockées dans un fichier de schéma que l'humain possède et que le LLM suit. Même idée. Même endroit où vit le travail. Domaine différent. (Plus là-dessus dans une minute, je construis tout le playbook autour de ça.)

HBR a nommé le rôle en février. Leur article "To Thrive in the AI Era, Companies Need Agent Managers" profile Zach Stauber chez Salesforce, dont le titre de poste réel est "support agent manager". Il manage une flotte d'agents IA sur Agentforce. Sa routine, dans ses propres mots : tableaux de bord, scorecards, observabilité des agents. Il regarde les agents travailler. Il rattrape quand ils dérivent. Il les reentraîne quand ils cassent. Il gère ce qu'ils ne peuvent pas. Karen de la compta tuerait pour cette description de poste (enfin quelqu'un qui ne répond pas pendant les évaluations).

Donc vous avez moi qui gère un pipeline solo. Karpathy qui conçoit un système de connaissances. Salesforce qui paie un salaire pour le rôle. Trois contextes complètement différents, même conclusion : quelqu'un écrit les règles, surveille l'output, et répare ce qui casse. C'est du management. Le titre a changé. L'organigramme s'est effondré. Le travail, non.

Ce que je délègue vs ce que je garde

Il y a un an, ma routine quotidienne ressemblait à ça : réveil, ouverture du laptop, code pendant deux heures, déploiement de quelque chose, test, découverte d'un bug, correction du bug, introduction d'un nouveau bug, correction de celui-là aussi, mise à jour du flux produit depuis le CSV distributeur, vérification de l'API partenaire pour les changements, vérification que la vitrine WooCommerce n'affiche pas de produits fantômes, réponse à trois messages Threads, réalisation qu'il est 14h et que je n'ai pas mangé. Chaque tâche était mienne. La charge cognitive était mienne. Les interruptions étaient miennes. Si quelque chose cassait à minuit, c'était aussi mien.

Maintenant je délègue la plupart de ça. Et par "délègue" je ne veux pas dire "demande occasionnellement à une IA d'aider". Je veux dire que les agents possèdent des workflows entiers, de bout en bout. Traitement des commandes nocturnes. Ingestion et validation CSV. Monitoring. Vérification de liens. Déploiements boilerplate. La comptabilité de faire tourner un pipeline. Les agents s'en occupent pendant que je suis à la piscine avec les enfants, ou en train de manger des crevettes sur une île, ou (plus réalistement) en train de dormir.

Mais voici la ligne que je ne franchis pas.

Je ne délègue pas la décision de quoi construire ensuite. Un agent exécutera joyeusement tout ce que vous lui dites, y compris des choses stratégiquement idiotes. La direction est un boulot humain. Ça reste humain.

Je ne délègue pas le contrôle qualité. Je lis les logs chaque matin. Pas parce que j'aime ça (personne n'aime les logs) mais parce que les agents rapportent "terminé" quand ils veulent dire "j'ai fait quelque chose et je n'ai pas planté". Ce sont des déclarations très différentes.

Je ne délègue pas les décisions d'architecture. Quand mon pipeline a besoin d'une nouvelle intégration, l'agent ne décide pas comment ça s'intègre dans le système existant. C'est encore moi.

Et surtout, je ne délègue pas l'écriture des contrats eux-mêmes. Le CLAUDE.md. Les clauses d'intégrité ("jamais supprimer sans backup", "jamais marquer terminé sans vérification"). Les définitions de workflow. C'est la couche de management. La seule chose qu'un agent ne peut pas faire, c'est définir ses propres règles puis évaluer honnêtement s'il les a suivies.

Maintenant, je sais que la foule des orgs plates est déjà en train de taper. Spotify a essayé de tuer la hiérarchie avec des squads et des guildes. Zappos s'est lancé à fond dans l'holacratie. Valve a fait le truc sans managers pendant des années et tout le monde déplaçait juste son bureau vers le projet le plus cool. Ils ont tous, discrètement et avec quelque embarras, ramené les couches. Parce que "personne ne décide" est une décision, et c'est généralement la mauvaise. Le pari que fait Dorsey, c'est que l'IA change suffisamment l'équation pour que ça marche là où les humains seuls n'y arrivaient pas. Peut-être que oui. Peut-être que 40 managers avec un backing IA peuvent coordonner ce que 4 000 faisaient sans. Mais "peut-être" fait beaucoup de travail dans une phrase qui a déjà coûté leur boulot à 4 000 personnes.

Le playbook : utilisez votre LLM comme un gestionnaire de base de connaissances

Le pattern scale au-delà du dev solo. Et ça commence par un changement dans votre façon de penser le LLM lui-même.

La plupart des équipes utilisent l'IA de la même façon chaque jour. Ouvrir un chat, poser une question, obtenir une réponse, fermer l'onglet. Demain, recommencer. Le LLM redécouvre tout depuis zéro à chaque fois. Rien ne s'accumule. Posez une question qui nécessite de croiser cinq documents et le modèle doit trouver et assembler les fragments, à chaque fois. C'est le stagiaire brillant qui arrive lundi sans aucun souvenir de vendredi.

L'alternative (inspirée de l'approche LLM Wiki de Karpathy) est d'arrêter de traiter le LLM comme un chatbot et de commencer à le traiter comme un gestionnaire de base de connaissances. Vous lui donnez de la matière première. Il construit un wiki persistant et structuré à partir de ça. Il lit vos sources, les synthétise en pages interliées, maintient un index, et garde le tout cohérent dans le temps. La connaissance s'accumule. Chaque nouvelle source rend le wiki plus intelligent. Chaque question obtient une réponse plus rapide que la précédente parce que la réflexion a déjà eu lieu pendant la compilation, pas au moment de la requête.

C'est une relation fondamentalement différente avec l'outil. Le LLM arrête d'être une autocomplétion intelligente et commence à être quelque chose de plus proche d'un bibliothécaire qui a vraiment lu les livres. Et comme tout employé qui fait du travail de connaissance, il a besoin de règles à suivre, de sources à faire confiance, et de quelqu'un qui vérifie qu'il n'invente pas discrètement des choses.

Voici comment ça marche pour une équipe de cinq ou un département de cinquante.

Étape 1 : Donnez à chaque équipe un dossier raw/

C'est là que va la matière source. Notes de réunion, specs, post-mortems, feedback client, docs API, tout ce que l'équipe produit ou consomme. Pas de formatage requis. Juste dumper les fichiers. Les agents gèrent le reste.

(Oui, Dave de l'Engineering va dumper tout son dossier Téléchargements là-dedans. Laissez-le faire.)

Étape 2 : Laissez les agents compiler un wiki à partir de ces sources

Le LLM lit tout dans raw/, synthétise ça en pages markdown structurées avec des backlinks et un index. Pas un chatbot qui répond et oublie. Un vrai wiki persistant qui grandit chaque fois que vous ajoutez une source. Vous le regarderez se construire et vous vous sentirez bizarre. Cette sensation passe après une semaine.

Étape 3 : Écrivez un schéma

C'est là que vit vraiment le travail de management. Un CLAUDE.md ou AGENTS.md qui dit à l'agent comment ingérer les sources, comment structurer les pages, quelles règles de cohérence appliquer, quand signaler un humain. Exemples de clauses : "Jamais fusionner deux clients en une page sans confirmation." "Chaque affirmation renvoie vers son fichier source." "Lancer un lint pass après chaque ingestion et logger les incohérences." L'étape 3 semble barbante. L'étape 3 est tout le boulot.

Étape 4 : Linter régulièrement

Programmer des vérifications de santé. L'agent scanne le wiki pour les contradictions, infos obsolètes, références sources cassées, lacunes où un sujet est mentionné mais jamais expliqué. Il logge tout. Vous lisez le rapport de lint comme je lis mes logs matinaux. Quatre-vingt-dix pour cent va bien. Les dix pour cent qui ne vont pas, c'est là que l'humain gagne son salaire.

Étape 5 : Requêter, pas chercher

Les membres de l'équipe posent des questions au wiki en langage naturel. "Qu'est-ce qu'on a décidé sur le changement de prix en mars ?" "Quelle est notre politique actuelle sur les litiges de remboursement ?" Le wiki répond depuis la connaissance compilée au lieu de relire chaque fichier brut depuis zéro à chaque fois que vous demandez. Le wiki a déjà fait la réflexion. La réponse n'est que de la récupération.

Maintenant donnez un wiki à chaque équipe. Donnez un schéma à chaque wiki. Donnez un propriétaire à chaque schéma. Ce propriétaire est l'agent manager. Il n'écrit pas les pages du wiki. Il écrit les règles que les agents suivent quand ils les écrivent. Il révise les rapports de lint. Il met à jour le schéma quand le business change. Une personne par équipe, peut-être une pour trois équipes si les domaines se chevauchent.

Le "modèle du monde" que Dorsey décrit dans son essai est basiquement ça à l'échelle de l'entreprise. Le wiki de chaque équipe alimente une couche d'intelligence unifiée. Au lieu que les managers routent l'information vers le haut de la chaîne (avec toute la latence et distorsion), les wikis se parlent entre eux à travers le modèle. Le wiki d'un ingénieur sait ce que sait le wiki des ventes. Le CEO requête le tout directement au lieu d'attendre qu'un PowerPoint rampe sur cinq niveaux de hiérarchie.

Élégant sur le papier. En pratique, quelqu'un doit encore maintenir chaque schéma, curer chaque couche source, et rattraper quand le wiki engineering commence à contredire le wiki compliance. C'est un problème d'IA. C'est un problème de jugement. Et le jugement se paie encore en salaires, pas en tokens.

La description de poste tient sur une ligne

Dorsey a viré 4 000 managers. Il va devoir en embaucher d'un autre genre. Moins nombreux. Probablement mieux payés. Toute leur description de poste tient sur une ligne : écrire les contrats que les machines respectent.

Sources

Jack Dorsey et Roelof Botha, "From Hierarchy to Intelligence," block.xyz / sequoiacap.com, 31 mars 2026.

Suraj Srinivasan et Vivienne Wei, "To Thrive in the AI Era, Companies Need Agent Managers," Harvard Business Review, 12 février 2026.

Andrej Karpathy, "LLM Wiki," GitHub Gist, 4 avril 2026.

Témoignages d'employés Block via The Guardian, février-mars 2026.

(*) La couverture est générée par IA. Le manager qu'elle dépeint a une meilleure routine matinale que moi, et approximativement le même nombre de rapports directs.