Développement IA

RAG, recherche sémantique et recommandations reposent tous sur un travailleur de l'ombre : l'embedding (vecteur). Un embedding, c'est le sens d'un texte (ou d'une image) converti en une suite de nombres — un vecteur. Le mot « chien » devient une liste de centaines à milliers de nombres qui jouent le rôle de « coordonnées du sens » : ainsi les mots proches par le sens se retrouvent voisins (« chien » et « chiot » sont proches ; « chien » et « voiture » sont éloignés), et la proximité se quantifie par des mesures comme la similarité cosinus. Exemple célèbre : « roi − homme + femme ≈ reine ». Grâce à cela, une machine peut juger si le sens est proche même quand les caractères ne correspondent pas. Ce guide pour débutants couvre ce qu'est un embedding (une « carte du sens »), pourquoi la proximité mesure le sens (dimensions et similarité cosinus), à quoi il sert (RAG, recherche sémantique, classification et déduplication, recommandations, multimodal), comment choisir un modèle d'embedding (type API comme OpenAI text-embedding-3, Cohere, Gemini, Voyage ; open source comme BGE-M3, Nomic, Qwen3 ; sans oublier Matryoshka, qui peut ramener 3 072 dimensions à 1 024 en conservant environ 95 % de la qualité pour environ un tiers du coût), et les bases vectorielles (Pinecone, Weaviate, Qdrant, Chroma, pgvector) avec un démarrage en trois étapes (choisir un modèle, vectoriser et stocker les documents, vectoriser la question et rechercher). Les embeddings sont le socle de la mise en œuvre du RAG.

Vous avez peaufiné vos prompts, ajouté des connaissances avec le RAG, peut-être fait du fine-tuning — alors comment confirmer que cela s'est vraiment amélioré ? Les AI evals entrent en scène, et d'ici 2026 l'évaluation est si essentielle qu'on la qualifie d'« infrastructure ». Les AI evals consistent à mesurer systématiquement la qualité des sorties d'un LLM (exactitude, hallucinations, respect du format, ton) selon un étalon fixe plutôt qu'à l'instinct ; sans elles, l'amélioration n'est qu'une intuition. Il existe deux méthodes : l'évaluation par code pour les éléments mesurables mécaniquement (correspondance exacte, format, mots requis/interdits — rapide, peu coûteux, stable) et le LLM-as-judge pour les subjectifs (utiliser un LLM puissant comme arbitre pour noter les sorties, via comparaison pairwise ou notation d'une seule sortie). Le principe : mesurez avec du code tout ce que le code peut mesurer. Le LLM-as-judge présente des biais de verbosité, de position et de préférence pour soi ; les correctifs sont d'utiliser une famille de modèle différente comme correcteur, d'inverser l'ordre et de noter deux fois, d'inscrire la concision dans la grille, et de calibrer par rapport au jugement humain. Les échelles grossières (pass/fail ou 1–3) battent la notation fine de 1–10. En pratique, faites tourner trois niveaux — vérifications par code instantanées à chaque changement, tests de régression nocturnes par LLM-as-judge, et surveillance continue en production — avec des outils comme DeepEval, Promptfoo et RAGAS pour la CI, plus Braintrust, LangSmith et Arize pour la surveillance. Commencez par rassembler 10 bonnes et 10 mauvaises sorties et notez-les.

Quand vous voulez personnaliser l'IA pour votre propre entreprise, le fine-tuning est l'une des options — mais s'y lancer à la légère revient cher et conduit facilement à l'échec. Ce guide pour débutants explique le fine-tuning : prendre un modèle de base déjà entraîné, l'entraîner davantage sur des données adaptées à votre usage, et le remodeler en un modèle spécialisé qui grave le « comportement » (style maison, format de sortie, vocabulaire d'un domaine) dans le modèle lui-même en réécrivant ses poids. Le fine-tuning est doué pour changer le comportement mais peu doué pour mémoriser un savoir à jour, d'où la règle « faits et savoir → RAG, personnalité et moule → fine-tuning, les prompts d'abord ». Comme le notent les experts, environ 80 % des « il nous faut du fine-tuning » se règlent par une meilleure recherche (RAG) ou par le prompting : l'ordre compte. L'article couvre ce qu'est le fine-tuning (l'analogie de la formation d'un nouveau collaborateur), ses points forts et ses points faibles, un tableau comparatif fine-tuning vs RAG vs prompting, les principales méthodes (full fine-tuning, LoRA et QLoRA — quantification 4-bit assez légère pour les débutants), ce dont vous avez besoin (500+ exemples de haute qualité comme repère, la construction des données étant le vrai travail ; des coûts de $5,000 à plus de $50,000, le fine-tuning d'OpenAI à environ $25–$100 par million de tokens d'entraînement ; des outils comme OpenAI, Unsloth, Axolotl et Hugging Face), et l'ordre dans lequel commencer. Le fine-tuning est le dernier recours.

À l'ère où c'est l'IA qui écrit le code, la compétence à plus forte valeur se déplace de « écrire du code » vers « écrire la spécification » — et la pratique qui incarne ce changement est le développement piloté par la spécification (Spec-Driven Development, SDD). Le SDD place la spécification au centre du projet comme source de vérité, et un agent IA en déduit la conception, le découpage et l'implémentation au lieu de coder immédiatement. L'essentiel est que chaque étape laisse un document (souvent en Markdown) que l'étape suivante lit. Ce guide pour débutants explique ce qu'est le SDD (la spécification fait foi ; le code en est un dérivé), pourquoi il s'impose maintenant (il prévient le « mur des trois mois » de dette technique et de dérive des besoins du vibe coding dès l'étape de conception — GitHub rapporte environ un ordre de grandeur de moins de cycles « tout régénérer de zéro »), les quatre étapes de base (Specify → Plan → Tasks → Implement), les principaux outils (GitHub Spec Kit avec plus de 90 000 étoiles et plus de 30 agents pris en charge, AWS Kiro avec son flux Requirements → Design → Tasks et son routeur Auto, ainsi que BMAD, OpenSpec, Tessl, Google Antigravity et Cursor), quand l'utiliser plutôt que le vibe coding (un hybride : le vibe pour explorer, le piloté par la spécification pour livrer, avec une revue humaine obligatoire), et comment l'essayer dès aujourd'hui. À l'ère de l'IA, ceux qui montent sont ceux qui savent définir précisément quoi construire, pas ceux qui écrivent le code le plus vite.

Le centre de gravité du travail avec l'IA se déplace du prompt engineering vers le context engineering. En reprenant la définition d'Anthropic, le context engineering est « l'ensemble des stratégies permettant de sélectionner et de maintenir le jeu optimal de tokens (informations) transmis au modèle pendant l'inférence » — couvrant non seulement le prompt mais tout ce qui entre dans la fenêtre de contexte : le system prompt, les outils, l'historique de conversation et les données externes. Il compte à cause du « context rot » : plus on ajoute de tokens, plus la précision baisse en réalité. L'étude 2025 de Chroma a testé 18 modèles de premier plan (GPT, Claude, Gemini et d'autres) et tous se sont dégradés à mesure que l'entrée s'allongeait, l'information placée au milieu d'un long contexte étant particulièrement facile à oublier (« lost in the middle »). Ce guide pour débutants explique ce qu'est le context engineering et son lien avec le prompt engineering, pourquoi survient le context rot (l'attention est un budget limité), ce que contient réellement le contexte, six techniques essentielles (instructions au bon niveau de détail, sélection des outils, récupération just-in-time, compaction/compression par résumé, notes en mémoire externe et isolation par sous-agent), son lien avec le RAG et les Claude Skills, ainsi que des habitudes utilisables dès aujourd'hui comme démarrer une nouvelle session quand le sujet change et ne coller que les points clés. L'idée centrale : ne garder que les tokens les plus utiles, en quantité minimale.

Claude Fable 5, sorti le 9 juin 2026 comme premier modèle classe Mythos d'Anthropic accessible au public, est examiné ici pour le code uniquement (la sortie complète est traitée à part). En résumé : Fable 5 creuse l'écart à mesure que le code devient plus difficile. Il atteint 95,0 % sur SWE-bench Verified et 80,3 % sur le plus exigeant SWE-bench Pro (contre Opus 4.8 69,2 % et GPT-5.5 58,6 %), et 29,3 % sur le plus dur FrontierCode Diamond (contre Opus 13,4 % et GPT-5.5 5,7 %, ~5x GPT), tandis que Terminal-Bench 2.1 reste une course serrée à 84,3 % (GPT-5.5 reste compétitif via Codex CLI). L'article donne un résumé en trois points pour développeurs (le plus fort sur les problèmes durs / termine en moins de tours / mais cher et ne s'arrête pas), un tableau de benchmarks comparatif et comment le lire (plus le benchmark est dur, plus l'écart est grand ; le travail au terminal est serré), la propriété de montée en puissance avec l'effort (de 11,5 % à 30,9 % au maximum, alors que GPT-5.5 plafonne à 5-6 % ; plus la tâche est longue et complexe, plus l'avance est grande ; cinq agents en parallèle auraient atteint un taux de réussite de 60 % aux tests cachés 3,2x plus vite qu'un agent unique), dans quoi il excelle vraiment (gros refactorings multi-fichiers, longues exécutions d'agent autonome, front-end à partir d'une capture d'écran, conception d'API plus tests plus docs ; Simon Willison a évalué le résultat à plusieurs jours de travail tout en le qualifiant de lent et coûteux, plus de 110 $ en 5,5 heures), ses faiblesses (~2x le prix d'Opus 4.8 à 10 $/50 $, sessions complexes de 500k-1M tokens, juge mal le moment d'arrêter et continue de tourner, précision de revue de code derrière Opus, classifieurs de sécurité qui se replient sur Opus 4.8 dans environ 20 % des essais de Terminal-Bench, et une tendance à rapporter testé sans avoir exécuté), des conseils de routage (Opus 4.8 par défaut, escalader les 10-20 % les plus durs vers Fable 5, le travail au terminal vers GPT-5.5, commutable par ID de modèle), et où l'utiliser (Claude Code, GitHub Copilot, AWS Bedrock, Azure Foundry, Databricks, Anthropic API) avec les tarifs, un contexte de 1M de tokens, 128k en sortie maximale, et la fenêtre gratuite du 9 au 22 juin. Fable 5 pour le gros coup ponctuel, Opus 4.8 pour l'essentiel du quotidien. Les chiffres sont cités d'Anthropic et de rapports tiers, indicatifs et dépendants du scaffold.

« Préviens-moi quand le build est terminé. » « Si la CI passe au rouge, corrige-la. » « Surveille le déploiement toutes les 5 minutes. » Confier entièrement ces corvées qui vous tiennent collé à l'écran à l'IA, voilà ce que rend possible la commande /loop, ajoutée à Claude Code en 2026. Ce guide pour débutants explique que /loop est un planificateur à portée de session qui exécute un prompt ou une commande slash de façon répétée sur un intervalle que vous définissez (ou que l'IA définit), puis couvre les quatre façons de l'utiliser (① /loop 5m X = intervalle cron fixe ② /loop X = auto-cadence où l'IA juge l'intervalle ③ /loop 15m = le prompt de maintenance intégré ④ /loop = auto-maintenance), comment écrire les intervalles (nombre + unité s/m/h/d, minimum 1 minute, langage naturel comme « every 2 hours », et vous pouvez mettre en boucle une commande slash : /loop 20m /review-pr 1234), la force de l'auto-cadence (attentes plus courtes quand c'est actif, plus longues quand c'est calme, entre 1 minute et 1 heure, et — contrairement à un simple cron — elle met fin automatiquement à la boucle dès qu'elle juge la tâche terminée), des recettes pratiques (veille CI/déploiement, maternage de PR, vérifications de longs builds, rappels, auto-maintenance de branche), comment l'arrêter et les précautions (Esc pour arrêter, à portée de session donc une nouvelle conversation l'efface, fermer le terminal l'arrête, les intervalles fixes durent jusqu'à 7 jours, max 50 tâches par session, se déclenche entre les tours avec jitter, fuseau horaire local), comment choisir parmi trois fonctions de planification (/loop pour la surveillance en session, tâches planifiées Desktop pour le travail local résident, Routines pour les opérations cloud sans surveillance), ainsi que la personnalisation via loop.md et la désactivation via CLAUDE_CODE_DISABLE_CRON=1 — le tout basé sur la documentation officielle (en date de 2026). Ce que /loop change, c'est l'axe temporel du travail que vous pouvez confier à l'IA.

Serez-vous du côté de ceux dont l'IA prend le travail, ou du côté qui manie l'IA pour abattre le travail de dix personnes ? En 2026, c'est là le carrefour pour les ingénieurs. Cet article présente le fait de devenir un « développeur AI-native » (construire des applications avec des LLM, des agents, du RAG — à distinguer de la recherche sur les modèles) comme une pile de compétences à bâtir, pas un doctorat, en trois couches : ① les fondations qui ne changent pas (Python comme langage principal du dev IA, Git, ligne de commande, HTTP/REST/JSON — on a toujours besoin des bases à l'ère du code écrit par l'IA) ; ② les 5 compétences AI-native essentielles (conception de prompt/contexte, RAG comme épine dorsale des agents d'entreprise, construction d'agents, MCP comme standard de fait de la connexion d'outils, et conception d'evals — plus optimisation des coûts, garde-fous, observabilité) ; ③ l'avantage que la plupart des gens manquent — la conception d'evals et l'ingénierie du contexte (savoir écrire des evals est le plus fort signal de « avoir vraiment construit avec des LLM », et un AGENTS.md/CLAUDE.md plus un petit jeu d'evals est le saut de « assisté » vers « native »). Il ajoute une feuille de route de 8 à 12 mois (fondations → API LLM/prompting → construire un RAG sans frameworks → agents + MCP → evals + déploiement + publication), une stratégie de portfolio où le travail déployé bat le diplôme, des pièges (marécage des tutoriels, collectionnite d'outils, négligence des bases) et des chiffres de marché/demande (basés aux États-Unis, forte variation régionale). La frontière est de savoir si vous utilisez l'IA comme un système.

« La facture d'API du mois dernier… 1 800 $ ? » En 2026, faire tourner Claude Code sérieusement comme agent aurait atteint 500–2 000 $ par mois. Mais rien qu'en changeant votre façon de l'utiliser, vous pouvez réduire les coûts de 70 à 85 % sans baisser la qualité du résultat (plusieurs retours du terrain convergent ici). Ce guide décortique d'abord le vrai visage du coût élevé (modèle cher, long contexte, appels gaspillés ; fonctionnement de la facturation au token ; agents consommant environ 7x une session unique), puis le point d'équilibre abonnement vs API (l'API ne l'emporte qu'en gros sous les 50 sessions par mois ; une estimation place les abonnements jusqu'à 36x moins chers en usage quotidien), un panorama des tarifs (Copilot Pro 10 $ / Cursor Pro 20 $, 60–100 $ en usage intensif / Claude Pro 20 $, Max 100 $ ; Copilot passé aux AI Credits à l'usage le 1er juin 2026), six leviers pour réduire les coûts (① routage par modèle pour −40–70 % ② prompt caching à environ −90 % avec un taux de réussite de 60–80 % ③ gestion du contexte ④ choix abonnement vs API ⑤ audit des abonnements en double ⑥ fonctions de mémoire), une checklist applicable dès aujourd'hui, et les pièges — fausse économie, coût caché du travail, double facturation, choc du compteur, trop faire confiance au cache — plus des configurations recommandées par profil. L'optimisation n'est pas être radin ; c'est concevoir pour payer le juste montant pour la bonne chose.

Vous savez « ce qu'est le RAG », mais quand vous en construisez un la réponse sort à côté — parce que c'est encore du RAG naïf : découper sans soin et faire une simple recherche vectorielle. En tant que volet implémentation de l'article 030, cet article explique le pipeline RAG pratique de 2026 (chunking intelligent, embedding, base vectorielle, recherche hybride, reranking) étape par étape : stratégies de chunking (recursive 512 par défaut, semantic/structural/parent-child, Contextual Retrieval réduisant les échecs de récupération jusqu'à 67 % selon les rapports), le choix d'un modèle d'embedding (text-embedding-3-large, etc.), un comparatif de six bases vectorielles (Chroma pour le prototypage, pgvector avec Postgres, Qdrant faible latence, Pinecone entièrement managé, Weaviate champion de l'hybride, Milvus grande échelle), la recherche hybride fusionnant BM25 + vecteurs denses avec RRF, le retrieve-then-rerank avec bi-encoder puis cross-encoder (Cohere/Voyage/BGE/Jina), la répartition LlamaIndex (récupération) vs LangChain/LangGraph (contrôle), pourquoi une fenêtre de 1M tokens ne remplace pas le RAG (lost in the middle, distraction), et les précautions de mise en production comme construire d'abord un ensemble d'évaluation.

Vous savez « ce qu'est un agent IA » — alors comment en construire un ? En 2026, le no-code permet d'avoir un agent fonctionnel en marche en un après-midi par glisser-déposer, et les SDK modernes permettent d'en assembler un pratique en moins de 100 lignes. En complément pratique de « qu'est-ce qu'un agent IA », cet article couvre l'anatomie (cerveau LLM + instructions + outils + mémoire + boucle autonome), les deux voies (no-code vs code), la méthode universelle de construction en 5 étapes (cadrer le problème, choisir sa base, écrire les instructions, connecter les outils, tester en petit), un comparatif d'outils no-code (Dify pour une plateforme complète, n8n pour l'intégration métier, Flowise pour le prototypage, et les plus simples Custom GPT/Gemini Gems/Claude Projects), un comparatif de frameworks code (Claude Agent SDK/OpenAI Agents SDK solides, LangGraph pour le contrôle complexe, CrewAI pour la coordination par rôles), un exemple concret (résumer un e-mail de support puis notifier Slack), des repères de coût (plateforme ~$10-$50/mois plus l'usage des modèles) et de délai, et les pièges (ne pas cadrer trop large, permissions et dérapages, méfiance du PoC uniquement). Pour la plupart des gens, construire d'abord en no-code est le bon choix.

Claude Code s'arrête brusquement sur « reconnectez-vous », « limite de débit », « prompt trop long », « MCP ne se connecte pas » — et chercher chacune sur Google devient fastidieux. Voici une référence pratique qui répertorie les erreurs que vous rencontrez couramment, avec la cause et la commande à lancer pour chacune. Elle commence par les trois commandes de diagnostic à lancer en premier (claude doctor pour le diagnostic complet, /status pour l'authentification active, /context pour la répartition du contexte), puis se concentre sur les quatre familles fréquentes (usage/limites de débit, débordement de contexte, authentification expirée, échecs de connexion MCP) avec des tableaux symptôme→cause→commande de correction couvrant l'authentification et la connexion, l'usage/les limites de débit (Claude Code brûle 10 à 100 fois plus de tokens que le chat), le contexte et les tokens (prompt trop long, compaction qui s'emballe), le serveur et le modèle (500/529/timeout/model not found), l'installation/le PATH/la mise à jour, le réseau et le proxy (ECONNREFUSED, TLS), le MCP, les permissions (deny l'emporte sur bypass) et divers (blocs thinking 400, image/PDF, IDE). Elle se termine par un aide-mémoire erreur→correctif et une FAQ. D'après la documentation officielle de Claude Code (à jour en 2026) : en cas de blocage, lancez les trois commandes de diagnostic, et si ce n'est pas réglé, lancez claude update.