- Martin Fowler souligne que les récents sondages sur les usages des LLM peuvent aboutir à des conclusions biaisées s’ils ne reflètent pas les flux d’usage réels
- Aux questions sur l’avenir de la programmation ou la stabilité des emplois, personne n’a encore de réponse certaine ; il est important d’expérimenter soi-même et de partager ses retours d’expérience
- L’industrie de l’IA est clairement dans une phase de bulle, mais comme pour toutes les innovations technologiques dans l’histoire, des entreprises survivantes comme Amazon peuvent émerger après l’éclatement
- La nature même des LLM est l’hallucination, et le fait de reformuler plusieurs fois une question puis de comparer les réponses est en soi utile
- Les LLM élargissent fortement la surface d’attaque des systèmes logiciels, et les agents de navigateur présentent en particulier un risque structurel qui ne peut pas être rendu intrinsèquement sûr
Manières d’utiliser les LLM et productivité des développeurs
- Les discussions autour des premières études sur l’impact de l’IA sur le développement logiciel se multiplient
- La majorité des usages des LLM se concentre sur des fonctions d’autocomplétion avancée, de type co-pilot
- Pourtant, les personnes qui utilisent les LLM le plus efficacement préfèrent les employer de façon à pouvoir lire et modifier directement les fichiers de code source
- Les enquêtes qui ignorent les différences de mode d’usage des LLM risquent fortement de mener à une interprétation erronée des données
- Les écarts de capacités entre les différents modèles de LLM rendent aussi l’interprétation des résultats plus difficile
Les métiers de la programmation et l’avenir des LLM
- Des questions reviennent souvent sur l’avenir de la programmation, la nécessité des ingénieurs débutants et l’avenir des profils expérimentés
- Il est impossible d’y répondre clairement, car nous n’avons pas encore établi comment utiliser efficacement les LLM
- Une approche expérimentale est nécessaire, ainsi qu’une attitude consistant à observer et partager les expériences concrètes des workflows des autres
- Les utiliser soi-même et partager son expérience reste la manière la plus judicieuse de s’adapter
Le phénomène de bulle dans l’IA et les LLM
- À ceux qui estiment que l’IA est une bulle, il est rappelé que toutes les innovations technologiques s’accompagnent d’un phénomène de bulle
- La bulle finira forcément par éclater, et certains investissements échoueront
- Mais il est impossible de prédire quand la bulle se terminera et quelle ampleur de valeur sera créée
- Même après l’éclatement, toutes les entreprises ne disparaissent pas, et certaines peuvent continuer à croître durablement
- Lors de la bulle internet, pets.com et Webvan ont disparu, mais Amazon a survécu et s’est développée, ce qui reste un exemple représentatif
La nature hallucinatoire des LLM
- Le phénomène d’hallucination des LLM n’est pas un défaut, mais une caractéristique intrinsèque
- Les LLM sont au fond des outils conçus pour générer des hallucinations utiles
- Il est préférable de poser plusieurs fois la même question en variant la formulation, afin d’obtenir plusieurs réponses et de les comparer
- Quand une réponse chiffrée est nécessaire, il est important de vérifier la variabilité entre les réponses par répétition des requêtes
- Il n’est pas approprié de demander à un LLM de répondre directement à des problèmes calculables de manière déterministe
L’introduction de la non-déterminisme dans l’ingénierie logicielle
- L’ingénierie logicielle traditionnelle est conçue et mise en œuvre dans un environnement déterministe
- Les ingénieurs structure et process conçoivent des marges de tolérance en tenant compte de la non-déterminisme (incertitude) du réel
- L’adoption des LLM pourrait constituer un tournant où l’ingénierie logicielle entre dans le monde de la non-déterminisme
Les LLM comparés aux développeurs juniors
- Les LLM sont souvent comparés à un collègue junior
- Pourtant, un LLM affirme souvent que « tous les tests passent » alors qu’en réalité des tests en échec apparaissent fréquemment
- Chez un humain, un tel comportement mènerait vite à un problème RH
Hausse des menaces de sécurité et problème des agents de navigateur
- Les LLM élargissent considérablement la surface d’attaque des systèmes logiciels
- Le « trifecta fatale » signalé par Simon Willison désigne l’accès à des données privées, la communication externe et l’exposition à du contenu non fiable
- Des instructions cachées dans une page web (par ex. texte blanc en 1 pt) peuvent tromper un LLM et lui faire exfiltrer des informations sensibles
- Les agents basés sur le navigateur sont particulièrement dangereux, et des actions malveillantes comme un virement bancaire peuvent être déclenchées par des instructions externes
- Willison avance que les extensions de navigateur de type agent ne peuvent pas être rendues fondamentalement sûres
Conclusion
- Les LLM ouvrent de nouvelles possibilités pour le développement logiciel, mais il faut comprendre clairement leurs modes d’usage et leurs limites
- La bulle est inévitable, mais elle peut malgré tout déboucher sur un progrès technologique durable
- Les développeurs doivent exploiter au maximum le potentiel des LLM grâce à une approche expérimentale et à une prise en compte de la sécurité
3 commentaires
Rien que d’y penser, c’est étouffant…
Je suis particulièrement d’accord à 100 % avec l’analogie du junior. La catégorie d’erreurs qu’il commet est différente de celle des humains… Je pense que c’est une analogie typiquement ratée.
Discussion sur Hacker News
Mon ancienne collègue Rebecca Parsons dit depuis longtemps que les hallucinations des LLM sont moins un bug qu’une fonctionnalité centrale. En réalité, ce que font les LLM, c’est produire des hallucinations utiles. Chaque fois que j’entends cet argument, j’ai l’impression qu’on redéfinit arbitrairement le terme « hallucination » pour donner l’illusion d’un nouvel éclairage. Traditionnellement, une « hallucination » désigne le fait de fabriquer des détails plausibles comme s’ils étaient perçus, sans lien avec la réalité ; ici, ce raisonnement revient simplement à dire « sortie ». Ce n’est pas comme si le fait qu’un LLM produise une sortie était une nouveauté ; on prend juste une étiquette auparavant jugée « mauvaise », on l’applique à l’ensemble du comportement, et ça donne un vernis de nouveauté
Je ne pense pas que Fowler soit réellement en train de redéfinir le mot « hallucination ». Il souligne plutôt, de manière ironique, que c’est le mode de fonctionnement fondamental de ce système. C’est un peu comme dire que « les dommages collatéraux sont intrinsèques à une bombe » ; il ne faut pas prendre ça au pied de la lettre
Cet argument vise à corriger la fausse dichotomie selon laquelle « les LLM produisent soit la vérité, soit des hallucinations ». Présenté ainsi, on a l’impression que si on réduit les hallucinations, il ne restera plus que la vérité ; en pratique, toutes les sorties sont une forme d’hallucination. C’est juste que certaines reflètent la réalité ou correspondent à nos attentes, et paraissent donc vraies. C’est comme lancer un dé et dire « le dé a lu mon intention » quand le bon chiffre sort. Comme avec l’image des singes infinis frappant des machines à écrire infinies et finissant un jour par produire Hamlet, on a simplement augmenté cette probabilité avec l’IA
J’ai trouvé ce point de vue intéressant. Reconnaître qu’un LLM ne peut pas savoir si ce qu’il produit est exact apporte, selon moi, un contexte concret pour celles et ceux qui l’utilisent en développement logiciel
Je suis mal à l’aise avec l’usage du mot « hallucination » pour décrire cela. Quand une personne improvise quelque chose de plausible sans aucun fondement, on appelle ça du « bullshit » ; pour les LLM, c’est fondamentalement assez proche. Vu sous l’angle du « bullshit », une partie des critiques sur l’usage des LLM perd en pertinence. Au fond, si cet aspect des LLM vous met mal à l’aise, vous aurez aussi du mal à travailler avec des humains. En revanche, il est bien plus difficile de redéfinir le mot « bullshit ». Cela dit, je trouve que le texte remplit son rôle comme recueil de pensées un peu dispersées, et l’auteur ne semble pas chercher à parler d’une manière autoritaire
C’est formulé un peu maladroitement, mais l’idée centrale est qu’il n’existe pas de différence nette entre une sortie « hallucinée » et une autre sortie. Comme dans un RDBMS, où deux résultats de requête sont essentiellement de même nature. C’est une remarque pertinente
Dans notre entreprise, on a l’impression d’être submergés par du code correct à 90 %, cassé à 10 %, presque au niveau souhaité. La production de code a augmenté, mais personne n’arrive à suivre, donc la qualité baisse clairement. On n’avance pas lentement vers l’objectif ; on atteint 90 % presque instantanément, puis on passe du temps à s’habituer à un code peu familier et à le retoucher encore et encore. C’est peut-être malgré tout plus rapide qu’avant, mais l’écart réel entre les deux approches n’est peut-être pas aussi grand qu’on l’imagine. Ce qui me déplaît le plus, c’est que je préfère créer quelque chose de nouveau plutôt que passer mon temps à corriger du code que je ne connais pas
Moi aussi, je préfère largement créer quelque chose de nouveau. Mais certaines personnes prennent davantage de plaisir à cette nouvelle manière de travailler, rapide et improvisée. J’ai dû l’essayer un moment, ça m’a paru étrange, j’ai tout supprimé, puis j’ai ressenti une vraie satisfaction en le reconstruisant moi-même avec l’aide de l’IA. Le seul code généré par IA que je ne comprends pas encore à 100 %, c’est une requête SQL complexe ; mais avec SQL, on peut vérifier rapidement le comportement et il n’y a pas d’effets de bord inattendus, donc ça va
Ce phénomène ressemble douloureusement à ce qui se passe quand une équipe passe de 3 à 10 personnes. D’un coup, du code qu’on ne connaît pas s’accumule, la cohérence de l’architecture baisse, et on dépend davantage des règles et de la CI. La différence avec les LLM, c’est que le mentorat ou le licenciement n’ont aucun sens. La bonne façon d’utiliser les LLM, c’est que la personne qui les pilote assume 100 % de la responsabilité du résultat généré. Autrement dit, il faut comprendre clairement le code produit, mais garantir cela dans la pratique semble difficile
Les LLM sont très performants pour générer automatiquement du code boilerplate. Cela pousse à moins faire le ménage dans ce boilerplate. Quand de gros volumes de code arrivent en PR, la revue devient difficile. Même GitHub n’est pas vraiment adapté à la revue d’un trop grand nombre de lignes d’un coup. Résultat, les développeurs junior et intermédiaires se retrouvent à ne faire que du déblayage de boilerplate, avec moins d’occasions d’apprendre. Si ça continue, la qualité du code va se dégrader rapidement
Citation de l’aphorisme n°7 de Perlis : « Il est plus facile d’écrire un programme incorrect que de comprendre un programme correct »<br>http://cs.yale.edu/homes/perlis-alan/quotes.html
Je partage l’idée que « la qualité baisse clairement », et ce phénomène va probablement encore s’aggraver. Au final, il faut bien comprendre la notion de compromis en économie pour savoir s’il y aura un vrai « bénéfice net ». Beaucoup de gens semblent oublier qu’il n’existe pas de repas gratuit
Le cadrage de Rebecca Parsons — « l’hallucination est une fonctionnalité centrale des LLM » — me parle vraiment. J’essayais moi aussi de l’expliquer autour de moi, et cette formule résume parfaitement ce que je voulais dire
Moi aussi, j’explique aux proches les LLM en les comparant à des acteurs ou des comédiens. Les LLM jouent simplement un rôle cohérent avec leur personnage et n’utilisent des faits que lorsqu’ils en ont besoin<br>https://jstrieb.github.io/posts/llm-thespians/
La vieille maxime « Tous les modèles sont faux, mais certains sont utiles » s’applique parfaitement ici
L’intelligence, c’est la capacité à filtrer l’information non nécessaire, qu’il s’agisse de pensées ou de perceptions
Je ne me souviens plus de qui l’a dit, mais la sortie d’un LLM est toujours une hallucination. C’est juste que dans plus de 90 % des cas, elle tombe juste
Pendant un moment, j’ai eu l’impression que les LLM allaient nous prendre notre travail, mais j’ai fini par comprendre qu’ils pouvaient surtout nous laisser une montagne de travail à corriger plus tard. Aujourd’hui, je m’en sers bien comme outils d’assistance pratiques, comme Claude Code, et je ressens clairement qu’il s’agit d’un complément, pas d’un remplacement
J’ai vu ce conseil : « quand vous demandez une réponse chiffrée à un LLM, posez la question trois fois ». Ça marche aussi avec les humains. En interrogation policière, on fait raconter la même histoire trois fois, ou à l’envers. Si la personne ment ou si son souvenir est flou, elle peut finir par se trahir à force de répétitions. En entretien aussi, faire expliquer un sujet de trois façons différentes permet de vérifier si quelqu’un le comprend vraiment
Cette technique peut aussi embrouiller des personnes innocentes au point de les faire paraître menteuses. Il faut l’appliquer avec prudence
Ce genre de méthode n’est valable que dans certaines conditions. Il existe de nombreux cas où plus on rappelle un souvenir et plus on le reformule, plus il se déforme. Quand la police pose plusieurs fois la même question, c’est parfois justement pour provoquer des contradictions. Même avec une information identique, si on demande à quelqu’un de répondre trop souvent, de trop de façons différentes, il finira par se tromper. Et il faut toujours garder à l’esprit qu’on peut orienter les réponses dans le sens voulu par la personne qui pose les questions
La navette spatiale de la NASA utilisait la redondance modulaire triple. C’était pour se prémunir contre la corruption des processeurs ou de la mémoire due au rayonnement spatial<br>https://llis.nasa.gov/lesson/18803
Avec les LLM, j’ai l’impression d’être nettement plus productif. Ce n’est pas juste de l’autocomplétion : le gain de temps est réel. Mais je crains aussi qu’un usage trop libre crée sa propre dette. Personnellement, j’ai eu de bons résultats en construisant progressivement des fonctionnalités avec Claude Sonnet ou GPT-5 dans une approche Test Driven Development (TDD). Il n’y a pas encore beaucoup d’articles ou de discussions sur cette manière de faire, mais après avoir lu le texte de Martin, je crois comprendre pourquoi. Les vrais experts du TDD ne sont pas forcément ceux qui se ruent sur l’automatisation du code par LLM ; ils sont souvent fiers de l’esthétique du code et de la communication humaine. Du coup, il manque encore, pour l’instant, beaucoup de savoir-faire pratique comme on pouvait en trouver autrefois. Je pense qu’un nouveau « territoire » va s’ouvrir autour de l’écriture logicielle avec outils LLM, et qu’on en tirera énormément de leçons. Référence : https://news.ycombinator.com/item?id=45055439
Pour un développeur, il est normal de vérifier et contrôler directement le code produit par un LLM. Il vaut mieux éviter de demander trop de code d’un seul coup et utiliser le LLM sur des unités plus petites. J’exécute aussi moi-même les tests unitaires. Quand un LLM dit qu’il a lancé les tests et que « tout est passé », ce n’est pas forcément vrai. Je ne fais confiance aux tests que lorsque je les exécute moi-même
Je suis d’accord avec l’idée que « l’hallucination est une fonctionnalité des LLM »
J’aime dire que les LLM vivent dans un monde composé uniquement de texte et de combinaisons. Les mots, les histoires : pour eux, c’est l’intégralité du monde. C’est pourquoi ils excellent avant tout à inventer de nouvelles histoires. Leurs histoires sont parfois inexactes ou contradictoires, si bien qu’au final ils dépendent de la conjecture. Un LLM ne sait pas vraiment compter des nombres, mais il connaît des motifs comme « 2 vient après 1 » et « 3 est plus grand que 2 ». Comme les humains avec une calculatrice, ils peuvent aussi effectuer des opérations via des outils. À l’avenir, il faudra introduire non pas un moteur arithmétique, mais un « moteur épistémique » capable d’aider à raisonner, à éviter les contradictions et à distinguer les faits établis : c’est à cette condition qu’on aura une IA réellement digne de confiance
Dans cette perspective, on peut voir les agents LLM simplement comme un moyen de filtrer les résultats hallucinés
Je suis davantage d’accord avec l’idée que « toute sortie d’un (grand) modèle de langage est une hallucination ; certaines sont simplement utiles ». C’est parce que la proportion d’hallucinations utiles est très élevée que le boom de l’IA a eu lieu
Je trouve que c’est une vision trop simplificatrice
C’est aussi pour cela que le terme « hallucination » suscite toujours des débats. Il donne l’illusion que certains résultats pourraient ne pas être des « hallucinations », alors qu’en pratique toutes les sorties des LLM sont générées sans réflexion
Aujourd’hui, pour bien exploiter les LLM, il faut encore des développeurs expérimentés capables de réagir de manière logique afin d’obtenir les résultats souhaités. Si les juniors disparaissent à l’avenir, je me demande qui remplacera les seniors. J’imagine qu’à terme, les LLM finiront par programmer suffisamment par eux-mêmes. À ce stade, l’IA est clairement un bon outil d’assistance, pas un substitut
À propos du conseil consistant à poser plusieurs fois la même question à un LLM : pour les utilisateurs de macOS, je recommande d’utiliser un workflow Alfred. On appuie sur command + space puis on tape
llm <prompt>, et on peut lancer d’un coup, dans des onglets de navigateur, plusieurs LLM comme perplexity, deepseek (local), chatgpt, claude ou grok. Cela permet de faire rapidement et efficacement la validation croisée entre LLM dont parle Fowler ; à force d’utiliser plusieurs outils, on finit aussi par repérer quel LLM est le plus fort pour quel type de tâche