Avec l’IA, il sera plus difficile de devenir développeur
Je pense qu’on raconte un peu n’importe quoi quand on dit que l’IA va rendre le métier de développeur plus facile. Le code, oui… mais pas le développement.
Introduction
Pour moi, c’est même l’inverse :
avec l’IA, il va devenir plus difficile de devenir un vrai développeur.
Le code devient facile. Le jugement, non.
Aujourd’hui, Claude peut te générer une API.
Une base de données.
Une interface.
Des tests.
Une architecture complète.
Parfois même sans que tu écrives une seule ligne.
Donc oui, l’exécution devient plus rapide.
Mais le plus difficile dans notre métier n’a jamais été juste d’exécuter.
Le plus difficile, c’est de savoir :
quoi construire, pourquoi, dans quel ordre, avec quelle architecture, avec quels compromis et avec quels risques.
Et ça, l’IA ne le décide pas correctement à ta place si toi-même tu n’as pas compris le problème.
Tu peux obtenir une très bonne réponse à une mauvaise question
C’est là que ça devient dangereux.
Tu demandes quelque chose à Claude.
Il te répond avec du beau code.
Des services propres.
Des patterns.
Des composants.
Une architecture qui a l’air sérieuse.
Et tu te dis :
“C’est lourd.”
Mais est-ce que c’était la bonne solution ?
C’est une autre question.
Et si tu n’es pas déjà capable de juger la réponse, tu risques juste d’accepter une solution impressionnante… mais mal adaptée.
L’IA accélère aussi les mauvaises décisions.
J’ai eu un exemple très concret
J’ai développé mon blog quasiment en full IA.
Quand les développeurs que je dirige à MaMoni Finance l’ont vu, ils ont été impressionnés par la qualité du résultat.
L’un d’eux, un junior qui code très bien avec des outils d’IA, m’a demandé le code source.
Je lui ai donné un abonnement Claude et le lien du blog.
En gros :
“Voilà l’exemple. Voilà l’outil. Refais quelque chose de ce niveau.”
Et le résultat n’a pas suivi.
Pas parce qu’il ne savait pas coder.
Claude savait coder pour lui.
Le problème était ailleurs.
Voir une interface, ce n’est pas juste voir une interface
Avec l’expérience, quand je regarde une application, je ne vois pas seulement des cartes et des boutons.
Je vois déjà les modules derrière.
Je vois les rôles.
Les permissions.
Les statuts.
Les règles métier.
Les dépendances.
Les exceptions.
Les traitements asynchrones.
Les données.
Les contraintes.
Les scénarios de panne.
Et surtout, je peux assez vite estimer l’étendue réelle d’un module rien qu’en observant son interface.
Ça, ce n’est pas Claude qui me l’a appris.
C’est l’expérience.
Nous, on devait souvent comprendre avant de coder
Avant, on n’avait pas trop le choix.
Pour développer quelque chose de sérieux, il fallait beaucoup réfléchir avant de commencer.
Parfois passer des heures sur le problème.
Aujourd’hui, tu peux avoir une idée et trente secondes plus tard Claude commence déjà à générer ton projet.
C’est puissant.
Mais il y a un piège.
Tu peux maintenant commencer à construire avant même d’avoir réellement compris.
Et je pense que c’est exactement ce qui va compliquer l’apprentissage des développeurs de demain.
Quand le code arrive trop tôt, l’analyse arrive trop tard
Tu as une idée.
Tu ouvres Claude.
Tu écris :
“Crée-moi une plateforme pour…”
Et c’est parti.
Tu vois déjà des fichiers apparaître.
Des migrations.
Des modèles.
Des pages.
Des APIs.
Forcément, ton cerveau commence à suivre ce qui est en train d’être construit.
Alors qu’avant tout ça, il aurait peut-être fallu rester deux heures de plus sur le problème.
Comprendre le métier.
Comprendre les flux.
Comprendre les utilisateurs.
Comprendre les erreurs possibles.
Comprendre ce qu’il ne faut surtout pas construire.
Être développeur, ce n’est pas savoir demander du code
Pour moi, utiliser Claude n’est pas une compétence suffisante.
La vraie compétence, c’est aussi de pouvoir dire à Claude :
non, cette approche est mauvaise ici.
non, cette architecture est trop lourde.
non, ce traitement doit être idempotent.
non, cette donnée ne doit pas être supprimée.
non, ça doit passer en queue.
non, ce module va devenir impossible à maintenir.
L’IA peut proposer.
Mais quelqu’un doit juger.
Et plus l’IA devient bonne, plus ton jugement devient important.
Le développeur de demain risque de savoir produire avant de savoir concevoir
C’est là que le problème devient vraiment intéressant.
Aujourd’hui, quelqu’un peut produire très vite.
Une belle application.
Un beau dashboard.
Une API fonctionnelle.
Un MVP qui impressionne.
Mais est-ce qu’il comprend réellement ce qu’il vient de construire ?
Pas toujours.
Et le jour où le produit commence à prendre du volume, à gérer de vraies données ou à devenir critique, la différence apparaît très vite.
Parce qu’à un moment, il ne suffit plus de dire :
“Claude, corrige.”
Il faut comprendre.
Un architecte ne délègue pas le problème à Claude
Pour moi, un architecte logiciel, ce n’est pas quelqu’un qui connaît tous les patterns.
C’est quelqu’un qui sait penser une solution parce qu’il comprend profondément le problème.
Tu ne peux pas expliquer vaguement un métier à Claude et lui demander ensuite :
“Donne-moi la meilleure architecture.”
Si toi-même tu n’as pas compris le besoin, comment vas-tu savoir si sa réponse est bonne ?
C’est là que beaucoup de choses se jouent.
Tu ne peux pas déléguer à l’IA une compréhension que tu n’as jamais acquise.
J’aime être surpris par Claude. Mais pas par mon propre produit.
Claude me surprend souvent.
Une meilleure implémentation.
Une optimisation.
Une idée plus propre.
Un raccourci intéressant.
Ça, j’adore.
Mais je ne veux pas découvrir mon produit dans sa réponse.
Si Claude te génère une fonctionnalité et que tu te dis :
“Ah oui, je n’avais même pas pensé à ça…”
ça peut être génial.
Mais si ça arrive tout le temps, il faut peut-être se poser une question :
est-ce que j’avais vraiment compris mon projet avant de lui demander de le construire ?
L’IA va fabriquer beaucoup de codeurs
Ça, j’en suis presque sûr.
Des gens capables de sortir des applications.
Des APIs.
Des landing pages.
Des automatisations.
Des outils internes.
Et c’est très bien.
Mais je ne suis pas certain qu’elle va fabriquer autant de développeurs.
Parce qu’un développeur ne se résume pas à sa capacité à produire du code.
Il sait transformer un problème flou en solution cohérente.
Il sait faire des choix.
Il sait évaluer les risques.
Il sait simplifier.
Il sait anticiper.
Il sait dire non à une mauvaise solution.
Le vrai skill de demain ne sera peut-être plus de coder
Ce sera peut-être simplement de comprendre mieux que les autres.
Comprendre le métier.
Comprendre l’utilisateur.
Comprendre les contraintes.
Comprendre les risques.
Comprendre l’architecture.
Comprendre pourquoi une approche est meilleure qu’une autre.
Puis utiliser l’IA pour aller dix fois plus vite.
Pour moi, c’est ça le vrai développeur augmenté par l’IA.
Pas celui qui laisse Claude penser à sa place.
Mais celui qui sait exactement où il veut aller et qui utilise Claude pour y arriver plus vite.
L’IA peut écrire ton code. Elle ne peut pas porter à ta place la responsabilité d’avoir choisi la bonne solution.
Cette analyse vous a été utile ?
Partagez-la avec une personne qui pourrait en bénéficier.
La discussion continue
Votre contribution apparaît immédiatement.
Soyez le premier à partager votre point de vue.
