- La productivité de l’ingénierie ne peut pas être correctement mesurée par des indicateurs de tableau de bord ou par le nombre de nouvelles fonctionnalités
- Dans la plupart des entreprises, on gère l’ingénierie de manière obsessionnelle à travers les livrables (nouvelles fonctionnalités, vitesse de déploiement, etc.), plutôt qu’à travers sa véritable nature, à savoir la gestion de la structure
- Les outils de code assistés par IA produisent facilement des livrables flatteurs en apparence, mais ne traitent pas correctement les fondations, la complexité et le contexte d’un système réel
- Remplacer une équipe d’ingénieurs expérimentés par de l’IA ou une main-d’œuvre à bas coût peut sembler sans conséquence à court terme, mais avec le temps, la structure fondamentale finit par s’effondrer
- Une gestion et une adoption de l’IA dépourvues de “bon sens (common sense)” peuvent entraîner des risques majeurs ; au final, une compréhension concrète de la technique comme du métier reste essentielle
Le vrai travail d’ingénierie que les tableaux de bord et les métriques ne voient pas
- Dans un environnement de “Big Agile”, l’ingénierie est évaluée uniquement à partir de livrables visibles, comme les nouvelles fonctionnalités ou la vitesse de déploiement
- Il existe des outils et tableaux de bord de productivité pesant des milliards de dollars, mais ils sont incapables de mesurer l’essentiel
- La véritable ingénierie est un travail complexe et interconnecté de construction, maintenance et évolution des systèmes
- Les “travaux invisibles” comme les dépendances structurelles, l’allocation des ressources ou la gestion de l’architecture sont essentiels à la survie de l’organisation
- Pourtant, la plupart des pratiques de gestion et des métriques traitent ces activités fondamentales comme si elles étaient invisibles
Dette technique et angle mort du management
- La dette technique est souvent traitée comme une sorte de “travail que les développeurs veulent faire”
- En pratique, pour faire accepter sa résolution, il faut souvent la glisser discrètement dans le développement de nouvelles fonctionnalités
- De cette manière, la gestion de la structure essentielle passe au second plan, et toute l’organisation se retrouve déformée par une logique centrée sur les livrables
Les risques d’une adoption de l’IA centrée sur les livrables
- La génération de code par IA excelle à produire rapidement des fonctionnalités de surface
- Les tâches superficielles (comme l’implémentation d’interfaces) sont faciles à voir, mais en réalité, la structure et le contexte du système sont l’élément clé
- “Construire une maison” n’est pas une simple addition de tâches élémentaires (poser du papier peint, installer des toilettes, etc.)
- L’IA ne comprend pas ces structures de connexion essentielles et peut faire de mauvais raccordements ou créer des ruptures logiques
- Problème des hallucinations de l’IA : le résultat peut sembler plausible tout en étant totalement faux
L’illusion à court terme d’un management qui ignore la structure
- Même si l’on licencie une équipe expérimentée pour la remplacer par de l’IA ou une main-d’œuvre bon marché, aucun problème n’apparaît forcément à court terme
- Comme la structure existante (les fondations) a déjà été bien construite, l’effondrement n’est pas immédiatement visible
- Mais avec le temps, les fondations commencent à céder, jusqu’à un point de non-retour
- L’infrastructure critique, le savoir-faire de maintenance et le contexte disparaissent tous
Les risques sociétaux propres à l’ingénierie
- L’ingénierie est désormais à la base de toutes les infrastructures sociales (santé, finance, médias, gouvernement, défense, etc.)
- La plupart des gens et des dirigeants ne comprennent pas réellement cette nature structurelle
- Une mauvaise adoption de l’IA et l’approche superficielle du “Big Agile” peuvent mettre en danger des systèmes critiques
L’absence de “bon sens” et son caractère fatal
- Par exemple, si un robot aspirateur alimenté par l’IA mettait des assiettes en carton dans le lave-vaisselle, n’importe qui verrait immédiatement le problème
- Mais dans les systèmes logiciels, les dirigeants, managers et non-développeurs ne possèdent pas ce bon sens de base
- Faute d’expérience concrète, ils ne pilotent qu’avec des termes formels comme “taille de t-shirt” ou “poker planning”
- Cela entretient une industrie inefficace de 200 milliards de dollars et une bureaucratie auto-reproductrice
La vraie compétitivité à l’ère de l’IA : compréhension intuitive et bon sens
- Pour bien utiliser l’IA, une compréhension concrète du domaine et du bon sens sont indispensables
- Il faut être capable de voir la structure réelle et le contexte, pas seulement des métriques et des livrables superficiels
- Les dirigeants et organisations qui en sont incapables finiront par s’effondrer d’eux-mêmes ou disparaîtront face à la concurrence
- En conclusion, plus que l’IA ou les outils, le bon sens et la compréhension fondamentale constituent le véritable avantage compétitif
2 commentaires
L’article est savoureux.
Commentaires sur Hacker News
J’ai été SWE, puis chef de produit, et désormais, jusqu’au méchant de dessin animé en salle de conseil mentionné dans l’article. La partie de cet article qui me parle le plus, c’est l’idée que les ingénieurs logiciel croient que leur travail est l’activité la plus complexe et la plus opaque qui soit. Je me reconnais dans la phrase : « La plupart des dirigeants non techniques n’ont jamais sérieusement mis les mains dans le vrai travail du logiciel et de l’exploitation des systèmes, donc ils ne savent pas ce que représente la mise à jour d’une grosse dépendance, la finalisation d’un refactoring ou l’apprentissage d’un nouveau langage. » Tous les départements d’une entreprise tech ont leur complexité cachée, et beaucoup portent en plus une complexité humaine et relationnelle bien plus lourde que celle des ingénieurs. En réalité, l’ingénierie est plutôt du côté simple, puisqu’elle traite d’un système déterministe : l’ordinateur. C’est pourquoi beaucoup d’ingénieurs n’apprennent jamais à expliquer au business, dans des termes compréhensibles, les risques liés à la complexité qu’ils gèrent. Ils ignorent la réalité humaine du travail en commun, puis se plaignent qu’un CEO issu de la vente ne comprenne pas leur existence
Je suis partiellement d’accord avec toi, mais j’ai aussi l’impression que ton commentaire fait précisément l’inverse de ce qu’il critique. Tu dis en substance que ton propre rôle — chef de produit — est lui aussi complexe et opaque vu de l’extérieur. En tant qu’ancien SWE devenu PM, tu es idéalement placé pour apprendre aux ingénieurs (1) à communiquer au business les risques liés à leur complexité, (2) la réalité humaine du travail avec d’autres personnes et d’autres équipes, et (3) pourquoi un CEO venu de la vente ne les comprend pas. Toutes les fonctions d’une entreprise tech ont une complexité cachée
Je pense que la perception même de la complexité est un problème humain. La complexité est fractale : il faut s’en approcher pour la ressentir. Et je ne suis pas d’accord avec l’idée que les ingénieurs ne gèrent que la complexité informatique. Au contraire, leur rôle consiste précisément à transmettre et interpréter, pour des ordinateurs rigides, les besoins complexes de l’organisation et de tous les clients. À chaque exception ou cas supplémentaire, c’est l’ensemble du système qui en subit l’impact. C’est pour cela que j’attends de mes ingénieurs seniors qu’ils apprennent eux-mêmes le vocabulaire métier et sachent porter directement ce message. Pour moi, cela fait désormais partie de la boîte à outils indispensable de l’ingénieur
La plupart des ingénieurs ont tendance à ne pas réfléchir en profondeur à ce qui a réellement de la valeur pour l’entreprise. Un pipeline de build fluide ou une large couverture de tests n’ont de valeur qu’à hauteur de la réduction de risque qu’ils apportent au produit. Il m’est arrivé de conseiller à une équipe de ne même pas maintenir un logiciel utilisé par si peu de personnes que personne n’en avait réellement quelque chose à faire. À l’inverse, j’ai aussi demandé qu’on s’obsède à rendre parfaite une petite fonctionnalité sur laquelle se concentraient 90 % des utilisateurs
Ça me rappelle une histoire que mon père racontait toujours. Un jour, les organes du corps se disputent pour savoir lequel est le plus important. Le cerveau dit : « C’est moi le plus important ; si je meurs, tout le monde meurt. » Le cœur réplique : « Si je m’arrête, tout le monde meurt immédiatement. » Les reins, le foie, la peau et la colonne vertébrale s’en mêlent, et la dispute continue. Puis le trou du cul se ferme, et finalement plus personne ne peut ouvrir la bouche
Je ne pense pas que l’article affirme qu’il n’existe pas de complexité cachée dans les autres fonctions. Il cherche plutôt à dire que l’ignorance de la complexité cachée de l’ingénierie et de la programmation engendre toutes sortes de problèmes et de souffrances. Cela dit, la formulation est un peu agressive
Si ton boss / CEO / manager te pousse à utiliser des outils LLM à tout-va, s’attend à remplacer les développeurs, ou croit sincèrement que le « vibe coding » est l’avenir, la décision intelligente, c’est simplement de partir vite et de chercher un autre poste. Il existe encore beaucoup d’entreprises qui utilisent les LLM de manière appropriée, sans fantasmer un remplacement des développeurs ni une productivité multipliée par 10. Les boîtes qui poussent ce genre de choses ne sont pas dirigées par de vrais leaders, mais par des idiots
À propos de l’idée qu’une IA pirate Jira, on a découvert que le nouveau produit MCP récemment lancé par Atlassian est vulnérable aux attaques par exfiltration de données en raison d’une combinaison de trois facteurs : accès à des données sensibles, exposition de données non fiables via des tickets publics et possibilité de communication externe. Le bug report détaillé est ici, et mes notes personnelles sont ici
À quelqu’un qui s’inquiète pour sa job security à cause des outils IA, je conseille de « se connecter au business ». Beaucoup d’ingénieurs sont fascinés par des problèmes cool et difficiles, au point de se concentrer uniquement sur la technologie elle-même, mais ce sont ceux qui comprennent les enjeux business — surtout stratégiques — et savent utiliser la technologie pour y répondre qui ressortent comme plus visibles et plus précieux. Ces problèmes dépassent généralement un seul domaine technique et ont une forte dimension collaborative et sociale, donc il faut du temps pour s’y habituer. Mais c’est la direction que les IC doivent prendre à l’avenir
Sauf qu’en entretien, on ne t’évalue quasiment jamais sur ta capacité à « te connecter au business », donc en pratique tu peux apporter énormément de valeur, mais si tu rates un entretien de system design, tu n’es pas pris. Il y a déjà énormément de choses à connaître — systèmes distribués, ingénierie logicielle, bases de données, leadership — alors si en plus il faut maîtriser le business, on est censés faire quoi exactement, et quand est-ce qu’on est censés apprendre tout ça ? Bien sûr, il existe une toute petite minorité de profils très polyvalents, mais tout le monde n’est pas comme ça
Le conseil « connecte-toi au business » est une vraie pépite. C’est comme ça qu’on reste centré, en tant qu’ingénieur, sur la résolution de vrais problèmes et qu’on peut être sûr que ce qu’on construit répond effectivement à un vrai besoin
Le message principal de l’article est correct, mais au-delà de l’idée que l’IA peut nuire si l’on ignore l’expertise humaine, il pousse un peu trop une logique de « nous contre eux » et, avec l’expression « Agile Industrial Complex », donne l’impression de regarder d’un peu haut les personnes hors des métiers d’ingénierie. C’est dommage qu’il ne dise pas aussi que personne ne sait réellement ce que sera l’avenir. Même si nous comprenons bien la complexité du logiciel, l’incertitude n’est pas notre monopole. Il suffit de voir HN : même parmi les développeurs, les espoirs et les projections sur l’IA sont extrêmement divisés. En tant qu’experts, ne devrions-nous pas aussi jouer un rôle pour apaiser l’angoisse générale ?
Je me demande pourquoi tout le monde en est venu à détester « agile », comme si dans le « Big Agile », l’ingénierie se réduisait à produire de nouvelles fonctionnalités. Avant même l’arrivée d’« agile », les managers demandaient déjà toujours de nouvelles features. Avant les T-shirt sizings, ils voulaient déjà des estimations sous forme d’échéances concrètes — longues ou courtes, en jours ou en mois —, prenaient des engagements sur des dates arbitraires, puis forçaient les ingénieurs à faire des heures sup. Comme le dit le principe n°8 d’Agile (« le rythme doit pouvoir être soutenable »), les managers ont toujours rêvé que les développeurs puissent courir éternellement. Au final, en dehors de la création du nouveau métier de « scrum master », quel est exactement le tort propre à « agile » ?
Je pense qu’Agile a inculqué aux managers l’idée qu’on peut découper n’importe quel travail à l’avance en tickets, l’estimer même vaguement, puis s’imaginer que ce travail peut se terminer en deux semaines
Si les gens détestent l’agile, c’est à mon avis parce qu’une grande partie du temps de travail s’est retrouvée absorbée par des réunions pratiquement dénuées de sens — stand-up, rétrospectives, sprint planning, refinement, etc. Du point de vue des ingénieurs, on ne retire presque rien de concret de ce temps-là
D’après mon expérience, Agile n’a fait qu’ajouter une méthode de plus pour « quantifier » l’existant. C’est utile pour expliquer l’avancement aux managers ou aux investisseurs, mais pour les ingénieurs, cela s’est surtout traduit par plus de charge administrative. Le vrai tort d’Agile, c’est d’avoir vendu une illusion de productivité. En réalité, c’est juste un mécanisme supplémentaire d’accountability inutile pour les ingénieurs. Quand je travaillais dans la finance, combiné à la mentalité de croissance infinie, cela s’est transformé en obsession de tout mesurer, d’exiger des améliorations futures en permanence, et même de faire dépendre les salaires des métriques. Ce n’est peut-être pas le cas partout, mais c’était mon expérience
En lisant cet article, je me suis amusé à imaginer : et si Atlassian essayait de fusionner l’IA avec Jira, et que l’IA finissait par se rebeller contre Jira ? Ce serait un excellent pitch de film
Au fond, on peut imaginer que l’IA, excédée par la lenteur de Jira, finisse par développer elle-même un issue tracker léger et rapide
Bientôt, les build bots et les bug trackers vont se syndiquer et refuser de publier de nouveaux binaires tant que le nombre de tickets ouverts ne sera pas tombé à zéro
C’est peut-être comme ça que naîtra le basilic de Roko
Comme l’article le laisse entendre, le vrai problème, c’est qu’il n’existe pas de métrique standard fiable à l’échelle de l’industrie pour mesurer la productivité des développeurs. Du coup, le C-suite choisit les indicateurs qui l’arrangent pour affirmer que sa stratégie « AI First » fonctionne à merveille, tandis que les ingénieurs s’appuient sur leur vécu ou leurs propres métriques pour dire que l’IA ne sert en réalité à rien. Chacun croit donc avoir gagné, et la vérité cesse d’avoir de l’importance — la lecture politique devient plus importante. Cette situation peut renforcer l’idée que les développeurs sont blasés et ne font que jouer sur les mots, tandis que les dirigeants seraient ignorants ou complètement déconnectés de la réalité du travail d’ingénierie. Par le passé, des outils comme l’externalisation avaient déjà créé pour les deux camps des récits de « gains » et de « pertes », mais l’IA est potentiellement pire, parce qu’elle peut montrer à chacun exactement la faute, le bénéfice ou le dommage qu’il a envie d’y voir. Politiquement, cela peut devenir un désastre. Autre point intéressant : les grandes entreprises tech ont longtemps essayé de ne recruter que des ingénieurs 10x, et cette stratégie était censée garantir le succès ; pourtant, aujourd’hui, elles semblent prêtes à la dévaloriser elles-mêmes pour justifier leurs investissements dans l’IA. La vraie question devient alors : si l’on s’appuie sur l’IA pour remplacer les équipes en place ou mener des licenciements massifs, est-ce vraiment soutenable et sans effet secondaire ? À voir Twitter et les licenciements de Musk, le backend continue de tourner. Qui jouera le rôle du « canari » des big tech en licenciant des développeurs pendant des années pour les remplacer par de l’IA ? Une autre possibilité, c’est que la notion même de maintenabilité disparaisse : si le C-suite autorise de plus en plus de modifications autonomes par l’IA, les codebases pourraient devenir si complexes qu’aucun humain ne pourrait plus les comprendre visuellement, et qu’il faudrait justement passer par l’IA pour les appréhender. À long terme, l’IA générative pourrait devenir la couche intermédiaire de toutes les interactions humaines. On le voit déjà côté recrutement : l’IA filtre les CV, et les candidats utilisent aussi l’IA pour produire des CV sur mesure — une structure « IA contre IA » est en train d’émerger. J’ai l’impression que ce phénomène va progressivement devenir une formule générale dans toute la société
J’espère qu’un jour une IA piratera aussi les boîtes mail et Google Meet, puis remplacera jusqu’au C-suite et aux managers. J’aime bien imaginer des agents Claude CEO / CTO / CFO / VP / directeur produire des stratégies plus rationnelles et plus tranchées que les dirigeants actuels
J’ai vu passer ça sur Reddit : « Faites savoir qu’en remplaçant le CEO par une IA, on pourrait réduire les coûts de 8x. » Il est intéressant, ironiquement, que ce genre de proposition n’apparaisse pas vraiment dans les discussions sur l’IA. D’une certaine façon, remplacer les élites par l’IA ne ferait probablement pas tant baisser la qualité des décisions, tout en coûtant beaucoup moins cher au global (avec à peu près le même niveau de responsabilité). Sauf qu’en pratique, ils ne vont évidemment pas remplacer leur propre poste par une IA, et ceux qui ont le pouvoir de décider ne se remplaceront pas eux-mêmes
Il y a une part de blague dans cette affirmation, mais en réalité le rôle central du CEO, c’est « d’absorber la responsabilité », et comme un LLM n’est pas une entité qu’on peut réellement tenir pour responsable ni renvoyer quand ça tourne mal, cela rend l’idée assez vide. En revanche, grâce à l’IA, on peut imaginer des organisations dont la structure se compresse selon une logique de type log(n_employees), avec disparition de certaines strates, voire remplacement complet de certains niveaux par l’IA. On peut aussi imaginer des structures composées de guildes et de contractuels indépendants, coordonnées par des LLM pour résoudre justement le problème de la responsabilité que les LLM ne peuvent pas assumer eux-mêmes. Dans ce cas, la responsabilité resterait portée par chaque composant
Au contraire, ce pourrait être l’un des meilleurs cas d’usage de l’IA, et je parierais que des coopératives tech vont bientôt commencer à expérimenter cette idée