Une analyse honnête de la programmation avec l'IA

Par Mathieu Ropert

On m’a offert un abonnement à Claude et on m’a conseillé de me lancer dans le « tokenmaxxing », alors j’ai décidé de lui donner une chance.

De nos jours, il devient difficile d’échapper aux grands modèles de langage (LLM). Même si vous évitez les réseaux sociaux (ou du moins si vous sélectionnez soigneusement les comptes que vous suivez pour éviter l’essentiel de cette usine à contenu médiocre) et que vous faites fi des déclarations marketing grandiloquentes qui finissent par être prises pour argent comptant dans l’actualité, cette technologie finira probablement par vous rattraper sur votre lieu de travail. Contrairement aux solutions miracles du passé (comme les microservices ou NoSQL), l’adoption de l’IA semble avoir été imposée dans de nombreuses entreprises par la haute direction, quel que soit le nombre de ses membres ayant jamais exercé (ou étudié pour exercer) un métier d’ingénieur.

J’avoue que cette approche a immédiatement réveillé mon côté rebelle et m’a rendu très méfiant envers tout outil d’IA. Je ne crois pas qu’une personne qui n’a jamais écrit une seule ligne de code de sa vie doive me dire quoi utiliser dans mon travail d’ingénieur. Cela me semble être le cas le plus grave de microgestion, et ce n’est jamais une bonne chose (sans compter que c’est personnellement insultant).

Quoi qu’il en soit, au cours des trois derniers mois, j’ai eu l’occasion d’utiliser Claude et ses semblables dans le cadre de mon travail, et je dois admettre que je les ai trouvés assez utiles. À condition de ne pas lui demander d’écrire du code. S’il vous plaît, ne lui demandez pas d’écrire du code. Mais je m’avance un peu trop.

« Intelligence » artificielle

Vous l’avez sans doute entendu un million de fois à présent, mais l’intelligence artificielle n’est vraiment pas si intelligente que ça. Ce n’est que du marketing et des mots à la mode. Tout ce dont nous disposons réellement ici, c’est d’un (très) grand réseau neuronal spécialisé dans le traitement du langage naturel.

Il s’avère qu’une grande partie de ce que nous, les humains, faisons sur un ordinateur consiste à utiliser du texte pour communiquer dans les deux sens ; ce modèle peut donc être utilisé pour analyser des requêtes, générer des réponses textuelles basées sur une heuristique probabiliste ou produire des lignes de commande qui peuvent ensuite être exécutées à l’ancienne, leurs résultats étant réinjectés dans le modèle pour former une boucle jusqu’à ce qu’on atteigne une condition de sortie. (Je sais que les grands modèles de langage (LLM) peuvent également générer des images et des vidéos. Mais cela dépasse le cadre de cet article. De plus, les résultats sont nuls. À mon sens, « l’art » généré par l’IA n’a aucun avenir.)

Cela ne veut pas dire que ce soit intrinsèquement mauvais. Mais ce n’est pas non plus de la magie. Le « workflow agentique » (ou quel que soit le nom qu’on lui donne au moment où vous lisez cet article) n’est que la prise de conscience que tout problème logiciel peut être résolu en ajoutant une couche supplémentaire d’indirection, et les LLM ne font pas exception. Si la sortie du réseau neuronal peut être améliorée en fournissant davantage d’entrées, alors ajoutez davantage d’entrées. Et si la meilleure façon de déterminer quelle serait cette entrée consiste à interroger le modèle pour qu’il génère une commande, puis à la transmettre via system(), qu’il en soit ainsi.

Mais concentrons-nous sur le point de vue de l’utilisateur pour la suite de cet article.

Nous avons Google à la maison…

Il y a une mine d’informations précieuses sur Internet. Et en supposant que nous parvenions à préserver correctement les archives existantes, la somme totale des connaissances publiques ne peut que s’enrichir (mais, attention spoiler, il y a une mise en garde). Le problème, c’est de les trouver. Ce n’est pas nouveau. Je suis assez âgé pour me souvenir de l’époque où l’on vous suggérait pour la première fois d’essayer ce nouveau « Google ». Mais malheureusement, la situation s’est considérablement détériorée depuis l’âge d’or des années 2000. Ils mènent depuis un certain temps déjà un combat difficile contre le référencement naturel (SEO), et il ne semble pas qu’ils soient en train de gagner. (Si vous aimez cuisiner et que vous cherchez parfois des recettes en ligne, vous voyez exactement ce que je veux dire.)

C’est là qu’intervient l’IA, à la fois comme aide et comme obstacle. En tant qu’outil de recherche, je l’ai trouvée généralement efficace pour répondre à des questions précises formulées en langage naturel, notamment grâce à sa capacité conversationnelle qui permet d’affiner la réponse ou de poser des questions complémentaires en tenant compte du contexte actuel. En pratique, cela revient à effectuer une série de recherches, à parcourir les N premiers liens et à répéter l’opération jusqu’à ce qu’on estime avoir saisi le sujet. Rédiger un bref résumé à partir de textes plus longs semble être ce que les grands modèles de langage (LLM) font le mieux ; il est donc logique de les utiliser pour automatiser ce processus. De plus, l’exploration et la synthèse de plusieurs recherches constituent une tâche intrinsèquement parallèle ; il n’est donc pas difficile d’imaginer les gains d’efficacité que peut apporter l’automatisation de ce processus. À condition, bien sûr, de disposer de suffisamment de puissance de calcul et que les résumés ne soient pas fantaisistes — nous reviendrons sur ces deux points plus tard, car ils sont assez importants.

Le revers de la médaille est bien sûr que les LLM ont réduit le coût de l’inondation d’Internet par un « méli-mélo de mots » qui dilue un océan d’informations déjà précaire. Freya Holmér a publié une vidéo sur le sujet et l’impact de la pollution du Web par du contenu généré par l’IA dans la course sans fin au référencement naturel (SEO). La recherche manuelle d’informations reste une option aujourd’hui, surtout si vous connaissez déjà des sources fiables sur un sujet particulier. Mais si ce n’est pas le cas, il faut faire preuve d’une grande prudence pour trier le fatras des données réelles, et l’automatisation à l’aide d’une boucle LLM risque de ne pas aider si vous ne pouvez pas lui indiquer quelles sources conserver et lesquelles écarter. Avant même d’évoquer les hallucinations, un résumé généré par un LLM ne peut être que d’une qualité équivalente à celle des sources qu’il a ingérées.


…et désormais, Google est également présent au travail

Un domaine particulier dans lequel j’ai trouvé utile d’utiliser une boucle LLM pour effectuer des recherches, et dont je n’ai pas encore vu beaucoup de discussions jusqu’à présent, concerne les bases de connaissances internes aux entreprises. Quel que soit votre lieu de travail, il y a fort à parier que vous disposiez d’un mélange de wikis, de conversations sur Slack, de fichiers Google Drive, de pages Confluence et autres, où se trouvent de nombreuses informations utiles, mais que personne ne semble jamais parvenir à retrouver. J’ai constaté que certaines de ces « solutions d’entreprise » étaient si médiocres que, parfois, je ne parvenais pas à retrouver une page que j’avais consultée une semaine auparavant, même en saisissant le titre (ou ce dont je me souvenais du titre) dans la barre de recherche. J’ai moi-même rédigé mon lot d’articles techniques internes dont je suis presque certain que personne n’a jamais pris connaissance depuis, à moins d’avoir conservé un signet datant du moment où je l’avais partagé pour la première fois dans le chat technique de l’équipe.

Au cours des derniers mois, bien que je sois nouveau dans l’entreprise, j’ai pu trouver toute une série de réponses rédigées avant mon arrivée. Tout comme la « recherche Google avec IA » peut exécuter plusieurs requêtes en parallèle et synthétiser la réponse, Claude et ses outils peuvent transformer ma question en langage naturel en une série de requêtes de recherche portant sur des synonymes probables jusqu’à ce qu’ils tombent sur quelque chose. Cela s’est avéré très pratique lorsque j’ai rencontré un cas particulier avec le moteur : j’ai pu vérifier rapidement si quelqu’un l’avait déjà signalé, proposé une solution de contournement ou expliqué pourquoi il se comportait ainsi. Chaque fois que vous rencontrez un problème technique, il y a de fortes chances qu’il ait déjà été abordé auparavant, et vous partez de bien meilleur pied si vous parvenez à retrouver cette conversation.

Techniquement, ce n’est pas une technologie nouvelle. L’une des raisons pour lesquelles Google et ses concurrents sont si efficaces depuis si longtemps, c’est qu’ils génèrent automatiquement des synonymes lorsqu’ils créent des métadonnées de mots-clés pour une page. Ce n’est probablement pas le cas des fonctions de recherche de votre wiki d’entreprise ou de votre messagerie instantanée. (Le courrier électronique, en revanche, a connu quelques progrès depuis l’époque où il fallait installer Google Desktop pour pouvoir trouver quoi que ce soit dans Outlook, probablement parce que les plus grands fournisseurs de messagerie disposent aujourd’hui à la fois d’un moteur de recherche et d’un département de recherche en IA.) Je soupçonne qu’il y a beaucoup de valeur cachée dans les historiques de conversations Slack datant d’un an, qui sont absurdement difficiles d’accès sans un LLM pour les rechercher, ou sans un collègue plus expérimenté capable de s’en souvenir et de vous y diriger.

D’un point de vue technique, est-il efficace de faire tourner un LLM coûteux pour effectuer des recherches dans le wiki d’une entreprise alors qu’il serait possible de mettre en œuvre des techniques de moteur de recherche basiques qui existent depuis des décennies ? Non, j’en suis presque certain. Indexer le contenu comme le faisait Google il y a 20 ans serait sans aucun doute une solution bien plus efficace en termes de ressources informatiques. Mais du point de vue de l’utilisateur, c’est bien plus souhaitable que d’essayer de rechercher « UI » et de n’obtenir aucun résultat parce que le texte en clair indique « User Interface » dans la page qu’il consulte.

Hallucinations et faux positifs

Une fois qu’un LLM a trouvé une réponse, il est généralement recommandé de consulter la source primaire. La lecture de cet article, de ce document ou de ce historique de discussion permettra de s’assurer que la réponse n’est pas le fruit d’une hallucination.

Les hallucinations sont une caractéristique inhérente au fonctionnement des LLM. La génération de tokens ne repose pas sur la logique ou la vérité, mais sur des statistiques, et d’après ce que j’ai compris, il n’existe aucun moyen de les éviter complètement. J’en ai fait l’expérience avec tous les modèles, de la version gratuite (et assez médiocre) de Copilot fournie avec Bing aux modèles payants les plus sophistiqués de Claude.

Je les ai trouvées particulièrement fréquentes lorsque je posais une question très spécifique à laquelle personne n’avait encore répondu, par exemple en demandant une fonctionnalité de niche particulière dans CMake, Vulkan ou Xcode. Au lieu de répondre « non, ce n’est pas possible », j’obtenais une réponse hautement probabiliste qui me suggérait d’essayer de cliquer sur un bouton qui n’existait pas ou d’activer un indicateur de fonctionnalité inexistant.

Tout cela revient à interroger quelqu’un qui connaît globalement bien un domaine, mais pas le logiciel ou la bibliothèque spécifique que vous utilisez. Cette personne répondrait « oui, ça semble être quelque chose que vous devriez pouvoir faire », car cela semble être une attente raisonnable et qu’il s’agit peut-être d’une fonctionnalité présente dans des produits similaires. Je soupçonne que c’est pour la même raison que, lors de l’écriture de code, un LLM tenterait d’appeler une API inexistante : en se basant sur d’autres langages, il semble en effet que les conteneurs C++ devraient disposer d’une fonction .sort(). Car c’est le genre de chose que l’on peut faire en Python et en C#. Ce n’est pas le cas, car le C++ établit une distinction très nette entre les conteneurs, les itérateurs et les algorithmes, mais les LLM ne raisonnent pas (même si leur marketing parle de « raisonnement ») à partir des principes fondamentaux.

Bien que l’on puisse remédier en partie à ce problème en demandant systématiquement une source primaire ou une référence, je n’aime pas l’idée de devoir ajouter des formules magiques à ses requêtes pour obtenir les bons résultats. On peut bien rire des mèmes « ne vous y trompez pas », jusqu’à ce qu’on doive commencer à prendre ce genre de choses au sérieux. De plus, les modèles semblent faire l’objet d’une nouvelle version chaque année, voire plus souvent, ce qui obligerait probablement l’utilisateur à revoir tous ses rituels (ou à les voir devenir des rituels inutiles que les ingénieurs accomplissent sans se souvenir pourquoi).

Un autre problème que j’ai remarqué est qu’avec les connecteurs, il est assez facile d’amener le LLM à s’autoalimenter. Par exemple, lorsqu’on lui a demandé de trouver des mentions antérieures d’une recommandation que j’étais en train de rédiger pour un client, Claude a insisté sur le fait que cela était étayé par des rapports antérieurs… jusqu’à ce qu’il s’avère que l’un d’entre eux était justement celui que j’étais en train de rédiger. Ce fut assez facile à repérer car je disposais d’une ventilation avec les sources, mais s’il m’avait simplement fourni des chiffres, j’aurais facilement pu créer une boucle qui s’auto-renforce. De même, si des collègues avaient interrogé la même base de données et trouvé mon rapport en cours de rédaction, leurs résumés auraient pu le prendre pour parole d’évangile. Encore une fois, ces robots sont tout sauf intelligents, et il faut souvent leur expliquer des choses très élémentaires pour éviter des hypothèses vraiment stupides.

Pour conclure sur ce sujet, j’ai également remarqué un risque de « jeu du téléphone arabe » avec les connecteurs qui s’interfacent avec un autre LLM. Un jour, Claude m’a affirmé qu’il existait des preuves concrètes qu’une certaine conception technique résultait d’un choix délibéré de l’équipe, alors qu’il s’est avéré qu’il avait pris pour argent comptant le résumé d’une autre IA, et que la véritable source primaire était en réalité deux utilisateurs spéculant sur les raisons pour lesquelles le module fonctionnait ainsi sur des forums publics. Encore une fois, il s’agit d’un outil efficace pour résumer des données, mais pas toujours pour sélectionner celles auxquelles on peut se fier.

Le codage ?

Jusqu’à ce paragraphe, mes cas d’utilisation se sont concentrés sur la recherche. Mais qu’en est-il de l’écriture de code ? Après tout, c’est la prochaine grande révolution et elle ne devrait plus tarder, n’est-ce pas ? Pour faire simple : ce n’est pas très bon.

Si j’ai trouvé les LLM utiles pour la recherche et la planification de modifications de code, mes tentatives pour leur faire écrire du code se sont révélées assez décevantes. Je les ai trouvés lents et coûteux à générer, pour un résultat médiocre.

Dans un cas d’utilisation, après une longue discussion, je lui ai demandé d’effectuer une refactorisation d’optimisation consistant à supprimer la méthode Update() d’un objet dérivé de MonoBehaviour, à placer ces objets dans une List<Foo> gérée par une classe gestionnaire, puis à exécuter la mise à jour équivalente dans la classe gestionnaire sous la forme d’une boucle for. Il s’agit d’une optimisation assez courante dans les jeux Unity pour éviter de payer le coût d’un appel (virtuel) de MonoBehaviour.Update() depuis la partie C++ du moteur vers le script C# géré, lorsque l’on dispose de nombreux objets du même type.

Au lieu de se contenter de cela, Claude a créé une classe de base GameUpdateable dotée d’une méthode OnUpdate(), a fait hériter Foo de celle-ci, puis a stocké le tableau sous la forme d’une List<GameUpdateable> dans le gestionnaire et a créé une boucle appelant GameUpdateable.OnUpdate(). Même si cela pouvait encore être dévirtualisé par certains backends C#, et même si l’utilisation d’un appel C# pur reste un avantage par rapport à un appel C++ vers C#, il s’agissait tout de même d’une solution plus complexe et surconçue que celle que j’avais demandée. Au lieu de « se contenter de faire ce qu’il fallait », Claude avait décidé d’appliquer un modèle de conception OOP qui n’était pas nécessaire. Et ce n’était pourtant pas très difficile à réaliser : les modifications se limitaient à deux ou trois fichiers tout au plus.

D’après mes recherches, cela s’explique probablement par la mauvaise qualité des données d’entraînement pour le développement de jeux (et, dans une certaine mesure, pour toute la programmation native). Les langages favorisant la OOP dominent les données d’entraînement, même après application de certains poids de filtrage.

Pire encore, en ce qui concerne les jeux, il n’existe pratiquement aucune source primaire disponible. Le dernier jeu AAA à avoir été mis en open source était Doom 3, un titre sorti en 2004, il y a 22 ans. Il ne dispose même pas du multithreading ! (Il y en a dans l’édition BFG sortie en 2012, mais il s’agit davantage d’un portage que d’un nouveau jeu.) Les autres classiques publiés sur GitHub au fil des ans datent généralement des années 90, avec une rastérisation logicielle ou, si vous avez de la chance, un pipeline fixe OpenGL 1.2.

Si vous demandez aujourd’hui à un LLM d’écrire du code de jeu, il y a de fortes chances qu’il ait été entraîné sur des projets amateurs, des game jams et des démos de tutoriels, à supposer qu’il ait été entraîné sur des jeux tout court.

Des amis qui travaillent sur des moteurs personnalisés avec des langages de script sur mesure m’ont confié que la plupart des scripts générés par les LLM étaient en totale contradiction avec la façon dont ils les écrivent en interne, car les seules données d’entraînement disponibles pour leur langage de script maison proviennent de mods.

Ah, et quand je parle de coût élevé, n’oubliez pas que les sorties utilisent 5 à 10 fois plus de tokens que les entrées (ou peut-être que les tokens de sortie sont 5 à 10 fois plus chers que ceux d’entrée, ce qui revient au même). Ainsi, alors que la rédaction de résumés ne consomme pas trop de tokens car elle ingère bien plus qu’elle n’en produit, lui demander d’écrire du code, c’est tout le contraire.

Assistant de codage

Je lisais récemment un article sur les travaux du consultant en gestion britannique Stafford Beer. (Si vous avez déjà entendu l’expression « la finalité d’un système, c’est ce qu’il fait », c’est de lui.) Son domaine de recherche, la cybernétique de gestion, peut se résumer très grossièrement à l’idée qu’un dirigeant (et, à plus grande échelle, une entreprise) est limité dans sa capacité à prendre de bonnes décisions par sa capacité à traiter les informations concernant son propre fonctionnement, ses clients et ses fournisseurs, ainsi que tout autre facteur susceptible d’influencer les résultats. (Beer a été influencé par W. Ross Ashby, qui s’est lui-même inspiré des travaux de Claude Shannon. Oui, c’est bien le Claude qui a donné son nom à votre LLM. La boucle est bouclée, en quelque sorte.) Un facteur important réside dans le fait que le flux d’informations (signaux) ne cesse d’augmenter à mesure que les circonstances évoluent ; ainsi, si une information ne peut être traitée, elle sera probablement écartée, et si trop d’informations sont écartées (par exemple dans le cas extrême où l’on réduirait toutes les données entrantes à un simple signal vert ou rouge), des conséquences néfastes s’ensuivront. Il faut disposer d’une variété suffisante de données sur lesquelles agir pour éviter de passer à côté d’un élément crucial.

Dans une analogie similaire (mais imparfaite, je l’admets), l’intégration dans une nouvelle base de code nécessite de traiter un volume important de données pour prendre la bonne décision. Cela se produit chaque fois que l’on change d’emploi ou de projet, et lorsque l’on travaille dans le secteur du conseil, cela peut être assez fréquent. Ainsi, lorsqu’on cherche à avoir un impact sur un projet en peu de temps, on est souvent limité par la quantité d’informations que l’on peut assimiler. Dans ces contextes, disposer d’un LLM capable d’aider à explorer le code et à tirer quelques fils pour voir où ils mènent peut s’avérer très utile. Peut-être aurions-nous dû conserver le nom initial d’« assistant de codage IA » au lieu d’essayer de leur faire tout faire…

Je l’ai utilisé pour essayer de corriger des bugs, et je l’ai de nouveau trouvé utile dans des domaines que je ne maîtrisais pas bien, car il m’a aidé à comprendre certains passages de code, mais je tiens à souligner une fois de plus la nécessité de tout vérifier soigneusement. Je parviens généralement à repérer les affirmations absurdes lorsqu’il s’agit de sujets que j’ai déjà abordés, mais pour les nouveaux domaines, c’est beaucoup plus risqué.

Pour donner quelques exemples, je l’ai testé sur mon projet personnel de rendu et j’ai obtenu des résultats mitigés concernant les bugs que j’essayais de comprendre.

Le premier était un bug de culling dû à une confusion entre les mains. Il était assez facile à repérer si, contrairement à moi, on n’avait pas obstinément refusé d’apprendre les principes mathématiques fondamentaux qui le sous-tendent. Je suis sûr qu’une personne travaillant dans le domaine du graphisme depuis quelques années l’aurait repéré rapidement. Lorsque je lui ai demandé d’écrire un correctif, il a proposé une solution « de manuel » qui fonctionnait, mais qui était bien moins efficace que le projet dont je m’étais inspiré, bien que Claude ait analysé le code source dans son contexte.

Le deuxième problème concernait l’éclairage PBR : il nous a suggéré de réécrire tout le système d’éclairage, de déplacer la position de la lumière principale et d’ajouter un éclairage d’ambiance, pour finalement conclure, après quelques heures, qu’un des éléments comportait une texture métallique/de rugosité défectueuse et qu’aucune modification du code d’éclairage ne permettrait de le corriger correctement. Là encore, il est facile de se laisser entraîner dans une chasse à l’oie sauvage par un LLM qui semble sûr de lui lorsque l’on n’est pas soi-même un expert en la matière.

J’ai souvent cette citation à l’esprit ces derniers temps :


Durabilité

Les entreprises d’IA sont toutes déficitaires. Bien sûr, elles promettent toutes qu’elles finiront par dégager des bénéfices et générer un retour sur investissement faramineux, mais pour l’instant, ce n’est pas le cas. Les jetons que vous obtenez génèrent un bénéfice marginal, mais dans l’ensemble, ces entreprises fonctionnent à perte. (Ce qui signifie qu’ils sont rentables si l’on ne tient compte que des coûts directs liés à l’exploitation du modèle, ce qui exclut une grande partie des dépenses en R&D et en matériel.) Étant donné que le matériel ne devient pas moins cher et que les modèles doivent encore être entraînés en permanence, il ne semble pas, pour l’instant, que les prix actuels soient viables.

Tout cela pour dire que tout indique que les LLM deviendront plus chers à l’avenir, et non l’inverse. Comme pour tout outil que l’on peut acheter ou louer pour faciliter son travail, il faudrait garder à l’esprit un calcul coûts-bénéfices, et jusqu’à présent, cela ne semble pas être le cas, sauf dans les entreprises qui imposent à tout le monde d’utiliser l’IA, avant de revenir sur cette décision quelques mois plus tard, lorsque les factures arrivent.

Auparavant, je devais me battre chaque année pour renouveler la licence d’un outil de profilage qui coûtait environ 20 euros par mois. J’ai appris depuis que tout le monde dans l’entreprise bénéficie désormais d’un abonnement à Claude, même les non-programmeurs. C’est le genre de décision qui me laisse perplexe. La direction ne fait pas confiance à ses ingénieurs pour dépenser leur argent dans les outils dont ils disent avoir besoin, mais impose ensuite à tout le monde d’utiliser un jouet rutilant et coûteux qu’ils n’ont pas demandé.

Un abonnement à un LLM est-il plus polyvalent qu’une licence de profileur pour le programmeur moyen ? Probablement. Je l’ai trouvé utile pour accélérer mes recherches dans des domaines que je ne maîtrisais pas. Est-ce que je l’utiliserais tous les jours si je travaillais en permanence sur le même projet ? Probablement pas. Est-ce que cela a radicalement changé ma façon de coder ? Pas vraiment. Est-ce que cela va remplacer les programmeurs ? Je ne pense pas qu’on en soit là, et à ce stade, je doute sérieusement que cela arrive un jour.

Et si vous vous rendez compte que vous l’utilisez beaucoup pour écrire du code standard que vous ne prenez pas vraiment la peine de relire, vous devriez peut-être investir dans une meilleure API.

Sous licence CC BY-NC-SA 4.0

Source : "An Honest Review of AI Programming"

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Il existe une meilleure façon de coder avec l'IA, par Namanyay Goel

Les instructions génératives de l'IA sont aussi une dette technique, par Sean Goedecke

Nous pleurons notre métier : Le pire avec ces outils d'IA, c'est qu'ils fonctionnent, ils peuvent écrire du code mieux que vous ou moi, par Nolan Lawson

Le piège du codage par l'IA, par Chris Loy