Mais si, vous savez, le petit robot éboueur qui range les déchets de la Terre pendant que les humains se vautrent dans leurs fauteuils volants.
Adorable, infatigable, efficace.
Mon IA, c’est Wall-E : elle génère mes tests, écrit mes CRUD, nettoie mon boilerplate… et moi, je la regarde travailler, attendri. Le danger ? Comme les passagers du vaisseau Axiom, je risque de perdre mes muscles de dev à force de tout déléguer.
Les IA génératives excellent dans le “petit ménage” du code : elles bouclent les tâches répétitives plus vite que je ne peux les contrôler. Générer un squelette d’API REST, pondre un jeu de tests unitaires, reformater un projet entier… rien ne lui résiste.
Mais cette efficacité cache une mécanique vicieuse : plus l’outil est efficace, plus on se repose dessus. Pourquoi apprendre à écrire un test paramétré quand Copilot l’écrit pour vous ? Pourquoi mémoriser la syntaxe d’un framework si l’assistant vous la sert sur un plateau ? L’IA encourage une délégation systématique.
À court terme, c’est confortable et les chefs de projet se mettent à rêver de jours/hommes divisés par 10. À long terme, c’est de l’atrophie cognitive : on oublie ses réflexes de base (si tant est qu’ils soient acquis). Le jour où l’IA génère fatalement une absurdité (ou son éditeur triple ses tarifs), on se retrouve aussi démuni que les humains incapables de se lever de leur fauteuil.
Pour un junior, l’effet est redoutable : il “produit” du code sans vraiment le comprendre. L’apprentissage superficiel, pire encore que le copier-coller des labs en ligne. La dépendance au prompteur devient vitale, et la construction de fondations solides n’aura pas lieu (et oui, un développeur junior doit faire ses classes).
Pour un senior, la situation n’est guère plus enviable : transformé en relecteur fatigué, il corrige à la chaîne des propositions d’IA au lieu de coder. La frustration monte, la motivation baisse.
Pour l’organisation, c’est pire : si tout le monde s’en remet à Wall-E, plus personne n’entretient la compréhension intime de la codebase. La dette cognitive s’accumule (c’était déjà le cas avant que nous soyons en mesure de produire 8 features par jour), jusqu’au moment où l’IA pond une énormité… et plus personne n’a les compétences pour la détecter rapidement.
La clé est simple : transformer Wall-E en réel assistant, pas en substitut musculaire.
D’abord, il est possible d’utiliser l’IA comme outil pédagogique : demander des explications, des analogies, des alternatives. Se donner les moyens de comprendre transforme l’IA en un cours en ligne interactif, bien plus riche et contextualisé que des exemples générés en dur. En mode chat, l’IA est très utile pour explorer un nouveau sujet ou une nouvelle technologie.
Ensuite, nous recommandons d’instaurer des plages de temps sans IA. Comme en sport, on garde des “séances à vide” pour travailler le fond : écrire soi-même des tests, coder un micro-service from scratch, résoudre un kata sans copilote. Ça pique un peu, mais ça entretient la forme.
Troisième pratique, l’équipe peut s’imposer le rituel de l’auto-explication. Chaque fois que l’IA propose une solution, le développeur se doit d’en rédiger les commentaires : “voilà ce que ce code fait, voilà pourquoi il marche, voilà ce qu’il faudrait surveiller.” Le développeur redevient actif.
Enfin, au niveau d’un projet, il est nécessaire de documenter les usages de l’IA et d’instaurer des règles collectives. Comme pour tout outil puissant, c’est la culture qui fait la différence : dans une organisation consciente, Wall-E reste un allié adorable. Dans une équipe dépendante, il devient le fossoyeur des compétences.
Mon IA, c’est Wall-E : fidèle, efficace, mais dangereusement confortable. Mais si je la laisse tout faire, je deviens un passager de l’Axiom : gros, mou, et incapable de marcher seul.
“Sur l’Axiom, vous produirez des features.”
“Je ne veux pas seulement produire des features. Je veux coder.”
Source : https://searial-cleaners.com/wp-content/uploads/2023/01/WallE-2.png
