⏩2026.03.30
auto-complétion
Durant les séances d’exercice, je me retrouve souvent à réfléchir au rôle que joue l’auto-complétion, et plus généralement les outils de génération de code, dans la pratique de la programmation. Car c’est, je pense, l’un des nombreux domaines où les dommages causés par l’IA générative se fait fortement ressentir.
L’auto-complétion “traditionnelle” fonctionne est simple et largement déterministe: étant donné les éléments présents dans le scope et les premières lettres entrées par l’utilisateur, déterminer quels sont les possibilités de complétion et (seule partie probabiliste) les trier selon leur pertinence. Les outils de génération, eux-aussi, sont (étaient) simple: étant donné un template paramétrable, et une série de paramètres, générer un ou des blocs de code.
Simple, mais puissant. Il y a plus de dix ans maintenant, je l’utilisais pour générer des dizaines de classes à la volée en Java sur base d’un schéma de base de données. Tout le boilerplate répétitif de la création de classes “modèles” et “contrôleurs” était fait, on pouvait se concentrer sur la logique de plus haut niveau du programme.
Et l’auto-complétion classique, en plus d’être un gain de
temps, est aussi un formidable outil d’apprentissage et de
découverte. Quelles sont les méthodes disponibles depuis cette
classe? Tape un ., appuie sur TAB (ou
Ctrl-Espace selon les IDEs, en général), et fait
défiler tout l’univers des possibilités. Cette auto-complétion
fonctionne au rythme du développeur et encourage la réflexion et
la remise en question. Il m’est régulièrement arrivé de
m’arrêter, intrigué par une proposition de méthode que je ne
connaissais pas, de lire rapidement la documentation, et de me
rendre compte d’une possibilité que je n’avais pas envisagée
pour remplir les besoins de mon programme.
Le code généré, quand à lui, ne nécessitait pas vraiment de relecture. Une fois qu’on avait compris le principe de comment configurer le template, on pouvait être certain que le résultat serait toujours exact, et on garde une compréhension aussi complète que possible de ce qui se trouve dans le code du projet.
Les IAs génératives nous privent de tous ces bénéfices, et ne visent plus qu’à l’objectif de productivité à court terme: produire plus de lignes de codes, maintenant, tout de suite.
L’étudiant.e écrit if, et l’IA propose
immédiatement un bloc if-else complet qui fait
quelque chose, quelque chose qui à première vue semble
toujours logique par rapport à ce qui leur est demandé.
Parfois, on peut résoudre un exercice complet à coup de
TAB-TAB-TAB jusqu’à ce
que tous les tests passent.
On ne sait pas ce qu’il y a dans le code. On ne sait pas pourquoi ça marche. Quand finalement ça ne marche plus, on n’a pas la moindre idée de par où commencer.
Vécu récemment: un.e étudiant.e m’appelle, me montre son code.
– Monsieur, je ne comprends pas ce qu’il se passe.
– Qu’est-ce qui ne marche pas?
– Ca marche, mais je ne comprends pas pourquoi il faut écrire
ça.
– Pourquoi tu l’as écrit? Qu’est-ce que tu cherchais à
faire?
– …
Je peux alors expliquer le pourquoi, mais la qualité de l’apprentissage n’est jamais la même. On apprend en faisant. Avec l’IA générative, l’étudiant.e ne fait pas, il relit ce que l’IA a fait et pense le comprendre.
Heureusement, iels sont nombreux.ses à s’en rendre compte. Beaucoup m’appellent pour me demander de l’aide pour couper les aides IA. Ils voient bien qu’ils n’apprennent pas. Mais ces outils reviennent, se réactivent, se réinstallent à chaque mise à jour. Ce sont des mauvaises herbes dont ils peinent à se débarrasser. Et la tentation est toujours présente, quand la charge de travail devient un peu trop élevée, lorsqu’on se sent un peu trop largué, lorsqu’on est coincé alors que l’enseignant.e est occupé.e avec d’autres et qu’on a envie d’avancer.
L’utilisation des IAs génératives brident l’apprentissage. C’est dramatique pour les étudiant.es, c’est problématique même pour les développeur.euses aguerri.es. J’ai beaucoup appris durant cette première année en tant qu’enseignant, à donner des cours dans des matières qui ne sont pas nécessairement les miennes. Je suis un meilleur développeur aujourd’hui que je ne l’étais il y a un an. Et je le dois, je crois, au fait que je me suis forcé à toujours faire les choses moi-même, à faire tous (ou presque) les exercices qu’on demande aux étudiant.es de faire, à me donner des petits projets pour aller plus loin. Et toujours j’ai cherché à avancer à petits pas, en comprenant à chaque étape ce que je faisais et pourquoi je le faisais.
Serais-je allé plus vite avec Claude à mes côtés? Peut-être. Mais j’en serais sorti diminué. Au fur et à mesure des années, je suis persuadé que celleux qui se reposent sur Claude et ses amis seront de moins en moins compétents, de moins en moins capable de réfléchir, de moins en moins capable de penser une solution. Je crois qu’aujourd’hui déjà, et certainement demain après l’éclatement de la bulle spéculative des IAs génératives, être capable de développer sans agent à mes côtés est une compétence qui n’a pas de prix.