Trois piliers pour évaluer si un projet d'agents IA est prêt pour la production.

Un cadre applicable quel que soit le modèle, le fournisseur ou la stack utilisée.

Selon le MIT (The GenAI Divide, 2025 — 300 projets, 150 entreprises), 95% des projets GenAI en entreprise ne produisent pas de ROI mesurable. La cause identifiée n'est pas un manque de capacité des modèles, mais un défaut d'intégration : la manière dont le modèle est relié aux données, aux processus et aux décisions de l'organisation. Les trois piliers ci-dessous couvrent les composants essentiels de cette intégration.

« Le modèle, c'est le cerveau. Sans système nerveux pour le relier aux réalités de l'organisation, il ne produit rien d'exploitable. »

Le framework COP

CONTEXTE

Ce que l'agent sait de votre organisation
Le contexte regroupe les informations métier dont l'agent a besoin pour produire des résultats pertinents : contraintes sectorielles, politiques internes, vocabulaire, historique. Il se matérialise en system prompts, documents de référence et mémoire persistante.
À surveiller
Les instructions à l'agent ne sont pas documentées.
Aucun versioning ni test sur les prompts utilisés.
Chaque équipe maintient ses propres documents de contexte.
L'agent n'a pas accès au contexte des sessions précédentes.

OUTILLAGE

Les outils et opérations que l'agent peut exécuter de manière fiable
Les tâches récurrentes (nettoyage de données, extraction, normalisation, génération de rapports etc...) gagnent à être packagées en outils déterministes que l'agent invoque, plutôt que régénérées sous forme de scripts à chaque session. Pensez à une mcp toolbox locale ou workflow réutilisables.
À surveiller
L'agent génère du code à la volée pour des tâches déjà réalisées.
Les résultats diffèrent d'une exécution à l'autre pour le même input.
L'ensemble du système repose sur un seul fournisseur de modèle.
Pas de couche d'abstraction entre l'agent et les opérations techniques.

PROCESSUS

Le périmètre d'action de l'agent et ses points de contrôle
Le processus définit quelles étapes l'agent prend en charge, à quels moments une validation humaine intervient, et selon quels critères le résultat est considéré comme acceptable. Il rend le fonctionnement de l'agent auditable et reproductible. Cela se matérialise par des guardrails, des logs structurés et des tests de régression.
À surveiller
Aucun critère explicite de ce qui constitue un résultat acceptable.
Les décisions prises par l'agent ne sont pas journalisées.
Pas de validation humaine sur les étapes à conséquence.
En cas d'erreur, on ne peut pas identifier l'étape qui a échouée.

Ce que ces trois piliers rendent possible

Quand ces trois éléments sont en place, le système d'agents acquiert trois propriétés rarement présentes au stade du POC et qui déterminent sa viabilité à moyen terme.

Fiabilité
Le même input produit le même résultat. Le système peut être opéré par une personne qui ne l'a pas construit.
Auditabilité
On peut retracer ce que l'agent a fait, quelles décisions il a prises, et les expliquer à un tiers (client, direction, régulateur).
Portabilité
Le modèle utilisé aujourd'hui peut être remplacé sans reconstruire l'ensemble du système. L'investissement n'est pas lié à un fournisseur.

En pratique : les 6 composants du harness et 21 questions pour évaluer un projet.

Les trois piliers de la page précédente constituent le cadre de décision. En pratique, ils se décomposent en composants d'architecture concrets qui constituent ce que la communauté technique appelle le harness : tout ce qui entoure le modèle et qui détermine la qualité du système.

Les 6 principaux composants du harness

01

System prompts & configs

Les instructions qui cadrent le comportement de l'agent.
En pratique Les règles, le ton, les contraintes métier, les interdits, versionnés dans le repo, testés à chaque modification, partagés entre les membres de l'équipe.
02

Outils (Tools)

Les capacités d'action que l'agent peut invoquer.
En pratique L'ensemble des opérations que l'agent peut déclencher : appels à des APIs externes (CRM, messagerie, bases de données), serveurs MCP, scripts métier packagés, commandes système.
03

Mémoire & contexte

Ce que l'agent retient entre les sessions.
En pratique Documents de référence, glossaire métier, historique des décisions. Structurés en fichiers accessibles à l'agent, mis à jour avec le projet.
04

Observabilité

Savoir ce que l'agent fait, et à quel coût.
En pratique Logs structurés des décisions de l'agent, métriques de consommation de tokens par session et par tâche, traces des outils appelés et de leurs résultats.
05

Guardrails

Les mécanismes de sécurité et de contrôle qui encadrent l'agent.
En pratique Confirmation humaine sur les opérations à conséquence, détection des données sensibles, whitelisting des outils autorisés. Protection contre les prompt injections, sanitisation des entrées/sorties, isolation des privilèges.
06

Évaluation

Mesurer la pertinence du système après un changement.
En pratique Tests de régression sur les comportements critiques, benchmarks avant/après chaque modification du prompt ou des outils, métriques de qualité suivies dans le temps.

14 questions et 7 signaux d'alerte pour évaluer un projet d'agents IA

AVANT
Avant de lancer le projet
7 questions à se poser en interne
  1. Quel problème métier concret cet agent résout-il ?
  2. Quelle est la valeur créée par heure gagnée, et qui en bénéficie ?
  3. Quel est le coût d'une erreur de l'agent, et qui l'assume ?
  4. Quelles données internes l'agent doit-il connaître pour être utile ?
  5. À quelles étapes le jugement humain reste-t-il nécessaire ?
  6. Qui est responsable de l'agent après la phase de POC ?
  7. Que se passe-t-il si le fournisseur de modèle change ses conditions ?
PENDANT
À demander à l'équipe ou au prestataire
7 questions pour challenger l'implémentation
  1. Où est stocké le contexte métier de l'agent, et qui le maintient ?
  2. Comment vérifiez-vous qu'une nouvelle version ne dégrade pas les résultats ?
  3. Quels outils l'agent utilise-t-il, et lesquels sont déterministes ?
  4. Quel est le comportement prévu quand un outil échoue ?
  5. Peut-on consulter le log complet d'une exécution avec les décisions de l'agent ?
  6. Quel effort est nécessaire pour basculer sur un autre modèle ?
  7. Sur quels indicateurs mesurez-vous la valeur ajoutée de l'agent ?
APRÈS
Signaux d'alerte en cours de projet
7 situations qui indiquent un problème structurel
  1. L'agent fonctionne en démo mais n'est pas utilisé au quotidien.
  2. Le prompt principal dépasse 400 lignes et personne ne le modifie.
  3. Un changement de modèle casserait la majorité du système.
  4. On ne peut pas expliquer pourquoi l'agent a produit un résultat donné.
  5. Les résultats varient d'une exécution à l'autre sans raison identifiée.
  6. La consommation de tokens augmente sans que la valeur produite suive.
  7. Une seule personne est capable de maintenir le système.