Développement IA et programmation : créez des apps

Vous avez construit un RAG, mais la qualité de la recherche est médiocre — c'est exactement là que le reranking aide. Le reranking re-score, selon leur pertinence par rapport à la requête, les candidats grossièrement rassemblés par la recherche par embedding (vectorielle) et les réordonne en ne gardant que les meilleurs ; cette seule étape peut transformer radicalement la qualité des réponses d'un système RAG. Ce guide pour débutants explique ce qu'est le reranking (avec l'analogie de la présélection et de l'entretien final), pourquoi il est nécessaire (la recherche par embedding vectorise la requête et les documents séparément, donc elle ne juge la pertinence que grossièrement, et un mauvais ordre fait directement baisser la qualité des réponses — la recherche montre que le reranking peut nettement améliorer la précision de la recherche, et le superposer à la recherche hybride est le standard 2026), comment fonctionne la récupération en deux étapes (« rassembler large » avec une recherche par embedding rapide pour le rappel, puis « affiner intelligemment » avec le reranker pour la précision, avant de transmettre le haut du panier au LLM), pourquoi un reranker est plus précis (un bi-encoder vectorise la requête et le document individuellement, rapide mais approximatif ; un cross-encoder les fournit ensemble et produit un score de pertinence 0–1, précis mais lourd — on rassemble donc avec le bi-encoder rapide et on affine avec le cross-encoder précis), ainsi que les modèles et l'implémentation (type API comme Cohere Rerank, Voyage et Jina ; open source comme BGE reranker, mixedbread et FlashRank ; et scoring par LLM comme RankLLM — il suffit de récupérer 50–100 et d'affiner au top 5). Le principe : rassembler large, affiner intelligemment, et ajuster les nombres avec des évaluations d'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 permet à certains modèles récents de réduire les dimensions après coup, par exemple les 3 072 d'OpenAI à 1 024, au prix d'un peu de précision pour environ un tiers du stockage), 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) sont souvent recommandées plutôt que 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.

Le fine-tuning entraîne davantage un modèle de base sur vos données pour ajuster son style, ses formats et ses classifications. Ce guide le compare au RAG et aux prompts, présente les méthodes complète, LoRA et QLoRA, et détaille les données nécessaires, les coûts et les conditions d’accès d’OpenAI. Il montre aussi comment évaluer un modèle ajusté sur un cas de classification avant de décider de l’adopter.

À 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), les quatre étapes de base (Specify → Plan → Tasks → Implement), les principaux outils (GitHub Spec Kit avec plus de 140 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 % 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 valables en juin 2026 (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 ; aujourd'hui, lisez la famille Opus 5 à la place d'Opus 4.8), 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 (aujourd'hui la famille Opus 5) 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 l'auto-cadence et annulation pour les intervalles fixes, à portée de session donc une nouvelle conversation l'efface, fermer le terminal l'arrête sauf si la session passe en arrière-plan avec /background, 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.

Selon Anthropic, l'usage de Claude Code en entreprise revient en moyenne à 150–250 $ par développeur et par mois, et faire tourner des agents en parallèle longtemps peut largement dépasser ce chiffre. Mais rien qu'en changeant votre façon de l'utiliser, vous pouvez réduire nettement les coûts sans baisser la qualité du résultat. 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 ; équipes d'agents consommant environ 7x une session standard), puis le point d'équilibre abonnement vs API (l'API ne revient moins cher qu'en usage très léger, quelques fois par mois ; si vous codez tous les jours, l'abonnement l'emporte presque à coup sûr), un panorama des tarifs (Copilot Pro 10 $ / Cursor Pro 20 $, Pro+ 60 $ pour un usage agentique quotidien / Claude Pro 20 $, Max 100 $ ; Copilot passé aux AI Crédits à l'usage le 1er juin 2026), six leviers pour réduire les coûts (① routage par modèle ② prompt caching à environ −90 % ③ 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 notre guide RAG pour débutants, 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 avec reranking, qui réduit les échecs de récupération dans le top 20 jusqu'à 67 % selon Anthropic), 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 ~$20-$60/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.