• Introduction
• Pourquoi les agents IA?
• C'est quoi un agent IA ?
• LLM brut vs Agent IA
• Les outils (Tools) et l'action sur l'environnement
• Les skills : des méthodes réutilisables
• La mémoire et l'état
• Pourquoi des frameworks ?
• Quand l'orchestration devient vraiment intéressante
• Garde-fous, éthique et gouvernance
• Pourquoi c'est important d'apprendre à les concevoir

En 2024, on demandait à un modèle de langage : « Rédige-moi un courriel. »
En 2026, on lui dit : « Trouve le bon contact dans le CRM (Gestion de la Relation Client), rédige le courriel, vérifie la politique interne, envoie-le et mets à jour le dossier. »

Ce n'est plus le même métier. Ce n'est plus la même technologie. Ce n'est plus la même compétence.

Bienvenue dans l'ère des agents IA, des systèmes qui ne se contentent plus de répondre, mais qui agissent, en utilisant des outils, en gardant un état (mémoire), en prenant des décisions intermédiaires et en produisant des résultats concrets dans le monde réel.

Ce que vous allez apprendre

Cette leçon est conçue pour des personnes qui entendent le terme « agents IA » pour la première fois. À la fin, vous serez capables de :

Plan de la leçon

Le chatbot ne suffit plus

Pendant quelques années, la promesse de l'IA générative se résumait à ceci : posez une question, obtenez une réponse. On discutait avec un modèle de langage. Il rédigeait des courriels, résumait des textes, traduisait des documents. C'était utile, parfois impressionnant, mais fondamentalement passif.

Le problème ? Les vrais processus en entreprise ne ressemblent pas à une conversation. Ils impliquent plusieurs étapes, des systèmes différents, des validations, des données en temps réel et des actions concrètes. Demander à un chatbot de « gérer le remboursement d'un client » ne fonctionne pas si le modèle ne peut pas accéder au CRM, vérifier la politique de retour, émettre le remboursement et envoyer la confirmation.

C'est précisément ce fossé — entre répondre et agir — que les agents IA viennent combler.

Le coût d'un workflow se mesure

La viabilité d'un agent dépend aussi d'une question simple : combien coûte une tâche menée à terme ?

Le tarif dépend du modèle, des tokens en entrée et en sortie, du cache et des outils utilisés. Une comparaison de prix n'a de sens qu'à date, qualité et conditions comparables.

Un workflow peut enchaîner 5 ou 10 appels pour analyser, décider, agir et vérifier. Mesurez le coût de cet ensemble sur des cas représentatifs, en tenant compte des erreurs et des reprises.

Sources des pourcentages : McKinsey, The State of AI 2025 et Deloitte, rapport 2026 (3 235 responsables dans 24 pays). Ces enquêtes ne mesurent pas le coût d’inférence.

Ce que les entreprises veulent vraiment

Les grandes organisations ne s'intéressent pas aux agents IA par curiosité. Elles y voient un levier pour automatiser des processus complets, pas juste des tâches isolées. Voici des exemples déjà en production :

Le point commun ? Ce ne sont plus des démos. Ce sont des workflows multi-étapes, connectés à des systèmes réels, avec des garde-fous et une supervision humaine intégrée.

Le fossé entre ambition et exécution

Si l'enthousiasme est réel, la maturité ne suit pas encore. Les enquêtes récentes révèlent un écart significatif :

• 85 % des entreprises prévoient de personnaliser leurs agents pour les adapter à leurs besoins spécifiques.
• Mais seulement 21 % ont aujourd'hui un modèle de gouvernance mature pour encadrer ces agents autonomes.
• Les risques qui inquiètent le plus : la confidentialité des données (73 %), la conformité juridique (50 %) et la qualité des résultats (46 %).
• Les entreprises qui réussissent le mieux sont celles qui repensent leurs processus au lieu de simplement ajouter un agent sur un flux existant.

Une nouvelle compétence stratégique

Pendant quelques années, la compétence la plus en vue était le prompt engineering : savoir formuler la bonne question au bon modèle. C'est toujours utile, mais ce n'est plus suffisant.

Ce qui compte désormais, c'est la capacité à concevoir, assembler et gouverner des systèmes agentiques : choisir les bons outils, structurer la mémoire, définir le flux d'orchestration, intégrer la supervision humaine et garantir la traçabilité.

C'est exactement là que les entreprises constatent un manque de compétences. Les enquêtes montrent que la préparation en termes d'infrastructure, de données et surtout de talents est encore en retard par rapport à l'ambition stratégique. C'est précisément ce fossé qui rend l'apprentissage de l'orchestration agentique aussi pertinent.

→ Module suivant : Maintenant qu'on comprend pourquoi les agents IA sont importants, on va définir précisément ce que c'est.

Une définition simple

Le terme « agent IA » est partout, et souvent utilisé de manière floue. Certains l'utilisent pour parler d'un chatbot amélioré, d'autres pour décrire un robot autonome. Pour cette leçon, on va s'appuyer sur la définition qui fait consensus dans les documentations techniques actuelles :

Chaque mot compte dans cette définition. Décortiquons-la :

L'analogie qui clarifie tout

Pour bien comprendre où se situe l'agent par rapport à ce qu'on connaissait déjà, une analogie simple circule dans l'industrie :

Le chef de projet ne fait pas tout lui-même. Il coordonne, délègue, vérifie et ajuste. C'est exactement ce que fait un agent IA : le modèle de langage raisonne et décide, mais ce sont les outils qui exécutent les actions concrètes.

La boucle de fonctionnement d'un agent

Un agent ne fonctionne pas en une seule étape. Il suit un cycle itératif — une boucle qu'il répète jusqu'à atteindre son objectif ou rencontrer une condition d'arrêt. Cette boucle comporte quatre phases :

Les briques d'un agent

Si on ouvre le capot d'un agent IA, on trouve un ensemble de composants qui travaillent ensemble. Chaque brique a un rôle précis. On les détaillera dans les modules suivants, mais voici la vue d'ensemble :

Ce qu'un agent IA n'est pas

Pour éviter les malentendus fréquents, clarifions ce que le terme ne désigne pas :

Un test simple pour savoir si c'est un agent

Voici une question rapide à se poser devant n'importe quel système IA :

→ Module suivant : On sait maintenant ce qu'est un agent. Mais quelle est la vraie différence avec un LLM brut qu'on utilise dans un chat ? C'est la rupture conceptuelle qu'on va explorer.

Le LLM brut : puissant, mais limité

Quand vous utilisez un modèle de langage dans une interface de chat — sans outils, sans mémoire externe, sans boucle —, vous utilisez ce qu'on appelle un LLM brut. C'est un moteur de raisonnement remarquable, capable de comprendre des instructions complexes, de rédiger, d'analyser et de raisonner.

Mais il a des limites fondamentales :

En résumé, un LLM brut est une fonction : on lui donne une entrée, il produit une sortie. Point. C'est extrêmement utile, mais ce n'est pas suffisant pour les processus qui nécessitent plusieurs étapes, des données fraîches ou des effets concrets.

L'agent : de la fonction au système

L'agent prend le même moteur de raisonnement et l'entoure d'une infrastructure qui compense chacune de ces limites :

Comparaison directe

Mettons les deux côte à côte sur les dimensions clés :

Le mécanisme clé : le tool calling

La capacité technique qui rend tout ça possible s'appelle le tool calling (ou function calling). C'est le pont entre le raisonnement du modèle et l'action dans le monde.

Voici comment ça fonctionne, étape par étape :

Exemple concret : la même tâche, deux approches

Imaginons qu'un gestionnaire demande : « Quel temps fait-il à Montréal ? Si c'est en dessous de –10°C, envoie un avertissement à l'équipe terrain. »

Le même modèle de langage est utilisé dans les deux cas. La différence, c'est que l'agent a accès à des outils et à une boucle de décision qui lui permettent de transformer du raisonnement en action.

Aller plus loin : la délégation entre agents

Un LLM brut travaille seul. Un agent peut non seulement utiliser des outils, mais aussi déléguer à d'autres agents spécialisés. C'est ce qu'on appelle un handoff.

Prenons un agent de service client. Quand un utilisateur pose une question :

• L'agent de triage analyse la demande et identifie le sujet.
• S'il s'agit d'une réservation, il délègue à l'agent réservation.
• S'il s'agit d'un remboursement, il délègue à l'agent remboursement.
• Chaque agent spécialisé a ses propres outils, ses propres instructions et son propre périmètre.

Ce n'est pas un concept futuriste — c'est un pattern de conception standard dans les frameworks actuels (OpenAI Agents SDK, LangGraph, CrewAI). On y reviendra en détail dans le module sur l'orchestration.

→ Module suivant : On a vu que les tools sont la pièce maîtresse qui permet à l'agent d'agir. On va maintenant les explorer en profondeur : comment on les définit, comment le modèle les choisit, et ce que ça signifie concrètement d'« agir sur son environnement ».

Qu'est-ce qu'un tool ?

Un tool (outil) est une capacité externe mise à la disposition du modèle. C'est une fonction que l'agent peut appeler pour faire quelque chose que le modèle de langage ne peut pas faire seul : aller chercher une donnée en temps réel, exécuter un calcul, interroger une base de données, envoyer un message, déclencher une action dans un système.

Pensez-y comme une porte entre le raisonnement du modèle et le monde extérieur. Sans tools, le modèle est enfermé dans sa bulle de texte. Avec des tools, il peut percevoir, agir et produire des effets concrets.

Exemples concrets de tools

Pour rendre ça tangible, voici des exemples de tools qu'on pourrait donner à un agent, classés par type d'action :

Comment on définit un tool

Un tool n'est pas une boîte noire magique. Pour que le modèle puisse l'utiliser, le développeur doit lui fournir trois éléments essentiels :

Exemple : définir un tool météo

Voici ce que le développeur fournit au modèle (en JSON simplifié) :

{
  "name": "get_weather",
  "description": "Retourne la température actuelle et les
                  conditions météo pour une ville donnée.",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "Nom de la ville (ex: Montréal)"
      }
    },
    "required": ["city"]
  }
}

Et voici ce que le modèle émet quand il décide d'appeler ce tool :

{
  "tool": "get_weather",
  "arguments": { "city": "Montréal" }
}

Le runtime reçoit cet appel, exécute la vraie fonction (qui contacte une API météo), puis retourne le résultat au modèle — par exemple {"temperature": -14, "conditions": "neige légère"}. Le modèle peut ensuite raisonner sur ce résultat.

Comment le modèle choisit le bon tool

Un agent a souvent accès à plusieurs tools en même temps. Comment le modèle sait-il lequel appeler ? Il ne suit pas de règles codées en dur — il raisonne.

Concrètement, à chaque tour de la boucle, le modèle reçoit :

• Les instructions de l'agent (son rôle, ses objectifs).
• La conversation en cours (ce que l'utilisateur a demandé, les résultats précédents).
• La liste des tools disponibles, avec leurs descriptions et schémas.

Sur cette base, le modèle peut :

Le développeur peut aussi forcer le comportement : obliger le modèle à utiliser un tool spécifique, exiger qu'il utilise au moins un tool, ou le laisser choisir librement. Mais dans la plupart des cas, on laisse le modèle décider — c'est justement là que réside l'intelligence de l'agent.

Agir sur son environnement : le passage décisif

C'est probablement l'idée la plus importante de cette leçon. Les tools ne servent pas seulement à récupérer de l'information. Ils permettent à l'agent de produire des effets dans le monde réel. C'est le passage de l'IA générative à l'IA opérationnelle.

Voici le spectre complet de ce qu'un agent peut faire via ses tools :

Vers un standard : le Model Context Protocol (MCP)

Jusqu'à récemment, chaque framework et chaque fournisseur avait sa propre façon de définir et connecter des tools. Ça fonctionnait, mais créait des intégrations fragiles et non portables : un tool écrit pour un framework ne marchait pas dans un autre.

Pour résoudre ce problème, un protocole ouvert a émergé : le Model Context Protocol (MCP). L'idée est simple : créer un standard universel pour connecter un agent à des outils et des sources de données externes — un peu comme le USB-C a standardisé les câbles de recharge.

L'avantage majeur : un tool défini en MCP est portable. Il fonctionne avec n'importe quel agent compatible MCP, qu'il utilise LangGraph, CrewAI, Google ADK ou l'OpenAI SDK. On connecte une fois, on réutilise partout. C'est un changement de paradigme pour l'écosystème.

Le flux complet en un coup d'œil

Voici comment tout s'enchaîne quand un agent utilise un tool :

→ Module suivant : Les tools permettent à l'agent d'agir. Comment lui fournir une méthode réutilisable pour accomplir une tâche ? C'est le rôle des skills.

Module 5

Les skills : des méthodes réutilisables

Un outil permet d’agir. Un skill décrit une méthode pour accomplir une tâche avec les moyens disponibles.

À retenir

Un skill n’est ni un nouvel entraînement du modèle, ni une mémoire, ni une autorisation d’exécuter du code. Il ne garantit pas un résultat correct : les permissions et les validations restent nécessaires. L’application doit prendre en charge ce format.

Le problème : un LLM n'a pas de mémoire

Un modèle de langage, par nature, est sans état (stateless). Chaque appel est indépendant. Le modèle ne « se souvient » de rien entre deux requêtes. Si vous lui parlez aujourd'hui puis revenez demain, il ne sait pas qui vous êtes ni de quoi vous avez discuté.

Ce qui donne l'illusion de mémoire dans un chatbot, c'est un truc d'ingénierie simple : à chaque tour de conversation, on renvoie au modèle tout l'historique précédent dans le même prompt. Le modèle ne se souvient pas — on lui rappelle tout à chaque fois.

Ça fonctionne pour une conversation courte. Mais pour un agent qui doit gérer un processus sur plusieurs heures, jours ou semaines, ou qui doit se rappeler des préférences d'un utilisateur d'une session à l'autre, cette approche ne tient plus. Il faut une vraie stratégie de mémoire.

Les types de mémoire d'un agent

Les frameworks actuels distinguent plusieurs niveaux de mémoire. Chacun répond à un besoin différent :

Vue d'ensemble : les 4 niveaux de mémoire

La mémoire est un choix d'architecture

C'est un point essentiel pour des débutants : la mémoire d'un agent n'est pas automatique. Elle n'apparaît pas toute seule parce qu'on utilise un framework. C'est le développeur qui décide :

• Quoi garder : Tout l'historique ? Seulement les faits importants ? Les résumés ? Les préférences utilisateur ?
• Où le stocker : En mémoire vive (rapide, mais perdu au redémarrage) ? Dans une base de données ? Dans un fichier ? Dans un store clé-valeur ?
• Combien de temps : Le temps de la session ? Indéfiniment ? Avec une date d'expiration ?
• Comment le retrouver : Par recherche exacte (clé-valeur) ? Par recherche sémantique (base vectorielle) ? Par chronologie ?
• Qui y a accès : Seulement cet agent ? Tous les agents du même workflow ? L'utilisateur peut-il voir ou corriger ce que l'agent a retenu ?

Ce que proposent les frameworks

Les principaux frameworks offrent des mécanismes différents pour gérer la mémoire. Voici un aperçu simplifié :

Un concept avancé : l'exécution durable

Certains workflows agentiques prennent du temps. Beaucoup de temps. Un processus d'approbation peut durer des jours. Une analyse multi-sources peut prendre des heures. Et entre-temps, un serveur peut redémarrer, une connexion peut tomber, un humain peut mettre du temps à répondre.

C'est là qu'intervient le concept d'exécution durable (durable execution) : la capacité d'un agent à :

• Sauvegarder son état complet à chaque étape (checkpoint).
• Reprendre exactement là où il en était après une interruption — sans perte de contexte.
• Attendre indéfiniment une réponse humaine ou un événement externe sans bloquer de ressources.
• Rembobiner (rewind) à un point antérieur si quelque chose a mal tourné.

C'est une capacité qui distingue les frameworks pensés pour la production (comme LangGraph et Google ADK) de simples scripts. Sans exécution durable, un workflow qui tombe au milieu doit tout recommencer depuis le début.

Partage d'état entre agents

Dans un système multi-agent, la mémoire pose une question supplémentaire : comment les agents partagent-ils l'information entre eux ?

Plusieurs approches existent :

Les pièges courants

La gestion de la mémoire est un domaine où les erreurs sont fréquentes. Voici les pièges les plus courants à connaître :

→ Module suivant : On connaît maintenant le rôle du modèle, des tools, des skills, de la mémoire et de la boucle. Mais comment tout ça tient ensemble quand les tâches deviennent complexes ? C'est le rôle des frameworks d'orchestration.

Pourquoi ne pas tout coder à la main ?

En théorie, on pourrait construire un agent IA avec juste une API de modèle de langage et du code Python. On appelle le modèle, on parse sa réponse, on appelle un tool si nécessaire, on reboucle. Ça marche… pour un prototype.

En pratique, dès qu'on veut passer en production, les problèmes s'accumulent vite :

Ce qu'un framework apporte

Un framework d'orchestration agentique, c'est un ensemble de briques prêtes à l'emploi pour construire, exécuter et surveiller des agents. Voici ce qu'ils fournissent en commun :

Panorama des frameworks

L'écosystème s'est stabilisé autour de cinq frameworks principaux. Chacun a une philosophie différente. Plutôt que de les comparer sur une grille abstraite, voyons-les comme des outils de construction qui répondent à des besoins différents.

Comparaison rapide

Voici un résumé des différences clés pour choisir le bon framework selon le besoin :

Comment choisir ?

Il n'y a pas de « meilleur » framework universel. Le bon choix dépend du besoin :

→ Module suivant : On connaît les briques et les frameworks. Mais dans quels cas l'orchestration multi-étapes et multi-agent devient-elle vraiment intéressante ? Voyons les cas d'usage concrets.

Commençons par l'essentiel : ce n'est pas toujours nécessaire

Avant de parler de cas où l'orchestration brille, un avertissement important : un agent seul avec de bons tools suffit souvent. L'erreur classique est de construire un système multi-agent sophistiqué pour un problème qu'un simple agent avec quelques outils résoudrait très bien.

L'orchestration devient intéressante quand la tâche dépasse ce cadre simple. Voyons quand.

Les signaux qui appellent l'orchestration

Voici les caractéristiques d'une tâche qui bénéficie réellement d'une orchestration structurée :

Cinq cas d'usage concrets

Voici des scénarios réels où l'orchestration transforme un simple assistant en système opérationnel. Pour chacun, on montre pourquoi un agent seul ne suffit pas.

Les patterns d'orchestration récurrents

À travers ces cas d'usage, on voit émerger des patterns réutilisables :

Orchestration déterministe vs raisonnement dynamique

Un point subtil mais important : il y a deux façons de piloter le flux d'un système agentique, et les meilleurs systèmes combinent les deux.

→ Module suivant : Plus un agent est autonome, plus il peut faire de dégâts. Comment s'assurer qu'il reste dans les limites ? C'est le sujet des garde-fous, de l'éthique et de la gouvernance.

Le paradoxe de l'autonomie

Tout ce qu'on a appris dans les modules précédents — les tools, les skills, la mémoire, la boucle itérative, l'orchestration multi-agent — rend les agents IA puissants. Mais cette puissance a un revers : plus un agent peut agir, plus il peut mal agir.

Un chatbot qui génère une mauvaise réponse, c'est gênant. Un agent qui envoie un courriel erroné à un client, supprime des données en production ou approuve une transaction non autorisée, c'est un incident opérationnel.

C'est pourquoi la question n'est jamais « est-ce que l'agent peut faire ça ? » mais plutôt « est-ce qu'on veut qu'il le fasse, dans quelles conditions, et comment on s'assure qu'il reste dans les limites ? »

Les garde-fous techniques (guardrails)

Les guardrails sont des mécanismes intégrés au système agentique pour contrôler ce que l'agent peut faire et ne peut pas faire. Ce n'est pas un ajout cosmétique — c'est une brique architecturale au même titre que les tools ou la mémoire.

On peut les organiser en quatre couches :

L'humain dans la boucle (HITL)

Le garde-fou le plus puissant reste l'humain. Le concept de Human-in-the-Loop (HITL) consiste à insérer des points de contrôle humain dans le workflow de l'agent.

La question clé est : quand impliquer l'humain ? Trop de checkpoints et l'agent ne sert à rien — on fait tout manuellement. Pas assez et on perd le contrôle. Voici un cadre de décision :

La traçabilité : savoir pourquoi l'agent a fait ça

Quand un agent produit un mauvais résultat — et ça arrivera — il faut pouvoir comprendre pourquoi. C'est le rôle du tracing (traçabilité) : l'enregistrement détaillé de chaque étape du raisonnement et de l'exécution de l'agent.

Un bon système de tracing capture :

Tous les frameworks majeurs intègrent du tracing nativement : OpenAI SDK a son propre système de traces, LangChain s'appuie sur LangSmith, CrewAI offre du tracing en temps réel, et Google ADK supporte OpenTelemetry. C'est devenu un standard, pas un luxe.

La gouvernance : au-delà de la technique

Les guardrails et le tracing sont des outils techniques. La gouvernance, c'est le cadre organisationnel qui décide comment ces outils sont utilisés, par qui, et selon quelles règles.

Une gouvernance mature des agents IA couvre plusieurs dimensions :

Penser en niveaux de confiance

Une façon pragmatique de concevoir la gouvernance est de raisonner en niveaux de confiance progressifs :

L'idée est de monter progressivement dans ces niveaux — tâche par tâche, pas globalement. Un même agent peut être au niveau 4 pour la lecture de données et au niveau 2 pour l'envoi de courriels.

→ Module suivant : On a fait le tour complet — du concept à la gouvernance. Pour conclure, voyons pourquoi tout ça est si important à apprendre maintenant, et quel avenir ça ouvre.

Le décalage entre l'offre et la demande

Récapitulons ce qu'on a appris dans les modules précédents :

• Selon Deloitte (rapport 2026), 74 % des répondants anticipent un usage des agents IA au moins modéré dans leur entreprise d’ici 2027.
• Les outils existent : les frameworks sont matures, les coûts sont viables, les protocoles se standardisent.
• Mais seulement 21 % ont la gouvernance nécessaire, et la préparation en matière de talents est systématiquement citée comme le point le plus faible.

C'est ce décalage qui crée l'opportunité. Les organisations savent ce qu'elles veulent construire. Elles manquent de personnes qui savent comment le construire — de façon fiable, sécuritaire et maintenable.

La compétence a changé de nature

Pendant quelques années, la compétence la plus valorisée en IA était le prompt engineering : savoir formuler la bonne instruction pour obtenir la meilleure réponse. C'est toujours utile — mais ce n'est plus suffisant.

Ce que les entreprises recherchent maintenant, c'est la capacité à concevoir des systèmes complets. Voici comment la compétence a évolué :

Ce que vous savez maintenant

En parcourant cette leçon, vous avez acquis un socle de compréhension solide. Faisons le point :

Ce qui vient ensuite

Cette leçon était une introduction conceptuelle. Vous avez la carte mentale. Pour passer à la pratique, voici les prochaines étapes naturelles :

Ressources pour aller plus loin

Le mot de la fin

Les agents IA ne sont pas une mode passagère. Ils représentent un changement fondamental dans la manière dont l'intelligence artificielle s'intègre aux organisations : on passe d'outils qui assistent à des systèmes qui exécutent.

Ce changement crée un nouveau métier — ou du moins, de nouvelles responsabilités. Celui ou celle qui sait concevoir un agent fiable, bien outillé, traçable et gouvernable possède une compétence rare et précieuse. Les frameworks sont accessibles. Les protocoles se standardisent. Les entreprises cherchent activement ces profils.

Vous avez maintenant la carte. Il reste à emprunter le chemin.

— Fin de la leçon —