Sommaire
TL;DR — Le développement moderne ne consiste plus seulement à écrire du code depuis zéro. Il consiste à assembler des briques, vérifier qu’elles tiennent ensemble, les remplacer lorsqu’elles ne répondent plus au besoin, puis apprendre de chaque itération. L’IA accélère ce mouvement, mais elle ne remplace ni le jugement, ni l’architecture, ni la responsabilité de construire quelque chose qui dure.
RSS
Le RSS envoie les nouveaux articles dans le lecteur de votre choix, sans algorithme ni newsletter.
Quand on était enfant, une énorme boîte de LEGO avait quelque chose de très particulier. Elle ne promettait pas un résultat précis. Elle promettait des possibilités.
On pouvait suivre le plan et construire le modèle sur la boîte. Puis on pouvait décider que la voiture devait avoir des ailes, que le château avait besoin d’un garage ou que le vaisseau spatial devait devenir une base secrète. On assemblait, on regardait ce que cela donnait, on démontait une partie, on cherchait une autre brique et on recommençait. Ce n’était pas du travail bâclé. C’était une manière très concrète d’apprendre à construire.
On pense que le développeur d’aujourd’hui ressemble beaucoup à cet enfant-là. Pas parce que son métier serait devenu un jeu. Au contraire : parce que notre capacité à créer dépend de plus en plus de notre aptitude à explorer, à assembler intelligemment et à améliorer ce qui existe déjà.
Le code reste important. L’architecture l’est encore davantage. Mais le fantasme du développeur qui écrit seul, depuis une page blanche, chaque ligne d’un système parfaitement maîtrisé est devenu largement insuffisant pour décrire la réalité.
Le développement n’a jamais été une suite de lignes écrites dans le vide
Même avant l’arrivée des assistants IA, nous travaillions déjà avec des briques. Un framework, une bibliothèque, une API de paiement, une base de données, un système d’authentification, un design system, un service de cache : chacun apporte une partie du produit final.
La vraie compétence n’était donc pas seulement de savoir fabriquer une brique. Elle consistait à savoir laquelle choisir, comment l’intégrer et, surtout, comment éviter que l’ensemble s’effondre au premier changement.
Avec l’écosystème moderne, cette logique est devenue encore plus visible. En quelques heures, on peut connecter une API, démarrer un projet Next.js, mettre en place une base PostgreSQL, intégrer une authentification ou automatiser un workflow. Ce n’est pas de la magie. Ce sont des briques de plus en plus accessibles.
Et c’est précisément là que se situe le piège : avoir beaucoup de briques ne suffit pas à construire quelque chose d’utile.
Un enfant peut empiler toutes les pièces de sa boîte jusqu’à faire une tour. Mais il comprend très vite qu’une tour trop haute, mal équilibrée ou posée sur une base trop petite finit au sol. En développement, le résultat est moins spectaculaire, mais la mécanique est la même : dette technique, dépendances incompatibles, données mal modélisées, sécurité ajoutée trop tard, absence de tests ou comportement impossible à diagnostiquer.
Le problème n’est pas d’aller vite. Le problème est de ne pas regarder comment ce que l’on vient de construire tiendra demain.
Construire, tester, casser : ce n’est pas échouer, c’est travailler
Pendant longtemps, on a présenté l’erreur comme le contraire du travail bien fait. Dans le développement, cette idée est absurde.
Un prototype qui échoue rapidement peut avoir bien plus de valeur qu’une solution longuement théorisée qui arrive trop tard. Une intégration cassée en environnement de test peut éviter une panne en production. Une fonctionnalité que l’on démonte parce qu’elle ajoute de la complexité inutile est parfois la meilleure décision du projet.
La différence se joue dans la manière de casser.
Casser au hasard en production, sans logs, sans tests et sans possibilité de retour arrière, ce n’est pas itérer. C’est transférer le risque aux utilisateurs et à l’équipe qui devra gérer l’incident. En revanche, expérimenter dans un cadre maîtrisé, avec une hypothèse claire, des critères de validation et une possibilité de rollback, c’est faire avancer le produit.
L’enfant devant ses LEGO ne pleure pas lorsqu’une construction ne tient pas. Il identifie une pièce trop fragile, cherche un autre point d’appui et recommence. Le développeur expérimenté fait pareil : il observe un comportement, réduit le problème, vérifie ses hypothèses et reconstruit sur une base plus solide.
L’itération n’est pas l’absence de méthode. C’est une méthode qui accepte la réalité : on comprend rarement un problème complexe avant d’avoir essayé de le résoudre.
L’IA a ajouté des briques. Elle n’a pas construit le bâtiment à notre place.
L’arrivée de l’IA générative rend cette métaphore encore plus juste. Aujourd’hui, un développeur peut demander un squelette de composant, une migration SQL, des tests, une documentation technique ou une première version d’intégration. Cela réduit énormément le coût de l’exploration.
Mais un assistant IA ne sait pas spontanément pourquoi ton modèle de données est ainsi, quelles contraintes métier sont invisibles dans le ticket, quel flux doit rester idempotent ou quelle dépendance ne doit jamais être introduite dans ce projet. Il peut produire une brique. Il ne porte pas la responsabilité de la structure.
Le risque actuel est de confondre vitesse de génération et vitesse de livraison. Générer du code très vite est devenu facile. Comprendre ce code, le tester, le sécuriser, le faire évoluer et l’assumer dans six mois reste le vrai travail.
On ne crois pas à l’opposition simpliste entre « coder à la main » et « faire coder par l’IA ». C’est comme opposer un enfant qui fabrique chaque brique de LEGO à un autre qui utilise une boîte déjà complète. Dans les deux cas, la question utile est la même : qu’est-ce que tu essaies de construire, et est-ce que tu maîtrises suffisamment les pièces pour le faire tenir ?
L’IA donne un accélérateur à ceux qui savent déjà cadrer un problème. Elle donne aussi l’illusion d’une compétence à ceux qui ne vérifient rien. La frontière n’est pas l’outil. C’est le niveau d’exigence que l’on garde face à son résultat.
Le plan reste essentiel, mais il ne doit pas empêcher de commencer
Dans une boîte de LEGO, le plan a une vraie utilité. Il évite de chercher inutilement, donne une direction et montre dans quel ordre certaines pièces doivent être posées. En développement, c’est exactement le rôle d’une bonne phase de conception : clarifier l’objectif, identifier les contraintes, découper le sujet, décider de ce qui doit être stable avant de démarrer.
Mais suivre un plan ne signifie pas prétendre que tout est connu à l’avance.
Un projet sérieux a besoin d’un cap, d’une architecture et de choix explicites. Il a aussi besoin de boucles de retour rapides. Si la première intégration révèle que l’API ne répond pas au besoin, si les utilisateurs ne comprennent pas le parcours ou si la performance s’effondre avec des données réelles, le bon réflexe n’est pas de protéger le plan initial. C’est de corriger le plan.
Le mode plan est précieux. Il force à penser avant d’empiler les pièces. Mais un plan qui ne survit pas au contact du terrain est un document décoratif, pas un outil de développement.
Les meilleures constructions ne sont pas celles qui ne changent jamais
Dans beaucoup d’équipes, on valorise encore le fait de « finir » une fonctionnalité comme si elle était ensuite gravée dans le marbre. Pourtant, les bons produits évoluent. Les usages changent, les contraintes métier se précisent, les technologies avancent et ce qui semblait évident six mois plus tôt peut devenir une mauvaise réponse.
Construire pour durer ne signifie pas construire pour ne plus toucher à rien. Cela signifie rendre le changement possible sans devoir tout casser autour.
C’est là que les fondamentaux reprennent toute leur importance : une architecture compréhensible, des frontières claires entre les responsabilités, des tests qui protègent les comportements essentiels, des logs exploitables, une documentation qui explique les décisions importantes et des déploiements réversibles. Ce sont les tenons et les plaques de base du projet. Ils ne sont pas toujours visibles dans la démo, mais ils déterminent ce que l’on pourra reconstruire ensuite.
Le code le plus intelligent n’est pas forcément celui qui impressionne le plus. C’est souvent celui qu’une autre personne peut relire, modifier et déployer sans avoir peur de provoquer une réaction en chaîne.
Réapprendre à expérimenter sans renoncer à l’exigence
Le développement moderne demande paradoxalement deux attitudes que l’on oppose trop souvent : l’audace d’essayer et la discipline de vérifier.
Il faut essayer une nouvelle approche quand elle peut simplifier un problème. Il faut utiliser une bibliothèque plutôt que réécrire inutilement une solution connue. Il faut parfois produire un prototype en une journée pour savoir si l’idée mérite trois semaines de travail. Et il faut accepter de démonter ce prototype s’il ne passe pas l’épreuve du réel.
Mais il faut aussi savoir dire non. Non à une dépendance de plus sans raison. Non à un morceau de code généré et incompris. Non à une démonstration qui contourne tous les vrais cas métier. Non au « ça marche chez moi » qui devient trop facilement une stratégie de livraison.
Cette exigence n’est pas un frein à la créativité. Elle lui donne une direction.
Un enfant invente librement avec ses LEGO parce qu’il connaît progressivement les contraintes des pièces : ce qui s’emboîte, ce qui tient, ce qui bloque une porte, ce qui rend une construction trop fragile. Plus il apprend, plus il peut imaginer grand. Pour un développeur, c’est la même chose. Les fondamentaux techniques ne limitent pas l’usage de l’IA, des frameworks ou des outils no-code. Ils permettent de les utiliser sans devenir dépendant de résultats que l’on ne comprend pas.
Le métier ne disparaît pas : il se déplace vers le jugement
Le développeur de demain écrira probablement moins de code répétitif qu’il y a dix ans. Mais il devra prendre davantage de décisions : quelles briques réutiliser, quels compromis accepter, quelles parties automatiser, quels risques encadrer et à quel moment arrêter d’itérer pour livrer.
Il devra aussi mieux communiquer. Car dans un monde où produire une première version devient très rapide, la valeur se déplace vers la capacité à clarifier un besoin flou, rendre des choix explicites et faire circuler la compréhension entre les personnes, les outils et les systèmes.
Ce n’est pas une diminution du métier. C’est une élévation de son niveau de responsabilité.
La grande boîte de LEGO est donc une bonne image du développement actuel, à condition de ne pas la prendre pour une caricature. Les briques sont plus nombreuses, les constructions plus ambitieuses et les conséquences d’une erreur bien plus importantes. Mais l’énergie de départ reste la même : prendre un problème, imaginer une première forme, essayer de la construire et apprendre de ce qui ne marche pas encore.
Construire mieux après chaque essai
Le développement n’est pas une course pour produire du code le plus vite possible. C’est un travail de construction continue.
Nous assemblons des briques existantes, nous en créons certaines quand il le faut, nous testons les liens entre elles et nous recommençons lorsque la réalité nous montre une meilleure voie. L’IA accélère cette boucle, mais elle ne supprime ni la nécessité de comprendre, ni celle de choisir, ni celle d’assumer.
Au fond, le bon développeur n’est pas celui qui ne casse jamais rien. C’est celui qui sait distinguer ce qui peut être expérimenté de ce qui doit être protégé, qui apprend vite de chaque essai et qui laisse derrière lui une construction plus solide que la précédente.
Comme devant une immense boîte de LEGO, la question n’est pas de savoir si l’on possède assez de pièces. La question est de savoir ce que l’on veut bâtir, et si l’on est prêt à reconstruire intelligemment jusqu’à ce que cela tienne vraiment.
