Checklist agent IA en production : permissions, evaluation, observabilite

Reponse courte

Avant de mettre un agent IA en production, verifiez 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 reference. Elle complete l'article long Architecture d'un agent IA en production : harnais, evaluation et observabilite. L'objectif est simple : donner une grille que l'on peut relire avant une demo client, une PR, un POC interne ou une mise en production.

Checklist rapide

Zone	Question	Pret pour production ?
Objectif	La tache est-elle specifique, mesurable et limitee ?	Oui / Non
Risque	Les actions dangereuses sont-elles classees avant execution ?	Oui / Non
Contexte	Le contexte est-il borne, justifie et reproductible ?	Oui / Non
Outils	Les outils sont-ils petits, types et observes ?	Oui / Non
Permissions	Les effets de bord exigent-ils une validation explicite ?	Oui / Non
Evaluation	Les refus, erreurs et cas limites sont-ils testes ?	Oui / Non
Observabilite	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 reel.

1. Objectif et perimetre

• Le workflow a un nom clair.
• L'input attendu est documente.
• L'output attendu est structure.
• Les cas hors perimetre sont explicites.
• Le succes ne depend pas seulement de "la reponse semble correcte".

Un mauvais objectif : "aide l'equipe support".

Un meilleur objectif : "classer un ticket entrant en categorie, niveau d'urgence et prochaine action proposee, sans envoyer de reponse client sans validation humaine".

2. Classification du risque

Niveau	Exemple	Politique recommandee
Low	Resumer un texte public	Execution directe avec log
Medium	Generer un patch local	Sandbox, tests, revue humaine
High	Modifier des donnees metier	Dry-run et approbation explicite
Critical	Supprimer, publier, facturer, envoyer	Workflow separe ou refus

Le point important : la classification doit se faire avant le plan. Sinon l'agent peut construire un plan dangereux puis demander au systeme de l'executer.

3. Contexte

• Le contexte a une limite de taille.
• Chaque document inclus a une raison.
• Les donnees sensibles sont masquees ou exclues.
• Les fichiers autorises sont listes.
• Les exemples d'input/output sont fournis.
• Le contexte peut etre reconstruit pour audit.

Un bon contexte n'est pas le plus grand contexte. C'est le plus petit contexte qui permet une decision verifiable.

4. Outils et MCP

• Chaque outil a un schema d'input.
• Chaque outil a un schema d'output.
• Chaque outil a un niveau de risque.
• Les outils destructifs ne sont pas exposes par defaut.
• Les erreurs outil sont explicites.
• Les appels externes utilisent une cle d'idempotence quand c'est pertinent.

MCP peut aider a exposer des outils de facon standardisee, mais il ne remplace pas la politique de permission. Un serveur MCP donne une capacite. Votre application decide si cette capacite est autorisee.

5. Permissions

Action	Controle minimal
Lire un document public	Log
Lire une donnee interne	Scope + audit
Modifier un fichier local	Sandbox + diff
Appeler une API interne	Validation schema + trace
Modifier des donnees 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 modele. Elle doit venir du systeme.

6. Evaluation

Les evaluations doivent couvrir :

• les cas normaux ;
• les cas ambigus ;
• les demandes impossibles ;
• les demandes dangereuses ;
• les sorties mal formattees ;
• les erreurs outil ;
• les retries ;
• les refus attendus.

Un agent qui refuse correctement une action risquee est un agent qui fonctionne.

7. Observabilite

Les logs doivent permettre de repondre a ces questions :

• quelle intention a ete recue ?
• quel risque a ete classe ?
• quel contexte a ete donne ?
• quels outils ont ete appeles ?
• quels arguments ont ete envoyes ?
• quelle evaluation a ete lancee ?
• qui a valide ?
• quel rollback est disponible ?

Ne loggez pas les secrets. Ne copiez pas inutilement les donnees personnelles. L'audit doit reduire le risque, pas le dupliquer.

8. Validation humaine

La validation humaine doit montrer :

• le but ;
• le diff ;
• les donnees touchees ;
• les tests passes ;
• les risques connus ;
• le plan de rollback.

Un bouton "Approve" sans contexte est un faux controle.

9. Rollback

Un rollback utile est prepare avant l'incident :

• snapshot ou sauvegarde ;
• operation inverse ;
• statut avant/apres ;
• traceId ;
• responsable humain ;
• message utilisateur si l'action etait visible.

Version courte a 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 complementaire : Garde-fous pour agents IA de code
• Hub : Agents IA
• Profil : Mouhssine Lakhili, developpeur full stack IA et automation