Module 00 — Les bases de l'IA pour développeurs Gratuit

0.1 — C'est quoi un LLM ?

Un Large Language Model (LLM) est un réseau de neurones entraîné sur des quantités massives de texte pour accomplir une tâche fondamentale : prédire le prochain token. Quand tu tapes "La capitale de la France est", le modèle calcule une distribution de probabilités et détermine que "Paris" est le token le plus probable. Il n'y a pas de base de données interne, pas de moteur de recherche caché, juste de la prédiction statistique à grande échelle.

L'analogie de l'autocomplétion

L'autocomplétion de ton IDE analyse le contexte local (imports, types, variables en scope) pour proposer le token suivant. Un LLM fait la même chose, mais son "scope" couvre l'ensemble des connaissances absorbées pendant l'entraînement : documentation, code open source, livres, articles. Même principe, échelle radicalement différente.

Entraînement en 3 phases

L'entraînement se décompose en étapes distinctes :

1. Pré-entraînement, Le modèle ingère des téraoctets de texte (code, Wikipedia, livres, forums) pour apprendre les patterns statistiques du langage. Cette phase coûte des dizaines de millions de dollars en calcul GPU.

2. Fine-tuning, Le modèle est affiné sur des données plus spécifiques et de meilleure qualité.

3. RLHF (Reinforcement Learning from Human Feedback), Des humains évaluent les réponses du modèle, qui apprend à produire des résultats utiles et pertinents. C'est cette phase qui transforme un prédicteur de texte brut en assistant conversationnel.

Le mécanisme technique central est l'attention (architecture Transformer, Google, 2017). Il permet au modèle de "regarder" simultanément toutes les parties du texte d'entrée. Si tu écris une fonction de 200 lignes et que le type de retour est défini à la ligne 3, l'attention permet au modèle de connecter cette information à la ligne 200.

0.2 — Les tokens : l'unité de base

Un token n'est pas un mot. C'est un fragment de texte, parfois un mot entier (function), parfois un bout de mot (dés + ér + ial + isation), parfois un seul caractère (une accolade, un retour à la ligne). Le processus de découpage s'appelle la tokenization, réalisé par un algorithme (tokenizer) spécifique à chaque famille de modèles. Confondre tokens et mots est une erreur qui coûte cher, littéralement.

Pourquoi les tokens comptent pour un développeur

Trois raisons directes :

• Coût, Tu payes à l'usage en tokens, pas en mots ni en caractères. Chaque token envoyé (input) et généré (output) est facturé.
• Fenêtre de contexte, Si ton modèle a une fenêtre de 200 000 tokens, c'est la limite de ce qu'il peut "voir" simultanément, pas 200 000 mots.
• Le code est gourmand, Accolades, parenthèses, indentation, noms de variables longs : un fichier de 100 lignes de code représente facilement 500 à 800 tokens.

Compter ses tokens

Règle approximative : 1 token ≈ 4 caractères en anglais ≈ 3/4 d'un mot. Le français consomme 20-30 % de tokens en plus que l'anglais.

Le tokenizer d'OpenAI est disponible en ligne (platform.openai.com/tokenizer). Prendre l'habitude de vérifier le nombre de tokens de tes prompts et fichiers de contexte est le premier pas vers une utilisation efficiente des LLM.

0.3 — La fenêtre de contexte

La fenêtre de contexte est la quantité maximale de tokens qu'un LLM peut traiter en une seule interaction. C'est sa mémoire de travail. Tout ce que le modèle "sait" de ta conversation, de ton code, de tes instructions doit tenir dans cette fenêtre. Si tu dépasses la limite, les informations les plus anciennes sont tronquées ou ignorées.

Ce qui occupe la fenêtre

La fenêtre ne contient pas uniquement ton prompt. Elle inclut tout :

Quand tu utilises Claude Code et qu'il lit 15 fichiers de ton projet, ces 15 fichiers occupent de l'espace. Si ta conversation dure depuis 30 échanges, tout cet historique est là aussi. Un projet avec ses fichiers de configuration, ses modules, ses tests, quelques dizaines de fichiers suffisent à saturer la fenêtre.

Le phénomène "lost in the middle"

Les LLM accordent plus d'attention aux informations en début et en fin de contexte, et tendent à "oublier" ce qui se trouve au milieu. Si tu colles 50 fichiers et que l'information critique est dans le 25ème, le modèle risque de la manquer. La sélection et l'ordre du contexte sont aussi importants que le contenu du prompt.

Tailles de fenêtre courantes (2026) :

• Claude Opus 4 / Sonnet 4 : 200K tokens (standard), 1M tokens (étendu)
• GPT-4 Turbo : 128K tokens
• Gemini : jusqu'à 1M tokens

0.4 — Prompt vs Contexte

La plupart des développeurs déçus par l'IA font la même erreur : ils se concentrent sur le prompt (la question posée) et négligent le contexte (l'ensemble des informations qui accompagnent cette question). Dans la pratique, le contexte est responsable de la majorité de la qualité des réponses. Un prompt simple dans un contexte riche bat un prompt sophistiqué dans un contexte pauvre.

Les couches de contexte

Le contexte d'un LLM fonctionne en couches, de la plus profonde à la plus superficielle :

1. System prompt, Instructions de base qui définissent le comportement du modèle

2. Contexte persistant, Fichiers de configuration comme CLAUDE.md, règles du projet, conventions

3. Contexte de session, Fichiers lus, résultats de recherche, historique de conversation

4. Prompt utilisateur, Ta question ou instruction

Chaque couche influence la réponse, mais les couches profondes ont plus d'impact que le prompt de surface. Un fichier CLAUDE.md bien rédigé améliore toutes tes interactions futures, pas juste la prochaine.

L'analogie du consultant

Le prompt, c'est la question que tu poses à un consultant. Le contexte, c'est le brief envoyé avant la réunion : documentation du projet, code existant, contraintes techniques, historique des décisions. Sans brief, tu obtiens une réponse générique. Avec un brief complet, la même question produit une réponse spécifique et actionnable.

0.5 — Temperature, top-p et paramètres de génération

Quand un LLM génère le prochain token, il calcule une distribution de probabilités sur l'ensemble de son vocabulaire. Les paramètres de génération contrôlent comment le modèle choisit parmi ces candidats. La plupart des développeurs utilisent les valeurs par défaut sans comprendre ce qu'ils laissent sur la table.

Temperature

La temperature contrôle le niveau d'aléatoire dans la sélection du token :

Autres paramètres

• top-p (nucleus sampling), Tronque les options. Un top-p de 0.9 ne considère que les tokens dont les probabilités cumulées atteignent 90 %. Élimine les tokens improbables tout en conservant de la diversité.
• max_tokens, Longueur maximale de la réponse. Trop bas = réponse tronquée en plein milieu d'un bloc de code.
• top-k, Limite le choix aux k tokens les plus probables.
• frequency_penalty, Pénalise les tokens déjà utilisés pour éviter les répétitions.

En pratique, avec Claude Code en mode agentique, ces paramètres sont gérés automatiquement. Mais quand tu utilises l'API directement ou configures un outil comme Cursor, comprendre ces paramètres fait la différence.

0.6 — Les limites des LLM

Comprendre les limites d'un outil, c'est ce qui sépare le développeur qui l'utilise efficacement de celui qui est déçu en permanence. Un LLM n'est pas un oracle. C'est un outil avec des angles morts prévisibles, et les connaître te permet de les contourner.

Hallucinations

Un LLM peut générer des informations fausses avec une confiance absolue : inventer une API inexistante, citer des paramètres fictifs d'une vraie bibliothèque, produire du code qui utilise des fonctions imaginaires. Le modèle ne "vérifie" rien, il génère du texte statistiquement probable. Le risque augmente sur les sujets peu présents dans les données d'entraînement : bibliothèques récentes, API internes, code propriétaire.

Raisonnement limité

Les LLM excellent en pattern matching mais peinent face au raisonnement multi-étapes complexe. Tracer l'exécution d'un algorithme récursif sur 15 niveaux de profondeur dépasse leurs capacités de prédiction statistique. Ce n'est pas du raisonnement formel, c'est de la reconnaissance de patterns.

Autres limites structurelles

• Pas de mémoire persistante, Chaque conversation repart de zéro (sauf mécanismes de persistance comme CLAUDE.md)
• Date de coupure, Le modèle ne connaît pas les événements postérieurs à son entraînement
• Biais des données, Sur-représentation de certains langages (Python, JavaScript), frameworks (React, Spring), approches architecturales
• Pas d'exécution, Ne peut pas tester, compiler ou vérifier son propre output. C'est pour ça que les outils agentiques comme Claude Code sont puissants : ils comblent cette lacune

0.7 — L'écosystème des outils IA pour devs

Le marché des outils IA pour développeurs évolue chaque semaine. GitHub Copilot, Cursor, Claude Code, Windsurf, Codeium, Amazon Q Developer, la profusion est réelle. Comprendre les différences fondamentales entre ces outils te permet de choisir celui qui correspond à ton workflow.

Trois types d'intégration

Trois paradigmes d'interaction

1. Inline completion (Copilot, Tabnine, Codeium), Prédit la suite de ton code pendant que tu tapes. Autocomplétion avancée, niveau ligne ou bloc.

2. Chat intégré (Copilot Chat, Cursor Chat), Questions et demandes de modification dans une fenêtre de chat à côté du code.

3. Agentique (Claude Code, Cursor Composer, Windsurf Cascade), Actions autonomes : lire des fichiers, exécuter des commandes, modifier du code, lancer des tests, itérer.

Modèle sous-jacent vs outil

Un point souvent confondu : l'outil et le modèle sont deux choix distincts. Cursor peut utiliser GPT-4 ou Claude. Copilot utilise des modèles OpenAI. Claude Code utilise exclusivement les modèles Claude. La qualité de l'intégration, quel contexte l'outil envoie, comment il gère les erreurs, comment il orchestre les actions, compte souvent plus que le modèle brut.

0.8 — Inline completion vs Agent

L'inline completion et le mode agentique sont deux paradigmes fondamentalement différents. Cette distinction détermine le type de tâches que tu peux déléguer, le niveau d'autonomie accordé à l'IA, et le multiplicateur de productivité que tu peux espérer.

Inline completion

Tu tapes du code, l'IA suggère la suite en temps réel. Tu acceptes (Tab) ou tu refuses. Le contrôle est total : tu restes le pilote. Le gain est linéaire, entre 10 et 30 % de code tapé en moins. L'IA travaille au niveau de la ligne ou du bloc, jamais au niveau du projet.

Mode agentique

Tu décris une intention de haut niveau :

Implémente un repository pour les offres retail
en suivant le même pattern que le repository existant
pour les partenariats.

L'agent explore ta codebase, crée les fichiers nécessaires, écrit le code, lance les tests, corrige les erreurs, et itère. Tu n'es plus le pilote, tu es le commanditaire. Des tâches de 2 heures se font en 10 minutes.

Le changement de posture

Plus l'IA a d'autonomie, plus les erreurs peuvent être coûteuses. Un agent qui modifié 15 fichiers sur une mauvaise compréhension de ton architecture crée un désastre en 30 secondes. C'est pour ça que la configuration (garde-fous, conventions, fichiers de contexte) est cruciale en mode agentique.

0.9 — Le concept de Harness Engineering

Le terme vient de l'anglais "harness", le harnais. Un LLM en mode agentique est un cheval de trait puissant. Sans harnais, cette puissance est incontrôlable. Avec un harnais bien ajusté, elle devient une force de traction précise et dirigée. Le Harness Engineering, c'est l'art de concevoir et d'ajuster ce harnais.

Le concept est décrit en détail par Martin Fowler.

Configuration > prompts individuels

Le Harness Engineering repose sur une conviction : le temps passé à configurer l'environnement de travail de l'IA a un retour sur investissement supérieur au temps passé à peaufiner des prompts. Un prompt, c'est un usage unique. Une configuration, c'est un multiplicateur, elle améliore toutes les interactions futures. Rédiger un fichier CLAUDE.md complet prend 30 minutes, mais il améliore des milliers d'interactions sur la durée d'un projet.

Les composants du harnais

Le harnais se compose de 4 éléments :

• Fichiers de configuration (CLAUDE.md, .cursorrules) : contexte persistant, architecture, conventions, patterns
• Hooks et garde-fous : linting, tests, compilation après chaque modification de l'agent
• Templates et exemples : fichiers de référence pour reproduire le bon pattern
• Règles de scope : ce que l'agent peut et ne peut pas modifier

Prompt Engineering vs Harness Engineering

Le Prompt Engineering optimise des interactions individuelles, c'est tactique. Le Harness Engineering optimise l'environnement de travail, c'est stratégique. Un bon Prompt Engineer obtient de bonnes réponses. Un bon Harness Engineer obtient de bonnes réponses par défaut, sans effort supplémentaire à chaque interaction.

0.10 — Le coût de l'IA

L'IA pour développeurs n'est pas gratuite. Si tu ne comprends pas comment le pricing fonctionne, tu risques de sous-utiliser l'outil par peur du coût ou de recevoir une facture désagréable en fin de mois. Ce sous-module démystifie le modèle économique.

Pricing par token

Le pricing repose sur deux métriques : tokens d'entrée (input) et tokens de sortie (output). Les tokens de sortie coûtent significativement plus cher.

Le ratio output/input est d'environ 5x. Un bon contexte (input) qui permet une réponse concise (output) est plus économique qu'un contexte maigre qui force de longues explications.

Coût réel en pratique

Avec Claude Code, chaque interaction consomme des tokens : fichiers lus, recherches dans la codebase, résultats de commandes analysés. Une session intensive de développement agentique sur un gros projet consomme entre 5 et 20 dollars par jour. À mettre en perspective : si cette session te fait gagner 4 heures à 80 €/h, le ROI est de 20 pour 1.

Stratégies d'optimisation

1. Bon modèle pour la tâche, Sonnet pour le quotidien, Opus pour le complexe

2. Conversations courtes, Une nouvelle conversation est plus efficace qu'une longue conversation dont l'historique coûte de plus en plus cher

3. Bon contexte persistant, Un CLAUDE.md bien rédigé évite de réexpliquer le contexte à chaque session

4. Forfait si gros usage, Claude Max (100 ou 200 $/mois) peut être plus économique que le paiement à l'usage

0.11 — Sécurité et confidentialité

Quand tu utilises un LLM, ton code quitte ta machine. C'est le fonctionnement normal, pas un bug. Comprendre exactement ce qui est envoyé, où, et comment c'est traité n'est pas de la paranoïa, c'est de la responsabilité professionnelle.

Ce qui est transmis

Avec Claude Code, chaque interaction envoie des données aux serveurs d'Anthropic via l'API : ton prompt, les fichiers que l'agent lit, les résultats des commandes exécutées, l'historique de conversation. Anthropic s'engage contractuellement (politique API) à ne pas utiliser ces données pour entraîner ses modèles. Mais la transmission elle-même est un vecteur de risque.

Les trois risques concrets

1. Secrets envoyés accidentellement, Un fichier .env avec des clés AWS, un token OAuth hardcodé, un mot de passe de base de données. Si l'agent les lit, ils sont transmis.

2. Données personnelles, Des fixtures de test avec de vrais emails, noms, adresses : violation RGPD potentielle.

3. Propriété intellectuelle, Code propriétaire, algorithmes métier, logique business envoyés à un service tiers.

Bonnes pratiques

Exemple de fichier .claudeignore pour empêcher l'agent de lire les fichiers sensibles :

.env
.env.*
credentials/
secrets/
**/fixtures/production/

Règles de base :

• Jamais de secrets dans le code, utiliser des variables d'environnement + gestionnaire de secrets
• Fixtures de test anonymisées
• Vérifier régulièrement les logs de session

Au niveau organisationnel : définis une politique claire sur l'utilisation des outils IA avant que les problèmes n'arrivent. Pour les cas sensibles, des options existent : déploiement VPC chez Anthropic, proxy de filtrage, ou modèles locaux (LLaMA, Mistral).

0.12 — Choisir son modèle

Tous les modèles ne se valent pas, et le plus capable n'est pas toujours le meilleur choix. Chez Anthropic, la gamme Claude se décline en trois tiers : Opus (le plus capable), Sonnet (l'équilibré), et Haiku (le plus rapide). Choisir le bon modèle pour la bonne tâche est l'une des optimisations les plus simples et les plus impactantes.

La gamme Claude

Quand utiliser quoi

• Opus : bug subtil impliquant 10 modules, refacto architecturale, décision de conception avec compromis complexes
• Sonnet : génération de code standard, écriture de tests, refactoring de taille moyenne, revue de code
• Haiku : formatage, boilerplate, transformations syntaxiques, pipelines automatisés à haut volume

Claude Code supporte la sélection de modèle en cours de session :

/model sonnet        # Modèle par défaut recommandé
/model opus          # Pour les tâches complexes
/model opus[1m]      # Opus avec fenêtre étendue à 1M tokens
/model sonnet[1m]    # Sonnet avec fenêtre étendue à 1M tokens

Au-delà d'Anthropic : GPT-4o (OpenAI), Gemini (Google, fenêtre jusqu'à 1M tokens), LLaMA et Mistral (open source, déployables localement). Le choix dépend de tes contraintes de coût, confidentialité, performance et intégration.

Le niveau d'effort

Au-delà du choix de modèle, Claude Code permet de contrôler le niveau d'effort que le modèle investit dans chaque réponse via la commande /effort. Trois niveaux sont disponibles :

/effort high    # Analyse approfondie
/effort medium  # Équilibre (défaut)
/effort low     # Réponses rapides et économiques

Point important : Anthropic a abaissé le niveau d'effort par défaut de high à medium. En pratique, medium suffit pour la majorité des tâches de développement. Réserver high aux moments où tu as besoin d'une réflexion approfondie permet d'économiser des tokens et d'obtenir des réponses plus rapides au quotidien.