Avant de virer tes “glue people” pour de l’IA, lis ça

Combien d’équipes tiennent debout grâce à une ou deux personnes que personne ne voit dans les dashboards ? Spoiler : beaucoup. Et pendant que la tech bat des records de plans sociaux — près de 46 000 suppressions de postes dans la tech au seul mois de mars, “facteur IA” assumé par des CEO [6] — la même question revient : remplace-t-on vraiment ce qu’on croit remplacer ?

Le piège des heuristiques qui marchent “souvent”

John Cutler le formule mieux que personne : nos modèles mentaux sur “où l’IA fonctionne” sont justes assez souvent pour être crédibles, et faux assez souvent pour faire des dégâts structurels [1]. Les “glue people” — ces profils qui tiennent les liens entre équipes, traduisent les besoins métier, débloquent les angles morts — ne produisent pas d’artefacts visibles. Donc on les juge remplaçables par un agent.

Sauf que ce qu’ils font n’est pas du traitement de tickets : c’est de la maintenance de relations, de contexte et de confiance. Et ça, aucun copilote ne le porte aujourd’hui.

Les organisations qui se sont trompées ne s’en sont rendu compte que des mois plus tard. À ce moment-là, les dégâts étaient structurels et les personnes qui auraient pu aider étaient parties.

Tout le monde a Copilot. Personne n’apprend.

Robert Glaser, en s’appuyant sur Ethan Mollick, met le doigt sur le vrai sujet : les gains de productivité individuels ne deviennent pas automatiquement des gains organisationnels [2]. On voit des équipes utiliser Copilot en autocomplétion et basta. À côté, un dev sort une root-cause analysis en une heure avec Claude Code, quand ça lui aurait pris deux semaines. Et personne ne capitalise.

C’est le “messy middle” de l’adoption IA. La licence est partout, l’usage est partiel, caché, hétérogène. Et le management regarde le coût (“Où est le ROI des 2 M€ versés à Anthropic ?”) sans regarder l’apprentissage.

C’est aussi pour ça qu’Anthropic vient de dépasser OpenAI sur l’adoption business — 34,4 % vs 32,3 % en avril, selon le Ramp AI Index [3] : les entreprises bougent vite, mais ce qui se passe à l’intérieur reste opaque.

Les dashboards mentent. Les diffs d’équipe parlent.

Un team a les mêmes rituels, le même headcount, la même roadmap qu’il y a un mois. Et pourtant, il n’est plus le même. La senior qui challengeait les plans s’est tue. Les code reviews sont mécaniques. Les standups durent toujours 15 minutes, mais personne ne nomme les risques [4].

C’est ça, un team diff. Pas un diagnostic — un signal. Si tu ne regardes que l’état (les dashboards verts), tu détectes les problèmes quand ils apparaissent dans les chiffres. Si tu regardes le changement, tu les vois quand c’est encore peu cher à comprendre.

Et l’IA accélère ces glissements. Quand un dev se met à déléguer ses revues à un agent, quand un PO prototype seul au lieu de cadrer avec l’équipe, quand une décision se prend avec deux prompts au lieu de cinq voix — la productivité monte, et l’apprentissage collectif disparaît.

La dette de maintenance, vraie ennemie de la productivité IA

Voilà la partie qui m’a fait grincer des dents. James Shore le pose froidement : si ton agent IA double ta vitesse d’écriture, il faut qu’il divise par deux ta dette de maintenance, sinon tu échanges un boost temporaire contre une servitude permanente [5].

Son modèle de calcul est brutal. À coûts de maintenance “normaux”, une équipe passe sous 50 % de productivité en 31 mois. Si tu doubles la maintenance — exactement ce qui arrive quand tu génères du code en masse sans discipline — tu y tombes en 10 mois.

Le code écrit vite mais peu compris est une bombe à retardement. Et l’IA, mal cadrée, est une machine à empiler du code peu compris.

Stop starting, start finishing

Ce que pointe Yordan, c’est qu’on connaît le pattern depuis longtemps côté data : un ingénieur ultra-talentueux disparaît six semaines, revient avec une solution “objectivement correcte”, et le stakeholder dit “ce n’est pas ce que j’avais en tête” [7]. Le code est propre. La logique est saine. Et personne ne l’utilise.

L’IA ne corrige pas ça. Elle l’amplifie. Plus tu vas vite à produire, plus tu produis vite la mauvaise chose. Le problème n’a jamais été technique : il est de processus, de cadrage, de relation. Exactement le boulot des glue people.

Alors, qu’est-ce qu’on garde ?

Aaron Levie, CEO de Box, donne l’angle que je trouve le plus juste sur la question “AI va-t-il prendre ton job” [6] : tant qu’il restera de la demande non satisfaite et des problèmes mal résolus, l’IA absorbe la production, pas la valeur. Mais la valeur se déplace : vers le cadrage, vers le jugement, vers la coordination, vers tout ce qui permet à l’organisation d’apprendre.

Autrement dit : vers ce que faisaient déjà tes glue people.

Avant de signer le plan social, regarde les diffs d’équipe. Mesure ce qui s’apprend, pas seulement ce qui se produit. Et compte la dette de maintenance que tu génères avec ton agent. Si tu fais ça honnêtement, tu vas trouver des surprises — et probablement, tu vas garder des gens.

Qui sont tes glue people, à toi ? Tu les vois ?

---

Sources

1. TBM 417: Before You Fire All Your Glue People Because of AI
2. When everyone has AI and the company still learns nothing
3. Anthropic beats OpenAI on business adoption
4. Engineering managers should read team diffs, not just dashboards
5. You Need AI That Reduces Maintenance Costs
6. The best argument I’ve heard for why AI won’t take your job
7. 👷 Stop Starting Data Projects

Pour aller plus loin

• Why your AI agent has amnesia and why forgetting is the fix — une architecture mémoire inspirée du cerveau pour des agents qui n’oublient pas tout entre deux sessions.
• Tokenmaxxing, Promomaxxing, and Misaligned Incentives in Tech — quand mesurer la “consommation d’IA” devient un objectif, on se retrouve avec des devs qui brûlent des tokens pour rien.
• AI is the New Netflix — l’IA redessine le trafic broadband en mode upload-first, signe que les usages changent en profondeur.
• Seema Amble on X: “Is Software Losing Its Head?” — à l’ère agentique, la défense d’un système de record se déplace de l’UI vers les données et l’exécution réelle.

Cet article a été rédigé en m’appuyant sur une IA pour m’aider à synthétiser et structurer ma veille. Les idées, le choix des sources et la relecture restent les miens.