À l’intérieur d’un agent IA : modèles, outils, mémoire et raisonnement expliqués
Il décrit en détail l’architecture de base des agents d’intelligence artificielle — objectifs, modèles, outils, mémoire et raisonnement — et présente un exemple concret d’agent de recherche basé sur Python.
Dans le premier volet de AI Agents with Python 2026, nous avons abordé une question fondamentale :
Qu’est-ce qu’un agent d’IA, exactement ?
Nous avons examiné en quoi le logiciel traditionnel diffère des chatbots, des systèmes d’IA générative et des agents capables de poursuivre des objectifs par eux-mêmes. Nous avons également présenté les éléments clés qui composent un agent : des modèles, des outils, une mémoire, des connaissances, des actions et des mécanismes de sécurité.
Cette fois, nous allons ouvrir le capot pour examiner le fonctionnement interne.
Que se passe-t-il réellement lorsque l’agent s’exécute ?
Comment choisit-il sa prochaine action ?
Comment sélectionne-t-il l’outil adapté à la tâche ?
Comment conserve-t-il des informations d’une étape à l’autre ?
Et comment reconnaît-il qu’une tâche a été accomplie ?
Bienvenue dans la deuxième partie de cette série — en passant d’une automatisation simple vers des systèmes véritablement autonomes.
L’architecture d’un agent IA
À un niveau conceptuel, un agent IA assemble un ensemble de composants au sein d’un cycle répétitif :
Objectif → Modèle → Décision → Outil → Observation → Prochaine décision → Résultat
Une version simplifiée de cette architecture pourrait ressembler à ceci :
USER / APPLICATION
│
▼
┌──────────────┐
│ GOAL │
└──────┬───────┘
│
▼
┌──────────────┐
│ AI MODEL │
│ LLM / Model │
└──────┬───────┘
│
▼
┌──────────────┐
│ DECISION │
│ / PLANNING │
└──────┬───────┘
│
┌─────────┼─────────┐
▼ ▼ ▼
TOOL 1 TOOL 2 TOOL 3
│ │ │
└─────────┼─────────┘
│
▼
OBSERVATION
│
▼
┌──────────────┐
│ NEXT ACTION? │
└──────┬───────┘
│
┌──────┴──────┐
│ │
YES NO
│ │
▼ ▼
Continue Result
N’oubliez pas qu’il s’agit d’une représentation simplifiée.
Les systèmes d’agents de niveau professionnel sont généralement bien plus complexes, mais comprendre ce cycle fondamental vous offre un point de départ solide pour tout ce qui suivra.
1. L’objectif
Le comportement de tout agent commence par un objectif.
Le système a besoin d’une compréhension concrète de ce qu’il doit accomplir.
Prenons cet exemple :
« Analysez les données de ventes de ce mois et identifiez les trois produits présentant la plus forte baisse. »
Un objectif définit la direction de l’ensemble du processus.
Lorsque l’objectif n’est pas clairement énoncé, l’agent risque de produire des réponses hors sujet ou d’entreprendre des actions qui ne sont pas vraiment utiles.
Un objectif bien formulé précise généralement :
- La tâche à accomplir
- Les données ou informations importantes
- La forme attendue du résultat
- Tous les limites ou contraintes à respecter
Prenons ces deux versions :
Objectif faible :
"Analyser les données."
Objectif plus précis :
"Examiner l’ensemble de données des ventes, identifier tous les produits dont le chiffre d’affaires mensuel a diminué de plus de 10 pour cent, et rédiger un tableau résumant les résultats."
Par rapport à la version vague, cette formulation donne à l’agent une cible bien plus claire à atteindre.
2. Le modèle d’IA
Le modèle agit comme le moteur de raisonnement et de langage au cœur de la plupart des agents modernes.
Les grands modèles de langage (LLM) occupent cette place car ils sont capables de :
- Analyser les entrées en langage naturel
- Comprendre les instructions
- Évaluer les informations contextuelles
- Produire des résultats bien structurés
- Sélectionner parmi les actions possibles
- Construire les arguments nécessaires à un outil
Cela dit, le modèle n’est qu’une pièce du puzzle.
Imaginez-le comme le cerveau au sein d’un organisme plus vaste.
Un cerveau isolé des yeux, des mains, de la mémoire et du monde extérieur ne peut pas faire grand-chose tout seul.
Il en va de même pour un LLM : son utilité augmente considérablement une fois qu’il est connecté à des outils et des sources de données pertinents.
3. Instructions et contexte
Le modèle doit connaître son rôle ainsi que les spécificités de la tâche en cours.
Cela comprend généralement :
- Des instructions au niveau du système
- Des instructions provenant de l’utilisateur
- Une liste des outils qu’il peut appeler
- L’historique des conversations précédentes
- Des données obtenues par recherche
- L’état actuel de la tâche
- Toutes les règles ou limites qu’il doit respecter
À titre d’exemple, un agent conçu pour assister un service d’assistance informatique pourrait être configuré avec des éléments tels que :
You are an IT support assistant.
Your responsibilities:
1. Diagnose common technical issues.
2. Search the approved knowledge base.
3. Provide troubleshooting instructions.
4. Escalate high-risk issues to a human technician.
Do not modify production systems without authorization.
De telles instructions déterminent le comportement attendu de l’agent.
4. Outils
Bien qu’un modèle puisse générer du texte et raisonner, ce sont les outils qui permettent à un agent d’interagir réellement avec des systèmes externes.
Les catégories courantes d’outils incluent :
- La recherche sur le Web
- Des API externes
- Des bases de données
- Des systèmes de fichiers
- Des calculatrices
- Des fonctions Python personnalisées
Prenons l’exemple d’un assistant chargé de fournir des informations météo en temps réel.
Les connaissances intégrées au modèle ne comprennent pas les conditions actuelles.
Ainsi, l’agent fait appel à une API météo via une requête vers un outil.
Le flux est à peu près le suivant :
User Request
↓
AI Model
↓
Weather Tool
↓
Current Weather Data
↓
AI Model
↓
Response
Cet outil fournit des données que le modèle ne peut pas générer de manière fiable par lui-même.
Appel d’outil
Une idée clé dans les systèmes agents est ce qu’on appelle l’appel d’outil.
Au lieu de se contenter de générer une réponse en texte brut, le modèle peut indiquer qu’un outil spécifique doit être exécuté.
Par exemple :
tools = [
"search_database",
"calculate",
"get_weather"
]
Supposons qu’un utilisateur demande :
"Quel temps fait-il à Accra ?"
Le modèle pourrait reconnaître que get_weather est l’outil approprié pour cette demande.
L’application environnante exécute alors cette fonction et renvoie le résultat au modèle.
En Python, cela peut être exprimé simplement comme suit :
def get_weather(city):
# Call an approved weather service
return weather_data
La règle essentielle ici est que le modèle propose ce dont il a besoin, mais c’est l’application qui contrôle ce qui est réellement exécuté.
Cette séparation est très importante pour la sécurité.
Les modèles ne devraient pas avoir un accès illimité
Imaginez confier à un modèle d’IA un contrôle illimité sur :
- Votre base de données
- Vos comptes e-mail
- Votre système de fichiers
- Vos systèmes financiers
- Votre système d’exploitation
Un tel niveau d’accès introduirait de graves risques.
Les agents ne devraient recevoir que l’accès strictement nécessaire à l’exécution de leurs tâches.
Cela correspond à une idée bien connue en ingénierie de la sécurité :
Principe du moindre privilège
Accordez à un système uniquement les permissions dont il a réellement besoin pour accomplir sa mission, et rien de plus.
Par exemple :
Un agent d’assistance client peut avoir légitimement besoin de lire les données des clients.
Mais il n’a probablement aucune raison de supprimer ces données.
Cette idée sera abordée plus en détail lorsque nous traiterons de la sécurité des agents dans la suite de cette série.
5. Mémoire
La mémoire permet à un agent de conserver des informations importantes tout au long d’une conversation ou d’une tâche.
Sans elle, chaque échange semblerait déconnecté du précédent.
Imaginez un assistant IA personnel.
Vous mentionnez :
« Mon langage de programmation préféré est Python. »
Puis plus tard, vous demandez :
« Recommandez-moi un projet de programmation. »
Si l’assistant dispose d’une mémoire de travail, il peut relier ces deux moments et adapter sa réponse en s’appuyant sur ce que vous lui avez dit précédemment.
La mémoire n’est pas un concept unique — elle fonctionne à différents niveaux d’abstraction.
Mémoire à court terme
La mémoire à court terme concerne des détails qui ne sont pertinents que au cours de la session ou de la tâche en cours.
User:
My budget is GHS 5,000.
User:
Show me laptops.
Agent:
I'll focus on options around your GHS 5,000 budget.
Sans conserver le budget mentionné précédemment, l’agent ne saurait pas comment définir correctement les recommandations de laptop.
Mémoire à long terme
La mémoire à long terme persiste au-delà d’une seule conversation.
User Preference:
Prefers Python tutorials.
Previous Project:
Built an AI study assistant.
Current Goal:
Learning AI agents.
Une application stocke généralement ce type de données dans une base de données dédiée ou dans une couche mémoire.
Cela dit, le stockage des informations personnelles soulève des questions de confidentialité qui ne doivent pas être ignorées.
Vous devrez réfléchir aux points suivants :
- Quelles informations méritent d’être mémorisées
- Pendant combien de temps elles doivent être conservées
- Où elles sont stockées
- Qui a le droit d’y accéder
- Comment un utilisateur peut les faire supprimer
La mémoire ne doit jamais être une considération secondaire — elle nécessite une conception réfléchie.
6. Connaissances
Mémoire et connaissances ont l’air similaires mais servent à des fins différentes.
La mémoire suit généralement des détails concernant l’utilisateur, la conversation ou l’état actuel de la tâche.
La récupération des connaissances, quant à elle, consiste à obtenir des faits pertinents à partir de sources externes.
Considérez un agent d’IA corporate qui pourrait avoir besoin de consulter :
- Les politiques des employés
- La documentation des produits
- Les manuels techniques
- Les procédures internes
- Les questions fréquentes
Au lieu d’inclure tous les documents dans la requête, le système ne récupère que ce qui est pertinent au moment où il en a besoin.
C’est la base d’un modèle important dans l’architecture de l’IA :
Génération améliorée par la récupération d’informations (RAG)
À un niveau général, le flux de travail RAG se présente comme suit :
User Question
↓
Retrieve Relevant Information
↓
Knowledge Source
↓
Relevant Context
↓
AI Model
↓
Answer
Le RAG devient particulièrement utile lorsqu’il est associé à des agents.
Nous examinerons plus en détail ce modèle dans la partie 6.
7. Raisonnement et planification
L’une des capacités les plus intéressantes des agents d’IA est de décomposer une tâche complexe en une série d’étapes plus petites et gérables.
Supposons qu’un utilisateur demande à l’agent de préparer une comparaison de trois fournisseurs cloud destinés à une petite entreprise.
Pour mener à bien cette tâche, il pourrait être nécessaire de :
- Identifier les plateformes
- Rassembler des informations sur les prix
- Comparer les fonctionnalités
- Évaluer les avantages et inconvénients
- Organiser les résultats
- Rédiger le rapport final
L’agent devra peut-être déterminer, de manière dynamique, quelle étape est la plus appropriée à suivre en fonction de ce qu’il sait actuellement.
C’est là que joue un rôle le planification.
La planification ne signifie pas toujours un raisonnement complexe
Ne supposez pas que chaque agent ait besoin d’un moteur de planification élaboré et entièrement autonome.
Certains flux de travail peuvent rester simples :
Input
↓
Call API
↓
Format Result
↓
Return Response
D’autres préconisent véritablement une solution plus complexe :
Goal
↓
Plan
↓
Research
↓
Analyze
↓
Verify
↓
Generate
↓
Review
↓
Complete
Le choix dépend entièrement du problème à résoudre.
Vale la peine de le répéter :
Sélectionnez l’architecture la plus simple capable de résoudre le problème de manière fiable.
8. Observation
Lorsqu’un agent entreprend une action, il a besoin de feedback sur les résultats réels.
C’est l’étape de l’observation.
Agent:
Search for information about Python.
Tool:
Returns 20 search results.
Agent:
Analyze the results and determine which are relevant.
Les données qui reviennent constituent une observation que l’agent prend en compte pour son prochain mouvement.
Tout cela forme un cycle récurrent :
Penser → Agir → Observer → Décider → Agir à nouveau
Le cycle de l’agent
Avec tous les éléments en place, voici comment ils s’assemblent :
┌──────────────┐
│ GOAL │
└──────┬───────┘
↓
┌──────────────┐
│ CONTEXT │
└──────┬───────┘
↓
┌──────────────┐
│ AI MODEL │
└──────┬───────┘
↓
┌──────────────┐
│ DECISION │
└──────┬───────┘
↓
┌──────────────┐
│ TOOL │
└──────┬───────┘
↓
┌──────────────┐
│ OBSERVATION │
└──────┬───────┘
↓
┌──────────────┐
│ COMPLETE? │
└───┬──────┬───┘
│ │
NO YES
│ │
↓ ↓
Continue Result
Comprendre cette boucle est essentiel pour saisir le fonctionnement des systèmes agents.
Un exemple concret : l’agent de recherche
Examinons en détail la conception d’un agent de recherche simple.
Imaginons une demande demandant à l’assistant d’étudier comment les petites entreprises au Ghana pourraient bénéficier de l’adoption de l’énergie solaire, et de résumer les résultats en un bref compte rendu.
Gérer cette tâche peut se décomposer en les étapes suivantes.
Étape 1 — Comprendre
Déterminer :
- Le sujet
- La zone géographique concernée
- Le public cible
- La forme que doit prendre le résultat
Étape 2 — Planifier
Décider quelles informations sont réellement nécessaires.
Étape 3 — Récupérer
Récupérer des données auprès de sources fiables.
Étape 4 — Analyser
Examiner ce qui a été récupéré.
Étape 5 — Organiser
Classifiez les résultats en catégories logiques.
Étape 6 — Générer
Rédigez le résumé demandé.
Étape 7 — Vérifier
Vérifiez que le résultat répond bien à la demande initiale.
Étape 8 — Retourner
Fournissez la réponse finale.
Ceci illustre un flux de travail d’agent axé sur des objectifs en pratique.
Que se passe-t-il si un outil échoue ?
Dans le monde réel, des problèmes surviennent.
Les API tombent en panne.
Les bases de données atteignent leur limite de temps.
Les recherches renvoient des résultats irrelevants.
Les outils envoient parfois des données mal formatées.
Pour exemple :
try:
result = get_data()
except Exception as error:
print("Tool failed:", error)
Les systèmes de niveau production nécessitent généralement un traitement bien plus robuste que celui-ci.
En fonction de la situation, l’agent peut :
- Réessayer l’étape qui a échoué
- Passer à un outil différent approuvé
Gérer les échecs avec élégance fait partie intégrante de la conception des agents, et non d’un cas particulier.
Intervention humaine
L’automatisation ne devrait pas s’étendre à chaque décision.
Par exemple :
AI Agent
↓
Prepare financial transaction
↓
Human Approval
↓
Execute Transaction
Cette approche est connue sous le nom de Intervention humaine (HITL).
Elle est particulièrement utile lorsque l’agent est capable de prendre des décisions à haut risque, telles que :
- Les transactions financières
- La suppression de données
- L’envoi de messages sensibles
- La modification des systèmes en production
- L’approbation de décisions majeures
L’ajout d’un contrôle humain peut limiter considérablement les dommages causés par les erreurs de l’agent.
Flux de travail déterministes vs agents
Il y a une autre distinction qui mérite d’être comprise.
Step 1 → Step 2 → Step 3 → Step 4
Un flux de travail agent, en revanche, décide au fur et à mesure de la prochaine action à entreprendre :
Goal
↓
Decision
↓
Action
↓
Observation
↓
Next Decision
Aucun des deux n’est intrinsèquement le meilleur choix.
Pour les tâches prévisibles et bien comprises, un flux de travail déterministe est souvent plus facile à tester, à surveiller et à sécuriser.
Lorsque les conditions sont incertaines et que les exigences changent constamment, laisser à l’agent la liberté de choisir son propre parcours s’avère généralement plus efficace.
Aucun de ces modèles n’est supérieur dans toutes les situations. Choisir entre eux fait simplement partie d’une bonne pratique d’ingénierie.
Où Python s’intègre
Python est particulièrement adapté pour servir de lien entre les différentes composantes d’un agent.
Une architecture simplifiée pourrait ressembler à ceci :
Python Application
│
├── AI Model
│
├── Tools
│
├── APIs
│
├── Database
│
├── Memory
│
└── RAG / Knowledge Base
Python gère la coordination entre ces éléments et intègre la logique métier associée.
C’est en partie pour cette raison que Python s’avère si adapté à la construction de systèmes d’IA.
Une architecture simple d’agent en Python
Voici un schéma conceptuel d’un agent minimal :
class SimpleAgent:
def __init__(self, model, tools):
self.model = model
self.tools = tools
def run(self, goal):
context = goal
while True:
decision = self.model.decide(
context,
self.tools
)
if decision["action"] == "finish":
return decision["result"]
tool = self.tools[decision["tool"]]
result = tool(**decision["arguments"])
context = {
"goal": goal,
"previous_result": result
}
Cet exemple est délibérément très simplifié.
Un agent réel, prêt pour la production, nécessiterait beaucoup plus d’infrastructures de soutien, telles que :
- Vérification des données reçues
- Moyen de vérifier qui appelle le système
- Gestion des échecs au cours du processus
- Enregistrement de ce qui s’est passé et quand
- Règles concernant les outils pouvant être utilisés
- Suivi de l’état actuel de l’agent
Néanmoins, ce fragment illustre le flux essentiel :
Fixer un objectif → prendre une décision → utiliser un outil → observer le résultat → continuer ou s’arrêter.
Pourquoi les cycles d’agent ont besoin de limites
Imaginez un agent qui conclut constamment qu’il doit effectuer une action de plus.
Sans limite, il pourrait fonctionner indéfiniment.
Si cela n’est pas contrôlé, cela peut entraîner :
- Des coûts API démesurés
- Des réponses lentes
- Une utilisation excessive des ressources
- Des actions répétées et redondantes
- Un comportement imprévisible
Afin de se prémunir contre cela, les développeurs devraient intégrer des contrôles tels que :
- Un plafond au nombre d’itérations
- Des délais limites pour l’exécution
- Majuscules obligatoires pour les appels aux outils
- Limits de dépenses
- Étapes d’approbation obligatoires
Par exemple :
MAX_STEPS = 10
Le système peut arrêter l’agent dès qu’il dépasse le nombre autorisé d’étapes.
Une mesure de sécurité aussi simple peut suffire à empêcher que les workflows ne sortent de contrôle.
La sécurité fait partie de l’architecture
La sécurité pour un agent n’est pas quelque chose qu’on ajoute ultérieurement.
Elle doit être intégrée dès le début.
Les principaux aspects à prendre en compte incluent :
Authentification
Qui a le droit d’interagir avec l’agent ?
Autorisation
Quels ressources l’agent est autorisé à utiliser ?
Vérification des entrées
Quel type d’entrées les utilisateurs sont-ils autorisés à soumettre ?
Permissions des outils
Quelles fonctions l’agent peut-il réellement exécuter ?
Protection des données
Quels données sensibles l’agent pourrait-il être exposé à ?
Journalisation
Que a réellement fait l’agent, étape par étape ?
Approbation humaine
Quelles actions nécessitent l’approbation d’une personne avant de pouvoir être exécutées ?
Ces préoccupations deviennent de plus en plus cruciales à mesure que les agents gagnent en capacités.
La pile technologique de l’agent
┌──────────────────────────────┐
│ USER / GOAL │
├──────────────────────────────┤
│ AGENT LOGIC │
├──────────────────────────────┤
│ AI MODEL / LLM │
├──────────────────────────────┤
│ TOOLS & FUNCTIONS │
├──────────────────────────────┤
│ MEMORY & STATE │
├──────────────────────────────┤
│ KNOWLEDGE / RAG │
├──────────────────────────────┤
│ APIs & DATABASES │
├──────────────────────────────┤
│ SECURITY / GUARDRAILS / LOGS │
└──────────────────────────────┘
Chaque couche a sa propre fonction.
Comprendre bien ces couches rend la conception et le débogage des agents beaucoup plus faciles à gérer.
Le modèle mental pour débutants
Lorsque vous commencez à travailler avec des agents, gardez ces six questions en tête :
1. Quel est l’objectif ?
Quel résultat le système doit-il produire ?
2. Que le modèle doit comprendre ?
Quelles instructions et quel contexte lui sont nécessaires pour accomplir sa tâche ?
3. Quels outils sont disponibles ?
Quelles capacités externes peut-il mobiliser ?
4. Quelles informations a-t-il besoin ?
D’où proviennent réellement ses connaissances ?
5. Quelles actions peut-il entreprendre ?
Qu’est-ce qui lui est vraiment permis de faire ?
6. Que se passe-t-il en cas de problème ?
Comment le système réagit-il lorsqu’il y a une panne ?
Être capable de répondre à ces six questions signifie que vous raisonnez déjà comme quelqu’un qui conçoit des agents.
Votre exercice pratique
Sélectionnez un scénario, par exemple :
Aide à l’étude par l’IA
Puis déterminez :
Objectif :
Aider les étudiants à comprendre leurs matériaux d’étude.
Modèle :
Outils :
Knowledge :
Les matériaux pédagogiques eux-mêmes.
Mémoire :
La session d’étude en cours.
Actions :
Élaborer des explications et créer des questions d’exercice.
Règles de conduite :
N’inventez jamais de faits lorsque les matériaux pédagogiques pertinents ne sont pas disponibles.
Surveillance humaine :
L’étudiant vérifie tout ce que l’agent produit.
À ce stade, vous avez esquissé une architecture d’agent fonctionnelle.
Qu’y a-t-il dans la partie 3 ?
Avec l’architecture en main, l’étape suivante consiste à la transformer en code fonctionnel.
La partie 3 abordera la création de votre premier agent d’IA simple avec Python.
Vous passerez des diagrammes et de la théorie à une mise en œuvre concrète, et vous saurez comment lancer un projet d’agent, relier Python à un modèle de langage, définir clairement l’objectif de l’agent, créer un outil de base qu’il pourra utiliser, lui permettre d’appeler cet outil, traiter les résultats fournis par l’outil, et enfin produire une réponse finale.
La première version sera délibérément maintenue à un niveau minimal.
L’objectif à ce stade est de comprendre comment les éléments s’assemblent, et non de déployer immédiatement un système de production pleinement optimisé.
Pensées finales
C’est un système construit autour d’un objectif, doté des moyens de travailler avec des informations et d’agir à l’aide d’outils.
En son essence, l’architecture se résume à :
Objectif → Modèle → Décision → Outil → Observation → Prochaine action → Résultat
Au niveau supérieur de ce noyau, on ajoute :
Mémoire + Connaissances + Sécurité + Contraintes + Surveillance humaine
Lorsque tous ces éléments fonctionnent ensemble, l’IA agente cesse de sembler magique.
Cela devient alors un défi classique en ingénierie logicielle.
C’est précisément le type de défi pour lequel Python est particulièrement adapté.
Vous savez maintenant ce qu sont les agents IA et comment ils fonctionnent.
La prochaine étape consiste à en créer un vous-même.
Lectures complémentaires
- Comprendre les agents IA : objectifs, outils, mémoire et boucle d’agent — Une explication adaptée aux débutants sur les différences entre les agents IA et les chatbots, abordant les composants fondamentaux, la boucle de décision, les niveaux d’autonomie et des cas d’usage concrets.