L’expertise métier a toujours été le vrai moat
(brethorsting.com)- 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 les transports afin de construire un modèle de domaine ; le code était le produit de cette compréhension
- L’IA agentique permet de produire du logiciel même sans compréhension du domaine, 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, sans connaître le code, 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 où la bonne réponse dépend du savoir métier, comme le codage clinique, il peut laisser passer des erreurs plausibles
- La compétence la plus précieuse devient le jugement permettant de vérifier à la fois la solidité du code généré et la véracité de ses sorties, ce qui rend l’investissement dans l’expertise métier encore plus important pour les ingénieurs expérimentés
Comprendre le domaine, pas écrire du code, est l’essentiel
- Dans le développement logiciel, la partie difficile n’était pas d’écrire du code, mais d’abord de construire dans sa tête un modèle du fonctionnement du domaine
- Le code n’était qu’une transcription de cette compréhension, et le vrai travail consistait à acquérir cette compréhension
-
Exemples concrets
- Avant de lancer un système de paie, il fallait comprendre les retenues sur salaire pour saisie (garnishment), les déductions avant impôt, et le traitement à appliquer lorsqu’une période de paie chevauche un changement de taux horaire
- Avant de lancer une application de transports en commun, il fallait apprendre ce qu’est un flux GTFS, pourquoi un trip est différent d’une route, et comment un bus « à l’heure » peut malgré tout être faux
Le lien rompu par l’IA agentique
- L’IA agentique rompt le lien entre la construction du modèle et la production du logiciel, en rendant possible la création de logiciels même sans modèle
- Cela fait tomber le postulat sur lequel toute la profession était organisée
- Le point de vue de l’an dernier était que ces outils amplifient les développeurs seniors dotés de jugement ; c’est vrai, mais incomplet
- Le changement réellement observé est que la contrainte principale s’est déplacée de « peut-on le construire ? » vers « peut-on déterminer si c’est correct ? »
Comparaison entre deux profils
-
Expert métier (sans background logiciel)
- Répartiteur logistique, codeur clinique, actuaire, etc. ; il ne sait pas lire une stack trace et ne peut pas expliquer la différence entre une hashmap et une liste
- Mais en regardant un planning généré par un agent, il voit immédiatement qu’aucun chauffeur ne peut légalement effectuer ce service, ou que la facturation associée à ce code ne sera jamais payée
- Après 10 ans passés au milieu des entrées et des sorties, il connaît la bonne sortie pour une entrée donnée, et l’agent compense précisément la capacité de production de code qui lui manquait
- Ce qu’il apporte, c’est une vérité terrain (ground truth) que l’agent ne peut pas fournir
-
Ingénieur généraliste solide sans expérience métier
- Il peut tout concevoir et sait assurer la fiabilité, les tests et la tenue du système à 2 heures du matin
- Mais placé sur du codage clinique, il ne sait pas distinguer une mauvaise réponse plausible d’une bonne réponse
- L’agent produit des règles de facturation (billing rules) erronées, subtiles et coûteuses, qui compilent pourtant et passent les tests qu’il a écrits
- L’ingénieur n’a pas d’oracle, donc il peut vérifier que le logiciel est bien construit, mais pas qu’il est correct — parce que la correction est définie par un domaine qu’il n’a pas en tête
Une asymétrie où une seule voie s’est effondrée
- Avant les agents, l’ingénieur disposait d’une voie dont le répartiteur ne disposait pas : il pouvait suivre l’expert, lire les spécifications et apprendre lentement le modèle de domaine au contact des erreurs en environnement réel
- Dans beaucoup de secteurs, cette voie constituait même la progression de carrière elle-même, alors qu’il n’existait pas, pour l’expert métier, de voie équivalente vers des années d’apprentissage du logiciel fiable
- Les outils agentiques ne font s’effondrer qu’une seule de ces deux voies
- La force de l’ingénieur, qui consistait à traduire le modèle de domaine en code, devient désormais bon marché
- La force de l’expert métier, qui consiste à savoir ce qui est correct, ne le devient pas, et on n’y accède pas par prompt
- Il n’existe pas de fichier de compétences contenant le savoir tacite d’une personne qui a traité des milliers de paies
Les profils capables de valider les deux couches
- Dans ce nouveau monde, les personnes les plus précieuses sont celles qui réunissent les deux compétences et peuvent valider les deux couches
- Elles savent que le code généré est solide, et elles savent en même temps que les réponses qu’il produit sont vraies
- Parce qu’elles connaissent les règles, elles peuvent écrire un test qui encode « un chauffeur ne peut pas dépasser 11 heures », et parce qu’elles savent ce qu’elles testent, elles peuvent déterminer si ce test a du sens
- L’agent s’occupe de la transcription ; l’humain s’occupe de juger deux fois
Le pari à faire pour les ingénieurs expérimentés
- Pour les ingénieurs chevronnés qui se demandent où investir les prochaines années, voilà la direction du pari
- La compétence mécanique qui consiste à transformer une idée claire en code propre voit sa valeur chuter brutalement
- Ce qui reste rare, c’est un modèle profond et éprouvé d’un domaine réel, et c’est cela qu’il faut acquérir
- Choisir un secteur, un produit financier, un cadre réglementaire ou un processus physique, et apprendre ce domaine comme on apprenait autrefois un langage de programmation ou un framework
- C’est la partie qu’un agent ne peut pas faire à votre place, et c’est désormais celle qui porte le plus de valeur
7 commentaires
Mais j’ai aussi l’impression que c’est un peu trop déprécier le code.
Le développement logiciel est lui-même un domaine, et y exceller relève aussi d’une expertise spécialisée.
L’IA peut produire un logiciel qui résout le problème sur le plan fonctionnel, mais elle ne peut pas le finaliser, et il faut quelqu’un pour combler cet écart.
C’est le même avis que celui exprimé dans les commentaires de Hacker News :
Je ne suis pas tout à fait d’accord avec l’avis de xguru.
Prenons l’exemple d’Excel. En général, dans le travail en entreprise, il y a un niveau suffisant pour faire ce qu’on a à faire, et au-delà, la plupart des gens n’essaient pas vraiment d’en apprendre davantage. Il existe bien des personnes qui maîtrisent Excel de façon hallucinante, mais ce sont vraiment des cas exceptionnels.
Pour le code aussi — même si ce n’est pas le cas aujourd’hui — je me suis dit qu’il pourrait peut-être se scinder en deux catégories. D’un côté, une minorité qui crée des produits vraiment complexes, et de l’autre, la grande majorité qui l’utilise comme on fait du vélo.
Hein ? On ne méprise pas les gens qui maîtrisent bien Excel.
Mais dire que la valeur du fait même de coder a baissé, ça donne quand même une impression de mépris.
Je pense qu’on ne devrait pas dire à quelqu’un qui crée des produits complexes, sous prétexte qu’il utilise ça comme on fait du vélo, que sa valeur est finalement assez faible.
Je suis d’accord avec le point que vous avez soulevé,
à savoir que la part de technologie et de code qu’on peut qualifier de logiciel complexe va diminuer. Si les choses qu’on peut coder facilement avec l’IA se multiplient.
Pour reprendre la formulation du résumé de GeekNews : il semble que le code qu’un agent ne peut pas remplacer va se réduire de jour en jour.
Sur ce point, la connaissance tacite est presque en voie de disparition, et comme des experts de tout premier plan conçoivent des agents qui sont intégrés aux modèles,,, on insiste aujourd’hui sur l’importance de l’expertise métier, mais je ne sais pas si on défendra encore la même idée dans un an. On est finalement dans une situation où la connaissance tacite passe peu à peu dans les prompts, et les modèles vont sélectionner la connaissance tacite ajoutée par les utilisateurs dans les prompts, puis la réinjecter dans les modèles. Des modèles d’agents embarquant cette connaissance tacite auront de la valeur, mais je pense que même cela se négociera sur le marché. Des agents avec une expertise métier bien plus riche dans ce domaine.
D’ici un an, j’imagine que le critère d’évaluation ne sera plus seulement l’orchestration, mais la gestion d’agents (comme une entreprise).
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
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
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
Dans 20 ans, je pense qu’on nettoiera les déchets coécrits avec Claude
https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...
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
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
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
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’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
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
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
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
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é
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