N+1, absence de pagination, injection SQL : l'IA n'en a corrigé aucun

Le billet qui a mis un nom sur ce que tout le monde ressent

Le 28 septembre, un billet de DEV.to intitulé « Dear Coder: Open This If You're Feeling AI FOMO » défendait un argument modeste et peu à la mode : l'auteur ignore la plupart des tutoriels hebdomadaires sur MCP, les agents et le « loop engineering », et consacre plutôt son temps à deux questions : comment adopter l'IA sans perdre ses compétences existantes, et comment repérer les problèmes que l'IA apporte. Les preuves à l'appui étaient trois bugs, et non trois frameworks. De nombreuses bases de code, écrit l'auteur, souffrent encore de problèmes N+1, d'une absence de pagination et d'injections SQL. La plupart de ce code a été écrit avant l'engouement pour l'IA. « Imaginez maintenant le chaos au sein des bases de code produites en vibe coding. »

Quatre commentateurs ont abondé dans son sens, d'un enseignant universitaire espagnol qui enseigne la programmation depuis 1998 à un ingénieur front-end d'Accra et un développeur autodidacte de Virginie. Ce consensus est la partie intéressante, car ces quatre personnes ne sont pas du tout d'accord sur l'IA, seulement sur ce qui se passe en dessous.

Ce que sont réellement ces trois bugs

Ce ne sont pas des défaillances exotiques. Ce sont les bugs ennuyeux qui survivent à tous les cycles technologiques.

Un problème N+1 est un schéma d'accès à la base de données : votre code exécute une requête pour récupérer une liste de cent enregistrements, puis une requête supplémentaire par enregistrement pour en compléter les détails. Cent lignes deviennent cent un allers-retours vers la base de données. Cela fonctionne très bien sur l'ordinateur portable d'un développeur avec dix lignes de test, et s'effondre en production.

L'absence de pagination est le même échec de passage à l'échelle au niveau de la couche API : un point d'accès renvoie la table entière au lieu d'une page. Rapide avec mille lignes, fatal avec un million.

L'injection SQL est la plus ancienne des trois. Les saisies de l'utilisateur sont collées directement dans une requête de base de données au lieu d'être transmises comme paramètre, de sorte que quiconque saisit les bons caractères dans un champ de formulaire peut exécuter ses propres commandes sur vos données. C'est un problème résolu, au sens où la correction est bien connue et tient en une ligne, depuis plus longtemps que la plupart des développeurs en activité n'ont de carrière.

Pourquoi le code généré les reproduit au lieu de les supprimer

Le commentateur de l'Université de Vigo a décrit le mécanisme sans détour : si l'IA mélange tout ce que chacun a écrit par le passé, le résultat ne peut être que brouillon tant que les sources d'entraînement ne sont pas triées. Les modèles apprennent à partir du corpus existant, et ce corpus est le même ensemble de code qui contient toutes les requêtes non paramétrées et tous les points d'accès non paginés jamais livrés. Rien dans l'étape de génération ne distingue le schéma courant du schéma correct.

La seconde moitié du mécanisme est le débit. Comme l'a dit Mika Flowers dans les commentaires, l'IA peut générer une implémentation incroyablement vite, mais un humain doit encore comprendre l'architecture, reconnaître quand quelque chose ne va pas, tester, déboguer, et décider si la solution a même un sens. La génération est devenue plus rapide. La relecture, non. Le « vibe coding » désigne ce qui se passe quand la seconde étape est sautée : du code accepté parce qu'il s'exécute, et non parce que quelqu'un l'a lu.

C'est pourquoi les commentateurs convergent vers la même posture à partir de directions différentes. Blaise Akpalu soutient que les fondamentaux comptent davantage quand l'IA est dans la boucle, précisément parce qu'il faut évaluer et vérifier ce qu'elle produit, tout en poussant pour un flux de travail agentique où le modèle se charge de l'exécution et où le développeur garde l'architecture, le contexte et la vérification. L'ordre du billet d'origine est plus direct : construire de vraies compétences d'abord, puis tirer parti de l'IA, dans cet ordre.

Les questions à vous poser

• À propos de votre propre équipe : quand du code généré est fusionné, qui l'a lu ligne par ligne, et cette personne peut-elle nommer le mode de défaillance qu'il rencontrerait avec une charge dix fois supérieure à l'actuelle ?
• À propos de tout fournisseur qui vend un agent : que fait l'outil face à ces trois bugs ennuyeux ? Les détecte-t-il, ou se contente-t-il de produire du code qui s'exécute ?
• À propos de votre processus de recrutement : si les fondamentaux comptent davantage aujourd'hui, qu'est-ce qui, dans vos entretiens, les teste réellement plutôt que de tester l'aisance à rédiger des prompts ?
• À propos de la FOMO elle-même : lequel des acronymes de ce mois a changé une décision que vous avez prise, et lesquels avez-vous lus puis jamais utilisés ?
• À propos de votre base de code : savez-vous combien de points d'accès non paginés vous livrez actuellement, ou le devinez-vous ?

Ce qu'il faut surveiller ensuite

Surveillez si la capacité de relecture devient ce que les équipes mesurent. L'argument de ce billet ne tient que si le code généré non relu produit des incidents à un rythme que l'on remarque. Le signal sera la première panne ou la première faille largement médiatisée, imputée non pas à une défaillance inédite de l'IA, mais à une requête N+1 ou à une chaîne SQL concaténée que personne n'avait lue avant la fusion. D'ici là, « choisissez vos batailles » reste le conseil le moins coûteux qui soit.