Dans le cadre du projet Revue30, nous avons beaucoup de discussions sur l'utilisation des LLMs dans le cadre du développement d'applications, logiciels et outils (merci beaucoup en particulier à David Larlet, Guilllaume Grossetie, Clara Grometto, et beaucoup d'autres personnes pour leurs réflexions). Il s’agit de pratiques très hétérogènes, allant du « vibe coding » pur (faire écrire du code à un LLM en lui donnant juste un prompt) à des demandes ponctuelles d’aide auprès de LLM pour déboguer une fonction, réécrire du code ou proposer des solutions à des problèmes particuliers…

Je voudrais commencer à poser certaines balises pour m'orienter dans les enjeux. Je précise que mon point de vue n'est pas complètement figé et que je crois qu'il faut faire une casuistique très complexe et précise pour éviter des prises de position trop génériques et idéologiques, et surtout pour éviter de tout confondre.

Tout d'abord, il faut distinguer deux enjeux qui sont à mon sens complètement différents -- au moins du point de vue théorique:

1. La question du rapport entre travail "humain" et travail des "machines". C'est le point le plus subtil et sur lequel, il me semble, il y a une panoplie de positions différentes toutes acceptables, mais qui ont des implications spécifiques à analyser attentivement.
2. La question du pouvoir et des impacts de la concentration des applications des grandes entreprises numériques, de leur opacité et des enjeux politiques connexes. En ce qui concerne ce dernier aspect, mes convictions sont plus définies.

"Humains"? "Machines"?

Je pense que l'opposition humain-machine est très mal posée, qu'elle représente un faux problème et qu'elle devrait être analysée autrement. Toutes nos pratiques sont technologiques. Il n'y a rien de "purement humain". Où se trouve la ligne de séparation? Utiliser une aide à la saisie de la syntaxe, un plugin qui permet de récupérer des fonctions dans une librairie, copier-coller des bouts de code depuis une discussion sur Stack Overflow, saisir un raccourci clavier, demander à son voisin de l’aide pour déboguer un programme, utiliser un éditeur de code plutôt qu’un autre… Tout cela est déjà une hybridation.... La syntaxe d'un langage de programmation, l'écriture elle-même sont des technologies qui externalisent la "pensée". Ou mieux: la pensée est toujours déjà technique.

La question, de ce point de vue, consiste donc, à mon avis, à identifier quelles sont les tâches auxquelles on attribue de la valeur symbolique et quelles sont celles que l’on considère comme triviales -- ou du moins celles dont nous ne voulons pas nous occuper directement. Je ne veux pas me concentrer sur l'écriture d'une fonction qui fasse une softmax, par exemple, et donc je l'importe d'une librairie qui la fait déjà. J’utilise un CSS déjà fait et je ne le fais pas moi-même, je paie quelqu’un pour le faire ou… je demande à un LLM de le faire pour moi.

Dans ce sens, ici, il faut s'interroger sur ce à quoi on attribue une valeur symbolique et ce à quoi on en attribue moins (c'est mon discours sur la fabrique des subalternes et sur le fait que la pensée n'est pas une prérogative "humaine").

Certes, quand on délègue une tâche -- à une "machine" ou à une autre personne, ça ne change rien -- on en est en quelque sorte dépossédé et on désapprend à la réaliser nous-mêmes. C'est vrai quand on délègue un calcul à une calculette -- on devient moins bon en calcul mental ou manuel. C'est ce qui arrive quand on achète une pétrisseuse et qu'on arrête de pétrir la pâte à pain nous-mêmes (clin d'œil à David qui fait du pain excellent, en pétrissant à la main). C'est ce qui arrive, plus généralement, avec la naissance de l'écriture: les cerveaux humains deviennent plus petits parce qu'on délègue la mémoire... La question est de savoir quelles tâches nous avons envie de déléguer et d'arrêter d'être capables de réaliser.

Ainsi, des développeurs me disent qu'ils n’ont pas envie de "perdre du temps" pour refactoriser du code, car un LLM peut bien le faire à leur place. Est-ce un bien? Ça dépend de nos objectifs, de nos valeurs, etc. Parfois, j'ai envie d'écrire moi-même l'algorithme qui fait du tf-idf, pour mieux comprendre comment ça fonctionne et aussi parce qu'en le faisant, je peux me concentrer sur les détails de l'algorithme, changer des paramètres fins, tester des choses. Il y a une grande valeur ajoutée à faire ça. Mais parfois, je peux me dire qu'une librairie déjà faite me convient, je vais l'importer et l'utiliser, ou demander à mon voisin de l'écrire, ou demander à un LLM. Et peut-être désapprendre à la faire moi-même.

Quelles sont les compétences que nous voulons garder? Et pourquoi? Où se situent les enjeux épistémologiques d'un projet particulier? Parfois même les choix d'indentation du code peuvent être fondamentaux pour un projet. Parfois je peux décider qu'ils ne m'intéressent pas.

Il y a par contre une considération fondamentale par rapport à ce point: le fait de décider qu'un certain type de compétence ne nous intéresse pas ne doit pas se transformer dans une attitude consistant à penser que cette compétence est "inférieure" ou pas intéressante en absolu. C'est ce qu'on remarque dans le phénomène du "Sloppy pasta". En gros: je n'ai rien à foutre d'une certaine chose -- par exemple, une fonctionnalité dans une application, mais aussi, un état de l'art pour un article, ou un résumé d'un article -- je le fais donc faire à un subalterne -- ou à un LLM... ça ne change rien -- je ne regarde même pas le résultat et puis je laisse le travail à quelqu'un d'autre. Dans le cas du vibe coding: je fais un prompt de trois mots en disant "fais-moi ça", l'LLM produit 1000 lignes de code dont je n’ai aucune idée de ce qu'elles font et que je ne me donne même pas la peine de relire et avec ça je fais une merge request en laissant le "sale travail" à une pauvre personne qui devra, de fait, faire le travail à ma place. Le problème ici n'est pas le rapport humain-machine, mais le rapport de pouvoir où on considère que des gens peuvent s'occuper de tâches que nous n'avons pas envie de réaliser -- en dévalorisant de manière brutale leur travail.

Mais certes, au contraire, l'usage d'un LLM peut être aussi un moyen d'apprentissage et d'émancipation -- apprendre à faire ce qu'on ne savait pas faire en se faisant aider par un LLM.

GAFAM?

Le second point concerne la réalité infrastructurelle, industrielle et commerciale des applications qu'on utilise. Concrètement: parle-t-on d'LLMs ou des deux ou trois applications, faites par des GAFAM? Car si LLM devient synonyme de OpenAi, Microsoft, Antrhopic, Google et une poignée d'autres entreprises, la question est différente. Les problèmes qui se posent sont tout à fait différents. Voici certains points d'attention:

1. Concentration et uniformisation. Toute opération passe par ces quelques entreprises. On concentre les pratiques et elles deviennent toutes uniformes. La façon de faire du code est déterminée par ces modèles uniques, biaisée par leur uniformité. Toute possibilité de différence est effacée. Tout comportement minoritaire, toute forme de pensée non majoritaire finit par disparaître. Le problème ici n'est pas l'utilisation de "technologies" ou de "machines". Le problème est que nous n'avons qu'une seule "machine", tous la même.
2. Opacité. On n'a aucune idée de comment ces applications fonctionnent -- quelles couches applicatives, quel type d'entraînement, quel prompts de système, quels paramètres, etc.
3. Impact environnemental. Ces entreprises développent des applications de plus en plus "grosses" qui utilisent une force computationnelle immense parfois pour réaliser des tâches très simples... Faire de l'autocomplétion de fonctions avec un LLM c'est bête, car on pourrait le faire avec des approches beaucoup moins couteuses. Dans ce sens, les GAFAM nous poussent à utiliser la même solution très high-tech aussi pour réaliser des tâches simples, avec des impacts environnementaux immenses et inutiles. D'ailleurs, leur comportement par rapport aux infrastructures -- un centre de données au Texas, par exemple -- est complètement irresponsable et très dangereux socialement et politiquement.
4. Vie privée, droit d'auteur, reconnaissance du travail. Finalement: où vont les données? Comment sont-elles gérées? Sont-elles réutilisées pour réentrainer des modèles? Pour extraire des informations? Tout ce que nous faisons devient la propriété de trois ou quatre entreprises qui s'approprient notre travail sans le payer pour ensuite le revendre. Cette attitude par ailleurs, a un impact néfaste sur nos infrastructures: il devient désormais impossible de mettre en ligne même un site en HTML statique sans se préoccuper de mettre en place des solutions complexes et coûteuses pour limiter les requêtes des bots qui, souvent, rendent toutes nos productions inaccessibles.

De ce point de vue, il me semble que l'utilisation de ces applications est très problématique et même irresponsable et devrait être limitée et parfois même interdite.

Le problème est que ce sont ces applications qui nous semblent "plus performantes", justement parce qu'elles sont plus "grosses". Pour les éviter, il faut se "contenter" de technologies moins "puissantes" et plus légères, qui parfois semblent donner des résultats moins convaincants -- un petit modèle qui tourne en local n'aura pas les mêmes résultats qu'une énorme application, on ne pourra pas lui dire "fais-moi une application"... il sera incapable de le faire. Il fera aussi beaucoup plus d'"erreurs".

C'est le vieux problème du rapport entre high-tech et low-tech, dont j'ai beaucoup parlé dans mon Éloge du bug et dans quelques billets de blog...

On doit revenir à des considérations beaucoup plus générales sur nos objectifs, la pertinence du paradigme de la productivité, nos valeurs, nos convictions politiques, nos visions du monde, si nous voulons nous orienter dans ce débat.