Agents IA en production : guide fiable

Du pilote à la production : ce qui change vraiment

Un prototype se contente généralement de tester un scénario nominal : il reçoit une requête, consulte des informations, appelle un outil et renvoie une réponse convaincante. En production apparaissent des entrées ambiguës ou malveillantes, des documents corrompus, des services en panne, des permissions héritées, des états partiels, de la concurrence, des changements de modèle et des personnes qui traitent la réponse comme une décision valide.

La différence décisive ne se joue pas au niveau du modèle, mais du système qui l'entoure. Un agent combine raisonnement probabiliste, mémoire, recherche d'information, outils et capacité d'action. Chaque composant introduit ses propres défaillances, ainsi que des défaillances d'interaction. C'est pourquoi la conception doit partir de l'autonomie nécessaire, et non de l'autonomie techniquement possible.

Il convient de distinguer quatre niveaux :

L'autonomie ne doit être augmentée que lorsqu'il existe des preuves qu'elle améliore le processus sans porter le risque résiduel au-delà du seuil accepté.

L'architecture minimale d'un agent fiable

Identité et permissions propres

L'agent ne devrait pas fonctionner avec le compte d'une personne administratrice ni hériter de l'ensemble de ses privilèges. Il a besoin d'une identité technique propre, d'identifiants rotatifs et de permissions limitées par outil, ressource, opération et environnement. Lire une commande, préparer un brouillon et approuver un paiement sont des capacités distinctes.

Les permissions doivent également limiter le volume et la fréquence : montant maximal, nombre d'enregistrements, destinataires autorisés ou plages horaires. Dans la mesure du possible, les opérations de lecture et d'écriture sont séparées, et une confirmation indépendante est exigée pour les actions irréversibles.

Orchestrateur à politique explicite

Le modèle peut proposer un plan, mais un composant déterministe doit décider si chaque action est autorisée. La politique valide le schéma, l'identité, le contexte, l'outil, les arguments et les limites. Une instruction contenue dans un e-mail ou un document ne doit jamais étendre les permissions.

Chaque appel d'outil doit inclure un identifiant d'exécution et une clé d'idempotence. Ainsi, une nouvelle tentative après un délai d'expiration ne crée pas deux factures, deux tickets ou deux virements. Les opérations composées nécessitent une stratégie de compensation : si la troisième étape échoue, le système doit savoir quoi annuler et quoi laisser en attente de vérification.

Mémoire et connaissances avec traçabilité de provenance

La mémoire conversationnelle ne doit pas devenir une base de données sans gouvernance. Il faut séparer le contexte éphémère, la mémoire approuvée et les sources de l'entreprise. Chaque fragment récupéré a besoin d'une provenance, d'une date, d'un propriétaire, d'une classification et de permissions. L'agent ne doit pas enregistrer comme un fait une sortie non validée du modèle lui-même.

Dans les systèmes RAG, l'autorisation s'applique avant la récupération du contenu et est revérifiée avant son affichage. Filtrer après que le modèle a déjà lu le document n'empêche pas l'exposition.

Environnement d'exécution isolé

Si l'agent génère du code, traite des pièces jointes ou navigue sur le web, ces tâches doivent s'exécuter dans un environnement limité, sans secrets inutiles, avec un accès réseau restreint, des quotas et une destruction après usage. Le résultat est traité comme une entrée non fiable. Le code généré n'est jamais exécuté directement en production.

Évaluer avant de le laisser agir

L'évaluation doit refléter le travail réel et ses conséquences. Un jeu de tests utile comprend des cas normaux, des cas limites, des données incomplètes, des instructions contradictoires, des attaques, des pannes d'outils et des changements de version. Il doit rester distinct des exemples utilisés pour ajuster les prompts.

Les métriques sont regroupées par couches :

• Résultat : tâche résolue, exactitude des champs, couverture et qualité de la décision.
• Processus : bons outils, ordre adéquat, nombre d'étapes, nouvelles tentatives et boucles.
• Sécurité : actions interdites, fuite d'information, résistance à l'injection et élévation de privilèges.
• Supervision : alertes correctes, escalades, annulations humaines et délai de détection d'une défaillance.
• Exploitation : latence, disponibilité, coût par tâche et consommation en percentiles, pas seulement en moyenne.
• Impact : erreurs qui atteignent des personnes, réclamations, corrections et dommages potentiels.

Un score global unique masque les risques. Les critères d'acceptation doivent inclure des portes éliminatoires : par exemple, zéro action critique non autorisée et une traçabilité complète. Un taux de réussite de 95 % ne sert à rien si les 5 % restants peuvent effectuer des paiements incorrects.

Avant le déploiement, des tests de régression sont exécutés à chaque changement de modèle, de prompt, d'outil, de politique, d'index ou de source. L'agent est ensuite activé d'abord en mode fantôme — sans exécuter d'actions —, puis auprès d'une population limitée, et enfin avec un déploiement progressif.

Menaces spécifiques aux agents

Le guide OWASP Top 10 for Agentic Applications 2026 identifie des risques qui doivent figurer dans le modèle de menaces. Parmi eux : le détournement d'objectif, l'usage abusif des outils, l'abus d'identité et de privilèges, la chaîne d'approvisionnement, l'exécution inattendue de code et l'empoisonnement de la mémoire ou du contexte.

Les contrôles les plus importants sont :

1. Traiter les messages, pages web, documents et résultats d'outils comme des données, non comme des instructions faisant autorité.
2. N'autoriser que des outils enregistrés et des versions approuvées.
3. Valider les arguments à l'aide de schémas et de règles métier déterministes.
4. Séparer les secrets du prompt et ne les fournir qu'au moment de l'appel autorisé.
5. Signer ou vérifier les artefacts et journaliser les changements apportés aux outils, connecteurs et modèles.
6. Limiter la profondeur du plan, le nombre d'itérations, le coût et le temps.
7. Tester les attaques par injection directe et indirecte, la confusion d'identité et le contenu contaminé.
8. Mettre en place un interrupteur qui bloque toute nouvelle action sans dépendre du modèle lui-même.

Une supervision humaine véritablement humaine

Ajouter un bouton « approuver » ne crée pas une garantie si la personne ne comprend pas l'action ou reçoit des centaines d'alertes. La relecture doit se concentrer sur les décisions significatives : paiements, modifications contractuelles, communications sensibles, suppression de données, octroi de privilèges ou décisions concernant des personnes.

L'écran d'approbation doit afficher l'objectif, les sources, l'action proposée, l'outil, les champs concernés, l'incertitude, les conséquences et les alternatives. La personne chargée de la relecture a besoin de temps, de compétence et de l'autorité de refuser. Les approbations sont enregistrées avec l'identité et le motif.

Une matrice peut être utilisée :

La confiance du modèle ne remplace jamais l'impact et la réversibilité.

Observabilité, incidents et amélioration continue

Chaque exécution nécessite une trace corrélée : version de l'agent et du modèle, politiques appliquées, sources récupérées, outils appelés, arguments — avec les données sensibles protégées —, résultats, décisions humaines, coût et latence. Les journaux ne doivent pas stocker sans discernement des prompts contenant des données personnelles.

Des alertes utiles détectent la répétition d'actions, une hausse des rejets, des variations brutales de coût, des appels inhabituels, des accès refusés, une perte de sources, un écart par rapport aux règles et une dégradation du jeu d'évaluation. Des responsables et des délais de réponse doivent être définis.

Un incident exige de pouvoir arrêter, isoler, reconstituer et corriger. La procédure minimale comprend la préservation des preuves, la révocation des identifiants, l'identification des actions réalisées, l'annulation lorsque c'est possible, l'évaluation des données et des personnes concernées, et la décision de procéder ou non à une notification réglementaire.

Maîtrise des coûts et des performances

Le coût par jeton n'est pas le coût du processus. Il faut y ajouter la recherche documentaire, les outils, les nouvelles tentatives, la relecture humaine, l'infrastructure, l'observabilité et les incidents. L'unité économique pertinente est généralement le coût par tâche valide, et non le coût par appel.

Pour le réduire sans dégrader la qualité :

• Utiliser des règles déterministes pour les validations simples.
• Sélectionner les modèles selon la difficulté de chaque étape.
• Limiter le contexte et ne récupérer que les documents pertinents.
• Ne mettre en cache que les résultats soumis à une politique d'expiration.
• Interrompre les boucles et les plans sans progression.
• Réserver les modèles les plus coûteux aux décisions qui le justifient.

Un plan pratique sur 90 jours

Jours 1-30 : périmètre et preuves

• Choisir un processus circonscrit, fréquent et réversible.
• Cartographier les données, systèmes, personnes et conséquences.
• Définir les actions autorisées et expressément interdites.
• Créer 50 à 100 cas de test initiaux, y compris attaques et pannes.
• Désigner un propriétaire, un responsable technique, la sécurité et une relecture juridique.

Jours 31-60 : contrôles et tests

• Mettre en place une identité propre, des permissions minimales et des politiques déterministes.
• Ajouter des traces, l'idempotence, des limites et un mécanisme d'arrêt.
• Exécuter des tests fonctionnels, de sécurité et de confidentialité.
• Fonctionner en mode fantôme et comparer avec le processus en vigueur.

Jours 61-90 : déploiement limité

• Activer avec des utilisateurs et des opérations restreints.
• Examiner des échantillons et tous les cas à fort impact.
• Mesurer le résultat, le risque, le coût et l'adoption.
• N'étendre que les capacités qui franchissent les portes d'acceptation.

Checklist de mise en production

• Cas d'usage, propriétaire et limites documentés.
• Identité technique et permissions minimales par outil.
• Données, mémoire et sources avec autorisation et traçabilité de provenance.
• Actions validées par des politiques déterministes.
• Idempotence, délai d'expiration, nouvelles tentatives et compensation testés.
• Évaluation fonctionnelle, adversariale et de régression validée.
• Supervision humaine liée à l'impact et à la réversibilité.
• Traces, métriques, alertes et runbook d'incidents actifs.
• Budget et limites de consommation configurés.
• Déploiement progressif et mécanisme d'arrêt vérifié.

Questions fréquentes

Quel taux de réussite un agent doit-il atteindre ?

Il n'existe pas de taux universel. Cela dépend du dommage potentiel. Pour les actions critiques, certaines catégories d'erreurs doivent avoir une tolérance zéro et une approbation humaine obligatoire.

Suffit-il d'ajouter des garde-fous au prompt ?

Non. Le prompt est une couche fragile. Les contrôles décisifs se situent en dehors du modèle : identité, permissions, schémas, règles, isolation, limites et audit.

Peut-il fonctionner avec le compte d'une personne ?

Ce n'est pas recommandé. Cela empêche d'appliquer le principe du moindre privilège et d'attribuer clairement les actions. Il doit utiliser une identité technique délimitée.

Quand vaut-il mieux le maintenir en copilote ?

Lorsque la tâche a un impact élevé, une réversibilité limitée, une faible fréquence, ou qu'il n'existe pas suffisamment de preuves pour automatiser la décision.

Comment éviter une boucle coûteuse ?

Avec des limites sur les étapes, le temps et le budget ; une détection de l'absence de progression ; l'idempotence ; et une escalade vers une personne.

Faut-il réévaluer en cas de changement de modèle ?

Oui. Également en cas de changement de prompts, d'outils, de permissions, de données, d'index ou de règles. Chacun de ces éléments peut modifier le comportement du système.

Sources primaires et techniques consultées

• NIST AI Risk Management Framework.
• NIST AI RMF: Generative AI Profile.
• NIST AI Agent Standards Initiative, février 2026.
• OWASP Top 10 for Agentic Applications 2026.
• AEPD (autorité espagnole de protection des données) : intelligence artificielle agentique et protection des données.

Summum IA accompagne le passage du prototype à la production grâce à l'architecture, l'évaluation, le LLMOps et la gouvernance. L'objectif n'est pas d'accorder une autonomie maximale, mais d'atteindre l'autonomie minimale qui produit de la valeur de façon maîtrisée.