L’expertise métier a toujours été le vrai moat

• La difficulté du logiciel n’a jamais vraiment été de saisir du code, mais de comprendre des règles du monde réel comme la paie ou le transport pour construire un modèle métier ; le code n’était que le produit de cette compréhension
• L’IA agentique permet de produire du logiciel même sans compréhension métier, et déplace le goulot d’étranglement de « peut-on le construire ? » vers « peut-on juger si c’est correct ? »
• Des experts métier comme les répartiteurs logistiques, les codeurs cliniques ou les actuaires peuvent ne rien connaître au code, tout en étant capables de déterminer si un résultat respecte les règles juridiques, de facturation ou d’exploitation
• Un ingénieur généraliste peut valider l’architecture et la fiabilité, mais dans des domaines comme le codage clinique, où la bonne réponse dépend étroitement de la connaissance métier, il peut laisser passer des erreurs plausibles
• La compétence la plus précieuse devient le jugement permettant de valider à la fois la solidité du code généré et la véracité de ses résultats ; pour les ingénieurs expérimentés, investir dans l’expertise métier devient encore plus important

---

Le goulot d’étranglement du logiciel se déplace de l’implémentation vers la validation

• La partie difficile de l’écriture logicielle n’a jamais été la saisie du code en elle-même, mais la construction préalable d’un modèle métier dans sa tête
  • Un système de paie doit prendre en compte les saisies sur salaire, les déductions avant impôt et le traitement des périodes de paie qui chevauchent une date de changement de salaire
  • Une application de transport doit intégrer les flux GTFS, la différence entre trip et route, et les raisons pour lesquelles un bus « à l’heure » peut malgré tout être incorrect
  • Le code était la traduction de cette compréhension ; acquérir cette compréhension constituait le vrai travail
• L’IA agentique affaiblit le lien entre compréhension métier et production logicielle
  • Il est désormais possible de produire du logiciel sans construire soi-même le modèle métier
  • Cela ébranle l’hypothèse sur laquelle reposait l’ensemble des métiers du logiciel
• Comme dans la perspective de l’an dernier, l’idée que ces outils amplifient les développeurs seniors dotés de discernement est juste, mais insuffisante
  • Le changement plus précis est que le goulot d’étranglement est passé de « peut-on le construire ? » à « peut-on juger si c’est correct ? »

Ceux qui utilisent bien les outils agentiques

• Les experts métier peuvent reconnaître la bonne réponse sans connaître le code

  • Des personnes comme les répartiteurs logistiques, les codeurs cliniques ou les actuaires peuvent être incapables de lire une stack trace ou d’expliquer la différence entre une hash map et une list
  • Mais en regardant un planning généré par un agent, elles savent immédiatement quel conducteur ne peut légalement pas assurer ce service
  • Elles peuvent aussi voir qu’une combinaison donnée de codes de facturation d’assurance ne sera pas remboursée
  • Elles ont passé dix ans dans les entrées et les sorties ; elles connaissent donc la bonne sortie pour une entrée donnée
  • Ce que l’agent leur apporte, c’est la capacité de produire du code qui leur manquait ; ce qu’elles apportent à l’agent, c’est ce référentiel de vérité (ground truth) qu’il n’a pas

• Les ingénieurs généralistes peuvent ne pas distinguer un logiciel bien construit d’un logiciel correct

  • Un bon ingénieur généraliste connaît l’architecture, la fiabilité, les tests, et sait comment éviter qu’un système ne s’effondre à 2 heures du matin
  • Mais dans un domaine comme le codage clinique, il peut ne pas savoir distinguer une réponse plausible mais fausse d’une réponse correcte
  • L’agent peut produire quelque chose qui compile et passe les tests imaginés par l’ingénieur, tout en introduisant des erreurs subtiles et coûteuses dans les règles de facturation
  • Un ingénieur peut vérifier si un logiciel est bien construit, mais lorsque la justesse est entièrement définie par un domaine qui n’existe pas dans sa tête, il devient difficile d’en valider l’exactitude

• Avant les agents, le parcours d’apprentissage favorisait les ingénieurs

  • Les ingénieurs pouvaient suivre des experts, lire des spécifications, faire des erreurs en production et apprendre progressivement le domaine
  • Dans beaucoup de secteurs, ce processus était au cœur de la progression de carrière
  • Les experts métier n’avaient pas de parcours symétrique
  • Apprendre à produire un logiciel fiable prend des années, et c’était une voie qu’ils pouvaient difficilement emprunter en pratique

• Les outils agentiques n’ont fait s’effondrer qu’un seul des deux parcours

  • La capacité des ingénieurs à traduire un modèle métier en code exécutable, qui était leur avantage, est devenue bon marché
  • La capacité des experts métier à savoir ce qui est correct, qui était leur avantage, n’est pas devenue bon marché
  • On ne peut pas acquérir cette capacité avec de simples prompts, et il n’existe pas de skill file contenant le savoir tacite de quelqu’un qui a réussi des milliers de traitements de paie

• Les personnes les plus précieuses sont celles qui peuvent valider aux deux niveaux

  • Celui qui sait à la fois si le code généré est sain et si les réponses qu’il produit sont vraies devient le plus important
  • Si l’on peut écrire un test du type « un conducteur ne peut pas dépasser 11 heures », c’est parce qu’on connaît la règle
  • Si l’on peut juger que ce test a lui-même du sens, c’est parce qu’on sait ce que l’on teste
  • L’agent fait le travail de transcription, et l’humain exerce son jugement à la fois sur la couche du code et sur la couche métier
  • Pour les ingénieurs expérimentés, l’investissement important consiste à acquérir un modèle profond et validé du domaine réel
  • La valeur de la capacité mécanique à transformer une idée claire en code propre a fortement diminué
  • Ce qui reste rare, c’est une compréhension profonde de véritables secteurs, outils, cadres réglementaires et processus physiques
  • Il faut choisir un domaine et l’apprendre comme on apprenait autrefois un langage de programmation ou un framework
  • La partie que les agents ne peuvent pas remplacer, et celle dont la valeur a le plus augmenté aujourd’hui, c’est l’expertise métier

[GN⁺]

Commentaires sur Hacker News

• Je ne sais pas combien de grandes tirades il faudra encore avant qu’on admette que personne ne sait vraiment comment utiliser l’IA à l’échelle individuelle
  Au début, on disait qu’il suffisait d’être un bon développeur et d’apprendre à utiliser l’IA, ensuite que tout se jouait sur les capacités d’architecture, puis que c’était avant tout une question de goût, et maintenant on affirme que seuls les experts métier comptent
  Tant que l’amélioration ou la stagnation de l’IA ne se stabilisera pas dans un état prévisible, ce genre d’interprétation restera probablement vide de sens et, le plus souvent, faux

  • Ce dont je suis de plus en plus convaincu, c’est que les outils d’IA rendent le développement logiciel plus difficile
    Ils le rendent plus difficile parce qu’ils rehaussent fortement le seuil de ce qui est possible. Un développeur solo peut maintenant prendre en charge des projets bien plus complexes, et au final la vraie contrainte a toujours été le temps ; l’IA aide simplement à faire davantage dans le temps imparti
    Mais ce qu’il est possible d’accomplir dans ce temps est devenu bien plus difficile. Il faut comprendre beaucoup plus de choses et sortir largement de sa zone de confort d’avant l’IA
    Avant, il était acceptable de passer plusieurs jours à préparer un refactoring de codebase ou la sortie d’une petite fonctionnalité parce qu’il fallait apprendre une nouvelle bibliothèque ou entrer dans une partie du système qu’on ne maîtrisait pas
    Les agents de code permettent de gravir cette courbe d’apprentissage bien plus vite, mais il faut quand même la gravir soi-même. Et le volume d’informations qui arrive est bien plus important
    Si l’on craint que des vibe coders non techniques nous prennent notre travail, la bonne réponse est de faire du logiciel nettement meilleur qu’eux. Et pour ça, il faut plus de compétence, plus d’ambition, plus d’expérience, et ce n’est pas facile
  • Les LLM ne sont qu’un outil de plus dans l’arsenal. Ils ne sont pas tout-puissants et doivent être maniés avec précaution comme n’importe quel autre outil
    La comparaison qui me paraît la plus juste jusqu’ici, c’est celle entre une visseuse-perceuse électrique moderne et des outils plus anciens comme le tournevis ou la perceuse manuelle
    Par rapport aux anciens outils, on peut obtenir des résultats étonnants en très peu de temps
    Par exemple, on peut raconter une anecdote impressionnante du genre : « J’ai fixé le plancher en une heure alors que ça m’aurait pris la journée entière, et j’ai même eu le temps de fumer plusieurs cigarettes entre-temps. » Avec un cloueur, ça aurait peut-être pris deux fois moins de temps, mais plus tard il aurait été difficile de soulever facilement ce plancher, et cela aurait peut-être coûté deux fois plus cher
    J’utilise aussi plusieurs LLM on-premises et j’ai accès à d’autres modèles, donc je finirai peut-être un jour par pousser cette analogie jusqu’aux différences entre marques
    Mais je ne pense pas qu’ils vont se mettre à chercher un nouveau travail. Une visseuse-perceuse n’est ni un charpentier ni un ouvrier de chantier, et sans humain elle ne sert à rien
  • Vous vous souvenez du battage autour de la programmation orientée objet il y a 20 ans ? On nettoie encore aujourd’hui dans notre codebase les dégâts laissés par tous ceux qui avaient feuilleté le livre du GoF en diagonale et balançaient des patterns partout sans comprendre pourquoi
    Dans 20 ans, je pense qu’on nettoiera les déchets coécrits avec Claude
    https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...
  • Même avant l’IA, il arrivait déjà qu’un expert métier ait plus de valeur qu’un excellent développeur logiciel
    En 2018, j’ai vu quelqu’un sans la moindre expérience en programmation créer en un mois un outil qui rapportait déjà correctement, simplement parce qu’il connaissait un marché de niche précis
    Il m’a montré une partie du code ; c’était aussi brouillon que mon tout premier programme, mais ça résolvait un vrai problème
  • Ça me rappelle la manière dont les spectateurs ou le grand public évaluent le sport professionnel
    Par exemple, ils disent : « Pour être bon en sport, il faut une symétrie parfaite, et c’est fortement corrélé à la stabilité du développement fœtal. Plus quelqu’un est symétrique, plus son développement est parfait. »
    Puis, quelques années plus tard, on apprend que Bruce Lee avait une jambe nettement plus courte que l’autre, et qu’Usain Bolt présentait lui aussi une asymétrie comparable dans son développement
    Alors ils se replient sur leur position initiale en disant que ce sont des exceptions qui ne remettent pas en cause la règle générale
    Il suffit de créer quelque chose d’intéressant, et ça peut marcher

• J’ai récemment audité une appli presque entièrement construite en vibe coding. Son propriétaire disait qu’elle était quasiment prête à être lancée et qu’il ne fallait qu’une vérification rapide
  En regardant, j’ai vu que la conception de la base de données était catastrophique. Certaines fonctionnalités marchaient, d’autres non. J’ai expliqué ce qui manquait et pourquoi ça cassait. Comme dans le billet d’origine, cette personne était un expert métier
  Rien que le mois dernier, elle a consommé des milliards de tokens, et les outils s’améliorent vite. Mais donner de l’IA à un expert métier ne supprime pas le besoin d’un ingénieur logiciel
  Un expert métier peut créer du logiciel avec l’IA, et un ingénieur logiciel peut apprendre le métier avec l’IA. Les deux apportent des expertises différentes

  • J’ai l’impression que la direction vers laquelle je vais ressemble finalement à celle d’un platform engineer
    Il s’agit de construire les garde-fous, la validation, les bibliothèques de prompts, les agents et la revue manuelle qui protégeront les experts métier lorsqu’ils commenceront à utiliser des agents de code
    C’est un peu semblable au support client interne T2/T3 ou aux ingénieurs support. Le rôle n’est pas de résoudre soi-même 100 % des problèmes du quotidien, mais de repérer les points à risque, les cas limites étranges, et de vérifier que toute la configuration est correcte
    Bien sûr, cela implique aussi beaucoup de sujets transverses
  • Mon expérience est similaire. Les LLM facilitent l’exploration d’autres domaines, mais ils ne font pas de vous un maître de ce domaine. Il faut toujours de véritables connaissances métier spécialisées
    En revanche, comme outil pour tester rapidement de nouvelles idées et creuser des pistes, c’est excellent. Avec de la curiosité, cela peut même devenir un formidable accélérateur d’apprentissage
  • J’ai du mal à comprendre le passage sur les « milliards de tokens consommés rien que le mois dernier »
    J’utilise Claude Code toute la journée (Opus 4.6, réglage d’effort maximal), et je ne vois pas comment c’est possible. Je me demande aussi si un tel volume d’usage apporte réellement un retour sur investissement
    C’est probablement moi qui passe à côté de quelque chose, mais je ne vois vraiment pas comment on peut arriver à ce niveau
  • L’expertise métier, combinée à un état d’esprit QA constant, pourrait peut-être remplacer un ingénieur logiciel, mais un état d’esprit QA constant est rare

• J’ai récemment vécu un très bon exemple de cela
  J’étais en voyage de pêche, et j’ai demandé au capitaine s’il accepterait de jeter un œil à l’application gratuite sur laquelle je travaille (https://oceanconnect.ca) pour voir si elle pouvait lui être utile dans son travail
  Je ne sais pas vraiment comment les gens utilisent les données marines en mer. Je ne sais pas très bien ce qu’ils veulent savoir, ni pourquoi. Les questions et les informations sur la manière dont les gens utilisent les données et sur ce qu’on peut faire avec ces données ont afflué, et je n’y étais pas du tout préparé ; c’était vraiment génial et fascinant d’obtenir ce point de vue
  Cela m’a rappelé qu’un modèle n’est pas le système qu’il abstrait, et que le savoir nécessaire pour développer un modèle n’a presque rien à voir avec le savoir nécessaire pour l’utiliser
  Cette personne avait une connaissance incroyable de la façon dont les données météorologiques sont utilisées sur l’eau. D’une certaine manière, elle connaissait mieux les données que moi et, même sans forcément s’en rendre compte ou comprendre leur représentation numérique, elle construirait probablement une application bien plus utile pour des gens comme elle si elle savait simplement programmer
  Je me suis dit que si des gens comme ça pouvaient mettre leurs idées sur un écran avec un LLM devant eux, ils pourraient créer des choses vraiment formidables. Si j’ai un jour le financement, j’aimerais interviewer des personnes qui vont en mer tous les jours afin d’affiner le produit. Cette connaissance du domaine est extrêmement spécialisée, et les gens qui ont vécu pendant des décennies dans un domaine complexe savent des choses qu’on n’imaginerait jamais

• Le généraliste logiciel décrit dans cet article possède lui aussi une expertise métier. Son domaine, c’est le logiciel
  Si vous êtes aujourd’hui un excellent ingénieur logiciel généraliste, vous n’allez pas vous précipiter dans un domaine pris au hasard pour fuir l’IA. Le logiciel est votre domaine, et vous allez y rester pendant qu’il s’étend et se transforme

  • Oui. Et en plus, nous avons maintenant ce nouveau superpouvoir qu’est l’IA, qui permet de creuser presque n’importe quel domaine et d’y faire monter rapidement son niveau d’expertise. À mon avis, l’orientation de l’article est plutôt inversée

• La bonne nouvelle, peut-être, c’est que même le meilleur comptable artisan du tableur de l’Ouest aura finalement besoin d’un minimum d’expérience en programmation pour faire des vérifications
  On peut demander à un LLM : « que fait ce code, et est-ce que X est toujours vrai quand Y se produit ? », mais cela ne fait qu’imbriquer un problème de vérification dans un autre problème de vérification

• Le cœur du sujet n’a jamais été le code
  Après avoir développé ces cinq dernières années des logiciels pour le capital-risque et le private equity, cet article me parle vraiment. Écrire du code est de loin la partie la plus facile de mon travail ; la partie difficile, c’est la finance d’ingénierie et le contexte subtil nécessaires pour comprendre ce dont les entreprises clientes ont réellement besoin
  On plaisante souvent en disant que, si possible, on aimerait embaucher un comptable de fonds senior et lui apprendre à programmer. Le problème, c’est qu’il n’existe presque pas de profils comme celui-là. Et il est tout aussi difficile d’amener un ingénieur à comprendre la comptabilité de fonds assez finement pour en faire un logiciel

  • Avoir uniquement l’expertise métier sans la technique mène, à partir d’un certain point, au mieux à une énorme dette technique
    En réalité, environ la moitié de ma carrière a consisté à gérer des choses faites par des gens qui avaient assez de connaissance métier pour fermer des tickets ou des epics, mais qui finissaient par laisser énormément de dette technique
    Par exemple, même avec la connaissance du domaine, les gens font des erreurs, ne connaissent pas de meilleure méthode, n’intègrent pas le feedback ou, pire, ne revérifient pas ce qu’un agent de code a écrit ; il fallait donc revoir les PR avec un soin extrême
    J’ai aussi souvent refactoré des choses « techniquement correctes mais si mal écrites qu’elles provoquaient des timeouts ou faisaient hurler le manager / DBA »
    Un très bon ingénieur logiciel a la capacité et la volonté d’apprendre le domaine, mais encore faut-il qu’il existe un moyen de l’apprendre. J’ai travaillé dans des entreprises, des équipes ou avec des collègues qui rendaient cela possible, et dans d’autres où l’on prétendait que c’était important alors qu’en pratique il fallait tout déduire de JIRA, des réunions et des remarques lâchées au passage par des personnes non-IT
    Le grand changement de paradigme de ces cinq dernières années, à mon avis, c’est que la plupart des entreprises attendent des gens qu’ils travaillent jusqu’à la limite, ce qui finit par être contre-productif en empêchant de prendre le temps d’avoir les conversations importantes
    La culture est une variable majeure. Il y a au moins des endroits où l’on peut avoir une courte discussion sur le côté ou planifier facilement une réunion, et d’autres où demander du temps pour discuter sérieusement donne l’impression qu’il faudrait lancer une pétition sur change.org
    Malgré tout, le point central est juste : au final, les exigences sont plus importantes que le code. J’ai aussi vu des endroits où toutes les exigences étaient remplies, où l’équipe avait validé les décisions d’architecture, et où pourtant une fonctionnalité était retardée parce qu’une personne absente pendant toute l’implémentation revenait ensuite en disant qu’elle n’aimait pas la manière dont c’était écrit
    Et puis on finit par découvrir que le « processus batch » effectue %numberOfRecord%*10 insertions, fait des requêtes supplémentaires à cause d’un modèle de données mal conçu, et réalise des upserts SQL de la pire manière possible : d’abord récupérer depuis la base, puis ajouter les enregistrements à insérer s’ils n’existent pas. Ensuite, au lieu de repenser les patterns de requêtes de la couche de données, on continue à empiler des choses de plus en plus douteuses sous l’étiquette « amélioration des performances ». J’ai vu ça plus d’une fois dans ma carrière

• Chaque fois que je lis un article très général présenté comme un conseil pour s’adapter à l’IA, je me rappelle que l’industrie du logiciel ressemble à l’industrie du bâtiment
  Elle n’est jamais totalement ordonnée, jamais complètement optimisée, et elle sera toujours forcément sur mesure. Parce qu’elle doit s’adapter à une réalité où les goûts, le contexte et les spécificités locales varient énormément
  Il peut arriver que de bons outils ou de bonnes matières premières apparaissent

• J’ai fini par penser que le vrai fossé défensif du logiciel ne résidait pas vraiment dans l’exigence d’une connaissance ou d’une expérience étendue à la fois des systèmes et du domaine
  Il est bien plus difficile de répliquer le goût et les effets de réseau. En réalité, même avant le vibe coding, les startups financées par le capital-risque, riches en talents et en ressources, s’imposaient rarement sur le marché
  C’est pour cela que même des gens dans la vingtaine pouvaient rivaliser avec des experts de nombreux secteurs. La réaction actuelle me semble venir de l’émergence, dans le logiciel, du même type de profil qu’on voit souvent dans d’autres industries matures : des gens définis par « X années d’expérience dans le secteur »

• Je travaille comme analyste, et dans notre groupe, environ 20 % des analystes ont de solides compétences techniques, c’est-à-dire de vraies capacités en ingénierie logicielle, tandis que le reste se compose d’analystes plus traditionnels ou d’experts métier
  Au cours de l’année écoulée, j’ai vu la productivité en développement d’outils internes augmenter à mesure que les analystes non techniques utilisaient des modèles d’IA pour la partie développement
  Avant cela, presque tout était développé dans Tableau. C’était la méthode la plus accessible pour permettre à quelqu’un qui n’était pas développeur de créer un outil fonctionnel
  Il y a encore quelques jours, un analyste de notre groupe a présenté un outil sur lequel il travaillait ; il s’agissait essentiellement de porter un rapport Tableau vers une application plus flexible

  • Dans notre groupe, nous remplaçons lentement Tableau par des outils développés en interne, et les gains de performance sont énormes
    J’ai l’impression que ces entreprises de BI vont avoir de gros problèmes. C’est encore plus vrai pour des sociétés comme Tableau, qui rendent presque impossible de tracer même quelque chose d’aussi simple qu’un histogramme

• Mon ami est ingénieur électricien et a récemment dépassé les 2000 Elo FIDE aux échecs. Il joue depuis 30 ans et a même fondé un club d’échecs au lycée. À l’université, il a juste un peu appris à programmer en travaillant sur des microcontrôleurs
  Moi, je suis plutôt un homme-à-tout-faire de l’infra/admin avec un diplôme en informatique, et je programme en amateur depuis 30 ans
  sur Lichess, mon Elo atteint 1000 les bons jours
  On a fait un concours de bots d’échecs. C’était open book, on pouvait programmer avec l’IA, utiliser un opening book, des tables de finales, bref tout ce qu’on voulait. Je l’ai complètement écrasé, alors qu’aux échecs sur un vrai échiquier, je ne l’ai battu que deux fois en 20 ans
  Lui battrait probablement 99 % des joueurs pris au hasard dans le monde réel, alors que moi j’en battrais sans doute à peine 20 %
  Je ne sais pas exactement ce que j’essaie de dire, mais j’ai l’impression que la connaissance du domaine n’est peut-être plus tout. Ou alors c’est peut-être le domaine lui-même qui a changé

  • Vu du point de vue de l’IA, l’interprétation modérée serait que certains domaines sont superficiels, comme les échecs, tandis que d’autres sont profonds
  • Je ne vois pas vraiment quel rapport il y a entre la capacité à jouer réellement aux échecs, au-delà de quelques principes simples, et le fait d’écrire un algorithme efficace d’exploration de l’arbre de jeu
    Tu lui as proposé un duel de programmation, et c’est toi, programmeur bien plus expérimenté, qui as gagné. Même avec la possibilité d’utiliser l’IA, j’estime que c’est ta connaissance du domaine qui a été décisive ici