Deux horloges : la vitesse des agents et le temps des organisations

Deux témoignages opposés qui ne mesurent pas la même chose

Le 9 septembre 2026, un post LinkedIn venu de Maleus annonce que « d'ici 12 mois, plus personne ne lira le code de la majorité des applications ». Son auteur s'appuie sur ce qu'il observe dans l'entreprise, où aucun développeur n'écrit ni ne lit le code des applications déployées pour les clients, et l'explique par la confiance croissante accordée aux agents, par la généralisation des tests automatisés et par une charge cognitive devenue intenable face au rythme de production des agents.

Quatre semaines plus tôt, le 14 août, le blog d'ingénierie de Zalando publiait un retour sur deux ans et demi d'agentic engineering à l'échelle de plus de 250 équipes. Le bot d'approbation des pull requests par niveau de risque y auto-approuve 33 % des PR et réduit le lead time de 20 à 40 %. Dans le même article, Zalando juge pourtant prématuré de faire converger sa gouvernance et impose du code écrit à la main pendant les formations, parce que l'usage des agents freine l'apprentissage.

Les deux récits sont exacts et portent sur des objets différents. Maleus rapporte ce qui se passe dans un périmètre où l'entreprise a choisi son mode de production, Zalando ce qui se passe quand un système de travail existant, avec ses équipes, ses dépôts et ses règles, doit intégrer ces capacités. Dans une chronique publiée le 19 août, la CTO de Thoughtworks faisait un constat voisin en observant que dirigeants et ingénieurs semblent décrire des futurs opposés alors que les deux ont raison sur des parties différentes du même système. On peut parler de deux horloges, celle des modèles et des outils, et celle de l'organisation qui doit les absorber, et discuter d'un horizon de 12 mois ou de plusieurs années reste vain tant qu'on ne précise pas laquelle on regarde.

Les modèles se déploient, les définitions et les responsabilités se construisent

Sur la première horloge, le rythme se compte en semaines. Le 2 septembre 2026, Google DeepMind présentait Gemini 3.8 Flash comme la troisième sortie de sa gamme Flash en six semaines. Pour une organisation, adopter une telle version relève d'une décision d'achat ou de configuration, qui se prend vite et se défait tout aussi vite si le résultat déçoit.

La seconde horloge porte sur des éléments qu'aucune version ne livre. Dans un article du 14 août sur la fiabilité des agents en entreprise, Thoughtworks raconte le cas d'un agent d'analytique santé qui a produit une requête valide et un taux de réadmission plausible, qui était faux. Le relecteur clinique y a trouvé trois erreurs combinées, dont un regroupement de codes diagnostiques obsolète, et leur origine se situait dans deux couches gérées par des équipes différentes, dont une couche sémantique aux définitions périmées. Les auteurs parlent d'un échec de gouvernance du système plutôt que d'une hallucination du modèle.

Un modèle plus capable n'aurait probablement corrigé aucune de ces erreurs, puisqu'elles tenaient à des définitions partagées, à des responsabilités réparties entre équipes et à des métadonnées que personne n'était chargé de maintenir. Il en va de même pour les rôles, les droits de décision et les compétences, qui ne changent que lorsque des personnes décident ensemble de les faire évoluer, les éprouvent sur des cas réels et corrigent ce qui ne fonctionne pas. Zalando en montre la durée, puisque l'entreprise continue après deux ans et demi de construire son socle et estime encore trop tôt pour figer une gouvernance centrale.

Les gains individuels se voient avant les coûts collectifs

Les deux horloges ne produisent pas leurs preuves au même moment. Un billet publié le 3 septembre sur FredCavazza.net relevait que différentes études montrent un déploiement soutenu des outils d'IA générative en entreprise, alors que les gains collectifs restent largement en retrait des bénéfices constatés au niveau individuel. Dans la chronique du 19 août citée plus haut, son autrice rapporte de son côté qu'on lui montre régulièrement une application construite en un week-end grâce à l'IA, avant de lui demander pourquoi les équipes d'ingénierie ne livrent pas dix fois plus vite.

La démonstration est réelle et disponible tout de suite. Les questions qui décident de la valeur collective de ce logiciel, comme la protection des données clients, la résilience aux pannes ou la capacité à passer un audit, n'apparaissent qu'au moment où il devient une dépendance de l'entreprise. Les mesures de Zalando suivent la même chronologie, avec des pull requests plus volumineuses depuis la sortie de Sonnet 4 au deuxième trimestre 2025 et des points d'inflexion de complexité cyclomatique sur quatre codebases, des effets qui ne deviennent lisibles qu'après plusieurs mois et qui pèsent sur la maintenance bien après la livraison.

Au moment de décider, une direction dispose donc surtout de preuves venues de la première horloge, qu'il s'agisse d'une démonstration, d'un prototype ou d'un développeur qui produit davantage. Ce qui mesurerait le gain collectif, comme la dette, la complexité, les incidents ou le coût de maintenance, n'existe pas encore ou reste dispersé entre plusieurs équipes. Vous pouvez ainsi décider de bonne foi à partir de preuves exactes mais incomplètes, simplement parce que la seconde horloge n'a pas encore produit les siennes.

Distinguer les décisions faciles à défaire de celles qui ne le sont pas

En août 2026, la newsletter The Pragmatic Engineer a publié une enquête fondée sur des entretiens avec une vingtaine de CTO et de VP Engineering qui ont quitté leur poste ou envisagent sérieusement de le faire. Parmi les causes citées revient l'attente, chez certains fondateurs, d'une transformation « AI-native » obtenue comme par magie, avec des baisses de coûts d'ingénierie visées de 20 à 50 % et des prototypes générés par IA qu'il faudrait transformer en produits finis en quelques semaines.

Le témoignage le plus instructif est celui d'un VP Engineering qui a démissionné parce que son CEO avait été, selon lui, à la fois trop lent et trop pressé. Trop lent, parce que les produits IA lancés ne correspondaient pas aux attentes des clients, ce qui a provoqué du churn. Trop pressé, parce que les fonctionnalités IA sont passées avant la fiabilité du cœur de produit, avec des pannes et des clients perdus. Les deux reproches paraissent contradictoires tant qu'on raisonne sur une seule vitesse, et ils deviennent cohérents si les décisions produit ont suivi le rythme des annonces technologiques pendant que la capacité à livrer un produit fiable suivait un autre rythme.

Ces décisions n'ont pas le même coût de retour en arrière. Adopter un nouvel outil ou changer de modèle se décide vite et se défait vite, puisqu'il suffit en général de revenir à la configuration précédente. Réduire une équipe, supprimer un rôle ou laisser partir des personnes expérimentées se décide tout aussi vite, en revanche cela se défait à la vitesse de la seconde horloge, parce que ces personnes emportent le jugement sur ce qui peut aller en production, la connaissance des définitions implicites et la responsabilité de couches que personne d'autre ne maîtrise.

Le risque principal se situe dans cette asymétrie. Une organisation qui règle des décisions difficiles à défaire sur des signaux renouvelés toutes les six semaines engage des effets durables à partir d'informations périmées à la prochaine version, et risque d'alterner entre l'euphorie des démonstrations et la déception des effets collectifs. Avant de supprimer un rôle au motif que des agents peuvent en assumer l'exécution, vous devez donc savoir qui portera le jugement que ce rôle exerçait, combien de temps il faudra pour le reconstituer, et ce qui se passera si l'agent se trompe entre-temps.

Former aujourd'hui le jugement qui supervisera les agents demain

Certaines organisations vont nettement plus vite. Chez un client, les squads classiques ont été remplacées par 11 binômes associant un profil technique et un profil fonctionnel, avec une révision simultanée de la taille des équipes et des rituels. Ce type de cas suggère que la seconde horloge se raccourcit quand on redessine un périmètre en entier plutôt qu'en le faisant évoluer par petites touches, sans qu'une observation isolée permette d'en tirer une règle.

La question la plus sensible concerne l'apprentissage. Zalando impose du code écrit à la main dans ses formations mensuelles, parce que l'usage des agents inhibe l'apprentissage. Une tribune publiée le 3 septembre sur le site de Thoughtworks, dont l'auteur précise qu'elle n'engage que lui, pousse l'argument plus loin en s'appuyant sur « Programming as Theory Building », publié par Peter Naur en 1985. Selon l'auteur, c'est le code qui porte le modèle mental de l'équipe, et lorsque l'IA l'écrit en prenant silencieusement des décisions de conception, ce modèle ne se forme pas et le logiciel devient du legacy dès sa création.

Dans sa chronique du 19 août, la CTO de Thoughtworks considère que les ingénieurs expérimentés deviennent plus précieux, parce que leur rôle se déplace vers les garde-fous, les plateformes et les boucles de retour qui permettent à d'autres personnes et à des agents de construire en sécurité. Ce scénario suppose qu'ils continuent d'exister. Si les agents absorbent l'exécution qui formait ce jugement, l'outil qui accélère la première horloge ralentit une composante de la seconde, et on ne dispose encore d'aucune mesure de cet effet.

Combien de temps faut-il alors à une organisation pour absorber ces capacités ? À la mi-septembre 2026, aucune source ne mesure cette durée, et le seul cas longitudinal documenté, Zalando, construit encore son socle après deux ans et demi. La bonne unité de pilotage est donc la capacité d'absorption de l'organisation plutôt que la vitesse d'adoption des modèles, ce qui se traduit par trois décisions. La première consiste à ne régler les décisions difficiles à défaire, sur les effectifs, les rôles ou les compétences, que sur des indicateurs suivis sur plusieurs trimestres, comme la complexité du code, les incidents ou le lead time. La seconde consiste à traiter les définitions partagées et la responsabilité des couches de données avant d'étendre les agents, puisque c'est là que naissent les erreurs plausibles. La troisième consiste à protéger les parcours où le jugement se forme, quitte à y limiter l'usage des agents comme Zalando le fait en formation.