Dans la partie 1, nous avons vu pourquoi les étudiants et les professionnels en poste ont intérêt à comprendre les systèmes agentiques, et pourquoi apprendre un framework n’est pas la vraie compétence qui compte pour une carrière.
Passons maintenant du pourquoi au comment.
Un premier agent peut être étonnamment facile à construire.
Donnez un objectif à un modèle, connectez-lui un ou deux outils et laissez-le décider quand s’en servir.
La question difficile vient ensuite :
Comment transformer cette démo qui fonctionne en un système auquel vous pouvez vraiment faire confiance ?
C’est là que commence l’ingénierie agentique.
Commencer par un seul problème utile
Imaginons que nous voulions construire un assistant de recherche.
L’utilisateur demande :
Qu’est-ce qui a changé dans la sécurité de l’IA cette semaine ? Trouve des sources fiables et prépare un court résumé avec citations.
Une version simple pourrait ressembler à ceci :
Question → modèle d’IA → outil de recherche → sources → réponse
C’est déjà plus qu’un chatbot ordinaire, car le modèle peut décider quand il a besoin d’informations extérieures et utiliser un outil pour les obtenir.
Pour un premier projet, cela suffit.
Ne commencez pas par créer un agent chercheur, un agent relecteur, un agent de citations, un agent rédacteur et un agent gestionnaire.
Prouvez d’abord qu’un seul agent peut bien résoudre un seul problème utile.
Ce principe compte, car chaque agent, outil et workflow supplémentaire ajoute des endroits où quelque chose peut mal tourner.
Étape 1 : donner des outils à l’agent
Sans outils, un modèle peut surtout raisonner sur les informations dont il dispose déjà.
Les outils lui permettent d’agir.
Notre assistant de recherche pourrait disposer :
- d’un outil de recherche web
- d’un outil de lecture de pages
- d’une fonction qui enregistre les sources utiles
La boucle de base devient :
Comprendre l’objectif
→ déterminer quelle information manque
→ choisir un outil
→ l’utiliser
→ observer le résultat
→ décider de la suite
Cette boucle simple est au cœur de nombreux systèmes agentiques.
Mais la conception des outils compte.
Un outil doit avoir un objectif clair, des entrées prévisibles et des résultats compréhensibles.
Si un agent dispose de 50 outils aux noms vagues, choisir le bon devient plus difficile.
Un ensemble plus restreint d’outils bien conçus vaut souvent mieux que de donner à un agent l’accès à tout.
Les recommandations d’ingénierie actuelles d’Anthropic le disent directement : la qualité des outils et des limites claires entre eux peuvent avoir un effet sensible sur les performances d’un agent.
Étape 2 : n’ajouter un état que lorsque le système en a besoin
Supposons que notre assistant de recherche consulte cinq sources.
Il doit maintenant se souvenir :
- de ce qu’il a déjà cherché
- des sources qu’il a retenues
- des affirmations qui ont encore besoin de preuves
- de l’étape de la tâche qu’il a atteinte
C’est ce qu’on appelle l’état.
L’état répond à la question :
Que se passe-t-il dans cette tâche précise, en ce moment ?
La mémoire est liée à l’état, mais elle est différente.
La mémoire peut conserver d’une tâche à l’autre des informations utiles, comme les sources préférées d’un utilisateur ou ses préférences de recherche récurrentes.
Pour un débutant, il suffit de garder cette distinction simple :
État = ce dont cette tâche a besoin pour continuer.
Mémoire = les informations utiles au-delà de cette tâche.
N’ajoutez pas de mémoire permanente simplement parce qu’un framework d’agents le permet.
Conservez des informations parce que le système en a réellement besoin.
Étape 3 : décider de ce que l’IA doit contrôler
C’est l’une des décisions de conception les plus importantes.
Certains processus sont prévisibles.
Par exemple :
rechercher → extraire les sources → valider les citations → rédiger le résumé
Si ces étapes doivent toujours se dérouler dans cet ordre, un workflow classique peut être préférable à un modèle qui réinvente le processus à chaque fois.
D’autres problèmes sont moins prévisibles.
Un agent de recherche peut découvrir qu’une source en contredit une autre et décider qu’il lui faut une nouvelle recherche.
C’est là que la prise de décision par le modèle devient utile.
Un système concret combine souvent les deux.
Le workflow contrôle ce qui doit se produire.
L’agent décide de ce qui demande du jugement.
Cette distinction aide à éviter une autonomie inutile.
Les recommandations actuelles de Microsoft vont dans le même sens : utilisez des approches plus simples lorsqu’elles suffisent, et des workflows lorsque l’ordre d’exécution explicite et les points de contrôle comptent.
Étape 4 : intégrer l’échec à la conception
Une démo suppose généralement que tout fonctionne.
La production, non.
L’API de recherche peut tomber en panne.
Un site web peut être indisponible.
Un outil peut renvoyer des informations incomplètes.
Le modèle peut choisir le mauvais outil.
Une tâche de longue durée peut s’arrêter à mi-chemin.
Un système agentique fiable doit avoir des réponses à des questions comme :
- Cette étape doit-elle être relancée ?
- Combien de fois ?
- La tâche peut-elle continuer sans cet outil ?
- Doit-elle revenir au dernier point de contrôle réussi ?
- Quand doit-elle s’arrêter ?
- Quand doit-elle demander à un humain ?
Pour notre assistant de recherche, l’échec de la consultation d’une source ne devrait pas forcément faire échouer toute la tâche.
Le système pourrait enregistrer l’échec, essayer une autre source et continuer.
Mais s’il ne peut pas vérifier une affirmation essentielle, il ne doit pas en inventer une en silence.
C’est toute la différence entre se remettre d’un échec et cacher un échec.
Étape 5 : évaluer le résultat
C’est là que beaucoup de tutoriels sur les agents s’arrêtent trop tôt.
L’agent a produit une réponse.
Mais était-elle bonne ?
Pour notre assistant de recherche, nous pourrions évaluer les points suivants :
- Les sources étaient-elles pertinentes ?
- Les affirmations étaient-elles étayées ?
- Les citations étaient-elles rattachées aux bonnes affirmations ?
- A-t-il utilisé des sources faisant autorité lorsqu’elles existaient ?
- A-t-il inventé quoi que ce soit ?
- A-t-il terminé dans un coût et un délai acceptables ?
C’est ce qu’on appelle une évaluation, ou « eval ».
Le logiciel traditionnel nous donne souvent une réponse simple :
test réussi / test échoué
Les systèmes agentiques sont plus difficiles, car certains de leurs résultats ne sont pas parfaitement déterministes.
Cela ne veut pas dire qu’on ne peut pas les tester.
Cela veut dire que nous devons définir à quoi ressemble un bon résultat.
Les recommandations actuelles d’Anthropic sur l’évaluation des agents le disent clairement : comme les agents agissent sur plusieurs étapes, modifient un état et réagissent à des résultats intermédiaires, l’évaluation doit examiner le comportement du système plutôt que sa seule phrase finale.
Pour les étudiants en particulier, apprendre l’évaluation tôt est plus utile que d’ajouter un framework de plus à son CV.
Étape 6 : rendre l’agent observable
Si la réponse finale est fausse, vous devez savoir pourquoi.
Le modèle a-t-il mal compris la question ?
A-t-il choisi une mauvaise source ?
Un outil a-t-il échoué ?
A-t-il reçu les bonnes informations et pris la mauvaise décision ?
Pour le savoir, il faut de l’observabilité.
Une trace utile pourrait montrer :
objectif
→ décision du modèle
→ outil choisi
→ résultat de l’outil
→ décision suivante
→ résultat final
Les recommandations actuelles d’AWS pour les systèmes agentiques vont plus loin : elles traitent les appels d’outils, l’exécution des workflows, l’état et le comportement des agents comme des éléments importants de l’observabilité en production.
Pour apprendre, retenez la règle simple :
Si un agent peut agir, vous devez pouvoir reconstituer ce qui s’est passé.
Sans cela, le débogage devient un jeu de devinettes.
Étape 7 : décider de la place des humains
L’intervention d’un humain ne signifie pas que l’agent a échoué.
Parfois, l’approbation humaine fait partie de la bonne conception.
Notre assistant de recherche peut être autorisé à chercher et à résumer automatiquement.
Mais imaginez un autre agent capable de :
- supprimer des ressources cloud
- transférer de l’argent
- envoyer un e-mail à l’extérieur
- approuver un remboursement
- modifier la configuration de production
Ces actions ont des conséquences.
Une bonne conception peut permettre à l’agent de préparer l’action, mais marquer une pause avant de l’exécuter.
L’agent propose → l’humain approuve → le système exécute
La question importante n’est pas :
L’IA peut-elle faire cela ?
C’est plutôt :
L’IA doit-elle être autorisée à faire cela sans un autre point de décision ?
L’ingénierie agentique consiste en partie à décider où l’autonomie doit s’arrêter. Pour un exemple concret de la façon de tracer cette limite, voyez notre Perspective expliquant pourquoi l’autonomie n’est pas la même chose que la confiance.
Étape 8 : ajouter la sécurité avant d’ajouter de l’autonomie
Chaque outil augmente les capacités.
Il peut aussi augmenter le risque.
Si un agent peut accéder à une base de données, à un compte cloud, à un système de fichiers ou à une API externe, posez-vous ces questions :
- Quelle identité utilise-t-il ?
- À quoi cette identité a-t-elle accès ?
- A-t-il plus de permissions que cette tâche n’en exige ?
- Les identifiants sont-ils protégés ?
- Un contenu non fiable peut-il influencer ses actions ?
- Les opérations à fort impact sont-elles restreintes ?
Ne donnez pas à un agent des pouvoirs étendus parce que configurer un accès restreint demande plus d’efforts.
Le principe est le même qu’en sécurité des systèmes traditionnels :
Ne donnez au système que les accès nécessaires à sa tâche.
Les systèmes agentiques rendent ce principe encore plus important, car le modèle lui-même peut décider quelle action autorisée entreprendre ensuite.
TechiesJournal traite séparément l’identité des agents et leur sécurité ; nous ne reviendrons donc pas sur ce sujet ici. Mais quiconque construit de vrais agents doit traiter la sécurité comme une partie de l’architecture, et non comme une fonctionnalité à ajouter plus tard.
Quelle est la place de MCP ?
À mesure que votre agent utilise davantage de systèmes externes, vous rencontrerez le Model Context Protocol, ou MCP. Notre guide expliquant comment MCP, A2A et WebMCP relient les agents (en anglais) traite du protocole lui-même.
MCP offre aux applications d’IA un moyen standard de découvrir des outils et des ressources externes, et d’interagir avec eux.
Cela peut réduire le travail d’intégration sur mesure.
Mais MCP ne remplace pas les fondamentaux dont nous avons parlé.
Vous devez toujours réfléchir :
- aux outils qui doivent exister
- à ce à quoi l’agent peut accéder
- à l’authentification
- aux permissions
- à la qualité des outils
- à la gestion des erreurs
- à l’évaluation
Apprenez MCP une fois que vous maîtrisez l’appel d’outils de base.
Sinon, vous risquez de comprendre le protocole sans comprendre le système que vous essayez de construire.
Quand avez-vous besoin de plusieurs agents ?
Plus tard que ne le suggèrent de nombreux tutoriels.
Supposons que notre assistant de recherche fonctionne bien, mais que nous découvrions que la vérification des sources exige un processus réellement différent.
Nous pourrions alors finir par séparer les responsabilités :
Agent de recherche → vérificateur des preuves → rédacteur
Cela peut être utile.
Mais une conception multi-agents ajoute aussi :
- plus d’appels au modèle
- plus d’état
- plus de coordination
- plus de latence
- plus de coût
- plus de chemins de défaillance
Les recommandations actuelles d’Anthropic et de Microsoft font en substance la même remarque d’architecture : utilisez l’approche la plus simple qui résout le problème, et n’ajoutez de l’orchestration ou plusieurs agents que lorsque la tâche l’exige réellement.
Avant de créer un agent de plus, demandez-vous donc :
Quel problème cet agent supplémentaire résout-il, qu’un seul agent ou un workflow classique ne peut pas résoudre ?
S’il n’y a pas de réponse claire, ne l’ajoutez pas.
De l’agent au système agentique
Notre assistant de recherche d’origine était simple :
Question → modèle → recherche → réponse
Une version plus fiable a désormais un autre visage :
Objectif
↓
Agent
↓
Outils
↓
État
↓
Preuves
↓
Évaluation
↓
Point de contrôle / décision humaine si nécessaire
↓
Résultat
Autour de tout cela :
sécurité + observabilité + reprise après échec
Alternative textuelle accessible pour cette figure
Trois stades de croissance. Un agent simple est un modèle doté d’un outil. Une application utile est un modèle doté d’outils et d’un état. Un système fiable conserve le modèle, les outils et l’état, et y ajoute l’évaluation, l’observabilité, la reprise, la sécurité et le contrôle humain. Les éléments ajoutés sont signalés par un signe plus et un fond de couleur chaude, afin que la progression ne repose pas sur la seule couleur.
C’est la transition essentielle.
Le modèle reste important.
Mais il n’est plus toute l’application.
C’est pourquoi la construction de systèmes agentiques devient de plus en plus une discipline du génie logiciel, plutôt qu’une simple compétence de rédaction de prompts.
Que construire ensuite ?
Si vous apprenez, n’essayez pas de mettre en œuvre tout ce qui figure dans cet article en même temps.
Construisez par couches.
D’abord : un agent et un outil utile.
Ensuite : ajoutez un état.
Ensuite : définissez à quoi ressemble un résultat réussi.
Ensuite : ajoutez le traçage et la gestion des échecs.
Ensuite : ajoutez une approbation humaine si l’agent peut entreprendre des actions lourdes de conséquences.
Ce n’est qu’après cela que vous devriez explorer l’orchestration complexe, les architectures qui s’appuient fortement sur MCP ou les systèmes à plusieurs agents.
Le meilleur projet d’apprentissage n’est pas celui qui compte le plus d’agents.
C’est celui où vous pouvez expliquer :
ce que l’agent cherche à accomplir,
ce qu’il peut faire,
ce qui peut mal tourner,
comment vous détectez un échec,
et pourquoi le résultat final mérite confiance.
C’est toute la différence entre construire une démo d’agent et construire un système agentique.
Poursuivre la série Construire des systèmes agentiques
Partie 1 : précédente. Construire des systèmes agentiques : ce que les étudiants et les professionnels en poste devraient apprendre dès maintenant. Commencez ici si vous voulez décider si les systèmes agentiques méritent votre temps d’apprentissage, et jusqu’à quel point votre rôle exige cette compétence.
Partie 2 : vous êtes ici. Construire des systèmes agentiques : de votre premier agent à un système fiable. Comprenez le parcours technique qui mène d’un simple agent utilisant des outils à un système doté d’un état, d’évaluation, d’observabilité, de sécurité et de reprise après échec.
Partie 3 : suivante. Apprendre l’IA agentique : cours gratuits, ateliers pratiques et certifications. Nous comparerons les ressources d’apprentissage actuelles d’AWS, de Microsoft, de Google, d’OpenAI, d’Anthropic et d’autres, et nous distinguerons formations gratuites, certificats de cours, attestations de compétences pratiques et certifications professionnelles.
Sources et lectures complémentaires
Revue des sources : 2 octobre 2026.
- Anthropic — Building Effective Agents. Utile pour comprendre la différence entre workflows et agents, pourquoi les architectures plus simples doivent passer en premier, et quand un surcroît d’autonomie se justifie.
- Anthropic — Writing Effective Tools for Agents. Explique pourquoi la qualité des outils, des interfaces claires et l’évaluation comptent pour les performances d’un agent.
- Anthropic — Demystifying Evals for AI Agents. Une explication pratique des raisons pour lesquelles le comportement d’un agent en plusieurs étapes exige une évaluation systématique.
- Microsoft — Agent Framework. Documentation actuelle qui progresse d’un premier agent et de ses outils jusqu’à l’état, la mémoire, les workflows, l’intervention humaine, les points de contrôle et l’hébergement.
- AWS — Agentic AI Lens. Recommandations utiles pour la production, qui couvrent l’observabilité, l’état, la résilience, la sécurité et le comportement opérationnel des systèmes agentiques.
- OpenAI — Agents SDK documentation. Ressources actuelles pour les développeurs, qui couvrent les outils, l’état, l’orchestration, les garde-fous, la revue humaine, le traçage et les évaluations.