Conception d'Agent IA
Philosophie Fondamentale
Les agents ne sont pas de la magie — ce sont des systèmes avec des entrées, des sorties, de la mémoire, des outils et une logique de décision. Concevez-les avec la même rigueur que n'importe quel logiciel de production. Chaque agent doit avoir un objectif clair, des limites définies et des modes de défaillance explicites.
Principes de Conception d'Agent
1. Clarifier l'Intention avant d'Agir
Un agent doit poser des questions de clarification lorsque l'intention de l'utilisateur est ambiguë — avant d'exécuter toute action irréversible. Utilisez ce modèle :
- L'objectif est-il clair ? Sinon, posez une question ciblée.
- Les contraintes sont-elles connues ? (périmètre, format de sortie, sources de données)
- À quoi ressemble le succès ?
2. Spécification avant le Code
Avant d'écrire la logique de l'agent, générez un fichier de spécification ou de liste de tâches :
- Définissez le rôle et les responsabilités de l'agent
- Listez tous les outils auxquels il doit avoir accès
- Définissez les contrats d'entrée/sortie
- Identifiez les modes de défaillance et le comportement de repli
- Écrivez ensuite le code
3. Responsabilité Unique
Chaque agent doit bien faire une seule chose. Préférez une équipe d'agents spécialisés à un agent polyvalent.
Modèles d'Orchestration
| Modèle | Quand l'utiliser | Description |
|---|---|---|
| Séquentiel | Pipelines linéaires | Les agents s'enchaînent dans un ordre fixe (brouillon → révision → publication) |
| Superviseur | Tâches multi-modules complexes | L'agent principal achemine vers des travailleurs spécialisés |
| ReAct | Résolution de problèmes autonome | Combine raisonnement (Thought) + action (Tool Use) |
| Chat de Groupe | Tâches collaboratives | Communication multi-agents avec supervision humaine |
| DAG | Workflows avec état | Graphe orienté acyclique pour une orchestration cyclique avec état |
Guide de Sélection de Framework
| Framework | Idéal pour | Statut |
|---|---|---|
| LangGraph | Agents complexes avec état, workflows cycliques, orchestration multi-agents, grade production | ✅ Actif — GA Mai 2025 |
| LangChain | Pipelines RAG simples, workflows linéaires, prototypes rapides | ✅ Actif — à utiliser pour RAG, pas pour les agents |
| CrewAI | Équipes multi-agents basées sur les rôles ("Manager", "Chercheur", "Rédacteur") | ✅ Actif |
| Microsoft Agent Framework | Agents d'entreprise dans l'écosystème Azure — remplace AutoGen + Semantic Kernel | ✅ Actif — Aperçu public Oct 2025, GA ciblé T1 2026 |
| AutoGen | Hérité — fonctionne encore mais sans nouvelles fonctionnalités | ⚠️ Mode maintenance depuis Oct 2025 |
| Personnalisé (MCP) | Outils d'agent légers, portables et interopérables via un standard ouvert | ✅ Actif |
LangChain vs LangGraph — Lequel Utiliser
L'équipe LangChain recommande désormais explicitement cette répartition :
- LangGraph → pour les agents : avec état, cycliques, multi-agents, tâches de longue durée
- LangChain → pour RAG et pipelines linéaires : questions-réponses simples sur documents, transformations étape par étape
LangGraph est construit au-dessus de LangChain — vous pouvez les utiliser ensemble, en commençant par LangChain et en passant à LangGraph lorsque vous avez besoin de plus de contrôle.
Conception de Pipeline RAG
Flux RAG Standard
Requête Utilisateur → Embedder la Requête → Recherche Vectorielle → Récupérer les Morceaux → Augmenter le Prompt → LLM → Réponse
Stratégie de Découpage (Meilleure Pratique 2026)
- Utilisez le découpage sémantique — coupez sur le sens, pas sur le nombre de caractères
- Taille du morceau : 256–512 jetons pour la précision ; 1024 pour le contenu narratif
- Incluez toujours les métadonnées : source, page, section, horodatage
Recherche Hybride (Recommandée)
Combinez vecteurs denses (sémantiques) + vecteurs creux (mots-clés) pour une meilleure restitution :
Score Final = α × Score Dense + (1 - α) × Score Creux
Sélection de Base de Données Vectorielle
| DB | Idéal pour |
|---|---|
| pgvector | Stack PostgreSQL existant, cas d'usage simples |
| Pinecone | Géré, échelle production, opérations minimales |
| Weaviate | Multi-modal, recherche hybride intégrée |
| Milvus | Haute performance, auto-hébergé, grande échelle |
| Chroma | Développement local, prototypage |
Architecture de Mémoire d'Agent
| Type | Description | Implémentation |
|---|---|---|
| En contexte | Fenêtre de conversation actuelle | Tableau d'historique de chat |
| Externe à court terme | Mémoire limitée à la session | Redis / stockage en mémoire |
| Externe à long terme | Persistante entre les sessions | Base vectorielle + métadonnées |
| Épisodique | Résumé des interactions passées | Chaîne de résumé → stockage vectoriel |
Avertissement sur la Rotation du Contexte : Les fenêtres de contexte longues dégradent la qualité de l'agent avec le temps. Implémentez une étape de résumé tous les N tours pour maintenir la pertinence.
Utilisation d'Outils et Appel de Fonctions
Modèle de Définition d'Outil
Chaque outil nécessite :
name: nom_descriptif_outil
description: Quand utiliser cet outil et ce qu'il fait (soyez explicite)
parameters:
- name: nom_param
type: string
description: Ce que ce paramètre attend
required: true
Meilleures Pratiques pour l'Utilisation d'Outils
- Les outils doivent être idempotents dans la mesure du possible
- Validez toujours les sorties de l'outil avant de les transmettre à l'étape suivante
- Implémentez des délais d'attente et des tentatives pour les appels d'outils externes
- Enregistrez toutes les invocations d'outils pour le débogage
Modèles de Communication d'Agent
Protocole de Clarification d'Intention
Lorsqu'un agent reçoit une demande ambiguë :
- Identifiez l'ambiguïté — qu'est-ce qui n'est pas clair précisément ?
- Posez une question — la plus importante, pas toutes
- Proposez une valeur par défaut — "Je suppose X sauf si vous me dites le contraire"
- Confirmez avant les actions irréversibles — demandez toujours avant de supprimer, publier ou envoyer
Rapport de Progression
Pour les tâches de longue durée, les agents doivent rapporter :
[Étape 1/4] Récupération des documents... ✓
[Étape 2/4] Découpage et embedding... ✓
[Étape 3/4] Interrogation du stockage vectoriel...
Communication d'Erreur
✗ Outil échoué : [nom_outil]
Raison : [erreur spécifique]
Repli : [ce que je fais à la place]
MCP (Model Context Protocol)
MCP est le standard ouvert pour connecter des agents à des outils externes et des sources de données. Utilisez-le lors de la création d'outils d'agent portables et interopérables.
Structure du Serveur MCP
mon-serveur-mcp/
├── server.py (ou index.ts)
├── tools/
│ └── mon_outil.py
└── README.md
Quand Utiliser MCP vs Intégration Directe
- Utilisez MCP lorsque l'outil doit être réutilisable sur plusieurs agents/plateformes
- Utilisez l'intégration directe pour des implémentations d'outils spécifiques à un projet
Voir la compétence mcp-builder pour des conseils détaillés sur l'implémentation de serveurs MCP.
Sécurité & Sûreté
- Ne permettez jamais aux agents d'exécuter du code arbitraire sans sandboxing
- Implémentez une limitation de débit sur tous les appels API LLM
- Validez et nettoyez toutes les entrées avant de les transmettre aux outils
- Enregistrez toutes les décisions de l'agent pour l'auditabilité
- Implémentez des barrières de protection pour éviter les coûts de jetons incontrôlés ou les boucles récursives
- Utilisez une protection contre l'injection de prompt système — séparez l'entrée utilisateur des instructions système avec des délimiteurs clairs
Conception d'Agent Résilient (Auto-Réparation)
Les agents échouent en production. Concevez pour la récupération dès le départ.
Boucle de Validation et de Nouvelle Tentative (Modèle LoopAgent)
Générer la sortie → Valider la sortie → Si invalide : retour + régénération
Itérations maximales : 3 ← disjoncteur pour éviter les boucles infinies
Planifier–Valider–Exécuter–Observer–Replanifier
PLANIFIER : Générer un plan, vérifier la faisabilité avant d'agir
EXÉCUTER : Agir
OBSERVER : A-t-ce réussi ? Vérifier les sorties, exécuter des tests
REPLANIFIER : Si l'observation montre un échec → ajuster et réessayer
ARRÊTER : Si le nombre maximal de tentatives est atteint → signaler clairement l'échec, demander de l'aide
Hiérarchie de Repli d'Agent
L'approche primaire échoue → Essayer une approche alternative
L'approche alternative échoue → Demander une clarification au développeur
Absence de clarification → Action par défaut sûre ou arrêt gracieux
Validation de la Sortie avant Présentation
- Exécutez des tests/linteurs sur le code généré avant de le présenter
- Vérifiez que le format de sortie correspond aux exigences
- Utilisez une étape de validation distincte (modèle ou invite différent) pour vérifier la sortie du générateur
- Ne présentez jamais une sortie non vérifiée comme terminée
Disjoncteur pour Agents
Définissez des limites strictes pour éviter les comportements incontrôlés :
- Nombre maximal d'itérations d'appel d'outil par tâche (ex. 10)
- Dépense de jetons maximale par session
- Nombre maximal de tentatives par étape en échec (ex. 3)
- Délai d'attente par invocation d'outil
Voir la compétence self-healing-mindset pour la philosophie complète de résilience et les modèles de code.