- Les discussions actuelles sur les LLM se déroulent sans base quantitative claire
- L’expérience de chaque utilisateur est très fragmentaire, et des éléments essentiels comme l’environnement réel d’utilisation ou les connaissances de contexte sont rarement partagés
- En raison de leur nature non déterministe, une même tâche peut produire des résultats différents selon le moment, ce qui limite leur fiabilité
- Les affirmations exagérées des leaders du secteur encouragent une acceptation peu critique et des attentes excessives
- Dans les faits, l’auteur utilise lui aussi divers outils d’IA au quotidien, et partage l’expérience concrète de n’obtenir le résultat souhaité qu’une fois sur deux environ
Débats autour des LLM et regard porté sur la technologie
Critiques des LLM et climat ambiant
- Dans les débats récents sur l’IA, et en particulier sur les LLM (grands modèles de langage), il existe souvent une tendance à rabaisser les points de vue critiques comme étant « l’avis de personnes qui ne comprennent pas vraiment la technologie »
- Sur Hacker News notamment, on voit revenir des réactions du type : « poser des questions sur l’IA révèle une ignorance de sa véritable nature »
L’écart d’expérience entre utilisateurs
- Sur l’utilité réelle des LLM, certains utilisateurs disent que « c’est utile dans une certaine mesure », tandis que d’autres affirment que « malgré toutes leurs tentatives, cela ne sert pas à grand-chose »
- Cette divergence existe parce que des critères concrets et des informations précises sur les expériences ne sont pas partagés
- sur quel type de projet l’outil a été utilisé
- l’état de la base de code (nouveau projet, code mature, source privée, etc.)
- le niveau d’expertise de l’utilisateur, et dans quelle mesure cette expertise est liée au problème réel
- l’effort supplémentaire réellement nécessaire pour affiner puis déployer le résultat produit par le LLM
La difficulté de comparer les expériences et le non-déterminisme
- Même si un utilisateur partageait toutes les informations en détail, il serait presque impossible de comparer réellement son expérience avec celle d’un autre utilisateur
- Les LLM et les agents d’automatisation sont par nature non déterministes
- même en soumettant exactement le même problème de la même manière, on obtient des résultats différents à chaque fois
- il existe trop de variables — type de projet, modèle utilisé, outils, langage, etc. — pour permettre une validation cohérente
Les leaders du secteur et les attentes exagérées
- De nombreux leaders du secteur mettent excessivement en avant les performances des LLM
- Exemple : un leader du secteur raconte qu’avec « Claude Code », un vieux bug a été corrigé avec une facilité étonnante, et ce récit suscite un fort écho sans partage des détails
- des informations essentielles comme la taille du code, la difficulté du bug, le travail additionnel requis, le langage de programmation ou le framework utilisés sont omises, tandis qu’un message très positif se propage seul
- ce type de cas enregistre plus de 1,8 k réactions et 204 reposts, ce qui facilite la diffusion d’un marketing exagéré
Expérience d’usage et perception de la réalité
- L’auteur utilise lui aussi chaque jour divers outils d’IA comme v0 de Vercel, Claude Code et Midjourney
- création d’une application de monitoring en SwiftUI sans connaissance préalable de Swift
- génération automatique d’affiches pour des événements avec Midjourney
- écriture de fonctions de serveur MCP basées sur Elixir, entre autres
- Mais le taux de réussite n’est que d’environ 50 %, et les résultats ne sont jamais vraiment cohérents
- Même si les LLM peuvent parfois donner une impression de magie, ils ne sont en réalité que des modèles statistiques non déterministes
- Dans cette réalité, l’auteur souligne que les discussions du secteur restent prisonnières d’une opposition binaire (magie vs ingénierie)
Conclusion
- Le terrain des LLM et de l’IA tend à privilégier des imaginations, attentes et croyances exagérées, sans cadre de validation ferme et clair
- Il est important de ne pas abandonner l’esprit critique et de continuer à vérifier en détail les fonctionnalités et les effets réels
- Ce qui compte dans le débat, c’est le partage d’informations concrètes et quantitatives
- Un regard équilibré sur les limites et les possibilités des LLM est nécessaire
1 commentaires
Avis Hacker News
J’éprouve une certaine frustration en entendant la direction de l’endroit où je travaille parler d’un gain de productivité de 10x. Certains de nos early adopters en interne tiennent eux-mêmes ce discours. Mais ces attentes sont beaucoup trop élevées. La loi d’Amdahl entre aussi en jeu : je passe la majeure partie de mon temps non pas à coder, mais à réfléchir et à communiquer. Même si le code devenait vraiment 10x plus rapide à produire (ce qui n’est pas le cas dans la plupart des situations), la productivité globale n’augmenterait que de 10 à 15 %. Cela resterait un résultat tout à fait correct, mais ce n’est pas du 10x
C’est peut-être parce que mon travail actuel a davantage une dimension R&D, mais les LLM m’apportent autant sur la partie « réflexion » que sur la partie « codage » (la communication, je la gère bien moi-même). Utiliser les LLM pour réfléchir me rappelle la sensation d’avoir appris à maîtriser la recherche web il y a 20 ans. À l’époque, il fallait savoir quoi chercher ; désormais, le LLM trouve d’abord ce qu’il faut chercher (et fait parfois la recherche à ma place). Des tâches que je classais autrefois comme difficiles sont maintenant facilement résolues grâce aux LLM. Aujourd’hui, je fais environ un tiers de mes recherches web avec ChatGPT o3. Je n’imagine même plus y renoncer. Il y a aussi un aspect psychologique important : le LLM m’aide à structurer mes idées incomplètes et me sert de partenaire de discussion. Grâce à cela, beaucoup de tâches me paraissent nettement moins intimidantes, et cette différence compte énormément
Chez moi aussi, c’est un peu la même situation. Les gains de productivité revendiqués par les premiers adoptants en interne sont souvent mesurés de manière très étroite, ou alors les calculs eux-mêmes sont assez bancals
Les LLM peuvent peut-être accélérer davantage les développeurs seniors que les juniors (les juniors distinguent moins bien le bon code du mauvais). Un senior utilisant un workflow LLM amélioré pourrait peut-être atteindre l’équivalent de la productivité de dix juniors d’autrefois. À l’inverse, un mauvais développeur peut même devenir négatif en productivité en pratique (en monopolisant le temps des seniors). Même les juniors corrects risquent de rester cantonnés à des tâches répétitives que les LLM font déjà mieux. C’est pourquoi je pense que certains emplois pourraient réellement disparaître
Si l’usage d’outils LLM n’apporte qu’un gain de 10 à 15 % de productivité, mais que leur coût fait grimper le coût d’embauche de 10 à 15 %, alors je ne vois pas d’avantage particulier. Il faut raisonner en coût total de production
Sur des projets personnels, je vais facilement presque 10x plus vite. Mais en entreprise, avec les discussions inter-équipes, les changements de exigences et les revues de PR, cet environnement ne s’y prête pas. Ce type de conception optimisée et de patterns standardisés n’est possible que dans de petites startups ou sur des projets solo. Dès qu’il y a plusieurs personnes, il devient déjà difficile d’obtenir un consensus. Pour qu’une IA donne son meilleur, tout devrait être standardisé, alors qu’en réalité tout est toujours légèrement décalé ; c’est pourquoi il est difficile d’obtenir un tel effet dans une organisation réelle. Entre quelques développeurs très motivés et alignés, le 10x est peut-être possible, mais en environnement d’entreprise c’est presque impossible. Je trouve que l’IA est plus adaptée au middle management et au project planning
La personne qui se plaint dans l’article, c’est moi à l’opposé. J’ai lancé un produit greenfield à l’époque où ChatGPT était encore très limité. Ensuite, j’ai utilisé Claude et du copier-coller entre le webchat et XCode, puis Cursor. Il y avait souvent des erreurs de build, mais malgré cela ma productivité a au moins été multipliée par trois. Aujourd’hui, les agents sont meilleurs et Claude 4 est sorti, donc je ne code presque plus. J’occupe plutôt un rôle d’architecte/manager : je dirige simplement les agents avec mon expertise. Cela fait des mois que, dans la startup, je n’ai pas écrit une seule ligne de code moi-même. Je vérifie tout avant d’ouvrir une PR et je teste rigoureusement, mais le combo Cursor+Sonnet est dingue. Le nombre de lignes n’a aucune importance ; au contraire, des experts de la codebase qui travaillent dessus depuis longtemps viennent me voir pour des questions sur des bugs mineurs. Grâce à Claude, je me suis même mis à toucher au travail frontend, ce qui me rend prudent. Je ne me contente pas d’envoyer une requête : je lui fais suivre un processus rigoureux de recherche, de planification et d’exploration par étapes. La connaissance métier reste indispensable. Malgré tout, je trouve étonnant que certaines personnes n’arrivent pas à en tirer autant. J’ai l’impression de voir deux articles de ce genre chaque semaine
Mon expérience est similaire, mais dans un contexte un peu différent (doctorant). J’étais sceptique vis-à-vis des LLM, mais depuis Claude Code, ma manière de travailler a complètement changé. Cela dit, la curation reste entièrement de mon ressort (c’est une soft skill importante qu’on apprend en doctorat, et aussi parce que les LLM perdent vite leur objectif ou leur contexte, ou ne s’en souviennent pas). Si l’on sait communiquer avec précision, on peut organiser le calcul avec CC d’une manière auparavant impossible. Ce n’est pas que programmer devient plus facile, c’est qu’un format complètement différent apparaît
Je serais curieux de connaître le processus réel de validation et d’inspection : comment vérifier rapidement du code LLM peu fiable, si le LLM écrit aussi les tests unitaires, quelle est la longueur moyenne des prompts, etc.
On fait remarquer qu’il ne faut pas faire confiance immédiatement à la sortie du LLM. Le LLM ne comprend pas tout le contexte du projet et hallucine beaucoup, donc il faut valider
J’ai l’impression que la qualité du code généré par les LLM reste globalement très insuffisante. Il faut souvent corriger plusieurs fois, si bien qu’il est souvent plus rapide d’écrire soi-même. En revanche, les agents sont très utiles pour les gros refactorings mécaniques. Au lieu d’écrire des macros vim complexes ou des scripts AST, j’utilise un agent
Personnellement, l’idée de ne pas écrire une seule ligne de code pendant des mois me semblerait très ennuyeuse
Cela ne fait que reconfirmer ce qu’affirmait le billet de blog (impossibilité de vérifier, revendications de performances énormes, etc.). Le compte semble même avoir été créé récemment
À mon avis, l’essentiel du travail réel dans les services consiste à déplacer des données à la main entre des feuilles Excel ou entre CRM, e-mail et Excel. Dans les grandes entreprises, je pense qu’il y a peut-être cent fois plus d’employés permanents qui font ce type de tâches répétitives que d’ingénieurs logiciel. Donc peu importe si un LLM ne sait pas faire d’OCaml : s’il fait un peu mieux qu’un humain dans Excel, cela crée déjà une valeur énorme. Avec quelque chose comme MCP pour relier e-mail, CRM et Excel et automatiser le tout, le taux d’erreur ou d’hallucination baisse aussi fortement. Les humains étant eux aussi non déterministes, le déterminisme n’est pas essentiel pour ce genre de processus. Les LLM et la crypto sont totalement différents en matière d’utilité ou d’adoption. Cela me fait plutôt penser à la diffusion des smartphones. Même mes amis non techniques utilisent désormais les LLM pour des usages très variés
Je ne trouve pas la comparaison avec la crypto très constructive. Techniquement, cela n’a aucun rapport. En revanche, il y a bien un phénomène de surévaluation technologique. Pour quelqu’un qui n’a même jamais touché à l’automatisation de base, un LLM peut sembler relever de la science-fiction. Ce domaine n’avait jamais été aussi mainstream auparavant. À l’avenir, je pense que ce sera un Far West mêlant réussites, échecs, opinions variées et retours d’expérience terrain. Le bon côté, c’est qu’on vit désormais dans un monde où même l’idée d’app d’un ami peut être testée directement
Les FTE qui font du nettoyage manuel de données ont aussi la responsabilité de valider les résultats, de respecter les délais et d’assumer la responsabilité juridique. Les LLM ne savent pas vérifier, hors contexte, des cas exceptionnels temporaires (par exemple, une valeur qui doit être à 0 à cause d’un jour férié). Pour cette validation, cela vaut largement la peine d’avoir un FTE
Je me demande dans quelles entreprises on trouve un ratio de 100 FTE de manipulation manuelle de données par ingénieur logiciel. Je ne pense pas que la majorité du travail réel en back-office ou en saisie de données corresponde à cela. Je suis d’accord sur l’impact potentiel de l’IA, mais je suis sceptique face à l’idée que la quasi-totalité des cols blancs ne ferait que de l’e-mail et de la saisie de données
Je pense que vous sous-estimez la complexité de ce type de postes
En tant que programmeur à la retraite, je n’arrive pas à imaginer confier une responsabilité critique à du code généré de manière probabiliste. Si quelques retouches suffisent pour le rendre exploitable, je peux le comprendre. En dehors du code (brainstorming, pensée créative, support à la recherche), les LLM sont impressionnants. Je les traite comme des partenaires de réflexion. Ils se trompent parfois, mais il est facile de le repérer en vérifiant avec d’autres sources ou en faisant relire par un autre LLM
Je suis moi aussi d’un naturel très sceptique, mais après les avoir réellement utilisés, ils ont dépassé mes attentes sur tous les plans. En quelques heures, j’ai fait avancer un projet de plusieurs mois, du prototype jusqu’au lancement. Les choses que je savais déjà faire, je les fais plus vite, et même celles que je ne savais pas faire (celles pour lesquelles il aurait fallu sous-traiter ou recruter) deviennent possibles à faible coût et rapidement. Bien sûr, ce n’est pas parfait et il y a beaucoup d’aspects agaçants (ignorer des consignes explicites, mentir, etc.), mais pour moi c’est un game changer
Utiliser un LLM comme partenaire de réflexion donne l’impression de bien marcher pendant un moment, puis à un certain point son caractère délirant apparaît. Les LLM excellent à donner l’illusion de savoir ou de raisonner. C’est encore plus dangereux dans les domaines que je ne maîtrise pas. Avec un moteur de recherche, on peut comparer la fiabilité des sources, alors qu’avec un LLM ce n’est pas possible. Et repérer les erreurs n’est pas toujours facile
Je suis développeur depuis 40 ans et j’ai commencé à utiliser les LLM il y a quelques mois ; ma manière de travailler a beaucoup changé. Je colle un message d’erreur issu des logs et j’obtiens un correctif en une minute, je fais du brainstorming d’architecture, je reçois de nouvelles propositions de solution, etc. Je vérifie le code, mais je suis chaque jour surpris par leur précision et leur intelligence. (Cela n’a absolument rien à voir avec la crypto)
Je suis dans le camp des sceptiques vis-à-vis des LLM, mais au fond tout le code écrit par des humains est lui aussi probabiliste par nature. C’est pour cela qu’il existe les code reviews, les tests unitaires, le pair programming et les guides. Il ne faut utiliser sans esprit critique ni la sortie d’un humain ni celle d’un LLM. En revanche, je crains qu’on fasse des LLM autre chose qu’un outil utile : qu’on les emploie pour empiler du boilerplate en ignorant l’efficacité, la sécurité, le refactoring et d’autres valeurs de long terme
À mon avis, le domaine où les LLM sont les meilleurs, c’est la data science. Les entrées/sorties y sont claires, donc les résultats sont faciles à vérifier. Quand on connaît les caractéristiques d’un jeu de données donné, il est aussi facile de leur faire générer des tests. Quand il faut du contexte, Claude Code change beaucoup de choses. Exemple : extraction de messages multiples dans chaque paquet UDP d’un fichier PCAP, filtrage, pattern matching, séparation pour les tests, etc. Si on dit « écris des tests unitaires pour toutes ces fonctions », le LLM peut même s’auto-vérifier
J’utilise les LLM presque tous les jours depuis un an, et dans 90 % des cas ils résolvent mon problème. Je ne sais pas à quel moment les avis négatifs sur l’IA/les LLM doivent être pris sérieusement. Dans mon expérience, il n’a jamais été question d’injecter toute une codebase et d’attendre la magie ; je ne pose que des questions précises et spécifiques, sur des sujets que je connais et comprends, puis j’applique les solutions d’une manière vérifiable. Si ce n’est pas ainsi qu’on les utilise, c’est qu’on les utilise mal. Pour vraiment faire l’expérience de la magie, l’essentiel est un usage modeste, quotidien et cohérent
Sur le ton de la parodie du monsieur météo : « ça marche toujours avec 60 % de chances ». Moi aussi, j’utilise GPT et Claude tous les jours dans Cursor. GPT o3 est bon pour la recherche de connaissances générales, Claude échoue souvent. Le modèle en lui-même est bête, mais il lui arrive parfois de viser juste. Je pense qu’on peut en tirer un usage productif si l’on sait soi-même ce qu’on veut et si l’on sait bien dresser le LLM
Il y a aussi l’avis selon lequel l’affirmation « dans mon expérience, ça marche dans 90 % des cas » est difficile à croire
L’auteur semble irrité par les commentaires inexacts des polémistes. En réalité, je pense que les utilisateurs-promoteurs, parce qu’ils s’y heurtent chaque jour, connaissent très bien les problèmes et limites des LLM. Des problèmes autrefois impossibles ou presque impossibles — traduction, transcription, génération de code (jusqu’à une certaine échelle) — sont désormais entièrement ou presque entièrement résolus
La traduction, la transcription et la génération de code étaient-elles vraiment proches de l’impossible ? On fait remarquer que Google Translate, Whisper, etc. existent depuis longtemps
Ce sont les detractors qui révèlent les défauts réels ; au contraire, les promoters encensent les LLM sans esprit critique, comme s’ils étaient universels
Dernièrement, j’ai l’impression que l’usage des termes AGI et AI est devenu particulièrement flou, surtout dans les articles scientifiques. J’aimerais au minimum que chaque article définisse clairement ses propres termes. Si l’on définit clairement ce qu’est l’AGI, on peut même démontrer logiquement qu’une IA donnée satisfait ou non cette définition. Même si cela semble peu utile en pratique, c’est toujours mieux que des termes vides de sens. Aujourd’hui, on a l’impression que le terme AGI est utilisé de manière fuyante, sans définition. Wikipédia parle de « presque toutes les tâches cognitives, au niveau ou au-delà de l’humain », mais c’est impossible à mesurer. Je me demande pourquoi employer des termes aussi creux
Il n’est pas nécessaire que tout le monde l’utilise avec exactement le même sens. Il suffit d’avoir ses propres critères pour le mot AGI (même si la majorité n’est pas d’accord). Pour moi, crypto signifie toujours cryptography. Le sens dominant et mes critères personnels peuvent différer
Si l’IA a une définition, alors c’est « ce qui n’a pas encore été réalisé », avec un lien vers l’explication de l’AI effect
Nous avons récemment commencé à utiliser les LLM dans mon entreprise. Première mission : transcription de 20 000 appels de support client et extraction de données (produits comparés, problèmes rencontrés, cas d’usage représentatifs, etc.). Une recherche qui aurait autrefois pris des semaines a été bouclée en quelques heures. Nous en avons même tiré une nouvelle stratégie business, avec une vraie valeur à la clé. Comme moteur de traitement du langage naturel, le LLM est extrêmement performant. Il y a beaucoup de battage exagéré, mais dans notre cas cela nous aide concrètement. Ce n’est qu’un outil ; je ne ressens pas le besoin de le prouver à qui que ce soit
Je pense que le battage marketing n’est pas complètement inoffensif. Il peut aussi provoquer des distorsions de marché, des surinvestissements, des réductions d’effectifs, des attentes irréalistes et d’autres effets négatifs. Ce type d’articles est nécessaire pour refroidir le marché et les attentes. Ceux qui vendent les LLM ne parlent généralement pas de résumer des appels de support ; ils racontent plutôt toutes sortes de scénarios exagérés censés remplacer des effectifs
On dirait que seuls ceux qui n’ont jamais eu à traiter de gros volumes de données de manière fiable disent que les LLM ne servent à rien. Même la traduction peut désormais être réalisée avec bien plus de contexte
Des personnalités fiables de l’industrie tech disent elles aussi directement que la GenAI aide beaucoup la productivité des développeurs. Cela peut vouloir dire tout et son contraire, de 5 % à 100 %, mais au minimum il faut la considérer comme un outil très utile. Je ne pense pas qu’il soit nécessaire d’avoir des chiffres précis (lignes de code, octets, CPU, etc.) pour défendre cette idée
La technologie des LLM finira sans doute par trouver des usages appropriés, mais trop de gens l’emploient déjà mal, au point qu’il n’est plus possible de revenir en arrière. D’innombrables développeurs juniors vont probablement échouer en prenant des risques, et énormément d’investissements seront gaspillés. Les entreprises aussi sont désormais dans une logique de all-in dont elles ne peuvent plus sortir