Coder avec l'IA

En quelques années, l'IA a transformé la façon de coder. Des assistants capables de compléter ton code, d'écrire des fonctions entières, d'expliquer une erreur ou de générer des tests sont désormais intégrés aux éditeurs. Pour un·e dev junior, c'est à la fois une opportunité formidable et un risque : bien utilisée, l'IA accélère énormément ; mal utilisée, elle produit du code qu'on ne comprend pas, truffé de bugs subtils, et freine l'apprentissage.

La bonne posture n'est ni le rejet (« l'IA, c'est de la triche ») ni la dépendance aveugle (« l'IA code à ma place »). C'est de considérer l'IA comme un outil, puissant mais faillible, qu'on apprend à manier avec discernement, comme on a appris à utiliser un débogueur ou un moteur de recherche. L'IA ne te dispense pas de comprendre : elle amplifie ce que tu sais déjà, et amplifie aussi tes erreurs si tu ne sais pas juger ce qu'elle produit.

Ce que l'IA change, ce qu'elle ne change pas

• Elle change : la vitesse d'écriture, l'exploration d'idées, l'apprentissage, la rédaction de code répétitif.
• Elle ne change pas : le besoin de comprendre le code, de le tester, d'en assumer la responsabilité.
• Elle déplace la valeur : moins vers « taper du code », plus vers « savoir quoi demander et juger le résultat ».

Les assistants de code reposent sur des modèles de langage (LLM, Large Language Model). Sans entrer dans la technique, retiens l'essentiel : un LLM a été entraîné sur d'immenses quantités de texte et de code, et il fonctionne en prédisant la suite la plus probable d'un texte, mot après mot (ou plutôt fragment après fragment). Quand tu lui demandes une fonction, il ne « comprend » pas comme un humain : il génère la continuation la plus plausible d'après ce qu'il a appris.

Cette mécanique explique à la fois sa puissance et ses défauts. Elle est puissante parce que des motifs de code corrects reviennent partout dans ses données d'entraînement. Mais comme il produit du plausible et non du vérifié, il peut générer avec le même aplomb du code juste et du code faux. Un LLM n'a pas de notion de vérité : il a une notion de vraisemblance. C'est la clé pour comprendre ses limites.

Les limites à toujours garder en tête

• Les hallucinations : il invente parfois des fonctions, des options ou des bibliothèques qui n'existent pas, de façon très convaincante.
• La date de connaissance : son savoir s'arrête à une date d'entraînement ; il ignore les nouveautés récentes.
• Le non-déterminisme : la même question peut donner des réponses différentes ; ce n'est pas une science exacte.
• L'absence de contexte : il ne connaît pas ton projet, tes contraintes, ta base de code, sauf ce que tu lui donnes.

La règle « garbage in, garbage out » (à question floue, réponse floue) s'applique pleinement à l'IA. Un prompt (la demande que tu formules) vague donne un résultat générique et souvent inadapté ; un prompt précis et contextualisé donne un résultat utilisable. Bien formuler ses demandes, ce n'est pas une astuce, c'est la compétence centrale pour tirer parti de l'IA.

❌ Vague :
"fais une fonction de validation"

✅ Précis et contextualisé :
"Écris une fonction TypeScript 'validerEmail(email: string): boolean'
qui vérifie qu'une chaîne est un email valide.
Contexte : projet React, je veux juste un contrôle simple côté client.
Renvoie true/false, sans dépendance externe. Ajoute 3 cas de test."

Compare les deux. Le prompt efficace donne le contexte (projet React), la signature attendue (nom, types, retour), les contraintes (pas de dépendance externe), et une attente précise (des cas de test). Résultat : une réponse directement utilisable, plutôt qu'un code générique à retravailler. Plus tu donnes d'informations pertinentes, meilleure est la réponse.

Les ingrédients d'un bon prompt

• Le contexte : langage, framework, contraintes du projet, ce que tu as déjà.
• L'objectif clair : ce que tu veux exactement, avec la forme attendue (une fonction, une explication, un tableau).
• Les contraintes : performance, style, dépendances autorisées ou non, niveau de détail.
• Des exemples si possible : une entrée et la sortie attendue valent mille explications.
• L'itération : rare qu'un prompt soit parfait du premier coup ; affine, corrige, précise.

Les assistants IA se déclinent en plusieurs formes, qu'il est utile de distinguer pour choisir le bon outil selon le besoin. Toutes reposent sur les mêmes modèles, mais s'intègrent différemment à ton travail.

• L'autocomplétion : l'IA propose la suite de ton code pendant que tu tapes (à la manière d'un GitHub Copilot). Idéale pour le code répétitif et prévisible.
• Le chat : tu dialogues avec l'assistant pour expliquer, générer, déboguer, apprendre. Idéal pour explorer et comprendre.
• Les agents : des assistants plus autonomes (comme Claude Code) qui peuvent lire ton projet, modifier plusieurs fichiers, lancer des commandes. Puissants, mais à superviser de près.

L'autocomplétion te fait gagner du temps sur le code évident, mais attention à ne pas accepter machinalement ses suggestions : relis chaque proposition. Le chat est parfait pour « explique-moi cette erreur » ou « comment ferais-tu ça ? ». Les agents peuvent réaliser des tâches complexes de bout en bout, mais plus un outil est autonome, plus ta vigilance doit être grande : tu restes responsable de tout ce qu'il produit et exécute.

Voici le chapitre le plus important du cours. Le code généré par une IA n'est pas un produit fini : c'est une proposition qu'il faut relire, comprendre et valider avant de l'intégrer. Traiter une sortie d'IA comme du code de confiance immédiate est l'erreur qui distingue l'usage amateur de l'usage professionnel. Tu es, et restes, responsable de chaque ligne que tu committes, qu'elle vienne de ta tête ou d'une IA.

La checklist avant d'accepter du code IA

• Je le comprends : je peux expliquer ce que fait chaque ligne. Si je ne comprends pas, je ne l'accepte pas.
• Je le teste : je l'exécute, y compris sur les cas limites (entrée vide, valeur négative, erreur réseau).
• Je vérifie les API utilisées : les fonctions et méthodes existent vraiment (chasse aux hallucinations).
• Je contrôle la sécurité : pas d'injection, pas de secret en dur, les entrées sont validées.
• Je juge la pertinence : est-ce la bonne solution pour mon contexte, ou une réponse générique ?

Le premier point est non négociable : ne committe jamais du code que tu ne comprends pas. Si l'IA produit quelque chose d'obscur, demande-lui de l'expliquer, ou simplifie jusqu'à comprendre. Un code que tu ne comprends pas est une dette : le jour où il bugue, tu seras incapable de le corriger, et tu ne pourras pas l'expliquer en entretien ou devant un jury.

Utiliser l'IA sans en connaître les risques, c'est prendre des dangers réels, parfois graves. Ces risques dépassent le simple bug : ils touchent à la sécurité, à la confidentialité et à la fiabilité. En tant que dev, tu dois les avoir en tête à chaque usage.

Le risque de confidentialité

Les autres risques à connaître

• Failles de sécurité : l'IA reproduit des motifs de code vulnérables vus dans ses données (injections, mauvaise gestion des entrées).
• Code obsolète : sa date de connaissance étant figée, elle propose parfois des méthodes dépréciées ou d'anciennes versions.
• Dépendances inventées : elle peut suggérer d'installer une bibliothèque qui n'existe pas, ou pire, une au nom proche exploitée par des attaquants.
• Uniformisation et biais : elle tend vers la solution la plus commune, pas forcément la meilleure pour ton cas.
• Questions de licence : le code généré peut ressembler à du code sous licence ; prudence sur l'origine et les droits.

Le risque de failles de sécurité mérite une attention particulière. L'IA a appris sur du code réel, y compris du code vulnérable : elle peut donc reproduire des failles classiques sans le signaler. Un code généré qui construit une requête à la base de données par concaténation, par exemple, peut ouvrir une injection SQL. La vigilance sécurité, que tu approfondis dans le cours OWASP, s'applique pleinement au code produit par l'IA.

Pour un·e dev junior, l'IA peut être un formidable accélérateur d'apprentissage, à condition de l'utiliser pour comprendre et non pour éviter de comprendre. C'est toute la nuance. Un même outil peut te faire progresser à vitesse grand V ou te maintenir dans une dépendance qui bloque ton évolution. La différence ne tient pas à l'outil, mais à la façon dont tu t'en sers.

Les bons usages pour apprendre

• « Explique-moi ce code » : décortiquer un bout de code que tu ne comprends pas, ligne par ligne.
• « Pourquoi cette erreur ? » : comprendre un message d'erreur et sa cause, plutôt que copier un correctif à l'aveugle.
• « Quelles approches pour ce problème ? » : explorer plusieurs solutions et leurs compromis.
• « Comment améliorer mon code ? » : obtenir un retour critique sur ce que tu as écrit toi-même.

Remarque le point commun : dans tous ces usages, tu restes actif·ve. Tu poses des questions pour comprendre, tu confrontes les réponses à ta réflexion, tu apprends quelque chose que tu sauras réutiliser. C'est l'opposé du « code-moi ça » suivi d'un copier-coller sans réfléchir, qui te laisse aussi ignorant·e qu'avant, avec en prime du code que tu ne maîtrises pas.

Utiliser l'IA de façon professionnelle, ce n'est pas seulement une question de technique : c'est aussi une question de responsabilité et d'éthique. Ces dimensions distinguent un·e dev mûr·e d'un·e simple utilisateur·ice d'outil, et elles sont de plus en plus scrutées par les employeurs et les jurys RNCP.

Le principe fondamental est simple : tu restes responsable. Quand tu intègres du code, peu importe qu'il vienne de toi ou d'une IA : c'est toi qui l'assumes, qui en réponds, qui devras le corriger. « C'est l'IA qui l'a écrit » n'est jamais une excuse valable pour un bug, une faille ou une donnée mal gérée. L'IA est un outil ; la responsabilité reste humaine.

Les réflexes d'une posture professionnelle

• Assume la responsabilité du code que tu livres, quelle qu'en soit l'origine.
• Protège les données : jamais de secrets, de données clients ou de code confidentiel dans un outil grand public.
• Sois transparent·e : selon le contexte et les règles de ton équipe, sur ton usage de l'IA.
• Garde ton esprit critique : l'IA propose, c'est toi qui décides, en connaissance de cause.
• Continue d'apprendre : l'IA t'aide à produire, mais ta valeur vient de ce que tu comprends vraiment.