Prérequis pour déployer des agents IA en production (2025–2026)

Avant qu'un agent IA ne quitte le staging, il doit franchir une vraie barre. L'équipe qui le construit sait généralement que le modèle fonctionne. Ce qu'elle ne sait pas toujours, c'est si le système qui l'entoure répond aux exigences opérationnelles, sécuritaires et réglementaires qu'impose la production à l'échelle.

Cet article est une liste complète et auditable de ces prérequis pour 2025–2026 — organisés par domaine, chaque item rédigé de sorte qu'un auditeur sécurité, un SRE ou un responsable achats puisse l'utiliser comme checklist.

Comment lire cette liste

Chaque exigence est marquée d'une priorité :

• MUST — non-négociable avant tout trafic externe
• SHOULD — requis pour la montée en charge, les industries régulées ou les contrats enterprise
• NICE — avantage concurrentiel en 2026 mais pas encore un standard

Si vous déployez un pilote interne, les MUST sont le plancher. Si vous vendez à des entreprises, attendez-vous à ce qu'on vous demande tout ce qui est marqué MUST et SHOULD pendant le processus d'achat.

1. Exigences runtime et orchestration

MUST — Exécution durable. L'agent doit survivre aux redémarrages de containers, aux déploiements et aux crashs de workers sans perdre les sessions en cours. Cela exclut les agents naïfs en boucle while et pousse vers un moteur de workflow durable (Temporal, Inngest, Restate, LangGraph avec checkpoints persistés).

MUST — Budgets par étape. Chaque exécution d'agent doit avoir un maximum imposé sur : le nombre total de tokens, le nombre d'appels d'outils, le temps total écoulé, et le coût total.

MUST — Limites de concurrence par principal. Des limites de concurrence par utilisateur, par tenant et par outil doivent exister au niveau de la couche d'orchestration.

SHOULD — Reprise depuis un checkpoint. Chaque étape de l'agent doit pouvoir être relancée depuis son dernier état durable, tant pour les retries en cas d'erreur que pour le replay en debug.

SHOULD — Identifiants d'étape déterministes. Chaque étape d'une exécution d'agent doit avoir un identifiant stable pour que les traces, logs et évaluations puissent être corrélés entre les systèmes.

2. Exigences d'accès aux modèles et gateway

MUST — Tous les appels modèle passent par un gateway. Aucun appel direct au SDK du provider depuis le code applicatif. Le gateway centralise l'auth, les retries, le fallback, le cache, la rédaction et l'attribution des coûts.

MUST — Retry avec idempotence. Chaque appel modèle a une clé d'idempotence stable pour que les retries ne produisent pas d'effets de bord dupliqués.

MUST — Fallback de provider. Au moins un provider ou modèle secondaire est configuré pour chaque chemin critique. Le failover est testé au moins trimestriellement.

SHOULD — Cache de prompts activé. Les prompts système, schémas d'outils et contexte stable doivent utiliser le cache de prompts au niveau provider. Le taux de cache hit est une métrique suivie.

SHOULD — Routage de modèles. Les modèles peu coûteux gèrent la planification et les étapes simples ; les modèles coûteux sont réservés au raisonnement complexe.

3. Exigences de la couche outils

MUST — Schémas d'outils typés. Chaque outil expose un schéma d'entrée et de sortie strict, validé des deux côtés de l'appel.

MUST — Exécution sandboxée. Les outils tournent dans leur propre processus, container ou worker — jamais dans l'espace d'adressage de l'agent.

MUST — Idempotence pour les outils à effets de bord. Tout outil qui modifie un état externe accepte une clé d'idempotence du runtime de l'agent.

MUST — Credentials scopées. Les outils reçoivent des tokens de capacité scopés à la requête en cours, jamais les credentials de session brutes de l'utilisateur.

SHOULD — Commit en deux phases pour les actions à haut risque. L'agent propose une action ; une couche de politique ou un humain approuve ; alors seulement l'action s'exécute.

4. Exigences état, mémoire et retrieval

MUST — Séparation session, mémoire et retrieval. Trois stores distincts avec des cycles de vie, règles de rétention et contrôles d'accès distincts.

MUST — Isolation des tenants au niveau stockage. Séparation logique ou physique par tenant dans le vector store, le memory store et le trace store.

MUST — Chemins d'écriture mémoire explicites. L'agent ne peut pas persister silencieusement une mémoire. Les écritures en mémoire sont des opérations explicites, loggées et réversibles.

SHOULD — Support du droit à l'oubli. Suppression par utilisateur des mémoires, documents de retrieval et données de traces, avec complétion vérifiable dans le SLA requis (typiquement 30 jours sous RGPD).

5. Exigences d'observabilité

MUST — Tracing distribué. Chaque exécution d'agent produit une trace OpenTelemetry couvrant chaque prompt, complétion, appel d'outil et transition d'état.

MUST — Logs structurés avec rédaction. Tous les logs sont structurés (JSON ou équivalent), avec les PII rédactés à l'écriture selon une politique documentée.

MUST — Attribution des coûts. Chaque trace porte assez de métadonnées pour attribuer le coût à un tenant, une feature, un utilisateur et une version d'agent.

SHOULD — Alertes sur les SLO spécifiques aux agents. Les alertes couvrent non seulement la latence et les erreurs, mais aussi : les pics de coût par tâche, la régression des scores d'éval, le taux d'échec des outils.

6. Exigences d'évaluation

MUST — Suite d'éval dans la CI. Un jeu figé de tâches représentatives s'exécute à chaque PR. Les régressions bloquent le merge sauf override explicite.

MUST — Éval pré-déploiement. Avant que tout changement de prompt, d'outil ou de modèle n'atteigne la production, il passe la suite d'éval.

MUST — Échantillonnage d'éval en production. Un pourcentage des exécutions de production est scoré automatiquement. La dérive est suivie dans le temps.

SHOULD — Jeu d'éval adversarial. Des cas de test spécifiques pour les modes de défaillance connus : injection de prompt, mauvais usage des outils, hallucination.

7. Exigences de sécurité

MUST — Authentification sur chaque requête. Aucune invocation d'agent anonyme. Chaque appel est lié à un principal authentifié.

MUST — Autorisation au niveau outil. L'agent ne peut pas appeler un outil que l'utilisateur sous-jacent ne peut pas utiliser.

MUST — Classification entrée/sortie. Chaque entrée et sortie passe par un classifieur ou un contrôle de politique approprié au déploiement.

MUST — Allowlist d'egress. Les appels d'outils et le trafic réseau initié par l'agent sortent via un proxy allowlisté.

MUST — Gestion des secrets. Les clés API et credentials vivent dans un gestionnaire de secrets avec rotation à courte durée de vie.

SHOULD — Défenses contre l'injection de prompt. Le contenu non fiable est structurellement séparé des instructions, classifié, et jamais élevé au statut de prompt système.

8. Exigences de conformité et audit

MUST — Log d'audit de chaque décision. Un enregistrement immuable de chaque action de l'agent, avec une rétention correspondant à vos exigences réglementaires.

MUST — Contrôles de résidence des données. Pour les clients EU, les modèles, vector stores et trace stores doivent être déployables en région EU.

SHOULD — Conformité avec l'EU AI Act. À partir de 2026, les systèmes agentiques dans l'UE tombent sous des obligations spécifiques de transparence et de gestion des risques.

SHOULD — Mécanisme de supervision humaine. Un chemin documenté de human-in-the-loop pour les décisions à haut risque.

9. Exigences de contrôle des coûts

MUST — Plafonds de coûts par tenant. Des plafonds durs qui mettent en pause l'activité de l'agent pour un tenant qui dépasse son budget.

MUST — Métrique coût-par-tâche-réussie. Suivie en production. Le coût par token est du bruit ; le coût par résultat est la métrique business.

SHOULD — Alertes de coûts. Alertes automatisées quand la dépense journalière ou le coût par tâche dépasse les seuils.

10. Exigences de déploiement et rollout

MUST — Rollout avec feature flags. Chaque changement d'agent est livré derrière un flag avec la possibilité de le désactiver instantanément.

MUST — Kill switch testé en production. Une procédure documentée, régulièrement exercée, pour désactiver l'agent et dégrader gracieusement le produit.

MUST — Prompts et schémas d'outils versionnés. Stockés dans le contrôle de version, liés aux versions de modèles, déployables indépendamment du code applicatif.

SHOULD — Releases canary. Les nouvelles versions d'agent se déploient vers un petit pourcentage du trafic avec rollback automatique sur régression.

11. Exigences de readiness opérationnelle

MUST — Runbook pour les principaux modes de défaillance. Procédures écrites pour : panne du provider, panne du service d'outil, régression du score d'éval, pic de coût, incident d'injection de prompt.

MUST — Couverture d'astreinte. Une rotation d'astreinte avec des personnes qui comprennent à la fois l'agent et l'infrastructure sous-jacente.

SHOULD — Game days. Des exercices réguliers qui simulent des pannes de providers, des défaillances d'outils et des incidents de sécurité.

12. Le set minimum viable de prérequis

Si vous ne retenez que douze choses de cette liste, les voici :

1. Exécution durable avec budgets par étape et limites de concurrence
2. Tous les appels modèle à travers un gateway avec retries et fallback
3. Outils typés, sandboxés, idempotents avec credentials scopées
4. Stores session, mémoire et retrieval séparés avec isolation par tenant
5. Traces OpenTelemetry couvrant chaque étape
6. Suite d'éval dans la CI qui bloque les régressions
7. Authentification sur chaque requête, autorisation au niveau outil
8. Allowlist d'egress et secrets dans un gestionnaire de secrets
9. Log d'audit immuable avec rétention adaptée à votre régime réglementaire
10. Plafonds de coûts par tenant et suivi du coût par tâche réussie
11. Rollout avec feature flags et kill switch testé
12. Runbook et couverture d'astreinte pour les principaux modes de défaillance

Questions fréquentes

Ces exigences sont-elles les mêmes pour un agent interne et un agent exposé aux clients ?

Les MUST sont les mêmes. Les agents internes peuvent différer certains SHOULD, mais dès qu'un agent touche aux données clients ou prend des décisions en leur nom, l'écart se comble.

Qu'est-ce qui change sous l'EU AI Act pour les systèmes agentiques en 2026 ?

Les systèmes agentiques qui affectent matériellement les utilisateurs — décisions de crédit, embauche, conseil juridique, santé — tombent dans la catégorie haut risque et nécessitent une gestion des risques, une documentation technique, une supervision humaine, des tests de précision et de robustesse, et une surveillance post-marché.

Ai-je besoin de tout cela pour un pilote ?

Non. Pour un pilote interne de 50 utilisateurs, les priorités sont : exécution durable, isolation des tenants, observabilité, évals et kill switch. Le reste peut atterrir dans les mois précédant un déploiement plus large.

Qu'est-ce qui est le plus difficile à ajouter après coup ?

L'isolation des tenants dans les vector et memory stores, et l'attribution des coûts par tenant. Les deux sont plus faciles à concevoir dès le premier jour qu'à ajouter après que des milliers d'enregistrements soient déjà mélangés.

La liste de prérequis pour les agents IA en production en 2026 est longue, mais chaque ligne a été gagnée par un incident réel dans une vraie entreprise. La traiter comme une checklist n'est pas de la bureaucratie — c'est la différence entre un agent qui scale avec votre business et un agent qui devient la raison de votre prochain postmortem.