Le vrai risque de l'IA n'est pas qu'elle code

J’ai récemment eu une drôle d’impression : passer une journée entière à faire avancer un agent, sans vraiment coder.

Pas de bug tordu à comprendre. Pas d’architecture à assembler. Pas de pièce manquante à trouver. Juste une suite de prompts, de validations, puis un petit next pour lancer l’étape suivante.

Et c’est là que la question m’est revenue : si développer, c’est en grande partie résoudre des puzzles, que se passe-t- il quand cette partie disparaît ?

🧩 Ce que j’aime dans le développement

Je développe depuis longtemps, sur le web, des applications, des scripts, des jeux, et quelques idées qui auraient probablement dû rester dans un dossier nommé side-project-final-v2-bis.

Ce qui m’a toujours attiré n’est pas seulement le code. C’est le fait de partir de rien, puis d’assembler quelque chose d’utile.

Le métier ressemble souvent à ça :

Situation	Le vrai travail
Une fonctionnalité arrive	Comprendre le besoin réel
Deux systèmes doivent parler ensemble	Choisir les bons points de contact
Le code grossit	Garder une structure lisible
Une contrainte change	Adapter sans tout casser

Bref, développer, c’est souvent faire du puzzle solving. On relie des pièces. On teste des hypothèses. On arbitre. On apprend.

🤖 Là où l’IA est vraiment utile

Je ne suis pas anti-IA. Bien au contraire.

L’IA est excellente sur beaucoup de tâches que je n’ai pas particulièrement envie de refaire à la main :

générer du boilerplate.
retrouver une route d’API.
écrire un CRUD classique.
proposer une première version d’un test.
résumer une documentation un peu trop longue.

Sur ces sujets, elle fait gagner du temps. Et c’est très bien.

J’aime aussi l’utiliser comme partenaire de réflexion : poser une idée, challenger une approche, comparer plusieurs options. Dans ce cadre, l’IA reste un outil. C’est encore moi qui tiens le volant.

🛠️ Le problème commence quand on ne résout plus rien

Le sujet change quand l’IA n’aide plus seulement à produire, mais qu’elle prend aussi en charge l’exploration du problème, la découpe, l’implémentation, puis la revue.

Admettons un workflow de ce type :

un besoin est transformé en cas d’usage puis en spécification.
la spécification est découpée en tâches.
chaque tâche est transformée en code.

Avant le développement “agentique”, tout cela était fait par l’humain et validé à chaque étape par un (autre) humain.

Admettons maintenant que l’IA remplace l’humain dans ce workflow et qu’elle génère les cas d’usages, spécifications, tâches et code. Un LLM sera bien plus rapide que n’importe qui pour écrire tout cela, et c’est ce que nous voulons. Mais dans cette situation, c’est aussi l’IA qui fait le travail de réflexion. Il manque parfois quelque chose d’essentiel : le moment où l’on cherche vraiment à comprendre.

Un humain validera probablement l’ensemble de ce que l’IA a généré. Mais s’il n’a pas réfléchi au problème au préalable, il risque de ne pas pouvoir savoir si la proposition est la meilleure, voire si un problème ne surviendra pas.

On ne construit plus la solution. On supervise sa génération.

👀 Du développeur au valideur

Quand ce mode devient la norme, le risque n’est pas que l’IA produise du code. Le risque, c’est que nous nous éloignons du code nous-mêmes.

Le quotidien peut vite ressembler à ceci :

Avant	Après
Lire le besoin	Lire le prompt généré
Concevoir une approche	Valider un plan proposé
Écrire et ajuster	Regarder défiler les étapes
Relire en profondeur	Vérifier que “ça a l’air bon”

Au début, on corrige beaucoup. On affine les prompts. On recadre. Puis, petit à petit, on peut glisser vers une forme de confiance passive.

Et c’est là que ça coince.

Une application ne casse pas toujours de façon spectaculaire. Parfois, c’est plus subtil : une règle métier oubliée, une hypothèse implicite, un détail d’UX qui disparaît au passage. Rien de très cinématographique. Juste assez pour créer de la dette, de la friction, et quelques réunions de plus. C’est ce que certains appellent “l’enshitification”.

🧠 Pourquoi apprendre reste indispensable

On entend parfois que, puisque l’IA connaît très bien les frameworks et sait mieux écrire du code que nous (oui c’est vrai), il devient moins utile de creuser les sujets en profondeur.

Je pense exactement l’inverse.

Apprendre reste indispensable pour au moins trois raisons :

comprendre si la solution générée est bonne.
repérer ce que le contexte ne dit pas explicitement.
préparer les changements futurs sans fragiliser l’ensemble.

Une IA peut proposer une implémentation solide. Mais elle ne porte pas, à elle seule, toute la mémoire implicite du produit, des discussions, des compromis et des évolutions à venir.

Le développeur, lui, peut relier ces éléments. C’est même là qu’il apporte le plus de valeur.

🧭 Ce que je veux préserver

Je veux continuer à utiliser l’IA. Mais je veux l’utiliser sur les bonnes couches.

Par exemple :

oui pour accélérer les tâches répétitives.
oui pour explorer une API ou une syntaxe.
oui pour générer une base de code.
non pour arrêter de lire ce qu’on livre.
non pour renoncer à comprendre pourquoi une solution tient debout.

🚀 Conclusion

Je ne pense pas que le vrai sujet soit de savoir si l’IA va écrire du code. Elle le fait déjà, et elle le fera de mieux en mieux.

Le vrai sujet, c’est ce que nous choisissons de lui déléguer.

Si elle nous aide à aller plus vite sur le répétitif, parfait. Si elle nous évite de penser, de relire, d’apprendre et de relier les pièces entre elles, alors on risque de perdre ce qui fait la richesse du métier.

À mes yeux, la valeur d’un développeur ne se limite pas à produire des lignes de code. Elle se situe dans la compréhension du besoin, les arbitrages, la vision d’ensemble, et la capacité à faire évoluer un système dans la durée.

Le code sera sans doute de plus en plus généré. La réflexion, elle, reste irremplaçable.