Réponse courte
Avant de mettre un agent IA en production, vérifiez trois choses : ce qu'il voit, ce qu'il peut faire, et comment vous prouvez qu'il a bien travaille.
Cette page est une ressource de référence. Elle complete l'article long Architecture d'un agent IA en production : harnais, évaluation et observabilité. L'objectif est simple : donner une grille que l'on peut relire avant une démo client, une PR, un POC interne ou une mise en production.
Checklist rapide
| Zone | Question | Prêt pour production ? |
|---|---|---|
| Objectif | La tâche est-elle spécifique, mesurable et limitée ? | Oui / Non |
| Risque | Les actions dangereuses sont-elles classées avant execution ? | Oui / Non |
| Contexte | Le contexte est-il borné, justifié et reproductible ? | Oui / Non |
| Outils | Les outils sont-ils petits, types et observés ? | Oui / Non |
| Permissions | Les effets de bord exigent-ils une validation explicite ? | Oui / Non |
| Évaluation | Les refus, erreurs et cas limites sont-ils testés ? | Oui / Non |
| Observabilité | Peut-on expliquer pourquoi l'agent a agi ? | Oui / Non |
| Rollback | Existe-t-il un chemin de retour documente ? | Oui / Non |
Si une ligne critique est "Non", l'agent peut rester en sandbox. Il ne devrait pas toucher un workflow réel.
1. Objectif et périmètre
- Le workflow a un nom clair.
- L'input attendu est documente.
- L'output attendu est structure.
- Les cas hors périmètre sont explicites.
- Le succès ne dépend pas seulement de "la réponse semble correcte".
Un mauvais objectif : "aide l'équipe support".
Un meilleur objectif : "classer un ticket entrant en catégorie, niveau d'urgence et prochaine action proposée, sans envoyer de réponse client sans validation humaine".
2. Classification du risque
| Niveau | Exemple | Politique recommandée |
|---|---|---|
| Low | Résumer un texte public | Execution directe avec log |
| Medium | Générer un patch local | Sandbox, tests, revue humaine |
| High | Modifier des données métier | Dry-run et approbation explicite |
| Critical | Supprimer, publier, facturer, envoyer | Workflow séparé ou refus |
Le point important : la classification doit se faire avant le plan. Sinon l'agent peut construire un plan dangereux puis demander au système de l'exécuter.
3. Contexte
- Le contexte a une limite de taille.
- Chaque document inclus a une raison.
- Les données sensibles sont masquées ou exclues.
- Les fichiers autorises sont listes.
- Les exemples d'input/output sont fournis.
- Le contexte peut être reconstruit pour audit.
Un bon contexte n'est pas le plus grand contexte. C'est le plus petit contexte qui permet une decision vérifiable.
4. Outils et MCP
- Chaque outil a un schéma d'input.
- Chaque outil a un schéma d'output.
- Chaque outil a un niveau de risque.
- Les outils destructifs ne sont pas exposés par défaut.
- Les erreurs outil sont explicites.
- Les appels externes utilisent une cle d'idempotence quand c'est pertinent.
MCP peut aider à exposer des outils de façon standardisée, mais il ne remplace pas la politique de permission. Un serveur MCP donne une capacité. Votre application décide si cette capacité est autorisée.
5. Permissions
| Action | Contrôle minimal |
|---|---|
| Lire un document public | Log |
| Lire une donnée interne | Scope + audit |
| Modifier un fichier local | Sandbox + diff |
| Appeler une API interne | Validation schéma + trace |
| Modifier des données client | Dry-run + approbation |
| Envoyer un email externe | Preview + validation humaine |
| Supprimer une ressource | Refus ou double validation |
Une permission ne doit pas venir du modèle. Elle doit venir du système.
6. Évaluation
Les évaluations doivent couvrir :
- les cas normaux ;
- les cas ambigus ;
- les demandes impossibles ;
- les demandes dangereuses ;
- les sorties mal formatées ;
- les erreurs outil ;
- les retries ;
- les refus attendus.
Un agent qui refuse correctement une action risquée est un agent qui fonctionne.
7. Observabilité
Les logs doivent permettre de répondre à ces questions :
- quelle intention a été reçue ?
- quel risque a été classe ?
- quel contexte a été donne ?
- quels outils ont été appelés ?
- quels arguments ont été envoyés ?
- quelle évaluation a été lancée ?
- qui a valide ?
- quel rollback est disponible ?
Ne loggez pas les secrets. Ne copiez pas inutilement les données personnelles. L'audit doit réduire le risque, pas le dupliquer.
8. Validation humaine
La validation humaine doit montrer :
- le but ;
- le diff ;
- les données touchées ;
- les tests passés ;
- les risques connus ;
- le plan de rollback.
Un bouton "Approve" sans contexte est un faux contrôle.
9. Rollback
Un rollback utile est prépare avant l'incident :
- snapshot ou sauvegarde ;
- opération inverse ;
- statut avant/après ;
- traceId ;
- responsable humain ;
- message utilisateur si l'action était visible.
Version courte à copier
Agent IA pret pour production si :
- objectif specifique ;
- risque classe avant execution ;
- contexte borne ;
- outils types et limites ;
- permissions systeme ;
- evaluation des erreurs et refus ;
- logs exploitables ;
- validation humaine pour effet de bord ;
- rollback documente.
Liens utiles
- Article long : Architecture d'un agent IA en production
- Guide complémentaire : Garde-fous pour agents IA de code
- Hub : Agents IA
- Profil : Mouhssine Lakhili, développeur full stack IA et automation
