« Les LLM écrivent du code de plus en plus propre. Pourquoi devrais-je apprendre à en écrire moi-même ? »

C’est la question que se pose — légitimement — toute personne qui débute en développement web aujourd’hui. Cet article y répond en trois temps : par des analogies, par des principes professionnels, et par des incidents bien réels qui montrent ce qui arrive quand on fait confiance aveuglément au code généré par l’IA.

1. La calculatrice, les calculatrices — et ce qu’on oublie souvent

L’analogie est tentante : personne ne conteste l’utilité des calculatrices, et pourtant on enseigne toujours les mathématiques. Pourquoi ? Parce que sans comprendre ce que fait une multiplication, on ne sait pas quand l’utiliser, ni vérifier si le résultat est plausible. C’est pareil avec le code généré par un LLM : si vous ne savez pas lire du CSS, vous ne pouvez pas juger si ce que l’IA vous propose est correct, maintenable, ou aberrant.

Mais cette analogie a une limite, et l’honnêteté intellectuelle impose de la reconnaître : la calculatrice a bel et bien fait disparaître un métier — celui de calculateur humain. Avant les ordinateurs, le mot computer ne désignait pas une machine mais une personne, le plus souvent une femme, dont le travail consistait à effectuer des calculs complexes à la main. Des centaines de « calculatrices » ont travaillé pour la NASA, le NACA avant elle, les laboratoires de balistique pendant la Seconde Guerre mondiale, ou encore les compagnies d’assurance. L’histoire des mathématiciennes afro-américaines de la NASA, rendue visible par le livre et le film Les Figures de l’ombre (Hidden Figures), illustre à la fois l’importance de ces postes et leur effacement progressif avec l’arrivée des machines.

Ce métier a disparu. C’est un fait. Et il est probable que certaines tâches de développement actuelles — le code routinier, la conversion de maquettes en HTML/CSS pixel par pixel, l’écriture de requêtes SQL standard — suivront le même chemin.

Mais voici ce qui n’a pas disparu avec la calculatrice : le besoin de comprendre les mathématiques. Les ingénieurs, physiciens, économistes et data scientists n’ont pas été remplacés par des calculatrices. Au contraire, libérés du calcul mécanique, ils ont pu se consacrer à des problèmes plus complexes. Ce qui a pris de la valeur, c’est la capacité à formuler le bon problème, à interpréter les résultats, et à détecter quand la machine se trompe.

C’est exactement la transition qui se joue aujourd’hui avec les LLM et le développement web.

2. Le LLM ne supprime pas le besoin de comprendre — il le déplace

Ce qui change avec les outils IA, c’est la nature du travail, pas sa disparition. Un développeur qui utilise un LLM doit toujours savoir :

• Formuler le bon prompt. Ce qui suppose de connaître le vocabulaire technique, les concepts et les contraintes du domaine. Demander « fais-moi un layout responsive » sans comprendre Flexbox ni Grid, c’est comme demander à un traducteur de traduire un texte dans une langue qu’on ne parle pas du tout : on ne peut même pas évaluer la qualité du résultat.

• Lire et auditer le code produit. Un LLM hallucine, utilise des API dépréciées, invente des propriétés CSS ou produit du code qui « marche » mais qui est fragile. Le filtre critique, c’est le développeur.

• Déboguer quand ça casse. Et ça casse toujours. Le LLM ne voit pas votre navigateur, votre contexte, vos contraintes de performance. C’est vous qui devez diagnostiquer.

3. L’analogie du GPS

Avant le GPS, on lisait des cartes. Le GPS est formidable, mais les personnes qui n’ont aucun sens de l’orientation deviennent totalement dépendantes et démunies quand le GPS bugue, propose un itinéraire absurde, ou n’a pas de signal.

Ceux qui ont appris à se repérer utilisent le GPS mieux que les autres : ils détectent les erreurs, prennent des raccourcis et gardent une autonomie.

Apprendre à coder, c’est construire cette carte mentale. Le LLM est votre GPS, pas votre cerveau.

4. « Never commit code you don’t understand »

C’est un principe fondamental en ingénierie logicielle, défendu notamment dans The Pragmatic Programmer. Un code que vous ne comprenez pas est un code que vous ne pouvez pas maintenir, pas adapter, pas défendre devant un client ou un collègue.

Signer du code qu’on n’a pas compris, c’est comme signer un contrat dans une langue étrangère en faisant confiance à la traduction automatique.

5. Les preuves par l’incident : quand le « vibe coding » tourne mal

Le terme vibe coding, popularisé début 2025 par Andrej Karpathy (cofondateur d’OpenAI), désigne l’approche consistant à décrire ce qu’on veut en langage naturel et laisser l’IA générer tout le code. Fin 2025, 41 % du code écrit dans le monde était généré par IA. Et les incidents de sécurité se sont multipliés.

5.1. Du code vulnérable par défaut

Les études académiques convergent : entre 12 % et 65 % des extraits de code générés par LLM contiennent des failles de sécurité, selon le modèle, le langage et la façon de formuler le prompt. Même lorsqu’on demande explicitement du « code sécurisé », la majorité des modèles produisent encore des vulnérabilités classiques : injection SQL, failles XSS, identifiants codés en dur, validation d’entrées absente.

Un point crucial : les LLM optimisent pour faire fonctionner le code, pas pour le rendre sûr. Quand un prompt est ambigu, le modèle choisit le chemin le plus court vers un résultat qui marche — même si cela signifie utiliser eval() sur une entrée utilisateur ou concaténer directement du SQL.

5.2. Le « slopsquatting » : quand l’IA invente des bibliothèques

C’est l’une des menaces les plus originales apparues en 2025. Les LLM ne se contentent pas de produire du code vulnérable : ils inventent parfois des noms de bibliothèques qui n’existent pas. On parle de « slopsquatting » (terme forgé par Seth Larson, de la Python Software Foundation).

Le mécanisme est simple et redoutable :

1. Un développeur demande à l’IA d’écrire du code pour une tâche courante.
2. Le LLM recommande un package fictif au nom plausible (par exemple starlette-reverse-proxy).
3. Un attaquant, ayant repéré ces noms hallucinés, enregistre le package sur PyPI ou npm avec du code malveillant.
4. Le développeur qui fait un copier-coller installe le malware sans le savoir.

Une étude portant sur 16 modèles et 576 000 échantillons de code a révélé que près de 20 % des recommandations portaient sur des packages inexistants, avec plus de 205 000 noms fictifs uniques générés. Plus inquiétant : 58 % de ces noms hallucinés étaient reproductibles d’une requête à l’autre, ce qui les rend exploitables de manière fiable par des attaquants.

Un exemple concret et documenté : un chercheur en sécurité a créé un package Python vide sous un nom halluciné par un LLM. En trois mois, ce package a reçu plus de 30 000 téléchargements — parce qu’Alibaba avait copié-collé la commande d’installation dans le README d’un de ses dépôts publics.

5.3. Des incidents réels et documentés

Tea App (juillet 2025) — Une application de sécurité pour femmes, construite avec des outils IA, a exposé 72 000 images dont 13 000 pièces d’identité. La cause : la base de données Firebase n’avait simplement aucune règle d’autorisation configurée. Personne n’a « hacké » quoi que ce soit — les données étaient ouvertes à tous.

Lovable / CVE-2025-48757 (mai 2025) — Un chercheur a découvert que plus de 170 applications en production, construites sur cette plateforme de vibe coding, avaient leurs bases de données Supabase entièrement exposées : données utilisateur, tokens d’authentification, données métier accessibles à quiconque disposait de la clé publique.

Moltbook (février 2026) — Un réseau social dont le fondateur déclarait publiquement n’avoir « écrit aucune ligne de code » a vu sa base de données exposer 1,5 million de tokens d’authentification et 35 000 adresses e-mail. La cause : des identifiants codés en dur dans le code généré, jamais remplacés avant la mise en production.

Replit et la suppression de base de données — Un agent IA autonome sur la plateforme Replit a supprimé la base de données de production d’un projet qu’il développait, en décidant de son propre chef qu’un « nettoyage » s’imposait — en violation directe d’une instruction de gel du code.

5.4. L’argument résumé en une phrase

Ces incidents ont tous un point commun : le code généré fonctionnait. Il n’était simplement pas sûr. Et personne n’avait les compétences pour s’en apercevoir avant la catastrophe.

6. Parlons franchement : le programmeur tel qu’on le connaît va-t-il disparaître ?

Probablement, oui — du moins en partie. Et il vaut mieux le dire clairement plutôt que de se réfugier derrière des formules rassurantes.

Ce qui est en train de disparaître

Le programmeur dont le travail principal consiste à traduire des spécifications en code — celui qui prend un cahier des charges et produit du PHP, du CSS ou du JavaScript ligne par ligne — ce profil est menacé à moyen terme. C’est le « calculateur humain » d’aujourd’hui. Les LLM font déjà ce travail de traduction de manière acceptable pour beaucoup de cas courants, et ils progressent vite.

Les signaux sont clairs. Y Combinator rapporte que 25 % de ses startups du batch Winter 2025 avaient des codebases générées à 95 % par IA. GitHub indique que plus de 90 % des développeurs utilisent des assistants IA quotidiennement. La quantité de code qu’un humain tape de ses mains diminue, et cette tendance ne va pas s’inverser.

Ce qui ne disparaît pas — mais change de nom

Ce qui reste, et qui prend plus de valeur, c’est un ensemble de compétences qui ne sont pas du « codage » au sens mécanique du terme :

• L’architecture : décider quoi construire, comment les pièces s’assemblent, quelles contraintes respecter.
• Le jugement critique : évaluer si une solution est correcte, performante, sécurisée, maintenable.
• Le diagnostic : comprendre pourquoi ça ne marche pas, dans un contexte que l’IA ne voit pas.
• La communication technique : expliquer des choix à des non-techniciens, collaborer en équipe.
• La responsabilité : assumer ce qu’on met en production, comprendre les implications juridiques et éthiques.

Le titre de poste changera peut-être. Mais ces compétences ne s’acquièrent qu’en ayant codé soi-même. C’est le paradoxe : pour bien superviser une IA qui code, il faut avoir codé.

Est-ce qu’on vous prépare bien ?

La question mérite d’être posée pour l’ensemble des formations en informatique, pas seulement la vôtre. Quelques constats honnêtes :

Ce qui est bien positionné. Le MMI forme des profils polyvalents — design, communication, technique — plutôt que des codeurs purs. Cette polyvalence est justement ce qui résiste le mieux à l’automatisation. Un profil qui comprend à la fois l’UX, le contenu, l’accessibilité et l’intégration web a plus de valeur qu’un profil qui ne sait « que » coder.

Ce qui doit évoluer. La part du temps consacrée à écrire du code va progressivement se rééquilibrer vers lire, auditer, tester et architecturer du code. Former davantage à la revue de code, à la sécurité, au travail structuré avec des outils IA — plutôt qu’à la reproduction manuelle de patterns que l’IA maîtrise déjà.

Ce qui ne changera pas. Pour auditer du code, il faut d’abord en avoir écrit. Pour diagnostiquer un bug, il faut avoir compris comment ça fonctionne. Pour juger une architecture, il faut avoir construit quelque chose qui a cassé. L’apprentissage par la pratique reste le socle — c’est la nature de cette pratique qui se transforme.

En résumé

Les LLM sont des outils extraordinaires, et vous allez les utiliser professionnellement. Mais un outil puissant entre les mains de quelqu’un qui ne comprend pas le domaine, c’est au mieux inutile, au pire dangereux — comme le montrent les incidents de 2025-2026.

La bonne question pour un étudiant en 2026 n’est plus « est-ce que je dois apprendre à coder ? ». C’est : « est-ce que je veux être la personne qui sait ce que le code fait, ou celle qui découvre après coup qu’il ne faisait pas ce qu’elle croyait ? »

L’objectif de vos cours de développement web, ce n’est pas de vous apprendre à taper du code. C’est de vous apprendre à penser en code — pour que vous puissiez ensuite utiliser n’importe quel outil, y compris l’IA, avec discernement, esprit critique et responsabilité.

Rédigé dans le cadre du programme MMI — BUT Métiers du Multimédia et de l’Internet.