Fondamentaux IA pour devs

1.0Objectifs de la session

• Expliquer comment un LLM produit du texte (tokens, probabilités, contexte)
• Écrire des prompts structurés qui donnent des résultats fiables
• Identifier une hallucination et savoir la contrer
• Choisir le bon outil (chat, assistant intégré, agent) selon la tâche

1.1Comment marche un LLM (version dev)

Un LLM est un moteur de complétion probabiliste : il prédit le token suivant le plus plausible compte tenu de tout ce qui précède. Pas de base de données de faits, pas de raisonnement symbolique garanti — une compression statistique gigantesque de texte.

Les concepts à retenir

• Token — unité de découpage (~¾ de mot en anglais, moins en français). Tout se paie et se mesure en tokens.
• Fenêtre de contexte— mémoire de travail du modèle. Tout ce qui n'y est pas n'existe pas pour lui. Elle est finie : un long historique dégrade la qualité.
• Température— dose d'aléatoire dans le choix des tokens. Basse = déterministe (code), haute = créatif.
• Poids figés— le modèle n'apprend rien de vos conversations. Sa connaissance s'arrête à sa date d'entraînement.

1.2Prompting efficace

Un bon prompt pour du code contient quatre ingrédients :

1. Rôle / contexte— stack, contraintes, style de l'équipe
2. Tâche précise — un verbe, un périmètre, un livrable
3. Exemples ou contre-exemples — le format attendu vaut mille explications
4. Critères de validation— comment on saura que c'est bon (tests, comportement attendu)

Mauvais :  « fais-moi une fonction de validation d'email »

Bon :      « TypeScript strict. Écris `validateEmail(input: string)` qui
           retourne un Result<Email, ValidationError> (types ci-dessous).
           Refuse les emails > 254 chars et les domaines sans point.
           Ajoute 5 cas de test vitest, dont 2 cas limites. »

1.3Hallucinations & limites

Une hallucination n'est pas un bug, c'est le fonctionnement normal du modèle appliqué à une zone où il manque de signal : il complète avec du plausible. APIs inventées, versions de libs mélangées, options de config imaginaires.

Réflexes de défense

• Tout code généré se vérifie — compile, teste, lit. Le modèle est un collègue brillant mais parfois sûr de lui à tort.
• Docs à jour dans le contexte — pour une lib récente, coller la doc ou utiliser un outil qui la récupère (MCP, recherche).
• Demander les sources d'incertitude— « signale ce dont tu n'es pas sûr » fonctionne étonnamment bien.
• Méfiance proportionnelle à la spécificité — numéros de version, noms de fonctions exacts, chiffres : zones à risque maximal.

1.4Panorama des outils

1.5TP de la session

Dossier exercices/session-1/ du repo. Au programme :

• TP1— Le même besoin, 4 prompts : mesurer l'impact de la structure
• TP2 — Chasse aux hallucinations : faire mentir le modèle, puis le corriger
• TP3 — Contexte minimal viable : quel est le plus petit contexte qui donne un bon résultat ?

1.6Checklist de fin de session

• Je sais expliquer tokens / contexte / température à un collègue
• J'ai écrit un prompt structuré (rôle, tâche, exemple, validation) qui a produit du code correct
• J'ai provoqué et identifié au moins une hallucination
• Je sais quel type d'outil choisir pour une tâche donnée
• Claude Code (ou équivalent) est installé et fonctionne sur ma machine

1.7Quiz de validation

1.8Défi inter-session