Je n'écris pas ces lignes comme développeur en activité.

J'ai longtemps travaillé dans l'univers du code, puis je suis passé de l'autre côté de la barrière, côté Product Management. Je travaille toujours avec des développeurs, je vois leurs contraintes, leurs outils, leurs arbitrages, leurs fatigues aussi. Et même si le développement n'est plus mon métier principal, je ne peux pas m'empêcher de m'interroger sur la façon dont les métiers du logiciel vont évoluer avec l'IA.

Ce texte n'est donc pas une vérité définitive. C'est le point de vue d'un observateur curieux, un peu inquiet, qui a assez connu le code pour sentir certains signaux faibles, et qui regarde maintenant la production logicielle depuis le produit. Après tout, un Product Manager qui cesse d'être curieux de la façon dont les produits sont fabriqués cesse probablement de faire correctement son métier.

Depuis quelque temps, je joue avec les assistants de développement. J'ai généré des scripts, fait avancer des petits projets, puis travaillé plus sérieusement sur une application. Et le constat est à la fois impressionnant et troublant : l'IA peut produire énormément, très vite. En quelques jours, on peut obtenir quelque chose qui ressemble à une vraie application.

Mais pendant tout ce temps, j'ai aussi passé une énergie considérable à la corriger.

Pas seulement sur des détails. Sur des fondamentaux. Des fichiers qui grossissent trop. Des tests absents. Du métier placé dans les API. Des choix d'architecture trop compliqués pour le besoin. Des solutions qui fonctionnent maintenant, mais qui pourraient devenir fragiles demain. Le plus étrange, c'est que lorsque je lui demande explicitement de faire autrement, elle sait le faire. Elle sait écrire des tests. Elle sait séparer le domaine de la tuyauterie. Elle sait proposer une solution plus simple. Elle sait reconnaître qu'une meilleure option existe.

Elle le sait. Mais elle ne le fait pas toujours spontanément.

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

L'IA n'invente pas les mauvais travers du logiciel

Il faut commencer par être juste : l'IA n'a pas inventé la dette technique. Elle n'a pas inventé la sur-ingénierie. Elle n'a pas inventé les architectures contradictoires, les tests oubliés, les décisions implicites, les produits mal cadrés ou les refontes qu'on repousse trop longtemps.

Tout cela existait déjà.

Certains développeurs savaient déjà construire une cathédrale pour poser une étagère. Certaines équipes savaient déjà aller lentement dans le mur. Certaines entreprises savaient déjà confondre vitesse de delivery et valeur réelle. Le problème du logiciel n'a jamais été seulement d'écrire du code. Il a toujours été de produire quelque chose qui tient, qui se comprend, qui se maintient, qui évolue, qui sert un usage réel.

L'IA ne crée donc pas un problème entièrement nouveau. Elle change son échelle.

Elle accélère ce qui allait déjà trop vite. Elle rend moins visible ce qui était déjà mal compris. Elle permet d'empiler plus rapidement des décisions que personne n'a vraiment prises. Elle donne une forme de maturité apparente à des systèmes qui n'ont pas encore traversé les étapes normales de maturation.

Le danger n'est pas que l'IA écrive du code. Le danger est qu'elle permette de produire des systèmes maintenus comme des prototypes, par des personnes qui n'ont pas toujours acquis l'expérience nécessaire pour savoir où ces systèmes vont casser.

L'illusion de maturité

Le vibe coding donne une sensation grisante : on demande, le code apparaît, l'application avance. Là où il fallait plusieurs jours, parfois plusieurs semaines, il suffit de quelques heures. L'effet psychologique est très fort. On voit des écrans. On clique. Ça répond. Une base de données existe. Une API tourne. Des fonctionnalités apparaissent.

Le produit semble mûrir.

Mais ce qui mûrit vraiment, parfois, c'est surtout la surface.

Une application peut fonctionner sans être vraiment comprise. Elle peut passer quelques scénarios heureux sans être robuste. Elle peut répondre à une démo sans être prête pour la production. Elle peut contenir des centaines de choix techniques que personne ne sait expliquer, parce qu'ils ont été générés, acceptés, patchés, puis oubliés.

Avant l'IA, une partie de cette fragilité existait déjà. Mais elle avait souvent une limite naturelle : la lenteur. Produire du code coûtait du temps. Cette lenteur imposait parfois des conversations, des arbitrages, des revues, des moments où l'on devait comprendre ce qu'on faisait avant d'aller plus loin.

Avec l'IA, cette limite saute.

On peut aller beaucoup plus vite que sa propre compréhension. C'est utile pour explorer. C'est dangereux quand on commence à confondre exploration et production.

Quand l'erreur arrive trop tard, elle ne forme plus

Une grande partie de l'expérience technique se construit dans l'erreur.

Pas n'importe quelle erreur, bien sûr. On peut souffrir longtemps sans rien apprendre. La douleur seule ne forme pas. Mais dans le développement, l'apprentissage profond vient souvent d'une boucle très concrète : on essaie, on se trompe, on cherche, on comprend, on corrige, puis on garde quelque chose de cette correction.

Parfois, on bloque une demi-heure. Parfois une journée. Parfois on ne trouve pas le jour même, on y revient le lendemain, et c'est justement ce détour qui crée de l'expérience. On apprend à reconnaître les signaux faibles dans le code. On apprend qu'une solution trop facile cache souvent un coût. On apprend qu'un bug n'est pas seulement un obstacle, mais un morceau du système qui résiste et demande à être compris.

L'IA peut casser cette boucle.

Quand un problème apparaît, on peut lui dire : débrouille-toi, trouve-moi une solution. Elle va trouver quelque chose. Peut-être une bonne solution. Peut-être une solution horrible mais fonctionnelle. Dans les deux cas, si l'on ne prend pas le temps de comprendre, on avance sans apprendre.

Le risque n'est pas seulement que l'erreur soit retardée. C'est qu'elle arrive à une échelle où elle n'est plus analysable. Le système a grossi. Les couches se sont empilées. Les décisions sont implicites. Les tests, quand ils existent, valident peut-être une mauvaise compréhension du besoin. Et lorsque tout s'écroule, on ne sait plus vraiment pourquoi.

Alors on patche.

On ne comprend pas mieux. On met juste une rustine de plus sur une architecture qu'on n'a jamais vraiment habitée.

Le cœur du problème : la disparition de la première marche

C'est probablement le point qui m'inquiète le plus.

Le sujet n'est pas seulement de savoir si l'IA va remplacer des développeurs juniors. Cette question est importante, mais elle en cache une autre, plus profonde : que se passe-t-il si l'IA remplace les tâches qui fabriquaient les juniors ?

Dans beaucoup d'équipes, l'apprentissage se faisait par gradation. Il y avait un lead, des développeurs expérimentés, des profils intermédiaires, puis des juniors. On ne confiait pas immédiatement à un junior l'architecture complète d'un produit critique. On lui donnait des petites tâches. Un bug limité. Un endpoint simple. Un script. Une correction. Un test. Un refactor modeste.

Ces tâches n'étaient pas seulement du travail à faire. Elles étaient les premières marches de l'échelle.

Elles permettaient de se casser les dents sans mettre tout le système en danger. Elles permettaient d'apprendre à lire un code existant, à comprendre un ticket, à demander de l'aide, à recevoir une revue, à découvrir qu'un changement local peut avoir des effets ailleurs. Elles permettaient d'entrer progressivement dans le métier.

Or ce sont précisément ces tâches que l'IA automatise le mieux.

Le boilerplate, les petits scripts, les corrections simples, les tests standards, les intégrations évidentes : tout cela peut être généré très vite. Du point de vue de la productivité immédiate, c'est une excellente nouvelle. Du point de vue de la formation, c'est beaucoup plus ambigu.

Si les premières marches disparaissent, comment devient-on senior ?

On peut répondre que les juniors apprendront autrement, avec l'IA comme tuteur socratique. C'est possible. Un bon usage de l'IA peut aider à expliquer, comparer, faire verbaliser, générer des exercices, simuler une revue de code. Mais cette possibilité demande une discipline, une curiosité et un cadre. Elle demande aussi que l'entreprise accepte de payer du temps d'apprentissage.

Et c'est là que la question économique devient brutale.

Si un senior augmenté par IA produit dix fois plus, combien d'entreprises accepteront encore qu'un junior aille dix fois moins vite parce qu'il doit apprendre ? Combien accepteront que quelqu'un passe une journée sur un problème que l'IA peut contourner en quelques minutes ? Combien préserveront la lenteur nécessaire à la formation, alors que le marché pousse à livrer toujours plus vite ?

Le risque est de casser le cycle de reproduction du métier.

Les entreprises de logiciel n'ont pas seulement besoin de code. Elles ont besoin de personnes capables de diagnostiquer, simplifier, maintenir, sécuriser, arbitrer et inventer. Or ces personnes ne naissent pas du simple pilotage d'un assistant. Elles se construisent par des années de pratique, d'erreurs, de revues, de décisions difficiles et de retours du réel.

Si l'IA augmente les seniors existants mais fragilise la formation des juniors, elle ne menace pas seulement quelques postes d'entrée. Elle menace la capacité future des entreprises logicielles à produire du logiciel de qualité.

Qui inventera les prochaines bonnes pratiques ?

On parle souvent des bonnes pratiques comme si elles formaient un stock stable. Il suffirait de les documenter, de les mettre dans des fichiers de directives pour l'IA, puis de demander aux assistants de les appliquer.

Mais les bonnes pratiques ne sont pas figées.

Elles naissent lorsque le terrain change. Les design patterns classiques ont répondu à un certain monde logiciel. Puis le cloud, les systèmes distribués, l'asynchrone, les microservices, les architectures événementielles ont fait émerger d'autres problèmes. Il a fallu inventer de nouvelles manières de penser : idempotence, retries, circuit breakers, sagas, observabilité, résilience distribuée.

Ces pratiques ne sont pas apparues parce que quelqu'un les a simplement demandées à un outil. Elles sont nées de systèmes réels, de pannes, d'incidents, de migrations difficiles, de contraintes d'exploitation, de compromis douloureux.

L'IA pourra probablement aider à formuler les prochains patterns. Elle pourra comparer des solutions, repérer des récurrences, documenter des pratiques émergentes. Mais pourra-t-elle les inventer seule, avant que le terrain ne les ait rendus nécessaires et compréhensibles ?

Je n'en suis pas sûr.

Pour inventer une bonne pratique, il ne suffit pas de connaître les anciennes. Il faut sentir pourquoi elles ne suffisent plus. Il faut avoir été exposé à la résistance du réel. Il faut savoir quand un pattern est une réponse élégante et quand il n'est qu'une complexité inutile.

La simplicité elle-même est une compétence senior.

Une IA peut proposer une solution trop complexe, puis reconnaître immédiatement qu'une solution plus simple est meilleure si on lui fait remarquer. Mais encore faut-il quelqu'un pour le voir. Encore faut-il quelqu'un pour dire : ce problème ne mérite pas cette architecture. Encore faut-il quelqu'un pour préférer une solution moins brillante, mais plus juste.

Produire plus, pour quoi faire ?

La vitesse de génération n'est pas la vitesse de livraison.

Une équipe peut se retrouver avec des dizaines de pull requests créées dans la nuit par l'IA. Mais qui les relit ? Qui vérifie les impacts ? Qui comprend les choix ? Qui teste les scénarios tordus ? Qui arbitre ce qui doit vraiment partir en production ? Qui s'assure que l'utilisateur peut absorber cette complexité ?

Produire plus de code n'est pas forcément produire plus de valeur.

Il y a une tentation concurrentielle évidente. Si un concurrent sort une feature en trois jours, comment accepter qu'une équipe prenne trois mois ? Si une maquette générée peut devenir rapidement du code de production, qui aura le courage de dire : arrêtons-nous, ce n'est pas encore assez propre ?

Mais le logiciel n'est pas seulement une course à la quantité. Un produit devient vite illisible, pour ses utilisateurs comme pour ses équipes, si l'on ajoute des fonctionnalités plus vite que l'on ne comprend leur usage. La complexité ne se mesure pas seulement dans le code. Elle se mesure aussi dans l'adoption, le support, la documentation, la cohérence de l'expérience, la capacité de l'organisation à expliquer ce qu'elle fabrique.

L'IA déplace donc les goulots d'étranglement.

Le code devient plus rapide. Mais la revue, la sécurité, le cadrage fonctionnel, l'intégration, la compréhension et l'absorption humaine restent limités. Peut-être même deviennent-ils plus critiques.

La reconstructibilité comme critère de qualité

Dans mon propre usage récent, ce qui m'a rassuré n'est pas seulement d'avoir produit une application. C'est d'avoir imposé des points d'ancrage.

J'ai insisté sur les contrats entre API. J'ai poussé l'IA à produire les jeux de tests, puis la pyramide de tests, avant de développer. J'ai essayé de garder une séparation claire entre le domaine métier et la tuyauterie technique. Je ne suis pas allé jusqu'à une démarche DDD complète, parce que le projet ne le justifiait pas, mais j'ai refusé que le métier soit simplement dispersé dans les endpoints.

Pourquoi ?

Parce qu'un système vraiment compris est un système qu'on saurait reconstruire.

Si demain je dois extraire cette application vers une autre technologie, je sais où sont les contrats, où sont les règles métier, où sont les tests qui décrivent le comportement attendu. Tout n'est pas parfait, mais le système n'est pas seulement un amas de code généré. Il contient des prises. Des repères. Des lignes de séparation.

C'est peut-être un critère central pour le développement assisté par IA : ne pas seulement demander « est-ce que ça marche ? », mais « est-ce que je saurais le reconstruire ? »

Si la réponse est non, alors il manque quelque chose.

Réintroduire volontairement de la difficulté

Il ne faut pas seulement apprendre à développer avec l'IA. Il faut aussi, parfois, apprendre sans elle.

Pas par nostalgie. Pas pour défendre une vision héroïque du développeur qui souffre pour mériter son métier. Mais parce qu'une compétence qui ne rencontre jamais la difficulté devient fragile.

On accepte très bien cette idée ailleurs. En mathématiques, la calculatrice est utile, mais apprendre sans jamais poser une opération soi-même produit une dépendance. Dans le sport, on ajoute volontairement des contraintes, du poids, de la résistance, parce que c'est cette résistance qui développe les muscles.

Le développement aura besoin de la même logique.

Des dojos sans IA. Des exercices avec IA bridée. Des revues où l'on doit expliquer le code sans demander à l'assistant de le faire à sa place. Des moments où l'on prend volontairement le temps de lire, de comprendre, de simplifier.

L'objectif n'est pas de ralentir partout. L'objectif est de ralentir au bon endroit.

Peut-être que les équipes de demain devront assumer un rythme hybride : produire très vite une partie du temps, mais sanctuariser du temps long pour comprendre ce qui a été produit. Une journée d'amélioration continue. Des moments seuls face au code. Des revues d'architecture. Des ADR. Des refactors lents. Des post-mortems de génération ratée.

Avant l'IA, ce temps long manquait déjà trop souvent. Beaucoup de développeurs restaient le nez dans le guidon, à produire sans prendre assez de recul pour monter en compétence. L'IA peut aggraver ce problème si elle sert seulement à remplir tout l'espace gagné par encore plus de production. Mais elle peut aussi devenir une chance si elle nous oblige à mieux distinguer le temps du faire et le temps du comprendre.

Quelques règles simples pour garder la maîtrise

Si les équipes veulent utiliser l'IA sans perdre leur profondeur, il faudra sans doute inventer une discipline explicite. Pas une bureaucratie. Une hygiène de compréhension.

Quelques règles me semblent déjà utiles.

D'abord, ne pas merger de code que personne ne peut expliquer. C'est simple, presque brutal, mais essentiel. Si une équipe accepte du code incompris, elle accepte une dette de compréhension.

Ensuite, prévoir un petit budget de compréhension par feature : le contrat, les tests, la décision d'architecture, les limites connues. Pas une documentation interminable. Juste assez pour que le raisonnement reste humainement transmissible.

Il faut aussi relier les tests au fonctionnel. Un test généré peut être très propre et valider une mauvaise compréhension du besoin. La boucle devrait être : fonctionnel, tests, code, retour au fonctionnel. Plus les tests expriment réellement l'usage attendu, plus le code a de chances de rester proche de la valeur.

Il faut maintenir une cartographie des patterns autorisés par l'équipe. Comment fait-on une API ? Comment gère-t-on les erreurs ? Comment écrit-on un job asynchrone ? Comment teste-t-on un appel externe ? Sans cela, chaque feature générée risque d'inventer sa propre manière de faire, et l'équipe maintiendra plusieurs architectures sans raison.

Il faut enfin analyser les échecs de l'IA. Quand elle produit une solution trop complexe, quand elle oublie les tests, quand elle met du métier au mauvais endroit, on ne devrait pas seulement corriger. On devrait comprendre le signal manqué, ajuster les directives, enrichir les pratiques.

L'IA peut écrire du code. Mais l'équipe doit rester propriétaire du raisonnement.

Comprendre dix fois mieux

Je ne crois pas que le développement logiciel va sombrer à cause de l'IA.

Je crois en revanche que certaines équipes vont se noyer dans du code qu'elles ne comprennent pas assez. Elles auront produit vite. Elles auront livré des choses visibles. Elles auront peut-être même impressionné leur marché pendant un temps. Puis elles découvriront que la vitesse ne remplace pas l'architecture, que les tests ne valent que s'ils expriment le bon besoin, que la sécurité vit dans les cas tordus, que le legacy demande une compréhension historique, et que les seniors ne se fabriquent pas en supprimant les tâches qui formaient les juniors.

Le vrai enjeu n'est donc pas de refuser l'IA. Ce serait absurde. Elle est trop utile, trop puissante, trop présente déjà.

Le vrai enjeu est de ne pas lui abandonner les mécanismes qui produisent la compétence.

Si l'IA nous permet de produire dix fois plus vite, alors elle devrait aussi nous obliger à réserver du temps pour comprendre dix fois mieux ce que nous produisons. Sinon, nous n'aurons pas seulement accéléré le développement logiciel. Nous aurons accéléré l'oubli de ce qui permet de bien développer.

Pour en savoir plus

Code centric La qualité appartient à ceux qui livrent Zéro bug : arrêtons de gérer des stocks de défauts