L’IA ne construit pas un produit fonctionnel à votre place : cela reste votre travail

• L’IA peut créer en quelques minutes un prototype doté d’une UI et d’une base de données, mais elle ne réduit pas la distance entre une première version fonctionnelle et un produit de niveau production
• Un vrai produit laisse subsister des problèmes qui exigent un jugement d’ingénierie plutôt que de la simple syntaxe : scalabilité, gestion des erreurs, observabilité, sécurité, authentification, structure des données
• La valeur de l’informatique réside moins dans la production de code que dans les modèles mentaux permettant de comprendre le comportement des systèmes et les causes de leurs défaillances ; c’est ce savoir qui permet de repérer des requêtes inefficaces ou des conditions de concurrence
• La demande pour la traduction mécanique de besoins en code diminue, mais les ingénieurs expérimentés peuvent confier les tâches répétitives à l’IA et se concentrer sur les problèmes exigeant de l’expertise, afin de travailler beaucoup plus vite
• Si l’IA est utilisée comme substitut à la compréhension, il devient difficile de corriger, d’étendre ou de transmettre un système en panne ; il faut donc d’abord acquérir les bases, puis exploiter les outils d’IA

---

Le fossé entre prototype et produit

• En décrivant une idée en langage naturel, on peut obtenir en quelques minutes un prototype fonctionnel avec UI et base de données, qui exécute les fonctions prévues
• Mais un prototype exécuté sur un ordinateur portable peut révéler de nombreux problèmes en conditions réelles
  • Il ne tient pas la charge et ne dispose pas d’une gestion des erreurs adaptée
  • Des tokens d’API peuvent fuiter
  • Un modèle de données conçu pour une démo peut s’effondrer dès l’ajout d’un deuxième utilisateur
  • L’authentification repose sur des hypothèses non vérifiées, et la sécurité reste incertaine
• Au moment du déploiement, un grand écart de production apparaît entre « ça marche » et « c’est prêt »

Le difficile venait après l’écriture du code

• Les ingénieurs logiciels savaient déjà faire tourner quelque chose rapidement ; la partie qui prenait vraiment du temps venait ensuite
  • Concevoir un système capable de tenir à l’échelle
  • Gérer les cas limites quand les utilisateurs empruntent des chemins imprévus
  • Mettre en place l’observabilité permettant de détecter les incidents
  • Prendre des décisions d’architecture de données qui réduisent les regrets trois ans plus tard
• L’IA a fortement réduit le temps nécessaire pour atteindre une première version fonctionnelle, mais elle n’a pas raccourci la distance entre cette version et un système de niveau production
• Le cycle rapide demande-réponse-vérification du résultat donne l’impression que le reste du développement a lui aussi été compressé, mais les problèmes difficiles du logiciel n’ont jamais été, au départ, l’écriture de la syntaxe
• Le jugement — décider quoi construire et comment le structurer, quoi reporter et quand dire non — distingue un prototype d’un système de production

Pourquoi l’informatique reste nécessaire

• À mesure que le code généré par l’IA devient facilement accessible, de plus en plus de nouveaux entrants se demandent s’il faut encore passer des années à étudier les algorithmes, les structures de données, les systèmes d’exploitation et la théorie
• La valeur d’une formation en informatique ne se limite pas à la capacité d’écrire du code ; elle forme les modèles mentaux qui permettent de comprendre comment les systèmes fonctionnent, échouent et pourquoi ils produisent certains résultats
• Cette base est nécessaire pour identifier les défaillances potentielles dans le code généré par l’IA
  • Une requête qui déclenche un scan complet sur une table de 50 millions de lignes
  • Une stratégie de cache qui crée une condition de concurrence sous charge concurrente
  • Une architecture qui résout les besoins actuels mais rend le prochain problème beaucoup plus difficile
• Sans connaissances fondamentales, on dépend entièrement du jugement du modèle
  • Le modèle ne s’appuie pas sur un jugement, mais sur de la reconnaissance de motifs, et génère activement le code qu’il estime correspondre à l’intention
  • Le code généré peut sembler correct et conforme aux conventions, tout en échouant en production
  • Sans les connaissances nécessaires pour reconnaître le problème, le diagnostic peut prendre des jours
• Maintenant que la distance entre compréhension et résultat s’est réduite, c’est un bon moment pour apprendre l’informatique ; un étudiant qui comprend vraiment les systèmes distribués peut les construire en bien moins de temps qu’il y a dix ans

Les tâches automatisées et la productivité amplifiée

• La demande pour le codage mécanique consistant à transformer les exigences ligne par ligne en implémentation diminue réellement, et ce domaine est en cours d’automatisation
• Le bas de la distribution de productivité se comprime, tandis que la limite supérieure s’élargit
  • Un ingénieur expérimenté utilisant des outils d’IA modernes peut travailler à une vitesse difficile à imaginer il y a cinq ans
  • Non pas parce que les problèmes difficiles ont disparu, mais parce que la plupart des tâches mécaniques qui consommaient du temps et de l’attention sont prises en charge
  • Le temps ainsi libéré peut être consacré aux tâches qui exigent une vraie expertise
• Les ingénieurs qui prendront du retard ne seront pas ceux qui ignorent comment utiliser l’IA, mais ceux qui utilisent l’IA comme substitut à la compréhension
  • Ils construisent en vibe coding des systèmes qu’ils ne peuvent pas raisonner
  • Ils ne peuvent pas corriger les incidents ni faire évoluer un système qui a grandi
  • Ils ne peuvent pas expliquer ce qu’ils ont créé aux personnes chargées de la maintenance

Travailler à un niveau d’abstraction plus élevé

• Le changement nécessaire ne consiste pas seulement à adopter un nouvel outil, mais à travailler à un niveau d’abstraction plus élevé tout en restant enraciné dans les fondamentaux
• Les ingénieurs qui utilisent l’IA comme amplificateur de connaissances profondes, et non comme substitut, peuvent prendre de l’avance rapidement sur leurs pairs
  • Ils comprennent ce qu’ils demandent au modèle de générer
  • Ils examinent de manière critique le code généré, comme ils reliraient la pull request d’un ingénieur junior
  • Ils ne transmettent pas seulement une description de fonctionnalité, mais dialoguent sous l’angle de l’architecture
  • Ils savent quand s’opposer aux propositions du modèle
• Il ne s’agit pas de remplacer les compétences existantes par une nouvelle compétence, mais d’appliquer les compétences existantes à un nouvel environnement pour obtenir un levier bien plus important
• Même après le prototype, un véritable jugement d’ingénierie reste nécessaire ; c’est cette capacité qui distingue les développeurs capables de livrer un logiciel fiable de ceux qui ne livrent qu’une démo
• L’ordre d’apprentissage doit être : les fondamentaux d’abord, les outils d’IA ensuite

[GN⁺]

Avis sur Hacker News

• Sur un side project, j’envisage de jeter plusieurs mois de code généré avec des LLM. Même en rédigeant soigneusement les spécifications de conception et en travaillant dans une base de code existante, les changements pris individuellement paraissaient logiques, mais l’ensemble est devenu une masse complexe dont plusieurs parties sont subtilement décalées
  Pour les rapports ou les articles aussi, chaque section semble plausible, mais le document entier paraît étrange. Les humains semblent faire un raisonnement de haut niveau encore impossible pour les LLM, même s’ils sont plus lents sur les tâches de détail. Quand on leur signale un défaut, ils répondent « vous avez tout à fait raison », mais sont incapables de le trouver lors de leur propre relecture
  Construire une simple app CRUD avec un framework JS courant, Tailwind et un ORM est probablement tout à fait faisable, mais on pouvait déjà acheter des templates SaaS avant, et un bon boilerplate artisanal a de fortes chances d’être meilleur que le résultat du vibe coding

  • J’utilise de plus en plus la programmation assistée par LLM plutôt qu’une programmation entièrement autonome. Des modèles comme Opus ont tendance à modifier jusqu’à atteindre l’objectif plutôt qu’à comprendre une bonne conception, en laissant derrière eux du code à remettre en ordre par un humain et un travail d’investigation excessif
    Je vois souvent aussi, dans les PR d’autres personnes, des implémentations qui règlent superficiellement le problème du prompt mais rendent la maintenance à long terme difficile. Donc je décide moi-même des étapes d’implémentation et de la conception, puis je travaille pas à pas avec de petits modèles open source ou avec Claude 4.5·4.6. L’exploration d’API et l’écriture de boilerplate vont plusieurs fois plus vite qu’à la main, sans que mes connaissances se dégradent ni que la base de code soit abîmée
  • Il m’est souvent arrivé de rester bloqué dans une solution complexe et surconçue, puis de réaliser la solution simple après une promenade ou en faisant autre chose. Les LLM traitent tout immédiatement, ce qui enlève le temps de réflexion nécessaire pour reconnaître une impasse ou penser aux conflits avec la tâche suivante
  • Mon side project aussi est désormais devenu difficile à comprendre entièrement et à modifier moi-même en toute sécurité, mais je pense que ce n’est plus nécessaire. J’ai écrit du beau code pendant presque 20 ans, donc maintenant je veux me concentrer sur la productivité et le résultat, et tant que Codex comprend le code spaghetti, cela me va pour un projet personnel ou une petite société indépendante
    L’IA est une nouvelle couche ajoutée à la stack technologique, comme les langages de haut niveau au-dessus du langage machine, donc il faut lâcher prise
  • La vraie valeur était moins dans le code que dans l’apprentissage acquis en y arrivant. En galérant, on découvre sans cesse les vrais besoins et les difficultés techniques, mais l’IA saute ce processus et donne l’impression d’avoir atteint l’objectif de façon superficielle
    Cela ne veut pas dire que l’IA est inutile, mais qu’il faut réfléchir plus profondément aux exigences et à la validation finale, et moins croire que le processus garantira un bon résultat
  • Sur un nouveau projet familial de gestion d’agenda, j’exploite la vitesse de l’IA pour affiner les problèmes d’expérience utilisateur. Je construis des fonctionnalités, je les utilise moi-même pendant quelques jours, puis je corrige ce qui ne me plaît pas, en répétant ce cycle avec pour objectif d’achever les fonctionnalités de la v1
    Je n’aime pas les couleurs ni la logique métier verbeuse et inutilement tape-à-l’œil, mais ce qui compte maintenant, c’est de savoir si le couple l’utilise vraiment de façon utile, et les résultats sont positifs. Ensuite, je compte redessiner l’UI selon mes goûts, fixer les exigences du backend, puis tout réécrire depuis le début pour faciliter maintenance et extension
    La famille Claude excelle pour le prototypage et la découverte des besoins, et facilite ensuite le fait de le refaire correctement

• Un critère simple de vérification est de savoir si, au cours des 12·24·36 derniers mois, on a réellement vu d’excellents nouveaux produits ou de grandes améliorations de produits existants. Le seul excellent nouveau produit que j’ai utilisé est mon LLM préféré, et les labos qui le développent embauchent au contraire davantage
  S’il n’y a toujours pas d’amélioration dans 12 mois, je pense qu’on répétera encore l’argument selon lequel « les LLM ne sont devenus assez bons qu’en février 2027, donc on ne peut pas encore les évaluer »

  • Le fait que la version web et la version VS Code de Claude Code soient toujours pleines de bugs est aussi un bon critère. Presque toutes les boucles d’exécution d’agents finissent par casser et nécessitent un rafraîchissement forcé, qui parfois ne résout même pas le problème. Anthropic dispose pourtant en pratique d’un budget LLM illimité et de modèles non publics
  • Je ne suis pas un partisan du LLM-pour-tout et je les utilise de manière contrôlée, mais la récente découverte automatique de vulnérabilités est une avancée intéressante. Chrome a corrigé en juin plus de bugs qu’au cours des deux années précédentes
    https://news.ycombinator.com/item?id=49120097
    Les dernières mises à jour de sécurité d’Apple et le bulletin de sécurité Android de juin corrigent eux aussi un nombre énorme de vulnérabilités. Une grande partie vient de langages non sûrs comme le C/C++, mais comme les LLM sont forts sur les tâches de transformation clairement définies et peu sujettes aux écarts, ils sont aussi utiles pour porter cela vers des langages sûrs comme Rust
  • La vitesse de sortie des projets est similaire à avant, mais grâce aux outils IA, le résultat est bien plus abouti et riche en fonctionnalités. Autrefois, je livrais seulement le chemin nominal ; maintenant, je peux aussi fournir sans gros effort la résiliation, l’export de compte, la politique de confidentialité, ainsi que l’ensemble des apps mobile et web
  • Rien qu’en regardant quelques communautés de développeurs, le nombre de nouveaux produits a triplé depuis l’arrivée de ces outils. Il n’existe aucune liste qui suit tous les logiciels lancés et indique s’ils ont utilisé l’IA, donc conclure que cela n’existe pas simplement parce qu’on n’a pas vu soi-même d’amélioration est étrange
    Dans le domaine médical aussi, le nombre de produits a fortement augmenté ; la qualité est très variable, mais dire qu’il n’y a eu aucun résultat est objectivement faux
  • À mon avis, l’usage réellement pratique date de la fin de l’an dernier, mais il est vrai que les logiciels de loisir ont récemment nettement augmenté. La question de leur maintenabilité est autre chose

• Si le produit fonctionne, je recommande de lui demander « examine si la base de code est prête pour la production et si elle répond au niveau requis pour être vendue 1 million de dollars ». Cela révèle alors que l’IA est loin du niveau qu’elle affirmait auparavant, et cela devient le « prompt du million de dollars » qui montre à quel point on s’est laissé berner

  • J’ai vu deux posts sur Hacker News, et dans les deux cas le commentaire le mieux classé disait que « l’IA ne sait pas écrire du code et va bientôt s’effondrer ». Il est difficile de comprendre qu’on continue à parler de mirage à des gens qui utilisent ces outils avec succès tous les jours depuis des années
  • Beaucoup de bases de code médiocres ont aussi été vendues plus d’un million de dollars
  • Dans ce cas, je me demande combien de millions de dollars Oracle Database devrait valoir
    https://news.ycombinator.com/item?id=18442941
  • Si on lui demande de corriger le problème puis qu’on repose la même question, il formulera probablement des critiques similaires même après les corrections
  • Il vaut la peine de réfléchir au prix auquel OpenClaw a été vendu

• J’ai essayé d’utiliser les LLM de deux façons. D’abord, j’ai fait du vibe coding avec Opus 4.6 et un backend Node pour un plugin qui envoie des notifications dans un canal Slack selon un tour de rôle, ainsi qu’un minuteur de temps de parole par participant dans Google Meet. Comme c’est un outil interne, même sans bien comprendre l’implémentation, il fonctionne sans problème sur GCP, et j’ai réduit le coût de l’outil Slack de 20 dollars par mois et par personne à un coût d’infrastructure total de 0,07 dollar par mois
  Ce n’a pas été fait d’un seul coup : il a fallu une planification détaillée, une exécution étape par étape et l’ajout de tests. Ensuite, pour un produit de long terme, l’équipe conçoit et révise l’architecture, crée des tickets JIRA détaillés, puis les transmet à Opus. Le modèle élabore un plan d’implémentation, et on ne le laisse coder qu’après validation par un ingénieur
  La première approche est bien pour un MVP rapide ou une preuve de concept, mais pour un produit de long terme, il faut abandonner le MVP, planifier dès le départ l’évolutivité et une architecture propre, puis utiliser le LLM comme ouvrier du code. Les LLM restent encore faibles pour juger d’une architecture maintenable sur la durée et d’un code propre

  • C’était excellent pour le vibe coding d’apps ponctuelles à faible risque, mais implémenter des fonctionnalités de la même manière dans une énorme base de code legacy est devenu un véritable cauchemar

• Le critère de jugement est de savoir si consommer des productions générées par l’IA est plaisant. Que ce soit des textes, des vidéos, des voix, des menus de restaurant, des photos de vêtements, des documents, le contrôle aérien ou la publicité, rien de tout cela ne semble plaisant, même si les LLM ont à mes yeux de la valeur comme moteurs de recherche améliorés ou outils de questions-réponses

  • Beaucoup de consommateurs se moquent de la faible qualité tant que le produit atteint un seuil minimal et fonctionne. On a déjà vu le même phénomène dans l’électroménager, le logiciel et la restauration rapide
    Si l’IA finit par atteindre ce seuil, ses productions domineront les créations artisanales, et les produits et services fabriqués directement par des humains risquent de ne plus être accessibles qu’à des prix bien plus élevés, comme l’artisanat aujourd’hui
  • Il est possible que vous profitiez déjà en permanence de bons résultats produits par l’IA sans même vous en rendre compte. Personne n’aime les productions jetables médiocres
  • Quand on voit que les gens dépensent au total des dizaines de milliards de dollars chaque mois, on peut considérer qu’ils aiment réellement ça
  • Je ne considère les productions de l’IA que comme des matières premières, pas comme des produits finis à livrer directement au grand public
  • Le problème n’est pas le fait que ce soit de l’IA, mais la faible qualité. Même si l’origine IA est évidente, les résultats bien réalisés plaisent

• Il va y avoir beaucoup de travail à remettre en ordre le résultat du vibe coding d’autres entreprises et à en faire des systèmes réalistes. La valeur de chaque projet individuel baissera peut-être, mais leur nombre augmentera, avec de fortes chances qu’ils ne fonctionnent pas correctement sans aide
  Une entreprise sans ingénieur logiciel disait utiliser Claude Code pour des tâches hors de son cœur de métier, tout en souhaitant que ses employés fassent le travail pour lequel ils ont été recrutés au lieu de bricoler du code
  À mesure que le sur-mesure devient plus facile, les produits uniformisés seront plus difficiles à vendre, mais livrer de vrais résultats personnalisés demandera toujours beaucoup de travail. C’est un avantage double pour les personnes qui combinent expérience de construction directe et connaissance du domaine métier concerné
  En général, les gens ne savent pas vraiment ce dont ils ont besoin, donc l’essence du conseil — découvrir les besoins puis y répondre — reste la même, et comme le logiciel devient moins cher, on peut prendre en charge davantage de clients

  • On ne sait pas bien de quel employé il s’agit quand on dit qu’il ne devrait pas toucher au code

• La logique de base du texte est défaillante. S’il reste du travail à faire après avoir créé un prototype, il suffit de continuer à faire ce travail. Le texte semble assimiler l’usage de l’IA à une génération en une seule fois avec un prompt de quatre lignes, et cela ressemble moins à une intuition fondamentale qu’à une rationalisation acritique

  • Cela correspond exactement à mon ressenti avec les LLM dans des bases de code où la couverture de tests est insuffisante, les exigences floues et le mode de déploiement non standard. Dès qu’on sort du chemin normal, ils commencent à faire de mauvaises hypothèses qui cassent la production, et même les modèles les plus intelligents n’atteignent pas le niveau requis pour une architecture adaptée à ce type d’environnement

• Même sans formation en ingénierie, cela m’a semblé intuitivement juste, et je l’ai vécu plusieurs fois en créant des jeux de cartes. Au début, tout allait bien, puis le fait d’avoir repris une bibliothèque standard de 52 cartes m’a empêché d’ajouter des cartes événement spéciales, alors qu’il me fallait un modèle de données flexible fondé sur des objets carte
  Si on le lui dit dès le départ, il peut résoudre le problème, mais si on considère le logiciel comme jetable et qu’on ne réfléchit pas en profondeur à l’implémentation comme le ferait un ingénieur expérimenté, on ne pensera pas à ce genre d’exigence. Le problème des textes et du code générés par l’IA, c’est qu’ils nous privent de la réflexion intrinsèque au processus de fabrication
  Cela dit, tous les logiciels n’ont pas besoin d’être évolutifs, rapides et maintenables. C’est nécessaire pour une infrastructure ou des apps utilisées par des millions de personnes, mais une application familiale de planification des repas n’a pas besoin de gérer les réglages d’allergies de dizaines de milliers d’employés de Google
  L’IA permet de faire du logiciel un outil comme un repas maison. Un repas maison n’a pas besoin d’être une cuisine parfaite : il suffit qu’il nourrisse la famille et représente pour quelqu’un un cadeau de temps et d’effort

• Si un produit pouvait être créé en une seule demande, les sociétés de sous-traitance domineraient les sociétés produit depuis longtemps. Une grande partie du développement produit se joue dans le travail itératif après le prototype ou le MVP initial
  Il ne s’agit pas seulement de technique : il faut aussi creuser le problème sur la durée, comprendre la cause profonde de la douleur, puis y répondre à la fois du point de vue de l’expérience utilisateur et de la technique. On pouvait déjà “prompter” des sociétés de sous-traitance pour obtenir un produit, mais c’est précisément pour cela qu’on payait des sociétés produit ayant acquis une expertise en parlant pendant des années avec leurs clients

• Un titre comme The Prototype Isn't the Product résume mieux la discussion. Avec l’IA, on peut créer à une vitesse surprenante des prototypes jetables et des apps personnelles pour lesquelles “ça marche à peu près” suffit, mais l’ingénierie logicielle, quand la qualité et la maintenance comptent, reste difficile et lente
  On voit beaucoup de démonstrations spectaculaires de vibe coding, mais peu de discussions sur l’utilité réelle de l’IA dans de vastes bases de code legacy ou dans le travail professionnel quotidien, banal et peu glamour
  On ne reçoit pas un appel le dimanche à 6 h du matin parce qu’un prototype de jeu 3D fait en vibe coding s’est arrêté, mais si un bug apparaît dans un système 24/7 que vous venez de mettre à jour, là, l’appel arrive à coup sûr