Agents IA et automatisation : RAG, workflows, guides

Vous avez construit sur OpenAI, puis voulu essayer Claude et comparer Gemini — et perdu des heures à cause des SDK, formats et gestions d'erreurs différents par fournisseur. Une passerelle LLM (passerelle IA / proxy LLM) est un relais que vous glissez entre votre application et les fournisseurs : elle expose une seule API compatible OpenAI pour atteindre tous les modèles et prend en charge les tâches transversales — bascule, suivi des coûts, clés virtuelles, mise en cache, limitation de débit et observabilité. Ce guide couvre pourquoi vous en avez besoin, ce qu'une passerelle est vraiment, les trois types (proxy auto-hébergé = LiteLLM / hébergé = OpenRouter / SDK = Vercel AI SDK), comment choisir parmi LiteLLM, OpenRouter et le Vercel AI SDK, le code de configuration minimal qui ne remplace que le point de terminaison, et les limites — un saut de latence, la passerelle comme nouveau point de défaillance, les frais (OpenRouter facture 5,5 % sur les achats), la perte de fonctionnalités et la confidentialité.

Après avoir construit un agent IA, on se heurte toujours au même mur : « D'accord, mais est-ce que ça marche vraiment ? » Le mécanisme qui permet de décider si un changement de prompt ou de modèle a rendu les choses meilleures ou pires avec des données plutôt qu'au feeling, ce sont les evals. Les LLM produisent une sortie différente à chaque fois pour la même entrée, si bien que les tests unitaires à correspondance exacte collent mal. Cet article se concentre sur les étapes pour les créer et les faire tourner en pratique, et couvre cinq façons de mesurer la qualité (① correspondance à la vérité terrain ② vérifications par règles ③ LLM-as-judge ④ tests de régression ⑤ surveillance en production), l'évaluation propre aux agents (taux de réussite des tâches, appels d'outils corrects, trajectoire, coût), comment démarrer petit à partir de 20 exemples d'échec, les pièges courants et les outils clés (Anthropic Console/Evals, OpenAI Evals, LangSmith, Langfuse, Ragas) — écrit pour les praticiens.

La question éternelle de l'automatisation : « agents IA ou RPA ? » La réponse n'est pas l'un ou l'autre — on choisit selon le rôle, et le schéma gagnant de 2026 est un hybride des deux. La RPA, ce sont des « mains » déterministes qui exécutent une procédure fixe vite et avec précision (mais qui cassent quand l'écran/la spécification change) ; un agent IA est un « cerveau » probabiliste qui lit la situation et décide (solide sur l'ambiguïté et les exceptions, mais pas identique à chaque fois). Cet article couvre la différence de principe de fonctionnement, un tableau comparatif (le compromis reproductibilité-vs-résistance), la manière de choisir (l'axe est « peut-on l'écrire entièrement en règles ? » — oui → RPA, jugement impossible à formaliser → agent IA), la tendance 2026 (les leaders de la RPA UiPath, Automation Anywhere et Blue Prism deviennent agentiques — convergence ; la question n'est plus « lequel » mais « où placer le raisonnement » = orchestration d'abord), et la réponse pratique : un hybride où le cerveau (agent IA) gère le jugement/l'orchestration et les mains (RPA) assurent l'exécution déterministe — ne placez pas d'agent là où le déterminisme est requis, et associez le jugement délégué à des garde-fous et à une validation humaine. Sur la base des informations officielles des éditeurs, avec une FAQ.

Peut-on confier l'exploitation d'AWS à l'IA ? En 2026, on peut déléguer beaucoup. AWS propose lui-même Amazon Q Developer et l'Agent Toolkit for AWS (mai 2026 — plus de 40 compétences d'agent + un AWS MCP Server managé + des plugins), de sorte que l'IA peut aller de la génération d'IaC à l'exploitation des ressources. Ce guide cadre la « délégation » en trois niveaux (① génération de code/IaC, ② exploitation/investigation orientée lecture, ③ un agent autonome qui exploite réellement AWS), présente les principaux outils (Amazon Q Developer, Agent Toolkit, AWS MCP Server, Terraform MCP, Bedrock AgentCore) — dont la voie « apportez le vôtre » consistant à donner l'AWS CLI à Claude Code ou Codex pour exécuter « aws » depuis le shell — les avantages (IaC rapide, triage automatisé, idées d'optimisation des coûts, savoir démocratisé), puis le vrai enjeu, les inconvénients (prolifération des permissions IAM, le surdimensionnement comme amplificateur de rayon d'impact des erreurs/injections de prompt, permissions qui survivent à la tâche, emballement des coûts — avec de vrais incidents de suppression de BDD de prod en 2025-26), en s'appuyant sur des sources officielles AWS et d'éditeurs de sécurité. La clé : la question n'est pas « est-ce possible ? » mais « comment déléguer sans emballement ni explosion de la facture » — et le fait qu'AWS ait lui-même intégré garde-fous IAM, audit CloudTrail et bac à sable dans l'Agent Toolkit donne la forme de la réponse. Inclut les cinq principes (IAM au moindre privilège, approbation humaine pour les opérations destructrices, observabilité, identifiants JIT à durée de vie courte, bac à sable) et une FAQ.

Le premier obstacle pour intégrer un agent IA à un travail réel est « sur quel framework le construire ». Du point de vue d'un développeur et d'un décideur technique, cet article compare six frameworks majeurs — LangGraph, CrewAI, AutoGen (fondu dans le Microsoft Agent Framework, GA avril 2026), OpenAI Agents SDK, Google ADK et Claude Agent SDK — selon l'approche d'orchestration (graphe orienté / équipe par rôles / GroupChat conversationnel / passations / arborescence hiérarchique / boucle d'outils autonome), le langage, la courbe d'apprentissage, le contrôle, la maturité en production, le coût en tokens et le cas d'usage le mieux adapté. La mise en garde clé : le framework le plus « rapide à prototyper » (CrewAI) peut être le plus coûteux en production — environ 3× les tokens (41k contre 18,5k pour LangGraph dans un benchmark) et non déterministe, ce qui le rend peu adapté à la finance et à la santé. Il explique aussi comment 2026 a apporté l'interopérabilité via MCP (outils) et A2A (agent à agent), permettant aux agents de frameworks différents de coopérer et faisant disparaître le verrouillage. Inclut un guide de sélection par cas d'usage et une FAQ.

L'observabilité de l'IA rend visible ce que font réellement les LLM et les agents en production : quels outils, quelles recherches, ce qui est renvoyé, en combien de temps et à quel coût. Contrairement au monitoring classique, l'IA peut renvoyer 200 OK en 50ms et halluciner avec aplomb : la plupart des défaillances sont des problèmes de qualité, pas d'infrastructure. Trois piliers : traces, metrics, logs. On distingue observabilité (ce qui s'est passé) et évaluation (la réponse est-elle bonne), à utiliser en duo. Outils : LangSmith, Langfuse, Arize Phoenix, MLflow, AgentOps et le standard OpenTelemetry.

Après avoir saisi le concept dans « Qu'est-ce qu'un système multi-agents ? », voici la suite pratique. En s'appuyant sur le standard de fait de 2026, le pattern supervisor, l'article guide les débutants à travers une construction en 5 étapes. Le principe clé : construire d'abord en mono-agent et n'ajouter des agents que de façon minimale, une fois une limite atteinte (~80% des cas d'usage se contentent d'un seul ; utiliser le multi pour un travail simple et linéaire gonfle le coût de 3-10x et, selon la recherche de Google, fait baisser la précision de -39-70% sur les tâches séquentielles). Trois signes pour passer au multi : séparation des spécialités, parallélisme, séparation des décisions. Le pattern supervisor (le supervisor reçoit la tâche globale, la décompose, la délègue à des workers spécialisés et agrège les résultats) est le point de convergence des sous-agents de Claude Code, de LangGraph Supervisor et des handoffs de l'OpenAI Agents SDK, car il offre le support framework le plus large, un mode de défaillance connu (sur-délégation, bornée par un plafond d'itérations) et est facile à auditer. Les 5 étapes : 1) décomposer clairement la tâche en amont ; 2) définir les workers avec un rôle + outils + format de sortie (3-5 max) ; 3) concevoir le supervisor en énumérant explicitement les noms de workers appelables (plafond strict) et en y consacrant le plus de temps ; 4) décider du handoff et du partage de contexte, ne transmettre que le nécessaire (le standard est A2A) ; 5) instrumenter chaque handoff avant d'ajouter des agents, plafonner itérations/tokens/coût, et mettre en place evals et garde-fous. Un pseudo-code indépendant de tout framework montre les définitions de workers, un supervisor plafonné et une boucle bornée par les itérations. Pièges et solutions : sur-délégation, explosion des tokens, instabilité, baisse de précision et point d'échec inconnu. La leçon : les prompts, la conception des outils et le harnais d'evals décident du succès plus que le framework. Construire petit, mesurer, n'ajouter que lorsque ça rapporte.

Maintenant que les agents IA sont courants, le prochain défi est de faire collaborer les agents entre eux. Si MCP relie un agent à ses outils, A2A (Agent2Agent) relie un agent à un autre agent — une norme ouverte permettant à des IA construites sur des éditeurs et des frameworks différents de se découvrir, de communiquer et de coopérer grâce à une convention commune. Google l'a publiée en avril 2025, l'a confiée à la Linux Foundation en juin de la même année, et elle a atteint la v1.0 en 2026. Ce guide pour débutants explique ce qu'est A2A (l'analogie de l'étiquette d'un partenariat commercial), pourquoi c'est nécessaire (des agents spécialisés se relaient le travail — un agent de planification vers un agent de réservation d'hôtel vers un agent de paiement), en quoi cela diffère de MCP (MCP est vertical, agent ↔ outils ; A2A est horizontal, agent ↔ agent ; empiler les deux est la configuration standard à deux couches), comment ça marche (une Agent Card — un JSON « carte de visite » à /.well-known/agent-card.json — sert à découvrir les capacités, puis une Task porte la demande à travers des états comme working, input-required et completed, et un Artifact renvoie le résultat, le tout via HTTP, Server-Sent Events et JSON-RPC 2.0, les agents gardant leurs rouages internes cachés), ainsi que son état actuel et sa mise en œuvre (à la date d'avril 2026, 150+ organisations en production, 22 000+ étoiles sur GitHub, des SDK dans cinq langages — Python, JavaScript, Java, Go, .NET — avec Microsoft, Salesforce, SAP et ServiceNow impliqués). Le moyen mnémotechnique : se connecter aux outils = MCP, se connecter aux pairs = A2A.

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 rapporte un gain de précision RAG d'environ 40 % grâce au reranking, 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.

Une fois que l'on sait construire des applications IA, l'étape suivante consiste à les faire fonctionner en toute sécurité. Les LLM peuvent être trompés par des entrées malveillantes, divulguer des données confidentielles ou affirmer n'importe quoi avec aplomb ; le mécanisme de sécurité qui empêche cela, ce sont les garde-fous IA, désormais essentiels en production en 2026 alors que les incidents liés aux agents IA se produisent réellement. Les garde-fous sont des règles et des filtres qui retiennent les entrées dangereuses et les sorties indésirables, vérifiant l'entrée de l'utilisateur avant qu'elle n'atteigne le LLM et la réponse avant qu'elle ne revienne — une couche de sécurité indépendante, distincte du modèle lui-même. Les principales menaces sont l'injection de prompt (la plus grande), les jailbreaks, la fuite de données (données confidentielles, PII, prompt système) et l'hallucination ou les sorties nuisibles. La protection opère sur deux couches : les garde-fous en entrée (détecter les injections et les jailbreaks, détecter/masquer les PII, restreindre les sujets, assainir) et les garde-fous en sortie (filtrer les contenus nuisibles, empêcher les fuites, vérifier les hallucinations, valider le format). L'injection de prompt — classée la plus critique de l'OWASP LLM Top 10 — se présente sous forme directe (un utilisateur tape « ignore toutes les instructions précédentes ») et indirecte (commandes cachées dans une page web ou un document RAG), et l'injection indirecte n'est pas bloquée par le RAG seul, si bien que les documents récupérés nécessitent leur propre contrôle. Ce guide pour débutants couvre aussi les outils (LLM Guard, Guardrails AI, NeMo Guardrails, Llama Guard et les fonctions de sécurité cloud d'Azure, AWS et OpenAI) ainsi que les principes pratiques de défense en profondeur, moindre privilège, approbation humaine et surveillance continue.

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.