Standards d'exécution IA

Les règles et attentes pour déléguer le travail à l'IA dans l'ensemble de l'organisation.

Politique des attentes organisationnelles

Le principe opératoire derrière ces standards est la règle de traduction universelle : remplacer « l'humain produit l'artefact » par « l'humain définit la spécification → le système produit l'artefact. »

Principe fondamental

L'IA est traitée comme un travailleur autonome, pas comme un agent conversationnel.

Tout travail assigné à l'IA doit être exécutable sans supervision humaine en temps réel pendant l'exécution. La clarification pré-exécution (l'agent fait remonter ses hypothèses et pose des questions calibrées avant de produire la sortie) est permise et, à plus haute maturité, attendue. Voir Lab IA § Les cinq étapes pour le patron opérationnel.

Couches de travail obligatoires

Chaque flux de travail IA doit définir les quatre couches d'entrée (1 à 4). La Couche 5 (Conception de processus) les prolonge avec le pipeline opérationnel qui consomme les entrées ; elle est obligatoire pour le travail Tier 3 / Échelon 5 et optionnelle en deçà.

Couche 1 : rédaction de prompts (compétence de base)

Les employés doivent :

écrire des instructions claires ;
spécifier le format ;
inclure des exemples quand c'est utile ;
résoudre l'ambiguïté en amont.

Requis minimum : le résultat IA ne devrait nécessiter ≤20% de correction.

Couche 2 : ingénierie de contexte

Chaque équipe doit maintenir un fichier de contexte structuré contenant :

les objectifs ;
les contraintes ;
la terminologie ;
les standards de qualité ;
les documents pertinents ;
les règles d'accès aux outils.

Exigence : les tâches IA doivent charger ce contexte avant l'exécution.

Couche 3 : ingénierie d'intention

Chaque flux de travail doit définir :

la hiérarchie des objectifs ;
les règles d'arbitrage ;
les conditions d'escalade ;
ce que l'IA peut décider vs ce qu'elle doit escalader.

Aucun agent ne peut s'exécuter sans intention définie.

Couche 4 : ingénierie de spécification (standard le plus élevé)

Toutes les tâches non triviales doivent avoir une spécification écrite.

Composantes requises de la spécification :

énoncé du problème ;
portée ;
entrées ;
contraintes ;
critères d'acceptation ;
conditions d'échec ;
tests de réussite ;
définition de complétion.

Règle : si le succès ne peut pas être vérifié objectivement, la tâche n'est pas prête pour la spécification.

Pour les bases de code brownfield, l'inversion compte : le code existe déjà, et les spécifications doivent être rétro-ingéniées à partir de lui avant que le nouveau travail spécification-d'abord puisse reprendre. Voir la stratégie brownfield pour le flux de travail spec-depuis-le-code.

Couche 5 : conception de processus

La couche opérationnelle. Une fois qu'une spécification fonctionne, la question suivante est le pipeline qui l'exécute. La conception de processus est la discipline de concevoir des flux de travail contraints et par étapes dans lesquels l'IA opère de façon cohérente : distincte de l'ingénierie de prompts et de la rédaction de spécifications en tant que telle. C'est la couche qui distingue le travail Tier 3 / Échelon 5 du travail Tier 2 / Échelon 4.

Le vocabulaire, tiré de Building Effective Agents d'Anthropic :

Prompt chaining : étapes séquentielles à prompt unique avec validation intermédiaire ;
Routing : classer la tâche, dispatcher vers le prompt ou flux de travail spécialisé approprié ;
Parallélisation : exécuter des sous-tâches indépendantes en concurrence, agréger les résultats ;
Orchestrateur-travailleurs : un agent maître décompose la tâche et dispatche les travailleurs ;
Évaluateur-optimiseur : un générateur associé à un évaluateur séparé qui note et itère ;
Agents autonomes : exploration ouverte avec usage d'outils et boucles de rétroaction.

Règle de décision : commencer à prompt unique ; ajouter du flux de travail quand nécessaire ; ajouter du multi-agent seulement quand la valeur par tâche justifie le surcoût en tokens (les agents typiques utilisent environ 4× les tokens d'une conversation ; multi-agent environ 15×, selon Anthropic, 2025). Ne pas tendre vers le multi-agent parce que ça paraît sophistiqué.

Anti-patrons :

Pitfall: Méga-prompt unique
Combine les modes de défaillance ; impossible à déboguer.
Pitfall: Multi-agent pour lui-même
Coûteux, fragile, souvent un agent unique fait aussi bien.
Pitfall: Déversement de contexte
Plus de contexte est souvent un pire contexte.
Pitfall: Sauter les évaluations
Sans évaluations, les systèmes IA se dégradent silencieusement.
Pitfall: Optimiser les prompts quand le problème est le contexte
Mauvaise attribution du mode de défaillance.

Les quatre couches d'entrée (Prompt → Contexte → Intention → Spécification) décrivent ce que l'humain prépare avant la délégation. La Couche 5 décrit le pipeline qui consomme ces entrées. Au T3 / É5, le pipeline est aussi un artefact conçu, et les portes de validation à l'intérieur sont graduées par le risque (HITL / HOTL / HOOTL).

Composantes de compétence (compétences à développer)

L'ingénierie de spécification repose sur cinq composantes. Chacune est une compétence distincte à pratiquer. Pour des exemples, gabarits et spécifications complètes par rôle, consultez le guide d'ingénierie de spécification.

Composante 1 : énoncés de problème autonomes

Formulez le problème avec suffisamment de contexte pour que la tâche soit résoluble sans que l'agent ait besoin de chercher plus d'information. Exposez les hypothèses cachées. Articulez les contraintes que vous laissez normalement implicites.

Exercice d'entraînement : prenez une demande que vous feriez normalement de manière conversationnelle et réécrivez-la comme si le destinataire n'avait jamais vu votre projet, ne connaissait pas votre terminologie, et n'avait accès à rien au-delà de ce que vous incluez.

Composante 2 : critères d'acceptation

Définissez à quoi ressemble « terminé » de sorte qu'un observateur indépendant puisse vérifier le résultat sans poser de questions. Si vous ne pouvez pas écrire trois phrases qui vérifient la complétion, vous ne comprenez pas la tâche assez bien pour la déléguer.

Composante 3 : architecture des contraintes

Définissez quatre catégories pour chaque tâche :

Doit – exigences non négociables ;
Ne doit pas – actions ou résultats interdits ;
Préfère – orientation quand plusieurs approches valides existent ;
Escalade – conditions où l'agent doit s'arrêter et demander.

Composante 4 : décomposition

Découpez les tâches en composantes qui peuvent être exécutées indépendamment, testées indépendamment, et intégrées de manière prévisible. Granularité cible : sous-tâches de ≤2 heures avec des frontières entrée/sortie claires, chacune vérifiable de manière autonome.

Composante 5 : conception d'évaluation

Pour chaque tâche IA récurrente, construisez 3 à 5 cas de test avec des résultats connus et validés. Exécutez-les après les mises à jour de modèles pour détecter les régressions. Les résultats sont jugés par les métriques, pas par l'apparence.

Une spécification valide doit passer les cinq critères : autonome, testable, contrainte, décomposable, évaluable.

Liste de vérification de préparation à la délégation

Avant d'assigner du travail à l'IA, les employés doivent confirmer :

Je comprends la tâche complètement ;
Je peux définir le succès objectivement ;
Je peux lister les cas d'échec ;
Je peux décrire les contraintes ;
Je peux vérifier les résultats sans interprétation.

Si une réponse = non → ne pas déléguer encore.

Modèle de responsabilité en cas d'échec

L'échec est attribué par couche :

Type d'échec	Cause racine
Mauvais résultat	Problème de prompt
Résultat non pertinent	Problème de contexte
Mauvaise direction	Problème d'intention
Résultat incomplet	Problème de spécification
Résultat dommageable	Problème de permission / rayon d'impact : l'agent n'aurait pas dû pouvoir prendre cette action
Résultat passé inaperçu	Problème de porte de validation : la mauvaise posture de supervision pour le rayon d'impact de cette action (voir portes graduées par le risque)
Mauvaise direction défendue avec confiance	Clarification sautée : l'agent s'est engagé avant que les hypothèses soient remontées

Les équipes doivent corriger la couche responsable, pas relancer les prompts.

Rôles organisationnels

Chaque système IA en production doit avoir :

Propriétaire de la spécification : responsable de la qualité de la spécification, des critères d'acceptation, et de ce que « terminé » signifie ;
Propriétaire du contexte : responsable des fichiers de contexte (CLAUDE.md / AGENTS.md), de la fraîcheur du contexte et du périmètre des outils/compétences ;
Propriétaire de l'évaluation : responsable de la suite d'évaluation, de la détection des régressions, et des métriques de qualité ;
Responsable des permissions : responsable de ce que chaque agent peut et ne peut pas faire, et du niveau de la porte de validation (HITL / HOTL / HOOTL) par classe d'action.

Une même personne peut occuper plusieurs rôles au départ. Le rôle de Responsable des permissions devient porteur de charge dès que les agents touchent à des systèmes de production avec effets secondaires irréversibles.

Ces quatre rôles gouvernent un système IA en production. Ils sont distincts des trois rôles requis pour gouverner la transformation IA d'une équipe. Voir Piloter la transformation § Rôles organisationnels.

Standard de documentation

Tous les documents internes doivent être rédigés comme si un agent allait les exécuter.

Les documents doivent :

énoncer les hypothèses ;
définir les termes ;
spécifier les résultats attendus ;
inclure les contraintes ;
éviter le savoir implicite.

Règle de synthèse

La pensée claire précède l'exécution IA.

Si vous ne pouvez pas le spécifier, vous ne pouvez pas l'automatiser.

← Retour à l'accueil · Le cadre de référence · Le Lab IA · Glossaire