You can't afford to lead agentic engineering from the sidelines
- Auteur
- blog.kilo.ai
- Thème
- Leadership
- Mots-clés
- agentic engineering, leadership, engineering management, AI adoption, operating model
- Ton
- opinion
Résumé
Un ancien Directeur de l'ingénierie raconte comment, fin 2025, un CTO décide de passer son entreprise « tout en IA » : les ingénieurs écriront des tickets, les agents coderont la nuit, les humains relieront le matin. L'auteur, fort de son expérience d'adoption de l'IA, identifie la faille : on conçoit le modèle opératoire avant d'avoir compris ce que le travail est devenu côté ingénieur. Sa thèse : quand le cœur du métier mute, la distance hiérarchique devient un handicap, et le leader doit remettre les mains dans le code.
💡 Pourquoi ça compte
C'est le contre-discours nécessaire à l'euphorie de l'agentique : la transformation est réelle, mais elle se pilote depuis le terrain, pas depuis une slide de comité de direction. Un repère essentiel pour tout Engineering Director qui veut éviter le déploiement qui casse les équipes.
Analyse approfondie
Fin 2025, la direction d'une entreprise a tranché : on passe tout en IA. La vision du CTO était simple. Les ingénieurs définissent le travail dans des tickets. Les agents l'implémentent pendant la nuit. Les ingénieurs reviennent le matin pour relire le résultat et amener le code jusqu'à la ligne d'arrivée. C'était la réalité d'un engineering manager que l'auteur mentorait dans une autre entreprise. Cette conversation l'a marqué.
Le plan sonnait juste — de la façon dont les plans sonnent justes avant de toucher un vrai codebase. L'auteur a ressenti une résistance immédiate. Pas parce que l'idée était absurde : ce type de raisonnement devenait au contraire de plus en plus courant. À mesure que la hype IA s'intensifiait, beaucoup de dirigeants se sentaient sous pression — montrer un retour sur investissement, réduire les coûts, ou simplement prouver qu'ils ne décrochaient pas.
Ce qui le troublait, c'est que sa propre expérience lui disait que ça ne marcherait pas. Il avait passé une grande partie de 2025 dans son rôle précédent de Directeur de l'ingénierie à mener l'effort d'expérimentation et d'adoption de l'ingénierie assistée par IA. Il avait vu où ces outils aidaient, où ils échouaient, et combien de jugement supplémentaire ils exigeaient des membres de l'équipe.
De ce point de vue, le plan du CTO ne semblait pas seulement techniquement naïf. Il semblait être un bon moyen de transformer les ingénieurs en rédacteurs de tickets et en équipe de nettoyage — un déploiement capable de démoraliser une équipe avant qu'elle ait eu la chance d'apprendre.
L'auteur précise : le CTO avait raison de prendre l'IA au sérieux. Le passage à l'ingénierie agentique est bien plus qu'une simple mise à jour d'outillage. L'erreur était de croire qu'on peut concevoir le modèle opératoire avant de comprendre ce que le travail ressent du côté de l'ingénieur.
C'est l'écart sur lequel il revient sans cesse : les leaders demandent aux ingénieurs de changer leur façon de construire le logiciel avant d'avoir eux-mêmes vécu ce changement.
En tant que leader, il est censé sortir du cambouis : c'est une partie du métier. On dirige par les systèmes, les managers, le planning, les métriques, le design organisationnel. Mais quand le cambouis lui-même commence à changer, la distance devient un handicap.
Pour lui, la réponse a été de remettre les mains sur le travail. Pas pour reprendre la livraison. Pas pour revivre ses jours d'IC. Mais pour comprendre ce que ce changement exige réellement des gens qui le vivent. Une compréhension de seconde main ne suffirait pas. De nombreuses organisations passent rapidement de « l'IA compte » à « il nous faut un [modèle opératoire agentique] » — et c'est précisément ce saut que l'auteur invite à ralentir.