Apprendre à l'ère de l'IA : entre illusion de progrès et vrai levier

Pendant ma formation de développeur chez VOID, je suis souvent dans une position particulière : je dois avancer vite, comprendre du code existant, corriger des bugs, poser les bonnes questions, tout en continuant à construire mes bases.

L'IA m'aide énormément dans ce quotidien. Mais elle peut aussi me donner une impression trompeuse : celle d'avoir progressé simplement parce que le problème est résolu.

Et c'est là que le sujet devient intéressant.

Avant, apprendre en faisant voulait dire : prendre un problème, chercher dans la documentation, tester, échouer, recommencer. C'était parfois lent, parfois frustrant, mais cette friction laissait des traces. Elle construisait des réflexes.

Aujourd'hui, à la moindre difficulté, j'ai une issue de secours. Je peux décrire mon problème à ChatGPT, demander à des harness d'agents comme Codex ou Antigravity de m'expliquer une erreur, ou d'explorer une codebase legacy à ma place.

Le projet avance. Les tâches se cochent. Le code finit par fonctionner.

Mais il y a une différence entre produire du code et savoir le produire. Et cette différence, l'IA peut facilement la masquer.

Un exemple concret : chez VOID, je travaillais sur un pipeline CI/CD local avec Docker pour une application React. Une étape d'analyse de code plantait systématiquement avec une erreur assez obscure :

Dynamic loader not found: /lib64/ld-linux-x86-64.so.2

Seul, je pense que j'aurais perdu beaucoup de temps. L'erreur venait d'une couche assez basse : mon Mac utilise une puce Apple Silicon en ARM64, mais le conteneur essayait d'exécuter un outil compilé pour x86_64.

L'IA m'a orienté très vite vers la solution : forcer Docker à utiliser la bonne plateforme.

--platform linux/amd64

En une minute, le problème était débloqué.

Sur le moment, c'est très satisfaisant. Tu as l'impression d'être efficace, presque meilleur que la veille. Mais si je m'étais contenté de copier-coller ce flag sans comprendre ARM, x86, l'émulation et le rôle de Docker, je n'aurais pas vraiment appris. J'aurais juste ajouté une ligne magique à ma configuration.

J'ai aussi vécu l'inverse : un moment où l'IA s'est trompée, et où j'ai dû reprendre la main.

Je travaillais sur l'analyse d'un ancien workflow J2EE. L'objectif était de comprendre comment certains statuts étaient filtrés dans du code legacy, et quel rôle jouaient certaines procédures stockées.

Au départ, Antigravity proposait des modifications sur plusieurs fichiers Java, notamment RegDetRepository.java, AuthenticationService.java et StoredProcedureRepository.java. Mais une partie de ses changements sortait du périmètre que je voulais traiter. J'ai donc commencé par poser une limite claire : l'appel à la procédure stockée PL/SQL GEN_MATR ne faisait pas partie du périmètre à modifier. Hors scope.

Ensuite, j'ai voulu comprendre pourquoi l'IA affirmait que cette procédure insérait des données dans la table HS_INTRANET. Sa réponse était plausible, mais elle restait basée sur une déduction. Et c'est là que j'ai senti le risque : une IA peut formuler une hypothèse avec beaucoup d'assurance, même quand elle n'a pas encore de preuve directe.

Je l'ai donc coupée avec une consigne simple :

Ce moment est important. Je ne lui ai pas demandé d'aller plus vite, ni de générer une solution. Je lui ai demandé de ralentir. Je voulais qu'elle quitte le raisonnement probable pour revenir au code réel.

À ce stade, l'IA affirmait aussi que le code J2EE ne filtrait pas certains statuts. Mais en lisant Model_Espace_Managers.java, quelque chose me semblait incohérent, notamment dans la méthode updateHSIntranet(). Je l'ai donc challengée directement :

Là, l'IA a reconnu que mon intuition était bonne. Elle avait manqué un détail dans son analyse initiale, et le simple fait de lui donner le bon point d'entrée dans le code a changé sa réponse.

Ce moment m'a marqué parce qu'il inverse le rapport habituel. Je n'étais plus seulement en train de demander à l'IA de m'expliquer le système. J'étais en train de vérifier son raisonnement avec mes propres indices.

Un autre détail m'a marqué dans cette analyse : la présence de deux méthodes très proches dans le code J2EE que j'investiguais. D'un côté, updateHSIntranet(). De l'autre, updateIhsIntranet().

À première vue, la différence semble minime. Juste une variation de casse dans le nom de la méthode. Mais dans un projet legacy, ce genre de détail peut complètement changer l'analyse.

La méthode updateHSIntranet() contenait bien une partie de la logique liée aux statuts. C'est celle que j'avais repérée en lisant le code, et c'est elle qui m'a permis de corriger l'IA lorsqu'elle affirmait que le code J2EE ne filtrait pas les statuts 98 et 99.

Mais l'autre méthode, updateIhsIntranet(), semblait être du code mort : une méthode encore présente dans le code, mais qu'une analyse approfondie a montrée absente du flux réel. J'ai donc posé la question directement :

Là encore, l'IA a reconnu que mon intuition était bonne. La différence de nommage confirmait qu'il ne fallait pas tout interpréter comme une seule et même logique.

Ce passage m'a appris quelque chose de très concret : avec du code legacy et les revues ou audits de code, comprendre ne veut pas seulement dire lire ce que fait une méthode. Il faut aussi vérifier si elle est réellement appelée, dans quel flux, et si une autre méthode presque identique ne porte pas la vraie logique.

Si j'avais demandé à l'IA de « moderniser » directement le code, j'aurais peut-être migré une méthode inutile. En la challengeant, j'ai évité de traiter du code mort comme s'il faisait encore partie du système actif.

Le vrai danger, ce n'est pas que l'IA donne de mauvaises réponses. Le vrai danger, c'est qu'elle donne assez souvent de bonnes réponses pour que tu ne voies plus tes propres lacunes.

Tu livres une fonctionnalité. Tu corriges un bug. Tu gagnes du temps. D'un point de vue extérieur, tu progresses. Mais intérieurement, la question reste ouverte : est-ce que tu as compris, ou est-ce que tu as simplement accompagné une solution produite par l'outil ?

Cette illusion existait déjà avec Stack Overflow, les snippets copiés-collés ou les templates trouvés en ligne. Mais l'IA change l'échelle. La réponse arrive plus vite, elle est contextualisée, elle ressemble à une explication, et elle donne parfois l'impression qu'il n'y a plus besoin de traverser la difficulté.

Sauf que pour un développeur junior, cette difficulté fait partie de la formation.

Je ne pense pas que le problème soit l'outil. Le problème, c'est la posture. La même question, posée à Cursor ou ChatGPT de deux façons différentes, ne produit pas du tout le même apprentissage :

La différence est subtile, mais elle change tout. Dans le premier cas, je cherche une sortie rapide. Dans le second, je cherche à comprendre ce qui se passe.

C'est comme ça que j'essaie de l'utiliser aujourd'hui : moins comme un générateur de code, plus comme un partenaire d'analyse. Je veux qu'elle m'aide à formuler mes hypothèses, à les tester, à les contredire, et parfois à les abandonner.

Quand je lui demande « fais-moi ça », je gagne du temps. Quand je lui demande « voici ce que je pense, où est-ce que je me trompe ? », je progresse.

Le point le plus difficile, c'est que je ne sais pas toujours ce que je ne sais pas.

Pour utiliser l'IA comme outil d'apprentissage, il faut savoir quelles questions poser. Et pour poser les bonnes questions, il faut avoir une idée de ce qu'on ne maîtrise pas. Or c'est précisément ce qui manque quand on est junior : la carte mentale du domaine est incomplète, on ne sait pas où sont les trous, et seule la friction nous les montre.

Un développeur senior voit plus vite quand une suggestion de l'IA est fragile. Il repère les problèmes de sécurité, les cas limites, les abstractions inutiles, les mauvaises hypothèses. Il peut auditer, corriger, contester l'outil. Moi, je construis encore ce radar.

Sans ce radar, on peut livrer dix features en s'appuyant largement sur l'IA, accumuler de la confiance, et ne jamais réaliser qu'on a des angles morts entiers : des edge cases qu'on n'a jamais rencontrés, des patterns qu'on n'a jamais eu à questionner, des erreurs qu'on n'a jamais eu à diagnostiquer seul.

L'IA ne comblera pas ces trous d'elle-même. Elle répond à ce qu'on lui demande. Si tu ne sais pas qu'une zone d'ombre existe, tu ne poseras jamais la question qui t'en sortirait. C'est précisément pour ça que je dois garder une part de friction volontaire dans mon apprentissage.

Je ne vais pas arrêter d'utiliser l'IA, ce serait absurde. Dans mon quotidien, elle me fait gagner du temps, elle m'aide à débloquer des situations complexes, et elle m'oblige souvent à formuler mes problèmes plus clairement.

À ce titre, elle joue parfois le rôle d'un canard en plastique augmenté. Les développeurs connaissent le rubber duck debugging : expliquer son code à voix haute à un canard en plastique posé sur le bureau, parce que le simple fait de verbaliser son raisonnement suffit souvent à faire apparaître l'erreur. Formuler un prompt clair et descriptif produit exactement cet effet : j'explique mon problème étape par étape, je verbalise mes hypothèses, et cette clarification révèle déjà des erreurs ou des angles morts. La différence, c'est que ce canard-là répond : il peut me relancer, me demander de préciser une hypothèse, ou pointer une incohérence.

Mais j'ai décidé de ne plus l'utiliser uniquement comme un outil qui produit des réponses. Je veux l'utiliser comme un interlocuteur qui m'aide à construire mon raisonnement. Concrètement, j'essaie d'adopter une méthode plus socratique :

C'est cette posture que je veux garder : utiliser l'IA comme un partenaire d'investigation et d'orientation, pas comme une sortie de secours permanente.