- Alberto Fortin, ingénieur logiciel avec 15 ans d’expérience, avait de grandes attentes vis-à-vis de l’adoption des LLM (grands modèles de langage), mais a constaté plusieurs limites en environnement de production
- Lors de la reconstruction d’une infrastructure basée sur Go et ClickHouse, il a pris la mesure des promesses et des limites de l’IA, et a estimé que même les améliorations des modèles ne résolvaient pas suffisamment les problèmes fondamentaux
- Il souligne qu’il existe une illusion de gain de productivité et qu’en pratique, cela entraîne surtout davantage de bugs et de problèmes imprévus
- Il insiste sur la leçon suivante : considérer les LLM comme des assistants, et comprendre que la conception et les décisions clés doivent être prises par les développeurs eux-mêmes
- « L’IA est révolutionnaire, mais elle n’est pas encore aboutie ; il faut donc un usage équilibré et une perception lucide de la réalité »
L’expérience et le retour d’Alberto Fortin sur les LLM
- Ingénieur logiciel avec 15 ans d’expérience, Alberto Fortin a intégré activement les LLM dans son travail de développement avec de grandes attentes
- En reconstruisant une infrastructure avec Go et ClickHouse, il s’est heurté à plusieurs défis et limites, ce qui l’a amené à écrire un billet de blog sur l’écart entre l’IA et le développement réel
- Plus récemment, il a mené une analyse complémentaire pour vérifier si les modèles récents, comme Claude Opus 4, avaient résolu ces problèmes
- L’expérience d’Alberto offre aux ingénieurs qui s’interrogent sur l’adoption des LLM en contexte professionnel des enseignements concrets, ainsi qu’une vision réaliste de la valeur réelle de ces outils et de leurs limites
Principales citations d’Alberto sur son expérience des LLM
> « J’ai été vraiment surpris de constater que le problème ne se limitait pas à des dysfonctionnements ou à des fonctionnalités qui ne marchaient pas. En tant que développeur qui devra maintenir ce code dans les années à venir, le code doit être suffisamment propre. »
> « On a l’impression que le problème va être résolu rapidement, mais au final une nouvelle erreur apparaît ensuite, et il faut encore environ deux semaines de plus pour la corriger ; cette expérience s’est répétée. »
> « Quand on transmet la sortie d’erreur à un LLM, il propose bien une nouvelle réponse, mais il complique souvent autre chose ou casse une autre partie du système. »
Prise de conscience face aux attentes excessives envers les LLM
> « Quand on utilise pour la première fois de petites fonctionnalités comme l’autocomplétion initiale, tous les développeurs sont impressionnés. On a l’impression que la machine lit dans nos pensées, ce qui tend à faire gonfler les attentes. »
> « On commence à croire que la productivité de développement pourrait être multipliée par dix, alors qu’en réalité on a tendance à nourrir ce niveau d’attente beaucoup trop vite. »
Redéfinir les rôles et les attentes
> « La plus grande différence, c’est le changement dans la perception des rôles. Je suis l’architecte et le développeur senior, et le LLM n’est que mon assistant. C’est moi qui fais le plan, et le LLM joue un rôle de soutien. »
> « Une fois la confiance perdue, je ne lui confie plus de fonctionnalités importantes. Je ne l’utilise plus que sur de petits périmètres, comme le refactoring. »
> « J’ai commencé à corriger les bugs moi-même. Quand on comprend parfaitement la codebase, résoudre directement le problème est beaucoup plus rapide et efficace. »
Évolution du regard porté sur les LLM et conseils
> « En tant que développeur senior, reconnaître que l’adoption des LLM ne me convient pas forcément ne signifie pas que je manque de compétences. L’essentiel est de conserver sa manière de travailler et d’utiliser l’IA comme un outil d’appoint. »
> « Il est vrai que la technologie a franchi une étape, mais elle n’a pas encore atteint la suivante. La prise de décision et l’architecture doivent toujours rester entre les mains des humains. »
> « La révolution de l’IA est impressionnante, mais pour l’instant, il faut des attentes équilibrées et réalistes. »
2 commentaires
Commentaire Hacker News
Si j’ai l’impression de passer trop de temps sur HN, c’est parce que je vois les mêmes arguments revenir dans presque chaque billet et chaque commentaire. Les LLM sont intéressants, mais le code généré est complexe, on ne se l’approprie pas vraiment, et comme on n’en a pas la structure complète en tête comme avec du code écrit soi-même, il est difficile à maintenir. Ça peut convenir pour de petits scripts qu’on n’a pas l’intention de maintenir, mais ça pose problème sur de gros projets. À l’inverse, certaines personnes expliquent que leurs workflows avec plusieurs agents LLM répartissant et fusionnant des tâches sont formidables, mais elles ne montrent jamais de vrai code et donnent surtout l’impression de se vanter
Je trouve que ce résumé vise vraiment juste. Les LLM accélèrent énormément le développement, mais comme je ne comprends pas l’ensemble du code, il m’est difficile d’identifier quand et où un problème est apparu. Au final, j’ai l’impression d’être un nouveau développeur qui découvre son propre projet. Du coup, je fais souvent des commits et je redemande régulièrement au LLM de réexpliquer le code. Dans ce processus, il arrive souvent que le LLM repère lui-même ses bugs. Pour des tâches à périmètre réduit, comme l’analyse de données, on peut aller vite tout en gardant la maîtrise. En revanche, sur une grosse codebase, si on n’a pas les compétences et les habitudes nécessaires pour bien utiliser les LLM, ça tourne facilement au chaos. Savoir rédiger des prompts, gérer le contexte, contrôler le rythme, organiser le travail et relire précisément les résultats du LLM fait partie des compétences indispensables. Personne ne l’enseigne vraiment de manière formelle pour l’instant, donc tout le monde apprend par tâtonnements. Cela dit, une fois qu’on y a goûté, il est difficile de revenir en arrière. On peut confier au LLM les tâches pénibles ou répétitives. Après plus de 20 ans de développement, j’ai aussi moins de patience qu’avant, et pour des idées dont je ne maîtrise pas bien l’implémentation, déléguer au LLM est bien plus efficace
J’aime bien l’idée de considérer la programmation comme un processus de « construction de théorie ». Voir Programming as Theory Building. Je n’ai rien contre l’usage de l’IA en soi. En revanche, je ne suis pas d’accord avec l’attitude qui consiste à se décharger de la responsabilité du résultat produit. Comme avec grep ou n’importe quel autre outil, il n’y a de sens à l’utiliser que si l’on assume ensuite le résultat. C’est encore plus vrai pour du code généré, et on ne peut pas s’en tirer avec un simple disclaimer
Je comprends la fatigue vis-à-vis des contenus sur l’IA. Les avis sont réellement partagés. Cela dit, il existe aussi des exemples concrets de gens qui montrent effectivement leur code. Armin Ronacher, créateur de Flask/Jinja2/Sentry, a mis en ligne sur YouTube une vidéo de workflow ainsi qu’une présentation de sa bibliothèque IA maison, et de mon côté je réalise environ 50 à 80 % de mon projet open source avec l’IA. Voir cijene-api
J’ai l’impression que les utilisateurs se répartissent selon une courbe en cloche. D’un côté, il y a ceux que les LLM submergent parce qu’ils produisent trop de code dans leur propre style, au point que le contexte ne rentre plus dans leur tête. À l’inverse, pour des utilisateurs qui n’auraient jamais pu implémenter seuls ce qu’ils veulent, les LLM ouvrent la possibilité de tout essayer. Et puis il y a aussi ceux qui pourraient implémenter les choses eux-mêmes, lentement, mais qui utilisent les LLM comme une armée de développeurs juniors, se concentrent uniquement sur le niveau algorithmique global et montent bien plus vite des projets de plus grande ampleur
À vrai dire, ce n’est pas si différent du travail sur une grosse codebase à laquelle plus de 25 développeurs contribuent en même temps. Dans mon organisation, 160 ingénieurs travaillent sur le frontend et le mid-tier, et il faut en permanence fouiller dans du code sans véritable propriétaire, avec des
git blamequi affichent souvent le nom d’un prestataire d’il y a trois ans. Les LLM semblent bien convenir à petite échelle, moins bien à l’échelle intermédiaire, puis redevenir utiles comme petit module dans de très gros projetsLes LLM m’aident beaucoup à atteindre mes objectifs, mais j’ai l’impression qu’ils affaiblissent aussi mes capacités de programmation elles-mêmes. C’est un peu comme des stéroïdes : on prend du muscle rapidement, mais avec beaucoup d’effets secondaires, et dès qu’on arrête, tout s’effondre. Comme les entreprises ne s’intéressent qu’aux résultats rapides plutôt qu’à la santé de long terme, ce phénomène s’aggrave encore. J’essaie donc désormais d’en faire un usage plus mesuré
J’ai l’impression que beaucoup de développeurs ont oublié, à cause des LLM, la leçon mise en avant dans "Simple Made Easy". Les LLM excellent à produire du « Ball of Mud » : du code chaotique, complexe, difficile à refactorer ou à maintenir. La vraie force, c’est de découper les problèmes complexes en petits éléments simples, chacun avec un comportement clair, puis de laisser leur interaction produire la complexité globale. Quand chaque composant reste simple, comprendre, déboguer et prédire les performances devient plus facile. Si les LLM finissent un jour par vraiment respecter ce principe, alors peut-être qu’on n’aura plus besoin de développeurs
En réalité, on peut aussi indiquer explicitement au LLM la direction souhaitée. La différence entre ceux qui trouvent les LLM utiles et ceux qui ne les trouvent pas utiles tient à leur capacité à comprendre leurs forces et leurs faiblesses, et à anticiper comment la qualité du résultat varie selon l’entrée, c’est-à-dire le prompt. Par exemple, j’aime demander au LLM comment découper un problème complexe pour vérifier si j’ai raté quelque chose, puis lui déléguer ensuite l’implémentation concrète. Je ne lui demande pas de générer d’un bloc un projet entier sans aucune instruction
Le problème du « Ball of Mud » ne concerne pas seulement le code. Dans mon entreprise aussi, certains dirigeants insistent pour « adopter l’IA de façon agressive », et j’ai vu l’idée de confier à l’IA jusqu’aux systèmes de déploiement et à l’exploitation complexe. On se retrouve alors à empiler une nouvelle boîte noire complexe sur un système déjà complexe, avec cette logique absurde selon laquelle « pour comprendre une boîte noire, il faut une nouvelle boîte noire ». L’ambiance coercitive dans l’organisation me donne parfois l’impression d’être celui qui raisonne de travers
Je me demande si, même dans l’hypothèse où les LLM deviendraient vraiment parfaits, on n’aurait plus besoin de développeurs. Je doute que qui que ce soit veuille d’une machine qui « produit » du logiciel 24/7 en continu. Il faudra toujours quelqu’un pour découper les problèmes, identifier le logiciel réellement nécessaire, puis le faire construire. Aujourd’hui, on appelle simplement ces personnes des développeurs logiciels
J’en suis finalement arrivé à une conclusion assez proche. Les LLM ne sont pas très bons quand on les utilise comme une sorte d’autocomplétion à l’échelle de toute la codebase. Dans ce cas, on perd son modèle mental de ce qui fait quoi et où. En revanche, les utiliser comme un StackOverflow personnalisé pour expliquer des mots-clés, résumer des concepts mal connus ou donner une direction générale, tout en gardant soi-même l’implémentation et les décisions, s’est révélé bien plus efficace
J’utilise aussi cette approche, mais Cursor continue de proposer obstinément des modifications de code. J’aimerais bien connaître l’astuce pour l’obliger à seulement introspecter sans toucher au contenu de la codebase
Dans mon cas c’est différent. Si je relis toujours soigneusement le code proposé par le LLM, j’arrive à garder une vision assez claire de ce qui se trouve où et de la manière dont les éléments interagissent
Moi aussi, je réduis beaucoup ma fréquence d’utilisation. Les réponses des LLM étaient assez souvent fausses. Du coup, ces temps-ci, je leur demande seulement dans quel manuel ou quelle documentation chercher, puis je vérifie moi-même le contenu. Cette méthode m’aide à développer ma capacité à localiser l’information et à moins dépendre des moteurs de recherche comme des LLM. Un LLM n’est qu’un outil, et il est loin d’être parfaitement fiable
Un point qui n’avait été mentionné nulle part, c’est que les LLM peuvent parfois réduire la productivité. Quand ils vous embarquent dans une mauvaise direction avec une réponse plausible, la perte de temps peut être importante. Dans l’ensemble, ils sont souvent utiles, mais la vérification des fondements est essentielle, et il arrive réellement qu’implémenter soi-même soit plus rapide
Les limites des LLM sont claires. Ils sont très puissants, mais ont du mal à faire des sauts créatifs comparables à ceux des humains. Par exemple, à la question « Sur Android, on ne peut pas binder un port inférieur à 1000, alors comment faire tourner un serveur web ? », Claude et Gemini m’ont tous deux proposé seulement trois solutions évidentes : 1) reverse proxy 2) rooter l’appareil 3) utiliser un port plus élevé. La vraie solution que j’attendais était les enregistrements HTTPS RR (référence). Les deux connaissent pourtant ce standard, mais ne savent pas l’appliquer à la situation. J’ai dû ajouter moi-même le contexte pour arriver à la réponse
En fait, je ne trouve pas si étrange que le LLM n’ait pas recommandé cette option. Il est difficile d’attendre qu’il conseille un standard très récent qui n’est même pas officiellement pris en charge par Chrome, et je n’y aurais probablement pas pensé moi-même non plus
Je note aussi cette information. En discutant réellement avec des LLM récemment, je me suis rendu compte qu’un peu d’indulgence, comme avec une personne, réduit le stress. Par exemple, quand je code avec Cursor et que je vois qu’il a oublié quelque chose, je me dis que j’aurais pu faire la même erreur. J’ai aussi utilisé un LLM comme partenaire de « club de lecture » ou de « ciné-club » en lui faisant discuter de deux films : il se trompait parfois sur la situation des personnages, mais sans exiger une exactitude à 100 %, et en faisant preuve de la même indulgence qu’avec un humain, la conversation devient bien plus fluide. Mieux vaut garder une attitude positive quand on échange avec l’IA
Je connaissais les enregistrements SRV, mais j’avais l’impression qu’ils étaient très peu utilisés ; je découvre les HTTPS RR. Leur niveau de support réel semble même meilleur que celui des SRV
C’est le problème classique des LLM : ils n’ajoutent une solution à la liste qu’une fois qu’on a explicitement mentionné la bonne réponse
Si l’on précise suffisamment clairement l’objectif et les contraintes, ChatGPT o3 propose bien cette solution. En revanche, il indique correctement qu’elle ne fonctionne que sur les navigateurs récents. Voir cet exemple
J’utilise souvent la version Enterprise de ChatGPT et, avec le temps, j’ai appris quelques choses. Il ne faut pas lui donner de gros volumes de code, mais travailler sur des fonctions très indépendantes ou de petites classes. Pour les demandes de génération ou de complétion de code, environ 10 % des cas se rattrapent avec des instructions supplémentaires, mais la qualité reste moyenne, et environ 25 % ne s’améliorent pas, quelle que soit l’explication fournie. Dans ces cas-là, je passe outre et je règle le problème moi-même. En revanche, pour relire du code nouvellement écrit, c’est plutôt utile. La moitié des commentaires sont sans intérêt, certains sont ambigus, mais il lui est arrivé de pointer de vrais bugs ou problèmes importants. Mieux vaut ne pas coller plusieurs pages à la fois, mais les découper. Dans des domaines de niche comme les shaders HLSL ou le SIMD, il apporte très peu de réponses, probablement à cause du manque de données d’entraînement. Globalement, cela aide à améliorer la qualité du code. Le fait de valider de petites unités de code pousse aussi à découper l’architecture en fonctions, classes et modules, ce qui améliore la qualité d’ensemble
Dans le développement logiciel de long terme, l’usage le plus séduisant des LLM me semble être celui de « générateur avancé de boilerplate ». Ils sont déjà très bien pour des tâches ponctuelles sans enjeu de maintenance, mais même dans le développement au long cours, ils sont vraiment utiles pour le code répétitif difficile à abstraire proprement, comme les tests. Au début, j’étais réticent, mais maintenant j’en suis très satisfait. Les parties ennuyeuses et répétitives se sont transformées en un nouveau jeu amusant d’« optimisation de prompt », et ma productivité a fortement augmenté. Rédiger des prompts et relire le code va bien plus vite que faire soi-même ces tâches mécaniques. Il ne reste ainsi que les parties intéressantes qui demandent vraiment de réfléchir
J’ai fini par comprendre que les LLM relèvent au fond du même phénomène que les « régimes à la mode », pas seulement pour le code mais pour beaucoup d’autres tâches. Tout le monde veut une solution rapide et facile, mais il n’existe pas de voie royale. Le confort implique toujours des compromis, et tout le monde finira par l’accepter