Plus besoin de savoir coder, de connaître les frameworks qu'on utilise dans sa codebase et les détails d'implémentation... L'important à l'ère de l'AI, c'est QUE le produit. Ou pas.
Product-first
J'avais dans les brouillons de ce blog une très vieille ébauche d'article sur une expression que j'ai toujours entendue dans ma carrière, qui semble sensée mais dont l'usage a été détourné : penser "Product-first".
Avec l'ère du développement assisté par AI, on voit son grand retour.
A première vue, ça a du sens: on travaille généralement à répondre à des problématiques pour des clients et donc l'existence même du logiciel est conditionnée au fait qu'il répond aux besoins du client. En plus de cela, on veut pouvoir itérer et délivrer de la valeur rapidement, et si possible plus rapidement que la concurrence.
S'intéresser au produit en tant que tech fait donc partie (et a toujours fait partie) du job, que ce soit lors des phases de design, de conception, ou d'exploitation d'une solution. Et une des capacités d'un bon développeur est de faire ce pont entre le produit et l'implémentation finale, ainsi que de la faire évoluer en fonction de métriques métier (e.g "est-ce qu'on apporte vraiment de la valeur au client").
Bref, on est sûrement tous d'accord là dessus, et faire de la technique pour de la technique n'est pas vraiment le genre de la maison.
Mais donc, c'est quoi le problème avec l'expression "Product-first" dont je parlais au début? Il est simple: une partie non négligeable de son utilisation n'est pas une incitation à penser produit, mais une excuse pour faire n'importe quoi, notamment sur l'implémentation technique mais pas que:
- Performances éclatées au sol (applications/appels http lents, requêtes SQL non optimisées, ne supporte pas la charge...)? "Product-first"
- Incidents et bugs à répétition? "Product-first" (ndlr: oui c'est contradictoire)
- Projets difficiles à faire évoluer, où chaque nouvel ajout est un hack au-dessus d'un existant pas terrible qu'on n'a jamais vraiment pris le temps de corriger? "Product-first"
- Applications qui ne s'insèrent pas dans une vision d'architecture globale, qui ont des difficultés à communiquer entre elles, où la donnée est difficilement accessible? "Product-first"
Tous ces exemples (non exhaustifs) impactent l'expérience produit et la vélocité des équipes. Bien sûr, il est normal de parfois prendre des raccourcis pour délivrer vite, avoir des premiers retours clients, et de réitérer ensuite sur des sujets liés à la qualité.
Ne prenez pas mon propos comme un signe de "encore un qui over engineer tout et qui délivre rien tant que c'est pas parfait", mais j'attends d'un développeur expérimenté qu'il puisse faire cet arbitrage entre rapidité et qualité de manière consciente, voire qu'il n'ait pas à le faire du tout en produisant une solution élégante à un coût équivalent ou presque à la solution "quick and dirty".
Vous voyez où je veux en venir. Parce que cette excuse-là, "Product-first", elle vient de trouver un nouveau meilleur ami : l'AI.
L'ère de l'AI
Aujourd'hui, quasi 100 % de mon code est écrit par une intelligence artificielle (Claude Code). Le gain de productivité est énorme. C'est assez dur à quantifier mais sur de l'écriture de code pure, la mienne a clairement été multipliée par plusieurs facteurs.
Pourtant, je ne crois pas au "coding is solved" que je lis partout. Savoir quoi construire n'est pas suffisant, le comment reste important même à l'ère de l'AI, du moins quand on construit quelque chose de non-trivial.
Le fameux talk Simple Made Easy de Rich Hickey (2011, donc bien avant la GenAI) a une slide qui résume très bien la situation.
Le vibe-coding donne un résultat immédiat, et c'est génial. Pour valider une idée, ou pour des projets sans importance (le front de ce blog par exemple), c'est parfait. J'adore également l'idée de démocratisation du développement logiciel, désormais accessible au non-tech, notamment pour de petites applications utilitaires locales (même si ça pose quelques problématiques de sécurité, dont on parlera dans un prochain article).
Mais la vie d'une entreprise tech, c'est pas ça. Maintenir une application ou pire, une collection d'applications (qui a dit microservices) sur 10 ans, avec de grosses équipes, et un turnover plus ou moins important, ce n'est pas comme vibe coder une application qu'on peut mettre à la poubelle le lendemain. Votre sprint initial devient un marathon.
Les mauvais choix et raccourcis se payent au centuple les années suivantes, avec des conséquences réelles sur les clients, les équipes, et l'entreprise. On ne peut pas baisser le niveau d'exigence sous prétexte que l'AI nous permet d'aller plus vite ; il faut au contraire réussir à le maintenir tout en multipliant par 2, 3, 4... notre productivité. Et c'est exactement ce point qui me fait dire que non, le "coding" n'est pas "solved".
Alors vous allez me dire "oui mais avec l'AI on peut refactorer plus vite si on fait les mauvais choix". Oui, on peut refactorer plus vite, mais ce sera toujours coûteux, risqué, et c'est du temps qu'on ne passe pas à faire de la feature, donc c'est une fausse bonne idée.
Un choix de langage de programmation a toujours son importance: écosystème, performance, taille du marché...
Un choix de librairie ou de framework a toujours son importance
L'ingénierie logicielle (organisation du code, DDD, architecture hexagonale, observabilité avec logs, métriques, traces, comment bien tester, performance...) a toujours son importance. D'ailleurs, l'AI bosse beaucoup mieux sur du code propre que sur du gloubi-boulga.
Je pourrais continuer pendant longtemps la liste de sujets liés à la tech qui sont importants et où débrancher son cerveau est une erreur. Le point important à retenir est que ces choix vont impacter fortement vos projets, et que donc VOUS en êtes responsables.
Mais l'AI peut pas tout faire pour moi?
C'est normalement à ce moment-là qu'on me dit : mais attends, pourquoi tu ne demandes pas à l'AI de faire tous ces choix, ou de "bien construire" le projet ? Si on rajoute make no mistake au prompt, ça devrait bien se passer, non?
L'AI, même avec les derniers modèles, oscille entre le développeur junior et l'expert mondial avec 40 ans d'expérience en fonction des sujets. Et elle peut rapidement passer de l'un à l'autre, c'est donc à nous d'être vigilants pour le détecter et la remettre sur les rails.
Je reste personnellement toujours en contrôle de ce que je produis. Bien que travaillant sur un projet où le code a été écrit quasi exclusivement par AI, je suis en capacité d'expliquer sur tableau blanc son architecture, les principaux modules et comment ils communiquent entre eux, le modèle de données, comment fonctionne l'observabilité, ou bien de dire quelles sont les parties un peu dégueulasses qui mériteraient des évolutions dans le futur.
Lorsqu'il faut faire un choix important (nouvelle architecture, nouvelle lib structurante, nouvelle fonctionnalité complexe...), c'est ma décision. L'AI va m'aider à brainstormer, me challenger, ouvrir mes horizons pour proposer des solutions auxquelles je n'aurais pas pensé... mais à la fin, c'est moi qui tranche. Et concernant les choix technologiques, je m'attends à ce que chaque personne travaillant sur un projet comprenne les technologies et patterns sous-jacents, notamment sur les parties critiques de l'application.
L'AI est une révolution dans nos métiers (et au delà), je travaille avec tous les jours, mais ne la prenons pas pour excuse pour débrancher notre cerveau.
En 2026, coding is not solved.