Pourquoi ce sujet est important
Un agent de démonstration peut réussir une tâche impressionnante puis échouer de façon coûteuse sur un cas banal. En production, la fiabilité vient d’une architecture qui contraint le modèle, vérifie ses actions et rend le travail reprenable.
Pattern — workflow avant autonomie
Si les étapes sont connues, utilisez un graphe ou une machine à états. Réservez la décision agentique aux embranchements réellement variables. Cette séparation facilite tests, budgets et diagnostic.
Pattern — outils étroits
Un outil effectue une opération claire avec schéma typé. Le backend applique identité, autorisation, validation et idempotence. Séparez lecture et écriture. Retournez des erreurs structurées que l’agent peut comprendre sans révéler de secrets.
Pattern — état et checkpoints
Stockez état métier, artefacts et événements hors de l’historique du modèle. Créez un checkpoint avant attente humaine ou action longue. À la reprise, vérifiez que données et droits restent valides.
Pattern — budgets et arrêts
Fixez étapes, durée, tokens, coût et répétitions d’outils. Détectez absence de progrès et résultats identiques. Définissez une sortie dégradée ou un transfert humain plutôt que de laisser la boucle continuer.
Pattern — validation humaine ciblée
Demandez approbation avant les effets sensibles. Présentez action, arguments, sources et conséquence. Mesurez rejets et modifications pour améliorer le système, puis automatisez progressivement les cas sûrs.
Anti-pattern — agent omnipotent
Un agent avec accès général au réseau, au shell et aux données transforme toute prompt injection en risque majeur. Appliquez le moindre privilège, des environnements isolés et des listes d’actions autorisées.
Anti-pattern — mémoire illimitée
Conserver tout l’historique augmente coût, fuite et erreurs. Séparez faits structurés, résumé et documents. Appliquez durée, provenance et correction.
Évaluer le processus
Mesurez résultat, choix d’outil, arguments, nombre d’étapes, coût, reprise et sécurité. Rejouez pannes, données ambiguës et injections. Une réponse finale correcte peut masquer des actions dangereuses.
Exemple concret
Un agent de facturation peut lire compte et factures, puis proposer un avoir. Il ne peut pas l’exécuter directement. Un workflow valide montant et règles, demande approbation et utilise une clé d’idempotence. La tâche s’arrête après cinq étapes.
Les erreurs fréquentes
- transformer tout workflow en agent
- donner des outils génériques
- utiliser le chat comme seul état
- réessayer sans distinguer les erreurs
- mesurer uniquement la réponse finale
- ne pas prévoir de transfert humain
Checklist
- [ ] Parties déterministes séparées
- [ ] Outils étroits et typés
- [ ] État durable et checkpoints
- [ ] Budgets configurés
- [ ] Actions sensibles validées
- [ ] Permissions minimales
- [ ] Traces et coûts observés
- [ ] Scénarios adverses testés
FAQ
Quel premier agent mettre en production ?
Un cas à faible risque, en lecture, avec peu d’outils et une sortie vérifiable.
Combien d’outils ?
Le minimum nécessaire. Un grand catalogue augmente erreurs de sélection et surface d’attaque.
Comment gérer les retries ?
Seulement pour les erreurs transitoires, avec backoff, limite et idempotence.
Un framework garantit-il la fiabilité ?
Non. Il fournit des primitives ; architecture, droits, tests et exploitation restent à concevoir.