Le piège du plateau

J’ai récemment écrit sur la fatigue de l’IA, en argumentant que ce que les ingénieurs expérimentent n’est pas une condition chronique, mais une douleur de formation. Poussez à travers, adaptez-vous, sortez plus forts.

C’est tout à fait logique, mais il y a plus à cette histoire, et cela devient rapidement plus évident. Le véritable risque auquel sont confrontées les équipes d’ingénieurs en ce moment n’est pas l’épuisement. C’est le plateau.

La nouvelle division

Presque tous les ingénieurs seniors utilisent maintenant l’IA. Copilot, Claude, Cursor, Codex, vous pouvez les nommer. Cette partie est réglée. Si vous dirigez une organisation d’ingénieurs, vous voyez probablement des chiffres d’adoption importants et vous vous sentez bien à ce sujet.

Vous ne devriez pas.

Le chiffre d’adoption est sans importance. Ce qui compte, c’est la division qui se produit en dessous. Votre équipe se divise discrètement en deux groupes. Il y a les ingénieurs qui ont obtenu un gain de productivité et se sont installés, et les ingénieurs qui continuent de pousser chaque semaine. De nouveaux flux de travail, de nouvelles configurations d’agents, de nouvelles façons de décomposer les problèmes pour que l’IA les gère.

Les deux groupes apparaissent dans vos tableaux de bord en tant que “utilisateurs de l’IA”. Mais l’un est sur un programme de formation progressif. L’autre s’est arrêté au premier poids qui lui semblait confortable.

Il y a six mois, l’écart entre ces deux groupes était à peine visible. Maintenant, c’est évident pour quiconque prête attention. Dans six mois, ce sera structurel.

À quoi ressemble réellement le plateau

L’ingénieur qui a atteint un plateau ne fait rien de mal dans le sens traditionnel. Il est compétent. Il livre. Il utilise son agent pour des tâches simples et nettoie après. Il a peut-être obtenu un gain de productivité de 20 à 30 % et a considéré que c’était suffisant.

Le problème est que l’ingénieur à côté de lui n’est pas arrêté là. Cet ingénieur exécute désormais des flux de travail multi-agents, améliore les boucles de vérification, décompose des fonctionnalités entières en morceaux exécutables par l’IA, examine les choses au niveau architectural et non ligne par ligne, et livre à un rythme 2 à 3 fois supérieur à son rythme précédent. Non pas parce qu’il est plus talentueux. Mais parce qu’il a continué à se former tandis que tout le monde prenait une pause qui est devenue un trimestre de pause.

Ce n’est pas une question d’enthousiasme pour l’IA ou d’être un précurseur. La phase d’adoption précoce est terminée. Il s’agit d’adaptation continue par rapport à un ajustement unique. Et la différence de rendement entre ces deux approches devient impossible à ignorer.

La pression concurrentielle est réelle et s’accélère

Si vos équipes avaient le luxe de s’adapter à leur propre rythme, le problème du plateau serait une question de gestion de la performance. Agaçant, mais gérable.

Mais si vous regardez la situation plus large dans l’industrie du logiciel, il est probable que vous n’ayez pas ce luxe.

L’industrie du logiciel, dans l’ensemble, a été créée pour aider les humains dans le travail numérique : aider les agents de support à voir les cas entrants, suivre les réponses des clients, gérer les flux de travail. Maintenant, les agents IA déplacent l’ensemble du flux de travail et, avec lui, perturbent les plateformes SaaS sous-jacentes. En outre, avec l’IA devenant plus capable chaque jour, vos clients commencent à se poser une question : “Avons-nous toujours besoin de l’acheter, ou pouvons-nous le construire nous-mêmes maintenant ?” L’IA a commencé à réduire la barrière entre “acheter” et “construire” pour un ensemble croissant de cas d’utilisation. La capacité de rétention qui protégeait autrefois vos revenus s’affaiblit chaque trimestre.

Vos ingénieurs qui ont atteint un plateau fonctionnent à un rythme calibré pour un environnement concurrentiel qui n’existe plus.

La citation qui a tout reframé pour moi

Je l’ai entendue plus d’une fois maintenant, de la part de responsables de produits qui ont roulé leurs manches et ont codé des fonctionnalités, de la part de dirigeants d’ingénieurs qui ont reconçu des architectures défaillantes, dans différentes entreprises, dans différents contextes :

“Il m’était plus facile d’itérer sur cela avec mes agents que avec cet ingénieur.”

La première fois que je l’ai entendue, j’ai pensé que c’était de l’hyperbole. La troisième fois, j’ai réalisé que c’était un indicateur précurseur.

Comme je le vois, il y a des ingénieurs qui prospéreront dans ce nouveau monde et seront des “multiplicateurs” des capacités de l’IA. Pour cela, ils doivent être forts dans deux domaines, tous deux pouvant être auto-développés avec suffisamment de motivation intrinsèque et de curiosité intellectuelle :

• Ils opèrent “sur la même longueur d’onde” que leurs parties prenantes (responsables de produits, responsables d’ingénieurs, etc.). Ils comprennent ce que signifie “bien”, vous n’avez donc pas à leur expliquer les choses. Parce que s’ils produisent le même nombre de malentendus que votre agent de codage, l’agent gagnera toujours cette bataille. Il est disponible instantanément, 24 heures sur 24, et sans fatigue.
• Ils améliorent constamment leurs configurations IA, afin que lorsque vous leur donnez quelque chose, vous savez que cela sera fait non seulement bien (voir le point ci-dessus), mais aussi suffisamment rapidement pour suivre le nouveau rythme du marché.

Pourquoi c’est un problème de leadership, et non individuel

Il est tentant de le présenter comme la responsabilité d’un ingénieur individuel. “Suivez ou restez en arrière.” Mais si vous dirigez une organisation d’ingénieurs, cette formulation vous permet de vous décharger de la responsabilité.

Vos ingénieurs qui ont atteint un plateau ne se sont pas retrouvés seuls dans ce plateau. Ils ont atteint un plateau parce que rien dans leur environnement ne les a poussés au-delà de l’ajustement initial. Ils ont obtenu un gain de productivité raisonnable et personne ne les a poussés à aller plus loin, et l’inertie a fait le reste.

Les ingénieurs qui ont continué à pousser ? La plupart d’entre eux sont auto-motivés. Ils pousseraient de toute façon. Mais vous ne pouvez pas constituer une organisation d’ingénieurs uniquement avec des pionniers auto-motivés. La question pour les dirigeants est : comment déplacez-vous le milieu ?

Ceci est un problème de gestion du changement, et l’un de mes cadres de gestion du changement préférés vient du livre des frères Heath, Switch. La version courte : vous devez donner aux gens une direction claire, leur faire ressentir pourquoi cela compte, et remodeler l’environnement de telle sorte que le nouveau comportement soit le chemin de moindre résistance. Appliqué aux équipes d’ingénieurs, cela ressemble à :

Trouvez vos points lumineux et rendez-les visibles. Identifiez les ingénieurs qui ont poussé le plus loin dans leurs flux de travail IA et faites-les démontrer régulièrement à l’équipe. Pas de sessions de formation. Des démonstrations en direct de travail réel. Lorsque le milieu de votre équipe voit la différence entre son flux de travail et celui de l’adaptateur le plus avancé, cela crée un inconfort productif que aucun mandat ne peut égaler.

• Réduisez le changement. “Adopter l’IA” est trop abstrait pour agir. Cette sprint, clouez le test agentic de bout en bout, la prochaine sprint déployez-le dans toute l’organisation, et ainsi de suite. Des étapes spécifiques et gérables battent les programmes de transformation ambitieux à chaque fois, et les petites victoires comptent.
• Remodelez les valeurs par défaut. Codifiez le processus de vérification dans les compétences IA, et assurez-vous qu’elles sont déployées dans votre équipe et dans tous leurs agents. Définissez vos flux de travail et utilisez l’outillage qui les prend en charge. Faites du nouveau mode de travail le chemin de moindre résistance, afin que les gens s’y dirigent naturellement au lieu de devoir se battre pour y arriver.

La fenêtre se ferme

Voici la partie qui rend cela urgent plutôt que simplement important.

Actuellement, l’écart d’adaptation est une différence de performance. Vos ingénieurs qui ont atteint un plateau sont plus lents que vos ingénieurs adaptés, mais ils sont toujours productifs. Ils contribuent toujours. Vous pouvez les supporter.

Cette fenêtre se ferme. À mesure que les capacités de l’IA s’accélèrent et que la pression concurrentielle se cumule, le rythme minimum de travail d’ingénierie augmente. L’ingénieur “suffisamment bon” d’aujourd’hui n’est pas garanti pour être suffisamment bon le trimestre prochain. Non pas parce qu’il s’est détérioré, mais parce que le plancher a monté.

Les organisations qui parviennent à déplacer leurs équipes entières le long de la courbe d’adaptation, et non seulement les précurseurs, auront un avantage structurel cumulatif. Celles qui ne le font pas se retrouveront dotées d’un rythme de concurrence qui n’existe plus.

Chaque dirigeant d’ingénieurs avec qui je parle comprend cela intellectuellement. Très peu ont changé la façon dont ils dirigent leurs équipes en réponse. L’écart entre la compréhension et l’action est lui-même une sorte de plateau.

Il n’y a pas de rythme confortable

Dans l’article sur la fatigue de l’IA, j’ai soutenu que la douleur est la preuve que la formation est efficace. C’est toujours vrai. Mais la vérité qui suit est plus difficile : le poids continue d’augmenter.

Dans une salle de sport normale, vous pouvez choisir un poids confortable et le maintenir à jamais. Personne n’ajoute de plaques à votre barre sans vous demander. Dans le paysage logiciel actuel, chaque nouvelle version de modèle, chaque nouvelle capacité d’agent, chaque nouveau flux de travail que quelqu’un découvre et partage, la barre monte. Restez immobile et le poids finira par vous écraser.

Il n’y a pas d’espace confortable dans l’industrie du logiciel en ce moment. Pas pour les ingénieurs individuels, pas pour les équipes sur lesquelles ils travaillent, pas pour les entreprises que ces équipes construisent. La seule position sûre est le mouvement continu. Et la seule question qui compte pour les dirigeants d’ingénieurs est de savoir si toute votre équipe bouge, ou si seuls ceux qui auraient bougé de toute façon le font.