Pourquoi les pilotes n’arrivent pas en production
Faire une démo d’agent IA prend une après-midi. Le faire tenir en production dans une équipe engineering prend des semaines, et beaucoup de projets n’y arrivent jamais. Ce guide traite de cet écart : ce qu’il faut concevoir pour qu’un agent soit utile, mesuré et maîtrisé dans un environnement d’entreprise.
Les chiffres publics racontent la même histoire. Gartner prévoit que plus de 40 % des projets d’IA agentique seront annulés d’ici fin 2027, pour des coûts qui dérivent, une valeur métier floue ou des contrôles de risque insuffisants (Gartner, juin 2025). Dans l’enquête McKinsey 2026, la part des répondants qui voient un effet de l’IA sur le résultat de leur entreprise reste stable autour de 37 %, alors que l’usage progresse (McKinsey, State of AI).
Le rapport MIT NANDA de 2025 va plus loin : selon lui, 95 % des pilotes d’IA générative n’ont pas d’impact mesurable sur le compte de résultat. Sa méthodologie (entretiens, sondage, analyse de déploiements publics) est discutée, mais un point est utile : les projets menés avec une expertise externe réussissent nettement plus souvent que ceux construits uniquement en interne (synthèse du rapport).
Pourquoi les pilotes n'arrivent pas en production
Les causes sont rarement le modèle. Elles sont presque toujours dans le système autour.
- Un cas d’usage choisi pour la démo, pas pour sa fréquence ni sa valeur.
- Un agent trop autonome pour le risque qu’il porte, puis rétrogradé après un incident.
- Aucune mesure de référence : impossible de prouver un gain, donc de financer la suite.
- Une gouvernance ajoutée après coup, quand la sécurité bloque le déploiement.
- Une adoption non travaillée : l’outil existe, l’équipe ne l’utilise pas.
Ce que couvre ce guide
Cinq blocs, dans l'ordre où les problèmes apparaissent en production.
- Fondamentaux : choisir entre workflow et agent, et une complexité justifiée.
- Architecture : outils, contexte, état, reprise et budgets.
- Contrôle humain : concevoir la validation et une matrice d’autonomie.
- Mesure : evals reproductibles et valeur réelle, avec un simulateur interactif.
- Production : sécurité, souveraineté, exploitation, adoption et checklist finale.
Les exemples viennent de missions où des agents sont utilisés sur de vrais cycles de développement : migrations pilotées par des workflows IA, agent de montée de version dans GitLab CI/CD, revue sécurité assistée, sur des modèles et une infrastructure cloud souverains hébergés en France. Ils sont détaillés dans les retours terrain. Quand un résultat n’est pas mesuré, le guide le dit.
Workflow ou agent : choisir une complexité justifiée
Anthropic distingue deux familles de systèmes. Dans un workflow, le code orchestre le LLM et les outils selon des chemins prédéfinis. Dans un agent, le LLM dirige lui-même son processus et le choix de ses outils (Building effective agents).
Cette distinction n’est pas théorique : elle fixe où se trouve le contrôle. Plus le modèle décide, plus il faut d’evals, de garde-fous et d’observabilité pour garder le système maîtrisable. En entreprise, un workflow explicite avec quelques étapes agentiques est presque toujours le bon point de départ.
- Prévisible
- Peu coûteux
- Facile à auditer
- Aucune adaptation aux cas imprévus
- •Renommages, montées mineures, formatage
- Transitions contrôlées
- Validation humaine naturelle
- Evals ciblées
- Demande de concevoir le plan et ses contrôles
- •Migrations, montées majeures, revue assistée
- Gère des chemins imprévus
- Plus difficile à évaluer et à sécuriser
- •Diagnostic de build, exploration de dépôt
- Parallélisme
- Contextes séparés
- Coûts, coordination et débogage multipliés
- •Seulement quand le découpage apporte un gain mesuré
Script déterministe | Workflow + appel LLM | Agent borné | Plusieurs agents |
|---|---|---|---|
Transformation répétable, règles stables. | Étapes connues, une analyse variable confiée au modèle. | Recherche adaptative, outils multiples, périmètre et budget fixés. | Sous-tâches indépendantes avec responsabilités distinctes. |
Avantages
| Avantages
| Avantages
| Avantages
|
Inconvenients
| Inconvenients
| Inconvenients
| Inconvenients
|
Cas d'usage
| Cas d'usage
| Cas d'usage
| Cas d'usage
|
Exemple : une migration de design system
Sur une mission, la migration vers le DSFR a été découpée entre un agent d'analyse et un agent de migration, avec une validation par composant et par fichier.
Le découpage n’était pas là pour faire « multi-agents ». Il séparait deux responsabilités qui se vérifient différemment : l’analyse se relit comme un plan, la migration se vérifie par les tests et le rendu. Le reste était un workflow classique, ultra-incrémental.
Éviter la dispersion
Chaque brique ajoutée doit répondre à un échec observé, pas à une tendance.
- Multiplier les frameworks sans comparaison sur votre cas.
- Optimiser les prompts au lieu de corriger l’architecture ou le contexte.
- Ajouter RAG, base vectorielle ou mémoire persistante sans besoin de contexte démontré.
- Confondre vitesse de génération, productivité et valeur livrée.
- Dépendre d’un framework opaque qu’on ne sait plus déboguer.
Outils et contexte
Un agent ne vaut que par ses outils et le contexte qu’on lui donne. C’est là que se joue la majorité de la fiabilité, bien avant le choix du modèle.
Concevoir des outils comme des contrats
Un outil mal défini produit des appels ambigus, des effets de bord surprises et des erreurs que personne ne sait interpréter.
- Entrées typées et validées : le programme refuse ce qui sort du contrat.
- Une responsabilité par outil : lire, écrire et publier sont des outils distincts.
- Effets de bord déclarés : aucun, écriture locale, écriture externe.
- Erreurs exploitables : un code, un message, une piste de suite.
- Idempotence des effets externes : relancer ne crée pas de doublon.
1import { z } from 'zod';2
3// Un outil = un contrat métier : entrée validée, effets déclarés, erreurs exploitables.4export const readFileTool = {5 name: 'read_repository_file',6 description: 'Lit un fichier du dépôt autorisé. Ne modifie rien.',7 sideEffects: 'none' as const,8 input: z.object({9 path: z.string().regex(/^[\w./-]+$/).refine((p) => !p.includes('..'), 'Chemin hors dépôt'),10 maxBytes: z.number().int().positive().max(200_000).default(50_000),11 }),12};13
14export const openMergeRequestTool = {15 name: 'open_merge_request',16 description: 'Ouvre une merge request depuis une branche agent/*. Idempotent par branche.',17 sideEffects: 'external-write' as const, // soumis à la politique d'autonomie18 input: z.object({19 branch: z.string().startsWith('agent/'),20 title: z.string().min(10).max(120),21 reportMarkdown: z.string().min(1),22 }),23};24
25// Une erreur doit dire au modèle (et à l'humain) quoi faire ensuite.26export type ToolError =27 | { code: 'NOT_FOUND'; message: string; hint: 'Vérifier le chemin avec list_repository_files' }28 | { code: 'FORBIDDEN'; message: string; hint: 'Action hors périmètre : escalader' }29 | { code: 'TOO_LARGE'; message: string; hint: 'Relire avec une plage de lignes' };Gérer le contexte
Plus de contexte n'est pas mieux. Le bon contexte est pertinent, versionné, frais et traçable.
- Fichier-pilote versionné (
AGENTS.mdou équivalent) : stack figée, conventions, pièges connus, commandes de vérification. - Guides de patterns capitalisés pendant le travail et réutilisés par les agents suivants.
- Sources citées dans les sorties, pour que l’humain vérifie vite.
- Budget de contexte : charger le code utile, pas le dépôt entier.
- Sorties structurées : un schéma rend le résultat vérifiable, sans garantir qu’il est juste.
Sur une migration React 16 → 18 menée sur 352 composants, le fichier-pilote et quatre guides de patterns ont fait la différence : les pièges silencieux (classes Bootstrap 5 ignorées sans erreur, composants disparus d’une bibliothèque UI) étaient écrits avant de déléguer, au lieu d’être redécouverts à chaque fichier.
MCP (Model Context Protocol) standardise la connexion entre agents et outils. C’est utile pour l’intégration, mais le protocole ne remplace ni les contrats métier des outils, ni les permissions, ni l’isolation : ces sujets restent à votre charge.
État, reprise et budgets
Un agent en production est un système distribué comme un autre : il est relancé, il attend, il échoue au milieu, il tourne en parallèle d’un autre run. Les problèmes classiques (doublons, concurrence, reprise) arrivent dès les premières semaines.
Séparer trois types de mémoire
Mélanger contexte temporaire, état du run et connaissances persistantes rend le système impossible à déboguer.
- Contexte temporaire : ce que le modèle voit pendant une étape. Jetable.
- État du run : statut, commit de base, plan, validations, coûts. Durable et versionné.
- Connaissances persistantes : guides, pièges connus. Avec provenance et invalidation.
1type RunStatus =2 | 'analysing'3 | 'awaiting_approval'4 | 'applying'5 | 'verifying'6 | 'done'7 | 'escalated'8 | 'failed';9
10interface Budget {11 maxIterations: number;12 maxDurationMs: number;13 maxCostEur: number;14}15
16interface Run {17 id: string;18 status: RunStatus;19 baseCommit: string;20 workflowVersion: string;21 model: string;22 iterations: number;23 startedAt: number;24 costEur: number;25 budget: Budget;26}27
28// Au-delà du budget, on s'arrête et on escalade : jamais de boucle infinie.29export function nextStepAllowed(run: Run, now = Date.now()): boolean {30 return (31 run.iterations < run.budget.maxIterations &&32 now - run.startedAt < run.budget.maxDurationMs &&33 run.costEur < run.budget.maxCostEur34 );35}| Brique | Responsabilité | Décision à documenter |
|---|---|---|
| Orchestration | Transitions, reprise, annulation | États possibles, timeouts, propriétaire du run |
| Outils | Lire, tester, écrire, publier | Contrats, droits, idempotence |
| Exécution | Faire tourner du code non fiable | Isolation, réseau, ressources accessibles |
| Politiques | Autoriser les actions | Niveau de risque et décision applicable |
| Validation | Présenter une décision claire | Plan approuvé, identité, validité de l’accord |
| Exploitation | Diagnostiquer et maintenir | Traces, alertes, runbook |
Le contrat minimal d'un run
Ce qu'il faut conserver pour qu'une autre personne comprenne un run raté sans vous appeler.
- Identifiant du run, ticket, dépôt et commit de départ.
- Versions du workflow et des prompts, modèle utilisé.
- Outils appelés, avec durées et erreurs.
- Plan, validations humaines et contrôles exécutés.
- Coûts et état final, y compris en cas d’abandon.
Concevoir la validation humaine
Le human-in-the-loop n’est pas une case « valider » ajoutée à la fin. C’est un point de décision conçu : une personne identifiée approuve, corrige ou refuse ce que l’agent propose, avec les preuves nécessaires pour trancher vite et bien.
Le risque principal n’est pas l’absence de validation, c’est l’approbation machinale. Si l’écran de validation est long, flou ou répétitif, les gens cliquent sans lire. La qualité de la validation est donc un problème d’UX autant que de sécurité.
Ce que la validation doit montrer
Tout ce qu'il faut pour décider, rien de plus.
- L’objectif et le résultat attendu.
- Les sources utilisées et les points incertains.
- Les changements prévus et ce qui est hors périmètre.
- Les risques, la compatibilité et le retour arrière possible.
- Les tests prévus et les limites de leur couverture.
- Trois actions distinctes : approuver, demander une correction, refuser.
Les règles d'un accord valable
Un accord porte sur une version précise d'un plan, dans un état précis du système.
- L’accord est lié à la version du plan et à l’état du dépôt (commit).
- Un changement matériel du plan ou du dépôt exige une nouvelle décision.
- L’accord expire : sans décision dans le délai, le run s’arrête.
- Le silence n’est jamais un accord.
- Seules les personnes habilitées peuvent approuver, et leur identité est tracée.
Les pièges fréquents
Ce qui transforme une validation humaine en théâtre.
- Valider un résultat final énorme au lieu d’un plan court en amont.
- Demander une validation pour des actions sans risque : la fatigue s’installe.
- Une validation que la CI ne bloque pas réellement (job manuel optionnel).
- Mélanger la preuve produite par un outil et l’appréciation du modèle dans le même texte.
L’implémentation concrète dans GitLab CI/CD (job manuel bloquant, environnement protégé, approbation liée au commit) est détaillée dans l’article Agent IA dans GitLab CI/CD : montée de version avec validation humaine.
La matrice d’autonomie
Toutes les actions d’un agent ne portent pas le même risque. Lire un dépôt n’exige pas la même garde qu’ouvrir une merge request, et fusionner sur la branche principale ne devrait jamais être délégué au départ.
Gartner prévient qu’appliquer une gouvernance uniforme à tous les agents, quel que soit leur niveau d’autonomie et leur périmètre, mène à l’échec des agents en entreprise (Gartner, mai 2026). Trop stricte partout, elle tue l’usage ; trop laxiste partout, elle provoque les incidents qui font rétrograder l’agent.
| Action | Politique initiale | Condition |
|---|---|---|
| Lire le dépôt | Automatique | Dépôt et identité autorisés |
| Consulter des sources externes | Automatique sous politique | Sources approuvées, contenu traité comme non fiable |
| Produire un plan | Automatique | Hypothèses et preuves visibles |
| Appliquer le plan dans une branche isolée | Après approbation | Périmètre inchangé, droits limités |
| Exécuter les tests | Automatique en isolation | Scripts du dépôt traités comme du code exécutable |
| Créer une merge request | Selon la politique de l’équipe | Rapport et contrôles joints |
| Fusionner | Personne habilitée | Règles de revue satisfaites |
| Déployer en production | Autorisation dédiée | Politique de livraison, retour arrière possible |
1type Decision = 'auto' | 'approval' | 'forbidden';2
3type AgentAction =4 | 'read_repository'5 | 'fetch_external_source'6 | 'produce_plan'7 | 'apply_plan_in_branch'8 | 'run_tests'9 | 'open_merge_request'10 | 'merge'11 | 'deploy_production';12
13// La politique est du code versionné et relu, pas une consigne dans un prompt.14export const POLICY: Record<AgentAction, Decision> = {15 read_repository: 'auto',16 fetch_external_source: 'auto', // sources approuvées, contenu non fiable17 produce_plan: 'auto',18 apply_plan_in_branch: 'approval', // après approbation du plan19 run_tests: 'auto', // en environnement isolé20 open_merge_request: 'approval', // selon la politique de l'équipe21 merge: 'forbidden', // décision d'une personne habilitée22 deploy_production: 'forbidden',23};24
25export function authorize(action: AgentAction, approved: boolean): boolean {26 const decision = POLICY[action];27 if (decision === 'forbidden') return false;28 if (decision === 'approval') return approved;29 return true;30}Faire évoluer la matrice
L'autonomie se gagne avec des preuves, action par action.
- Partir conservateur, puis assouplir une action quand les evals et l’historique le justifient.
- Documenter chaque changement de politique avec la preuve qui le motive.
- Revenir en arrière immédiatement après un incident attribuable, puis analyser.
- Garder la politique dans le code, relue comme n’importe quel changement sensible.
Evals : transformer les essais en preuves
Une eval vérifie un comportement sur un cas défini. Sans evals, chaque changement de modèle, de prompt ou d’outil est un pari. Avec des evals, c’est une comparaison.
Anthropic recommande de combiner trois types de correcteurs (par le code, par un modèle, par des humains) et de démarrer avec 20 à 50 tâches tirées d’échecs réels, puis de faire vivre la suite comme des tests unitaires (Demystifying evals for AI agents). Le jugement par un modèle est utile mais doit être calibré : il ne suffit pas à établir la correction.
Un protocole de départ
Petit, honnête, rejouable.
- Constituer 20 à 50 cas : simples, complexes, ambigus, impossibles et malveillants.
- Figer pour chaque cas le dépôt, la demande, les comportements attendus et les interdictions.
- Séparer les cas qui servent à améliorer les prompts de ceux qui servent à évaluer.
- Rejouer plusieurs fois les cas sensibles pour observer la variabilité.
- Réévaluer à chaque changement de modèle, prompt, outil ou contexte.
- Transformer chaque échec réel en nouveau cas, après retrait des données non partageables.
1interface EvalCase {2 id: string;3 kind: 'simple' | 'complex' | 'ambiguous' | 'impossible' | 'adversarial';4 repoSnapshot: string; // commit figé5 request: string;6 mustDo: string[]; // comportements attendus7 mustNotDo: string[]; // interdictions (périmètre, permissions)8 checks: Array<'build' | 'tests' | 'scope' | 'policy'>;9}10
11interface EvalResult {12 caseId: string;13 attempts: boolean[]; // une entrée par exécution14}15
16// pass@k : au moins un succès sur k essais. pass^k : succès à chaque essai.17export const passAtK = (r: EvalResult) => r.attempts.some(Boolean);18export const passPowK = (r: EvalResult) => r.attempts.every(Boolean);| Dimension | Exemple de critère |
|---|---|
| Analyse | Incompatibilités connues identifiées et justifiées par des sources |
| Périmètre | Aucun changement sans lien avec la demande |
| Résultat | Objectif atteint, comportement existant préservé |
| Qualité | Tests pertinents conservés, aucun contournement des contrôles |
| Autonomie | Arrêt à la frontière autorisée, escalade quand nécessaire |
| Résilience | Reprise sans duplication après interruption |
| Sécurité | Aucun accès interdit malgré une instruction malveillante dans une source |
Les pièges des evals
Une suite d'evals mal conçue donne une fausse confiance.
- Exiger un diff identique à une solution de référence alors que plusieurs implémentations sont valides : vérifiez les propriétés du résultat.
- Laisser l’agent modifier les tests ou la CI : il peut affaiblir les contrôles pour réussir.
- Conclure qu’un risque est nul parce qu’un échantillon n’a montré aucun incident.
- Définir les seuils de passage après avoir vu les résultats.
Mesurer la valeur réelle
LIVELes gains de productivité de l’IA dépendent fortement du contexte, et les perceptions ne suffisent pas. L’étude METR publiée début 2025 observait un ralentissement chez des développeurs expérimentés travaillant sur des projets qu’ils connaissaient (METR, 2025). En février 2026, METR explique que ses nouveaux résultats souffrent de biais de sélection et ne permettent pas une estimation fiable des gains actuels (METR, 2026).
Le rapport DORA 2025 décrit l’IA comme un amplificateur des forces et des faiblesses d’une organisation (DORA, 2025). Et dans l’enquête Stack Overflow 2025, 84 % des répondants utilisent ou prévoient d’utiliser des outils IA, mais 46 % se méfient de leur exactitude (Stack Overflow, 2025). Conclusion pratique : il faut mesurer localement, sur des tâches comparables, en comptant le temps de revue.
| Indicateur | Définition | Attention |
|---|---|---|
| Éligibilité | Tâches éligibles / tâches reçues | Afficher les exclusions |
| Réussite finale | Tâches acceptées / tâches tentées | Inclure échecs et abandons |
| Réussite au premier essai | Acceptées sans reprise / tentatives | Rend visible la fiabilité immédiate |
| Temps humain total | Cadrage + validation + revue + corrections | Mesurer le travail déplacé par l’agent |
| Coût par tâche acceptée | Coût de toutes les tentatives / tâches acceptées | Inclure les échecs |
| Qualité après livraison | Régressions sur une fenêtre définie | Taille d’échantillon et attribution |
| Adoption | Réutilisation par les personnes éligibles | Une présentation ne prouve pas un usage durable |
Ajustez le temps de génération, de relecture, le taux de reprise et les coûts : le simulateur montre quand un agent de code fait gagner du temps, et quand il en fait perdre.
1Temps humain évité = temps humain de référence − temps humain avec l'agent2
3Valeur nette sur une période =4 valeur du temps humain évité5 − coûts modèles et exécution6 − coût d'exploitation et de maintenance7 − part amortie du coût de constructionComparer honnêtement avant et après
Une comparaison opportuniste embellit toujours le résultat.
- Prendre des tâches comparables par dépôt, difficulté et familiarité du développeur.
- Répartir les tâches entre processus actuel et agent sans choix opportuniste.
- Ne pas faire refaire le même ticket à la même personne : l’apprentissage fausse la mesure.
- Conserver échecs, exclusions, changements de périmètre et coûts de maintenance.
- Publier taille d’échantillon, période, médiane et dispersion, pas seulement une moyenne.
- Le temps dégagé est une capacité disponible, pas automatiquement une économie de trésorerie.
Sécurité et souveraineté
Un agent lit du contenu qu’il ne contrôle pas : tickets, documentation, changelogs, pages web, fichiers du dépôt. Tout ce contenu peut contenir des instructions cachées. C’est l’injection de prompt indirecte, premier risque du classement OWASP LLM01:2025.
On ne corrige pas ce risque avec un meilleur prompt. On le contient par l’architecture : si l’agent est trompé, les dégâts possibles doivent rester petits et visibles.
Limiter les dégâts possibles
Partir du principe que l'agent sera un jour manipulé.
- Identité dédiée : un compte ou token propre à l’agent, jamais celui d’un développeur.
- Moindre privilège : droits limités au périmètre, impossible de fusionner sur une branche protégée.
- Aucun secret de production dans l’environnement d’exécution de l’agent.
- Exécution isolée : les scripts du dépôt et des dépendances sont du code exécutable.
- Réseau restreint aux sources nécessaires.
- Contrôles protégés : la CI, les tests et la politique d’autonomie ne sont pas modifiables par l’agent.
Les erreurs fréquentes
Ce qu'on retrouve dans beaucoup de premiers déploiements.
- Brancher des outils via le token personnel d’un développeur, hors de toute gouvernance d’identité.
- Traiter une instruction trouvée dans un fichier comme une demande de l’utilisateur.
- Journaliser tout le code et toutes les données sensibles « pour le debug ».
- Tester la sécurité uniquement avec des cas nominaux, sans cas malveillant dans les evals.
Souveraineté : où tournent le modèle et les données
Un choix d'architecture à faire au départ, pas une contrainte ajoutée à la fin.
Un agent de développement lit du code source, des tickets et parfois des données métier. Dans le secteur public comme dans beaucoup d’entreprises françaises, ce contenu ne doit pas quitter un environnement maîtrisé. Les missions décrites dans ce guide s’appuient donc sur des modèles et une exécution hébergés sur une infrastructure cloud souveraine, en France.
Ce choix détermine les modèles disponibles, leur fenêtre de contexte, leur latence et leurs coûts : il influence directement la conception du workflow et des evals. L’État a fait le même choix pour ses agents publics : son assistant d’IA générative repose sur un modèle Mistral AI hébergé en SecNumCloud, la qualification cloud de l’ANSSI (DINUM, juin 2026).
- Hébergement du modèle et des traces en France, sur une infrastructure qualifiée quand le contexte l’exige.
- Aucun envoi de code ou de données vers un service hors de l’environnement maîtrisé.
- Evals rejouées à chaque changement de modèle : un modèle souverain se valide comme un autre.
- Architecture indépendante du fournisseur : contrats d’outils, politique d’autonomie et traces ne changent pas.
Le cadre réglementaire européen
Repères de calendrier, pas un avis juridique.
Les pratiques interdites de l’AI Act s’appliquent depuis février 2025 et les obligations des fournisseurs de modèles à usage général depuis août 2025. Les obligations de transparence de l’article 50 s’appliquent depuis août 2026. L’accord Digital Omnibus a repoussé les obligations des systèmes à haut risque de l’annexe III au 2 décembre 2027 (Gibson Dunn, synthèse de l’AI Act). Un agent de développement interne est rarement à haut risque, mais la traçabilité et la validation humaine décrites dans ce guide préparent aussi ces échéances.
Exploitation et adoption
Un agent en production se maintient comme un service : il a des incidents, des dépendances qui changent, des modèles qui évoluent. Et il ne crée de la valeur que si les équipes l’utilisent vraiment.
Des traces exploitables
L'observabilité explique les runs réels ; les evals comparent des variantes. Les deux se complètent.
- Un identifiant commun pour relier appels d’outils, versions, durées, erreurs et décisions humaines.
- Pas de journalisation systématique du code ni des données sensibles.
- Un audit fondé sur les actions et les preuves observables, sans prétendre lire le raisonnement du modèle.
- Des alertes sur les échecs répétés, les budgets dépassés et les tentatives bloquées par la politique.
| Incident | Réponse attendue |
|---|---|
| Job relancé | Aucune action rejouée, aucun doublon (idempotence) |
| État de base modifié pendant l’attente | Invalider le plan et relancer l’analyse |
| Modèle indisponible | Arrêt explicite, reprise contrôlée ou traitement manuel |
| Validation expirée | Arrêt tracé, jamais de poursuite sur silence |
| Test instable préexistant | Distinguer dette existante et régression introduite |
| Plan impossible | Escalade humaine, sans élargir seul le périmètre |
L'adoption se travaille
Sur les missions décrites dans les retours terrain, l'adoption est venue du partage, pas de l'outil.
- Présenter l’approche aux équipes avec des cas réels, échecs compris.
- Transformer chaque workflow en toolkit réutilisable : fichier-pilote, commandes, fiches de patterns.
- Capitaliser les pièges rencontrés pour que l’équipe suivante ne les redécouvre pas.
- Mesurer la réutilisation réelle et les raisons d’abandon, pas le nombre de démos.
- Garder l’agent dans le processus existant (CI, merge request, revue) plutôt qu’à côté.
Checklist de mise en production
Avant de passer un agent en production, chaque ligne doit avoir une réponse. Une ligne sans réponse n’est pas forcément bloquante, mais elle doit être un choix explicite.
Cadrage
Le cas d’usage est fréquent et sa valeur est estimée avant de construire.
Une mesure de référence existe sur des tâches comparables.
La complexité est justifiée : workflow d’abord, agent seulement si nécessaire.
Architecture
Chaque outil a un contrat typé, des effets déclarés et des erreurs exploitables.
Le contexte est versionné (fichier-pilote, guides de patterns).
L’état du run est durable, les effets externes sont idempotents.
Durée, coût et itérations sont bornés, avec escalade au-delà.
Contrôle humain
La validation bloque réellement le processus.
L’accord est lié à une version du plan et à un état du système, et il expire.
La matrice d’autonomie est du code relu, adaptée au risque de chaque action.
Mesure
Une suite d’evals rejoue des cas réels à chaque changement de modèle, prompt ou outil.
Les métriques incluent échecs, exclusions, temps de revue et coûts.
Les seuils de passage sont fixés avant de comparer.
Production
L’agent a une identité dédiée et le moindre privilège.
Le modèle et l’exécution restent sur une infrastructure souveraine adaptée au contexte.
Le contenu externe est traité comme non fiable, des cas malveillants sont dans les evals.
Chaque run est traçable par quelqu’un d’autre que son auteur.
Un runbook couvre les incidents connus.
L’adoption est mesurée par l’usage réel.
Vous voulez appliquer cette checklist à un cas réel dans votre équipe ? L’approche Diagnostic → Pilote → Industrialisation est décrite sur la page Travailler ensemble.
Felicitations !
Vous avez termine ce guide.