Coder avec l'IA sans en devenir dépendant

C'est devenu sans bruit l'une des questions que les développeurs posent le plus souvent à voix haute : comment coder sans devenir complètement dépendant de l'IA ? Ceux qui la posent sont souvent ceux à qui l'on s'attendrait le moins. Un étudiant en informatique capable de réussir les examens de théorie, mais qui a construit chacun de ses vrais projets avec un modèle à portée de main, et qui ne sait plus écrire une fonction sans y recourir. Un ingénieur en poste qui remarque, un après-midi ordinaire, qu'il n'a pas tapé une ligne sans aide depuis des semaines. La réponse habituelle arrive vite, presque unanime, et elle vise juste pour exactement un type de personne et se trompe pour la quasi-totalité de ceux qui posent la question.

La réponse est : retirez la béquille.

Résiliez l'abonnement. Désinstallez. Codez hors ligne, comme si on était en 2010. Les métaphores arrivent à point nommé, et certaines valent le détour. Des petites roues boulonnées à l'unique vélo que vous possédez. De la triche à l'examen. Une calculatrice. La formule la plus tranchante : l'IA était un fauteuil roulant dont vous n'aviez jamais eu besoin, vos muscles de codeur se sont atrophiés, et le seul moyen de les remuscler, c'est de porter le poids vous-même.

Si vous êtes étudiant et que vous apprenez les fondamentaux, ce conseil est juste, et je ne vais pas l'édulcorer. On ne peut pas se construire un modèle mental d'un problème si une machine en fabrique la solution à chaque fois. La version la plus prudente de cette mise en garde nomme le vrai danger avec précision : le problème n'est pas d'utiliser l'IA, c'est de la laisser sauter le moment où votre cerveau construit le modèle du problème. Pour cette personne-là, la béquille doit tomber, parce que le but de l'exercice n'a jamais été le programme qui fonctionne. C'étaient les connexions qui se tissent en vous pendant que vous le produisez.

Mais la plupart de ceux qui posent la question ne vont pas devenir des gens qui ne touchent jamais à l'IA. Ils vont devenir des professionnels dont le métier consiste de plus en plus à la piloter. Et pour eux, « utilisez moins d'IA » n'est pas une réponse. C'est une manœuvre dilatoire qui repousse d'un an la vraie question.

La vraie cause

Voici ce qui échappe aux métaphores de la béquille.

La dépendance ne vient pas de ce que l'IA écrit votre code. Elle vient de ce que l'IA écrit du code que vous n'avez jamais transformé en compréhension.

Autant dire d'où je parle, parce que ce n'est pas du côté de l'abstinence. Ces derniers mois, j'ai passé mon temps à construire des outils d'IA : un pipeline qui transforme une phrase en plan et ouvre ses propres pull requests, un plan de contrôle qui gouverne des flottes d'agents. Je m'en sers tous les jours, et je ne vais faire la leçon à personne sur la pureté. Mais chacun de ces outils repose sur une seule règle qui n'a rien à voir avec la quantité d'IA que vous utilisez : personne ne merge ce qu'il ne sait pas expliquer.

Cette règle, c'est toute la différence entre utiliser un outil et en dépendre. Sous les métaphores, un point plus dur ne cesse de refaire surface. Imaginez le développeur tout-IA envoyer du code généré dans un vrai système de production, le voir casser, puis devoir réparer un code qu'il n'a jamais compris. Et la vantardise à la mode selon laquelle l'IA peut « construire toute l'appli sans que j'y contribue en rien » s'effondre au premier contact : vous fournissez quand même les contraintes et vous relisez le résultat, donc vous contribuez, et si vraiment vous ne relisez pas, ce sont vos propres failles de sécurité que vous mettez en production. Le coût de la dépendance, ce n'est pas d'avoir utilisé l'IA. C'est de ne pas pouvoir réparer, à deux heures du matin, la chose qui porte votre nom sur le commit.

Pourquoi l'analogie de la calculatrice s'effondre

La comparaison à laquelle tout le monde pense, c'est la calculatrice. Les calculatrices n'ont empêché personne d'apprendre l'arithmétique, alors pourquoi l'IA empêcherait-elle qui que ce soit d'apprendre à coder ?

Parce qu'une calculatrice renvoie une réponse à laquelle on peut se fier. Sept fois huit font cinquante-six, que vous le compreniez ou non. Un LLM renvoie une réponse qu'il faut vérifier. C'est là toute la différence, et elle joue à l'inverse de ce qui rassure : elle veut dire que comprendre compte davantage à l'ère de l'IA, pas moins. La calculatrice vous a permis d'arrêter de comprendre l'arithmétique parce qu'elle ne se trompait jamais. Le modèle de langage ne peut pas vous permettre d'arrêter de comprendre le code, parce que vous êtes son relecteur, et un relecteur qui ne comprend pas ce qu'il lit ne relit rien du tout.

La discipline qui marche vraiment

L'objectif n'est donc pas moins d'IA. C'est de garder la main sur ce que la dépendance vous prend. En pratique, cela tient en une courte liste, dont l'essentiel fait écho aux meilleurs conseils que l'on puisse donner.

Écrivez la première version à la main. Construisez vous-même la version laide et lente, puis laissez l'IA la comparer, la critiquer ou la refactoriser. La galère n'est pas un frottement qui gêne l'apprentissage. C'est l'endroit où se forme le modèle du problème.

Utilisez-la comme le senior assis à côté de vous, pas comme vos mains. La façon la plus utile de le dire, c'est un mentor, pas un stagiaire programmeur : mettez en doute ce qu'elle vous donne, exigez les liens, puis allez lire la documentation vous-même. Au moment où elle devient vos mains au lieu de votre conseiller, vous avez cessé de posséder la compétence et commencé à louer le résultat.

Ne mergez jamais ce que vous ne savez pas expliquer. Voilà toute la règle, et elle est applicable. Si vous n'êtes pas capable d'expliquer à un collègue pourquoi le code généré fonctionne, il n'est pas encore à vous. C'est une responsabilité que vous avez endossée.

Faites une vraie relecture. J'écrivais dans un autre billet qu'à force d'approbations, on arrête de lire, et un garde-fou qu'on ne lit pas n'est pas un garde-fou. C'est vrai aussi pour une seule personne à son clavier : le diff que vous acceptez sans le comprendre, c'est exactement la ligne où commence la dépendance.

Le compromis le plus lucide que j'aie entendu quelqu'un décrire, c'est un haltère : tout écrire et déboguer à la main, sauf sous la pression d'un délai ou pour des scripts jetables, où vous vous tournez vers l'IA en sachant parfaitement que ça crée de la dette technique et que ça vous rend un peu plus bête. J'aime cette posture plus que n'importe quelle pureté. Le but n'a jamais été de faire comme si l'IA n'existait pas. C'est de savoir précisément ce que vous avez troqué, et d'être capable de le racheter.

Ce qu'est vraiment ce muscle

Ceux qui vous disent de résilier votre abonnement protègent quelque chose de réel : la force qu'on ne peut construire qu'en faisant soi-même la partie difficile. Ils ont raison de dire qu'on la construit à la main, et raison de dire qu'elle s'atrophie quand une machine porte le poids à votre place.

Mais le muscle qui empêche un développeur en exercice de devenir dépendant, ce n'est pas la capacité à produire du code sans aide. C'est le jugement qui permet de reconnaître quand l'aide se trompe. Ce jugement s'acquiert comme tous les autres : en comprenant ce que la machine a écrit, à chaque fois, sans exception, avant que ça devienne le vôtre.

Alors utilisez toute l'IA que vous voulez. Ne mettez simplement jamais en production une ligne dont vous n'auriez pas pu repérer le problème.