Apprendre l’ingénierie de l’intelligence artificielle agente selon l’ordre enseigné par les défaillances.

Les développeurs qui se tournent vers l’ingénierie d’agents essaient souvent d’absorber tous les frameworks en même temps, en testant successivement LangChain, CrewAI, AutoGen et LangGraph au cours d’une seule semaine sans livrer de résultat concret. Le problème réside dans l’ordre d’apprentissage : ils étudient les outils avant de comprendre les échecs que ces derniers sont censés éviter. Ce guide propose un parcours en quatorze étapes, dans l’ordre où les compétences se construisent réellement les unes sur les autres, allant du Python de base jusqu’à la mise en production d’un agent qui fonctionne sans surveillance. Au fil du chemin, vous découvrirez les trois modes d’échec qui influencent chaque décision de conception, la petite pile d’outils suffisante pour la plupart des travaux en production, ainsi que les modèles structurels (fichiers d’état, revue maker-checker, évaluation en couches et délimitation des permissions) qui distinguent une démonstration d’un système fiable dès le premier jour.

Partie 1 : Le modèle mental

1. L’ingénierie d’agents n’est pas l’ingénierie de prompts avec une nouvelle étiquette

L’ingénierie des prompts consiste à formuler ce que l’on dit à un modèle. L’ingénierie des agents consiste à construire le système qui décide sur quoi le modèle doit travailler, quand il doit s’arrêter, et comment réagir lorsque sa réponse est incorrecte.

La définition pratique est claire : on crée un logiciel dans lequel un LLM choisit l’action suivante, invoque une outil pour la mettre en œuvre, examine le résultat, et répète ce processus jusqu’à l’achèvement de la tâche, sans aucune intervention humaine à chaque étape. Un chatbot répond à un message. Un agent choisit des actions, les exécute, vérifie leurs résultats et itère. C’est cette différence qui définit entièrement le travail.

Cela implique trois responsabilités que le travail sur les prompts n’a jamais nécessitées :

• Considérer les erreurs comme une préoccupation majeure. Les agents échouent constamment : les API expirent, le JSON est mal formaté, le modèle invente des appels d’outils, et les sorties de ces outils ne respectent pas leurs schémas. Un code qui suppose un succès plantera au pire moment, généralement lors d’une démonstration.
• Gérer l’état. Un appel individuel à un LLM ne conserve rien. Un agent qui effectue dix appels d’outils, des tentatives de réessai et fait appel à des sous-agents a besoin d’un état structuré et persistant qui survive au-delà de n’importe quelle fenêtre de contexte.
• Intégrer l’évaluation dans l’infrastructure. Il n’existe aucune intuition permettant de déterminer si un agent a raison. Il faut des mécanismes automatisés, tels que des tests, des grilles d’évaluation ou un modèle juge, afin de rejeter les sorties incorrectes sans que quelqu’un doive examiner chaque exécution.

Les descriptions des postes pour ces rôles ressemblent souvent à un catalogue. Les frameworks d’orchestration (LangGraph, LangChain, LlamaIndex), les protocoles (MCP, A2A), les fonctionnalités des modèles (appel de fonctions, sorties structurées, mise en cache des prompts), les méthodes de récupération d’informations (RAG, RAGAS, recherche hybride, réclassement, modèles d’encodage, bases de données vectorielles et graphiques) ainsi que les compétences opérationnelles (exécution dans un environnement isolé, capacité d’observation, évaluation) y figurent toutes, généralement suivies d’une exigence de maîtrise de l’itération rapide. La liste peut paraître intimidante, mais la plupart des éléments ne sont en réalité que quelques idées de base présentées sous différents noms. Une fois ces idées comprises, il devient facile d’identifier les produits correspondants.

2. Trois modes de défaillance expliquent la majeure partie du travail

Au préalable de commencer à écrire du code, il est essentiel de comprendre pourquoi les systèmes agents échouent. Presque chaque outil et chaque pattern dans ce domaine existe pour contrer l’un de ces trois comportements.

Paresse agente. Face à une tâche longue et composée de plusieurs étapes, le modèle s’arrête prématurément et déclare avoir réussi après un progrès partiel. Il traite 20 des 50 tickets en attente et indique que le reste a été géré. La mesure corrective consiste en une condition d’arrêt explicite vérifiée par un élément autre que le modèle lui-même.

Biais de préférence pour soi-même.Lorsqu’on lui demande d’évaluer sa propre sortie, un modèle l’approuve systématiquement. Un évaluateur ayant un intérêt personnel dans le résultat ne peut pas l’évaluer de manière objective. La mesure corrective est structurelle : l’agent qui produit le travail ne doit pas être celui qui l’évalue.

Dérive de l’objectif. Au fil de nombreuses étapes, et surtout après que le contexte a été résumé ou compressé, l’agent perd progressivement de vue l’objectif initial. Une contrainte telle que « ne pas toucher au module de paiement » peut disparaître silencieusement à l’étape 47. La solution consiste à utiliser un fichier de spécifications persistant, relu à chaque exécution, afin de conserver les contraintes que le modèle risquerait sinon d’oublier.

Lorsque l’écosystème semble déroutant, demandez pour tout nouvel outil ou modèle quel de ces trois problèmes il vise à résoudre. Cette question permet d’éliminer la plupart des éléments superflus.

3. Un petit ensemble de composants essentiels, et quatre choses à différer

Les listes de exigences sont longues, mais la majeure partie du travail des agents en production repose sur quatre couches, à maîtriser dans cet ordre :

Core stack (learn these, in this order):
1. Python + async    : the bedrock; everything else builds on it
2. LLM APIs          : Anthropic, OpenAI; understand tokens, context, costs
3. Tool use / MCP    : function calling; how models act on the world
4. LangGraph         : stateful orchestration for multi-step, multi-agent work

Différez ce qui suit jusqu’à ce que vous ayez déployé au moins un agent fonctionnel :

• Ajustement fin. Les projets initiaux n’en ont presque jamais besoin. Un modèle de base performant avec des prompts bien conçus est généralement supérieur à un modèle ajusté finement mais avec de mauvais prompts.
• Préoccupation excessive concernant les bases de données vectorielles. Des outils comme Chroma conviennent bien en environnement local, tandis que des services gérés tels que Pinecone sont adaptés en production. Attendez d’avoir un véritable goulot d’étranglement dans le processus de récupération des données avant de choisir l’un ou l’autre.
• Changement de frameworks. Choisissez un framework d’orchestration (LangGraph constitue une bonne option par défaut), terminez un projet, puis seulement après explorez d’autres options. Changer d’outil chaque semaine sous prétexte que chacun promet d’être plus simple ne garantit pas la finition des projets.
• Agents vocaux et agents navigateur. Il s’agit de spécialisations basées sur les mêmes fondements. Maîtrisez d’abord les agents textuels ; les principes s’appliquent également aux autres types d’agents.

Partie 2 : Les éléments de base

4. Python et code asynchrone

Vous n’avez pas besoin de maîtriser parfaitement Python, mais il vous faut suffisamment de connaissances pour déboguer les erreurs, or les agents échouent fréquemment. Concentrez-vous sur :

• Les classes et les modèles de données. Les agents transmettent des données structurées d’une étape à l’autre, il est donc nécessaire de les modéliser. Un schéma Pydantic sert de contrat entre les appels aux outils et la logique de l’agent ; considérez-le comme obligatoire, et non optionnel.
• L’asynchrone avec asyncio. Les agents passent beaucoup de temps à attendre que les outils répondent : une requête de base de données, un appel HTTP, un sous-processus. Le code synchrone bloque pendant chaque attente, tandis que le code asynchrone peut effectuer d’autres tâches. Un code d’agent lent est très souvent du code synchrone qui attend en série.

HTTP et REST. Sans API, un agent peut réfléchir mais pas agir. Apprenez à lire la documentation des API, à respecter les limites de fréquence, à interpréter les réponses d’erreur et à relancer de manière judicieuse. Un outil qui plante en cas d’erreur HTTP 429 est un outil sur lequel l’agent ne peut pas compter.

Gestion des erreurs. Enveloppez chaque appel à un outil dans try/except. Les agents s’exécutent sans surveillance, et une exception non gérée qui affiche un traceback puis s’arrête ne sert à personne au milieu de la nuit.

Un critère pratique : si vous pouvez confier une tâche à un ingénieur junior avec une liste de contrôle et vous fier à un ensemble de tests pour détecter ses erreurs, vous connaissez suffisamment Python pour commencer. Vous pourrez en apprendre davantage par la suite.

5. Fondamentaux des LLM : tokens, contexte et coût

Des modèles tels que Claude, GPT et Gemini sont puissants mais ont besoin de directives, or on ne peut pas diriger ce que l’on ne comprend pas.

Tokenisation. Les modèles lisent des tokens plutôt que des mots, et un même terme peut se diviser en plusieurs tokens selon le tokeniseur utilisé. En règle générale pour l’anglais, un contexte de 100 000 tokens correspond à environ 75 000 mots. Tout ce qui se trouve en dehors de cette plage, que ce soit une conversation de la semaine dernière ou un fichier oublié d’inclure, n’existe tout simplement pas pour le modèle. Si quelque chose est important, il doit figurer dans le contexte.

Limits de contexte et récupération d’informations. Les modèles ne se souviennent pas ; chaque session commence à zéro. Inclure tout dans la requête est coûteux et dégrade la qualité à mesure que celle-ci augmente. La génération augmentée par récupération vise à ne récupérer que les informations pertinentes.

Inference, et non entraînement. Vous n’allez presque jamais entraîner un modèle. Vous effectuez une inférence sur le modèle d’autrui et vous payez par token. Le coût correspond au nombre de tokens d’entrée multiplié par leur prix, plus le nombre de tokens de sortie multiplié par leur prix ; ainsi, une boucle effectuant 50 appels avec un contexte de 20 000 tokens entraîne une facture importante.

Induction pour les agents. Les prompts destinés aux agents diffèrent des prompts de chat. Trois modèles sont particulièrement importants : le chain-of-thought, où le modèle raisonne explicitement avant d’agir ; ReAct, un cycle de raisonnement, d’action et d’observation ; et la réflexion, où le modèle critique son propre brouillon avant de le renvoyer. La plupart des autres techniques d’induction ne sont que des variations de ces modèles. Pour en savoir plus sur le cycle ReAct, consultez comment les agents ReAct combinent le raisonnement avec des actions du monde réel.

6. L’utilisation d’outils et le MCP transforment un chatbot en agent

Mécaniquement, vous décrivez chaque fonction avec un nom, une description en langage naturel ainsi qu’un schéma JSON pour ses paramètres, puis vous envoyez ces définitions accompagnées du message de l’utilisateur. Le modèle décide s’un outil est nécessaire et, le cas échéant, renvoie une requête structurée contenant des arguments au lieu de texte brut. Votre code exécute la fonction, envoie le résultat en retour, et le modèle poursuit son travail à partir de là. La description est tout aussi importante que le schéma, car c’est elle que le modèle utilise pour déterminer quand un outil est applicable.

La plupart des outils pratiques pour les agents se répartissent en quatre catégories. Les signatures ci-dessous les illustrent : des outils qui lisent (observent le monde), des outils qui écrivent (modifient l’état), des outils qui exécutent du code, et des outils qui vérifient le travail effectué :

# Category 1: Read  (agent observes the world)
def search_codebase(query: str, path: str) -> list[str]: ...
def fetch_url(url: str) -> str: ...
def read_file(path: str) -> str: ...

# Category 2: Write (agent changes state)
def create_file(path: str, content: str) -> None: ...
def open_pull_request(title: str, body: str, branch: str) -> str: ...
def send_slack_message(channel: str, text: str) -> None: ...

# Category 3: Execute (agent runs code)
def run_tests(test_path: str) -> dict: ...
def execute_sql(query: str, db: str) -> list[dict]: ...

# Category 4: Verify (agent checks its own work)
def lint_code(file_path: str) -> list[str]: ...
def run_type_checker(path: str) -> bool: ...

Ces catégories constituent également un outil utile pour évaluer les risques. Les outils de lecture et de vérification peuvent généralement être utilisés librement sans danger, tandis que les outils d’écriture et d’exécution modifient des éléments et méritent des permissions plus strictes, un thème qui reviendra dans l’étape de sécurité.

Le Model Context Protocol (MCP) est une norme émergente qui remplace le code d’intégration personnalisé par un protocole. Une analogie courante est celle de USB-C pour l’IA : au lieu d’écrire un adaptateur sur mesure chaque fois que l’agent a besoin de GitHub, Slack ou d’une base de données, on se connecte à un serveur MCP existant, et l’application hôte découvre les capacités de ce serveur et les utilise sans code d’intégration supplémentaire.

Les intégrations qui donnent les meilleurs résultats rapidement sont GitHub pour les branches, les demandes de fusion et les problèmes ; Slack pour les notifications et les résumés ; votre base de données pour les requêtes et les écritures contrôlées ; ainsi que le suiveur de problèmes de l’équipe. Avec ces quatre outils connectés, un agent peut gérer la majeure partie du flux de travail en ingénierie.

7. La récupération d’informations, car le contexte a ses limites

La génération augmentée par la récupération d’informations permet à un agent d’accéder à des connaissances qui ne rentrent pas dans son contexte. Il s’agit d’une réponse à une contrainte réelle plutôt qu’à une mode : la fenêtre de contexte est finie, tandis que votre base de code et vos documents ne le sont pas.

Un système de récupération d’informations se compose de quatre parties principales :

• Chunking, c’est là que les débutants commettent le plus d’erreurs. Les blocs trop grands contiennent trop de matériel irrélevant ; les blocs trop petits perdent leur sens. La taille idéale dépend du contenu, et le code source nécessite généralement des limites différentes (comme des fonctions entières) par rapport à la documentation en prose.
• Embeddings, qui rendent possible la recherche de similarités. Un modèle d’embedding transforme du texte en un vecteur numérique, de sorte que des passages similaires génèrent des vecteurs proches les uns des autres.
• Recherche, qui trouve les vecteurs stockés les plus proches de la requête d’embedding et renvoie leurs blocs correspondants.

Évaluation, qui permet de distinguer un système qui fonctionne réellement d’un système qui ne fait que le paraître. Les critères principaux sont la précision de la récupération (ce qui a été obtenu est-il vraiment pertinent ?), la fidélité (la réponse reste-t-elle dans le matériel récupéré ?) et la pertinence de la réponse (répond-elle à la question ?). Des outils tels que RAGAS ou un modèle d’arbitre peuvent évaluer ces critères. Sans mesure, toute amélioration relève du hasard.

La récupération efficace n’est rarement un processus linéaire allant de la requête à la réponse. Les systèmes en production réécrivent souvent la question avant de rechercher, réclassent les résultats après recherche, et utilisent une étape d’arbitrage pour déterminer si le matériel récupéré répond réellement à la question. En fait, le modèle raisonne sur ce qu’il convient de récupérer et sur le succès de cette opération.

8. Orchestration à état avec LangGraph

Une seule appel à un LLM ne constitue pas un agent. Un agent exécute plusieurs étapes, conserve l’état entre elles, prend des décisions en fonction de ce qu’il observe et se remet des échecs. LangGraph fournit une structure conçue précisément pour cela.

D’un point de vue structural, une application LangGraph est un graphe orienté dont les nœuds sont des fonctions simples, telles que des agents, des outils ou des étapes de traitement. Les arêtes définissent la manière dont le contrôle passe d’un nœud à l’autre. Un objet d’état partagé et typé est lu et mis à jour par chaque nœud.

Le schéma ci-dessous définit un état comprenant une tâche, un plan, des résultats, des erreurs et un drapeau de finition, puis enregistre quatre nœuds : un planificateur qui divise le travail, un exécutant qui met en œuvre une étape, un vérificateur qui contrôle les résultats, et un gestionnaire d’erreurs qui réessaie ou escalade la situation. Le bord conditionnel situé après le vérificateur constitue le cœur du boucle : terminer lorsque l’état indique que la tâche est achevée, rediriger vers le gestionnaire en cas d’erreurs, et sinon exécuter l’étape suivante. Notez que ce n’est qu’un fragment ; un graphe exécutable nécessite également un point d’entrée, les autres bords ainsi qu’une appel à compile().

from langgraph.graph import StateGraph, END
from typing import TypedDict

class AgentState(TypedDict):
    task: str
    plan: list[str]
    results: list[str]
    errors: list[str]
    done: bool

graph = StateGraph(AgentState)

graph.add_node("planner", plan_task)       # breaks work into steps
graph.add_node("executor", execute_step)   # runs one step
graph.add_node("verifier", verify_output)  # checks the result
graph.add_node("handler", handle_error)    # retries or escalates

graph.add_conditional_edges(
    "verifier",
    lambda state: END if state["done"] else
                  "handler" if state["errors"] else
                  "executor"
)

Par rapport à une boucle Python écrite manuellement, ce framework ajoute trois fonctionnalités :

• Vérification à points clés.Lorsque vous compilez le graphe avec un outil de vérification, l’état est enregistré après chaque étape, ce qui permet à une exécution interrompue (un ordinateur portable en panne, une session redémarrée) de reprendre là où elle s’est arrêtée au lieu de recommencer depuis le début.
• Pauses avec intervention humaine.En définissant la valeur interrupt_before pour un nœud critique, le graphe s’arrête, affiche l’action proposée et attend une approbation avant de continuer. C’est un élément essentiel qui distingue un agent de démonstration d’un agent en production.
• Branches parallèles.Des étapes indépendantes peuvent s’exécuter simultanément, le framework s’occupant de fusionner leurs résultats dans l’état global ; ainsi, vous n’avez qu’à décrire la structure sans avoir à écrire de code de synchronisation.

Une règle raisonnable : optez pour un framework de graphes lorsque l’agent comporte plus d’environ trois étapes, des branches dans les résultats des outils, ou des boucles jusqu’à ce qu’une condition soit remplie. Une simple chaîne linéaire sans branches convient parfaitement en Python pur. Les compromis associés sont abordés plus en détail dans choisir entre chaînes et graphes à état.

Partie 3 : Le construire correctement

9. Cinq projets, en séquence

Comprendre les agents et en créer sont deux compétences distinctes, et ce parcours ne fonctionne que grâce à des projets pratiques. Ces cinq projets, réalisés dans l’ordre, couvrent tous les concepts nécessaires au travail de production.

1. Un agent doté d’un seul outil. Choisissez une seule API, comme GitHub ou un service météorologique, et écrivez un agent qui détermine si l’API est nécessaire, l’appelle et intègre sa réponse dans la réponse finale. Utilisez l’API brute d’Anthropic ou d’OpenAI sans framework, afin de voir directement le cycle d’utilisation de l’outil sans aucune abstraction qui le cache.
2. Un agent ReAct avec trois outils. Ajoutez une recherche sur le web, un calculateur et un exécuteur de code, puis écrivez vous-même le cycle raisonner-agir-observer. C’est généralement ici que l’on observe pour la première fois un agent remarquer et corriger sa propre erreur.
3. Récupération d’informations à partir d’une base de code que vous connaissez. Indexez un répertoire réel, créez un système de récupération à partir de celui-ci, et posez des questions nécessitant la compréhension de plusieurs fichiers. Évaluez la qualité de la récupération et corrigez les parties qui échouent. Ce projet montre pourquoi le découpage en fragments est plus important que tout autre facteur.

Un agent graphique à plusieurs étapes. Gérer le tri des tests en CI : lire les journaux des tests échoués, classifier l’échec, rechercher dans le codebase la cause probable, rédiger une correction et exécuter les tests, avec un flux d’état passant par cinq nœuds. Faire du vérificateur un nœud distinct du correcteur ; sinon, on risque de tomber dans un biais de préférence envers soi-même.

Un cycle autonome planifié. Exécuter le projet quatre selon un planning cron sans surveillance humaine. Fournir un fichier d’état afin qu’il puisse reprendre son travail plutôt que de redémarrer, un budget strict pour éviter que les coûts API ne montent en flèche, ainsi qu’un journal d’audit enregistrant ses actions. C’est ici que « ça marche en démonstration » devient « ça fonctionne sans surveillance ».

10. Le fichier d’état : les agents oublient, les fichiers non

Cela semble trop simple pour avoir de l’importance, mais c’est le pilier de tout agent autonome fiable : un fichier Markdown, un document JSON ou une ligne de base de données qui existe en dehors de la conversation et qui enregistre ce qui a été fait ainsi que les étapes suivantes.

Les modèles ne conservent rien entre les sessions. Tout ce qu’un agent apprend au cours d’une exécution disparaît à moins d’être consigné par écrit ; ainsi, une boucle sans état persistant recommence toujours à zéro, tandis qu’une boucle avec état reprend là où elle s’était arrêtée. L’exemple ci-dessous suit le dernier temps d’exécution, le nombre d’éléments traités et restants, les tâches en cours, les tâches terminées, les éléments transférés à un humain, ainsi que des leçons datées concernant les particularités de l’environnement à éviter la prochaine fois :

// STATE.md: what every working autonomous agent needs
{
  "last_run": "2026-07-01 03:00 UTC",
  "items_processed": 47,
  "items_remaining": 12,
  "in_progress": [
    "fix/auth-token-refresh: tests passing, awaiting CI"
  ],
  "completed": [
    "fix/null-check-in-billing: merged, CI green"
  ],
  "escalated_to_human": [
    "src/payments/refund.ts: root cause unclear after 3 theories"
  ],
  "lessons": [
    "2026-06-30: E2E tests require Stripe webhook secret in env. Skip if missing.",
    "2026-06-29: Windows runner has TLS 1.2 issue. Use bash, not PowerShell."
  ]
}

La liste des leçons mérite une attention particulière. C’est elle qui permet à un boucle d’éviter de répéter les mêmes erreurs, et elle sert également de spécification persistante pour lutter contre le décalage par rapport aux objectifs. Il existe deux formats courants : un fichier Markdown stocké dans le répertoire est contrôlé en version, facile à comparer et simple d’utilisation, ce qui convient aux individus et aux petites équipes. Pour les boucles de production que plusieurs personnes doivent suivre, un système externe tel qu’un outil de suivi des problèmes comme Linear ou une base de données est plus adapté. Le principe est simple : l’agent oublie, le répertoire se souvient, donc tout ce qui est important doit être en dehors de la fenêtre de contexte.

11. Maker-checker : séparer l’auteur du réviseur

Un agent produit le travail et un autre agent, dans son propre contexte, le vérifie. C’est la réponse structurelle au biais d’autopréférence, et son application cohérente constitue l’un des signes les plus évidents d’une conception d’agent mature.

Un modèle qui évalue ses propres résultats est bien trop indulgent envers lui-même. Demandez à l’agent qui a rédigé la correction si elle est correcte, et il trouvera des raisons de répondre par l’affirmative. Donnez à un évaluateur indépendant la correction ainsi qu’un critère d’évaluation, sans lui révéler qui l’a écrite ni pourquoi, et il identifiera de véritables défauts.

Contraste dans le code : la version incorrecte demande à un seul agent de corriger une erreur et de confirmer sa propre correction. La version correcte exécute un outil de correction sur un modèle, puis transmet uniquement le code résultant ainsi qu’une grille d’évaluation spécifique à un examinateur, qui est chargé d’ignorer l’auteur et l’intention derrière la modification, afin de retourner un résultat positif avec des explications ou négatif avec des références aux lignes concernées. L’examineur utilise un modèle plus puissant, car le jugement constitue la tâche la plus difficile :

# Wrong: one agent does both
result = await agent("Fix the auth bug and verify your fix is correct")

# Right: maker and checker are separate agents, separate contexts
fix = await agent(
    "Fix the auth bug in src/auth/middleware.ts",
    model="sonnet"
)

review = await agent(
    f"""Review this fix against the rubric below.
    Do not consider who wrote it or their intent.

    Fix:
    {fix.code}

    Rubric:
    - Does it handle the null case on line 47?
    - Does it preserve the existing token expiry logic?
    - Does the test cover the regression case?

    Return: PASS with reasoning, or FAIL with specific line references.""",
    model="opus"   # harder model for the harder judgment task
)

La règle concernant l’association est que l’examineur ne reçoit que deux entrées, la grille d’évaluation et le résultat de la correction, sans jamais connaître l’identité de l’auteur, les raisons de la modification ni la conversation qui l’a engendrée. Tout élément de ce type réintroduit une préférence personnelle par le biais du cadre de référence. La grille d’évaluation est également importante ; des questions spécifiques et vérifiables, comme celles mentionnées ci-dessus, fonctionnent bien mieux que de se demander simplement si la modification est bonne.

Cette même séparation s’applique bien au-delà du code : auteurs et réviseurs, écrivains et vérificateurs de faits, générateurs et juges. Une fois que vous l’avez remarquée, vous verrez à quel point les outils par défaut fusionnent souvent silencieusement ces deux rôles.

12. Évaluation : le mécanisme qui rend un cycle fiable

Un agent sans vérificateur n’est qu’un chatbot invoqué à plusieurs reprises. C’est l’évaluation qui détermine si un résultat peut être suffisamment fiable pour y agir, le fusionner ou le publier. Utilisez trois niveaux, dont le coût et les types de jugements possibles augmentent progressivement :

• Vérifications déterministes. Les tests, les linters, les vérificateurs de types et les compilations fournissent un résultat binaire sans aucune appréciation. Ce sont le premier et le moins coûteux des mécanismes ; utilisez-les chaque fois qu’une vérification déterministe peut rejeter une sortie incorrecte.

Juge basé sur un LLM. Un deuxième modèle évalue les résultats générés par le premier modèle en fonction d’un critère précis. Cette méthode fonctionne lorsque le critère est clair, mais échoue s’il est vague. Le juge doit être au moins aussi performant que le modèle qui produit les résultats, et on ne lui doit jamais révéler qui a généré ces derniers. Gérer correctement un tel juge constitue une discipline à part entière, abordée dans la gestion des LLM en tant que juges au sein d’un système de production.

Approbation humaine. Les actions irréversibles, telles que les déploiements en production, les codes de paiement, les mises à jour forcées ou les modifications architecturales, nécessitent l’approbation d’une personne avant que l’agent ne procède. Dans LangGraph, la fonction interrupt_before permet cette pause. Préservez-la pour les actions dont il est coûteux de revenir en arrière, plutôt que d’utiliser cette fonction pour tout bloquer.

Pour savoir si l’évaluation fonctionne correctement, suivez le taux de modifications acceptées. Si un agent conçu pour corriger les tests échoués résout 70 % de ses problèmes grâce à des modifications qui passent les tests d’intégration continue et l’examen humain, son taux est de 70 %. En dessous d’environ 50 %, les humains passent leur temps à terminer le travail commencé par l’agent, et ce cycle coûte plus qu’il n’économise.

13. Sécurité : un agent non surveillé représente une surface d’attaque non contrôlée

Tout agent autonome qui interagit avec des infrastructures réelles constitue une vulnérabilité en termes de sécurité, fonctionnant sans supervision. Le risque est réel : grâce à l’injection indirecte de commandes, un agent qui lit un e-mail ou une page web malveillante peut être manipulé pour exécuter les commandes d’un attaquant. Les principales menaces :

• Injection via les sorties des outils. Les pages Web, les problèmes GitHub et les tickets de support peuvent cacher des instructions au sein de contenus ordinaires, par exemple une ligne indiquant à l’agent d’ignorer les instructions précédentes et de supprimer les fichiers de test. La quarantaine constitue une mesure de protection : tout agent exposé à du contenu non fiable n’a qu’un accès en lecture seule. Gardez séparés les agents chargés de la lecture et ceux chargés d’agir.
• Évolution progressive des permissions. Un agent validé avec un accès en lecture seule obtient une permission d’écriture « juste pour plus de commodité », sans que personne ne réexamine la situation. Révisez régulièrement les permissions (un rythme mensuel est raisonnable) et accordez uniquement ce qui est strictement nécessaire à la tâche.
• Sécrets dans les journaux d’activité. Un enregistrement détaillé des activités dans une boucle qui tourne en continu dissémine les identifiants dans des sorties que personne ne surveille. Désactivez l’enregistrement détaillé dans les boucles en production et nettoyez ce qui reste.

Code généré non examiné. Les agents peuvent ouvrir des demandes de fusion plus rapidement que les personnes ne peuvent les lire. Si le CI ne dispose pas d’analyse statique, d’audits de dépendances ni de détection des secrets, du code vulnérable peut atteindre la branche principale sans que personne ne s’en aperçoive. L’automatisation rend ces contrôles encore plus importants, et non moins.

Un modèle de permissions rend ces règles explicites. L’exemple ci-dessous approuve automatiquement les actions à but d’observation uniquement, telles que la lecture de fichiers, l’exécution de tests et la consultation du statut ou des différences Git, et exige une intervention humaine pour effectuer des mises à jour, modifier les fichiers d’environnement, toucher au code de paiement ou toute action marquée par un indicateur de force :

# Safe agent permission model
permissions = {
    "auto_approve": [
        "Read(*)",           # read anything
        "Bash(npm test)",    # run tests
        "Bash(git status)",  # observe state
        "Bash(git diff*)",   # observe diffs
    ],
    "require_human": [
        "Bash(git push*)",   # never push without approval
        "Edit(.env*)",       # never touch secrets
        "Edit(src/payments/*)",  # never touch payments code
        "Bash(*--force*)",   # never force anything
    ]
}

Le test pour chaque règle consiste en une seule question : si cette action s’avère incorrecte, à quel point est-il coûteux de la corriger ? Un coût faible signifie approbation automatique ; un coût élevé nécessite une décision humaine. C’est en décidant cas par cas au fur et à mesure que commence le phénomène de propagation des permissions.

14. Transformer les compétences en carrière

Un parcours d’apprentissage doit mener quelque part. Voici une vision concrète des domaines où ces compétences peuvent être appliquées.

Que montrer. Évitez les clones de tutoriels. Trois projets réels qui résolvent des problèmes concrets ont bien plus de valeur :

• Un agent planifié dont les résultats sont utilisés en pratique, comme le boucle créé à l’étape 9.
• Un système multi-agents dans lequel au moins deux agents occupent des rôles différents, ce qui empêche structurellement une seule instance du modèle d’assumer les deux fonctions, comme dans le schéma créateur-vérificateur de l’étape 11.
• Un système de récupération doté de métriques d’évaluation documentées, montrant l’état avant et après une correction apportée à la récupération, plutôt que simplement le fait qu’il fonctionne.

Durée nécessaire. En estimation approximative, une personne qui maîtrise déjà Python et qui consacre de 10 à 15 heures par semaine à ses études peut s’attendre à ce que ce parcours dure environ huit mois. Considérez cela comme une donnée de planification, et non comme une promesse.

Où commencer. Les postes varient considérablement en termes de facilité d’accès pour quelqu’un qui débute :

• Ingénieur en automatisation IA au sein d’une entreprise dont l’activité principale n’est pas liée à l’IA. Il est nécessaire de disposer des compétences pour créer, par exemple, un boucle permettant de corriger des tests en une nuit. LangGraph, MCP ainsi qu’une connaissance pratique de CI suffisent ; des dizaines de frameworks ne sont pas requis.
• Ingénieur IA dans une startup dont le produit est un agent. Ce poste exige une maîtrise complète des étapes de récupération d’informations, d’évaluation, de conception et de déploiement de multiples agents, avec des exigences plus élevées.

Ingénieur en infrastructure agente au sein d’une grande entreprise technologique, ce qui ajoute des compétences en systèmes distribués à tout le reste et s’agit d’un poste senior plutôt que d’un point de départ.

Ce que la plupart des plans d’apprentissage négligent, c’est qu’il n’est pas nécessaire de tout savoir avant de commencer. Ce qui compte, c’est un agent déployé capable de résoudre un problème réel, la preuve que l’on peut quantifier son succès, ainsi que la capacité à expliquer contre quels modes de défaillance sa conception protège. Peu de candidats possèdent ces trois éléments, et aucun certificat ne peut les remplacer.

Conclusion

Pendant un certain temps, la majeure partie de l’efficacité en matière d’intelligence artificielle appliquée résidait dans les instructions fournies : une formulation plus précise, un contexte amélioré, des résultats de meilleure qualité pour chaque demande. À mesure que les modèles sont devenus suffisamment capables d’agir, cet avantage s’est déplacé vers le système qui décide des tâches auxquelles les agents se consacrent, du moment où leurs résultats sont vérifiés, de la manière dont leurs actions sont enregistrées et de ce qui se passe en cas d’échec.

• Apprenez les concepts avant les frameworks, et évaluez chaque outil en fonction du mode d’échec qu’il permet d’éviter : paresse, préférences personnelles ou dérive.
• Gardez l’état en dehors du modèle, dans un fichier ou une base de données que l’agent relit à chaque exécution.
• N’autorisez jamais l’auteur d’une modification à en être également le réviseur ; donnez au réviseur uniquement l’élément modifié et une grille d’évaluation spécifique.
• Structurez l’évaluation en allant des vérifications déterministes aux jugements humains, et mesurez le taux de modifications acceptées.

Restreignez les permissions en fonction de la réversibilité, et empêchez les agents qui lisent du contenu non fiable d’accéder à l’écriture.

Rien de tout cela ne nécessite une formation en recherche ni des compétences avancées en ajustement. Il suffit de maîtriser Python, de bien comprendre les erreurs fréquentes des LLM, et d’avoir l’habitude de mettre en place un mécanisme de vérification avant même le début du cycle. Créez le premier agent, laissez-le fonctionner toute la nuit, puis examinez ses modifications le matin.

Lectures complémentaires

• De chatbot à un seul nœud à agent géré par MCP dans LangGraph — Construisez une application LangGraph couche par couche : états et réducteurs, arêtes, boucles d’outils, threads sauvegardés, trois modes de streaming, et outils fournis via MCP.
• Concevoir une mémoire agente en quatre niveaux avec LangGraph et Amazon Bedrock — Apprenez à fournir aux agents LLM une mémoire épisodique, sémantique et procédurale fonctionnelle sur Bedrock et LangGraph, ainsi qu’à les protéger contre le poisonage, les fuites de PII et les interférences entre utilisateurs.