Module 1 — Fondamentaux des agents IA · 35 min

Qu'est-ce qu'un agent IA (et quand ne pas en construire)

Version vidéo de la leçon · le texte complet, le code et le corrigé sont ci-dessous.

Une équipe produit décide de « mettre un agent IA » dans son support client. Trois mois plus tard, le prototype impressionne en démo mais coûte 0,40 $ par conversation, répond parfois à côté et a créé 200 tickets en double un vendredi soir. Le problème n'était pas le modèle : c'était la décision initiale. Personne n'avait défini ce qu'est un agent, ce qu'il apporte par rapport à un simple enchaînement d'appels, ni ce qui justifie son coût. Cette leçon vous donne une définition opérationnelle, une grille de décision et le cadre du projet que vous construirez pendant toute la formation.

Chatbot, workflow ou agent : une définition opérationnelle

Le mot « agent » désigne aujourd'hui presque tout ce qui touche à un LLM. Pour concevoir, il faut une définition qui se traduise en code. Le critère décisif est simple : qui décide de l'étape suivante ?

Type de système	Qui décide de la suite ?	Nombre d'appels LLM	Exemple
Appel unique	Personne : une entrée, une sortie	1	Résumer un ticket
Chatbot	L'utilisateur, message après message	1 par message	Assistant FAQ sans outils
Workflow LLM	Le code, selon un chemin écrit à l'avance	Fixe (2 à 10)	Classer un e-mail, puis extraire les champs, puis rédiger un brouillon
Agent	Le modèle, selon ce qu'il observe	Variable, non connu d'avance	Chercher dans la doc, relancer une recherche, décider de créer un ticket ou d'escalader

Un agent est donc un programme dans lequel un modèle de langage choisit lui-même les actions à effectuer, observe leur résultat et recommence jusqu'à atteindre l'objectif ou une condition d'arrêt. Le code qui entoure le modèle, appelé le harnais, fournit les outils, exécute les actions, applique les règles et décide de ce qui est autorisé.

Cette distinction a une conséquence pratique : dans un workflow, vous pouvez tester chaque branche. Dans un agent, les chemins possibles sont combinatoires. Vous échangez de la prévisibilité contre de la flexibilité, et cet échange doit être justifié.

La boucle agentique

Quel que soit le framework, tout agent repose sur la même boucle :

Contexte : le modèle reçoit les instructions système, l'historique et la liste des outils.
Décision : il répond soit par un texte final, soit par une ou plusieurs demandes d'appel d'outil.
Action : votre code exécute l'outil (requête SQL, appel d'API, recherche documentaire).
Observation : le résultat est renvoyé au modèle sous forme de message.
Répétition jusqu'à ce que le modèle réponde sans demander d'outil, ou qu'une limite soit atteinte.

utilisateur ──► [LLM] ──► tool_use ──► [harnais : exécute] ──► tool_result ──┐
                  ▲                                                          │
                  └──────────────────────────────────────────────────────────┘
          arrêt : stop_reason = "end_turn", limite d'étapes, budget ou erreur

Le point à ne jamais oublier : le modèle ne fait rien lui-même. Il émet une demande structurée (« appelle create_ticket avec ces paramètres »). C'est votre code qui l'exécute ou la refuse. Sécurité, permissions, journalisation et validation humaine se jouent toutes à cet endroit. Un agent n'est jamais plus dangereux que les outils que vous lui donnez.

Le spectre de l'autonomie

Entre le workflow rigide et l'agent libre, il existe des positions intermédiaires. Les situer vous évite de construire trop d'autonomie d'un coup.

Niveau	Description	Exemple pour un support client
0	Appel unique, pas d'outil	Reformuler une réponse rédigée par un humain
1	Workflow fixe	Classer la demande → rechercher dans la KB → rédiger
2	Routeur	Un LLM choisit une branche parmi 4 workflows prédéfinis
3	Agent à outils en lecture	L'agent cherche librement, mais ne modifie rien
4	Agent à outils en écriture, avec garde-fous	Crée des tickets, escalade, sous validation pour les actions sensibles
5	Agent autonome longue durée	Traite une file de tickets toute la nuit sans supervision

La plupart des produits utiles en entreprise se situent aux niveaux 2 à 4. Le niveau 5 existe, mais il exige une maturité d'évaluation et d'observabilité que peu d'équipes ont au démarrage. Vous progresserez dans cette formation du niveau 3 au niveau 4, puis vous verrez au module 5 quand combiner routeur et agent.

Quand ne pas construire d'agent

Un agent coûte plus cher (plusieurs appels par demande, un historique renvoyé à chaque tour), répond plus lentement et se comporte de façon moins prévisible qu'un workflow. Avant d'en écrire un, passez la demande à travers quatre critères :

Complexité : la tâche comporte-t-elle plusieurs étapes dont l'enchaînement dépend des résultats intermédiaires ? « Extraire le numéro de facture d'un e-mail » : non. « Comprendre pourquoi la facture d'un client est fausse » : oui.
Valeur : le gain justifie-t-il un coût de 5 à 20 fois celui d'un appel unique ? Automatiser 30 % des tickets niveau 1 d'une équipe de 12 personnes, oui. Générer le texte d'un bouton, non.
Viabilité : un modèle actuel réussit-il la tâche avec les informations disponibles ? Si un humain compétent ne peut pas la résoudre avec les mêmes outils et documents, l'agent ne le pourra pas non plus.
Coût de l'erreur : une erreur est-elle détectable et réparable ? Répondre à une question sur l'export PDF : une erreur se corrige. Rembourser 4 000 € : non, il faut un humain.

Si l'un des quatre critères répond « non », restez au niveau inférieur. Quelques signaux d'alerte fréquents :

Le processus est déjà décrit dans une procédure pas à pas. Codez la procédure, utilisez le LLM seulement pour les étapes de langage (comprendre, rédiger).
La latence doit être inférieure à une seconde. Une boucle de trois tours dépasse souvent cinq secondes.
Le résultat doit être identique à chaque exécution. Un agent ne le garantit pas.
Personne ne sait dire à quoi ressemble une bonne réponse. Sans critère de réussite, vous ne pourrez ni évaluer ni améliorer.

Règle pratique : commencez par la solution la plus simple qui fonctionne, mesurez-la, puis ajoutez de l'autonomie uniquement là où elle apporte un gain mesuré.

Le projet fil rouge : Helia

Tout au long de la formation, vous construisez Helia, l'agent de support client de FacturaPro, un logiciel SaaS de facturation fictif utilisé par 8 000 PME. Le support reçoit environ 1 500 demandes par jour : questions d'usage (export PDF, TVA, relances), bugs, problèmes de paiement, demandes de remboursement ou de suppression de compte.

Helia doit :

Répondre aux questions en s'appuyant sur la base de connaissances (environ 300 articles), avec citation de l'article utilisé.
Créer des tickets structurés quand un problème exige une intervention technique.
Escalader à un humain les demandes sensibles (remboursement, litige, suppression de compte, client très mécontent) ou quand elle n'est pas sûre.
Se souvenir du contexte client sans exploser le budget de tokens.
Être évaluée, sécurisée et observée comme n'importe quel service de production.

Et Helia ne doit pas : rembourser, modifier un abonnement, accéder aux données d'un autre client, ni promettre un délai qu'aucun système ne garantit. Écrire ce périmètre négatif dès le départ est aussi important que la liste des capacités.

Une conversation cible :

Client : Ma facture de mars affiche deux fois la TVA, je veux être remboursé.
Helia  : [search_kb("TVA doublée facture mars")]  → KB-114 trouvé
         [get_customer("cus_8812")]                → plan Pro, 2 tickets ouverts
         Remboursement = action sensible → escalade
         [escalate_to_human(reason="refund_request", priority="high")]
Helia  : Il s'agit d'un problème connu, corrigé depuis le 4 avril [KB-114].
         Un conseiller va traiter votre demande de remboursement aujourd'hui.

Pour le code, vous utiliserez le SDK Anthropic en Python (TypeScript ponctuellement) avec trois modèles : claude-haiku-4-5 (rapide et économique), claude-sonnet-5 (polyvalent) et claude-opus-5-5 (raisonnement le plus poussé). La leçon suivante explique comment choisir entre eux.

Mise en pratique

Vous êtes consultant pour FacturaPro. Quatre demandes d'automatisation arrivent. Pour chacune, appliquez les quatre critères (complexité, valeur, viabilité, coût de l'erreur), placez la solution sur le spectre d'autonomie (niveau 0 à 5) et justifiez en trois lignes maximum.

Traduire automatiquement en anglais les articles de la base de connaissances à chaque publication.
Répondre aux questions des clients sur l'utilisation du logiciel (export, TVA, relances, modèles de facture).
Détecter dans les e-mails entrants les demandes de résiliation et les transmettre au service commercial.
Rembourser automatiquement les clients touchés par le bug de TVA de mars.

Livrable : un tableau de quatre lignes (demande, verdict des 4 critères, niveau retenu, justification).

Voir le corrigé

Demande	Critères	Niveau	Justification
1. Traduction des articles	Complexité faible (une étape), valeur réelle, viable, erreur réparable	0 (appel unique)	Une entrée, une sortie. Un script déclenché par le CMS appelle le modèle et enregistre la traduction, avec relecture humaine avant publication.
2. Questions d'usage	Complexité variable (une ou plusieurs recherches), forte valeur (volume), viable, erreur réparable	3 puis 4	Le nombre de recherches dépend de la question : c'est le cas d'usage type d'un agent. On démarre en lecture seule (niveau 3), on ajoute création de ticket et escalade ensuite (niveau 4). C'est Helia.
3. Détection des résiliations	Complexité faible (classification), valeur moyenne, viable, erreur modérée	1 (workflow)	Classifier puis router est un chemin fixe. Un appel de classification avec sortie structurée, suivi d'une règle de code, suffit. Un agent n'apporterait que du coût.
4. Remboursement automatique	Complexité faible, valeur réelle, mais coût de l'erreur élevé (argent, irréversible)	Pas de LLM pour l'action	La liste des clients touchés se calcule par une requête SQL sur les factures de mars. Le remboursement est une opération comptable déterministe, validée par un humain. Le LLM peut au mieux rédiger l'e-mail d'excuse.

Points à vérifier dans votre réponse :

Vous n'avez pas proposé d'agent pour les demandes 1 et 3 : leur chemin est connu d'avance.
Pour la demande 4, vous avez identifié que le problème n'est pas un problème de langage. L'erreur classique est de vouloir un agent « qui gère les remboursements ».
Pour la demande 2, vous avez prévu une montée progressive en autonomie plutôt qu'un agent en écriture dès le premier jour.

À retenir

Un agent se définit par un critère : c'est le modèle qui choisit l'étape suivante en fonction de ce qu'il observe.
Le modèle ne fait que demander des actions ; le harnais les exécute, et c'est là que se jouent sécurité et contrôle.
Avant de construire un agent, vérifiez complexité, valeur, viabilité et coût de l'erreur. Un seul « non » suffit à rester sur un workflow.
La plupart des produits utiles se situent entre le routeur et l'agent à outils en écriture sous garde-fous.
Helia, l'agent de support de FacturaPro, a un périmètre positif (répondre, tickets, escalade) et un périmètre négatif explicite (jamais de remboursement ni d'accès inter-clients).