Un cycle opérationnel de l’agent est un parcours contrôlé qui conduit une demande délimitée à un artefact révisé. Ce cycle attribue les responsabilités, enregistre les entrées, limite les outils et les données, consigne les actions et les preuves, vérifie le résultat, traite les défaillances et se termine par un état explicite d’acceptation, de révision ou d’arrêt.
Cette définition constitue le modèle de travail employé dans ce guide. Elle combine les recommandations actuelles de fournisseurs et de gestion des risques avec un contrat opérationnel pratique. Il ne s’agit ni d’une norme universelle ni de la description d’un produit particulier.
Ce cycle compte, car la déclaration d’un agent selon laquelle il a terminé ne représente qu’une catégorie de preuve. Un dossier opérationnel utile distingue ce qu’une source ou un système a observé, ce qu’une conception exige, ce que l’agent affirme, ce qu’un opérateur responsable a décidé et ce qui reste inconnu.
Commencez par déterminer si le travail nécessite un agent
Ne commencez pas par un outil. Commencez par la tâche, la personne responsable de la décision et les preuves requises à la fin.
Les recommandations de Microsoft sur la planification métier des agents d’IA distinguent le travail prévisible qui peut être traité par du code classique, les tâches de recherche statique et le travail qui nécessite un raisonnement dynamique ou l’emploi d’outils. Le guide d’Anthropic sur la création d’agents efficaces distingue également les workflows prédéfinis des agents qui dirigent eux-mêmes leur processus et leur emploi des outils, et recommande la conception la moins complexe adaptée à la tâche. Il s’agit d’aides à la décision, pas de lois techniques absolues.
Utilisez un programme déterministe ou un workflow prédéfini lorsque les règles, l’ordre des étapes, les entrées et le résultat attendu sont stables et vérifiables. Utilisez la recherche documentaire lorsque la tâche consiste à trouver des informations étayées dans un corpus connu, sans enchaînement dynamique d’outils. Maintenez le workflow sous responsabilité humaine lorsque l’acte central relève de la politique, de la responsabilité, du jugement ou de l’acceptation et que l’exécution dynamique apporte peu.
Un agent devient un choix raisonnable lorsque le travail exige des décisions contextuelles à partir d’entrées non structurées, des séquences d’outils variables ou la gestion d’exceptions, à condition que l’organisation puisse toujours définir :
- le résultat et la personne qui en répond ;
- les entrées, outils, données et cibles autorisés ;
- les actions interdites et les points d’approbation ;
- les preuves qu’une autre personne chargée de la révision peut examiner ;
- un responsable de la récupération et un état d’arrêt sûr ;
- un test d’acceptation pour l’artefact final.
Si ces champs ne peuvent pas être renseignés, l’ajout d’un agent rend l’incertitude plus difficile à discerner.
Utilisez cinq catégories de preuve
Ces libellés empêchent que le récit d’un agent soit traité comme une preuve. Ils constituent le modèle éditorial de ce guide.
| Catégorie de preuve | Signification | Ce qu’elle peut étayer | Ce qu’elle ne peut pas étayer |
|---|---|---|---|
| Fait de source | Un document primaire horodaté, une réponse du système responsable ou un effet observé indépendamment. | Le fait indiqué a été observé dans le périmètre consigné de la source. | L’exhaustivité au-delà de ce périmètre ou un effet non observé. |
| Règle de conception documentée | Un contrat opérationnel versionné indique qu’un rôle, une étape, une approbation, une preuve enregistrée ou une règle de récupération doit exister. | L’organisation a conçu et consigné la règle. | Le logiciel a appliqué cette règle ou chaque exécution l’a suivie. |
| Assertion de l’agent | Un agent énonce une intention, une interprétation, un résultat ou une cause. | Une hypothèse ou un résultat proposé à la révision. | L’exécution, l’exactitude, l’approbation ou l’achèvement du travail métier. |
| Décision de l’opérateur | Une personne responsable ou un système autorisé approuve, rejette, accepte, arrête ou choisit une voie de récupération. | La décision est connue lorsque son responsable, son périmètre, ses preuves, sa cible et son heure sont liés. | L’action approuvée a eu lieu ou a réussi. |
| Inconnue non résolue | Les preuves disponibles ne permettent pas d’établir ce qui s’est passé ou si le résultat est valide. | Une raison de s’arrêter, de rapprocher les éléments ou de recueillir des preuves plus solides. | L’autorisation de supposer, de réessayer ou de déclarer un succès. |
Un même événement peut relever de plusieurs catégories. Un agent peut proposer d’écrire un fichier, un opérateur peut approuver une cible et une somme de contrôle, puis le système cible peut confirmer l’écriture. Il s’agit respectivement d’une assertion de l’agent, d’une décision de l’opérateur et d’un fait de source. Les résumer par « l’agent a terminé le travail » masque les distinctions nécessaires à la personne qui révise.
Le cycle opérationnel en huit étapes
Chaque étape doit indiquer la personne responsable, l’entrée, le périmètre autorisé, l’action, la décision, la sortie, la preuve enregistrée, l’état de défaillance, le responsable de la récupération et la condition de sortie propres à cette étape. Les champs ci-dessous forment un seul contrat opérationnel, sans prétendre que toutes les mises en œuvre emploient les mêmes noms.
| Étape | Responsabilité et décision | Entrée, outils, action et transmission | Sortie, preuve, défaillance, récupération et clôture |
|---|---|---|---|
| 1. Délimiter la demande | Le responsable du résultat définit le résultat métier et décide si la demande est acceptée. | Consignez l’ID du travail, la tâche, le public, les objectifs exclus, la limite de risque et les critères d’acceptation. Aucun outil d’exécution n’est encore nécessaire. | La sortie exige un périmètre accepté. Une responsabilité ambiguë ou des objectifs contradictoires renvoient la demande à son responsable. |
| 2. Enregistrer les entrées | Un responsable des sources ou un opérateur confirme quelles preuves peuvent entrer dans le travail. | Consignez l’identité des sources, les dates ou versions, les sommes de contrôle lorsqu’elles sont utiles, les limites de fraîcheur et les règles applicables aux données manquantes. Transmettez un manifeste immuable des entrées. | La sortie exige une preuve enregistrée des entrées et des inconnues explicites. L’absence de preuves déterminantes arrête ou restreint le travail. |
| 3. Attribuer les responsabilités | Le responsable du résultat désigne l’agent ou le rôle du workflow, l’opérateur, la personne chargée de la révision, le responsable de l’approbation et le responsable de la récupération. | Définissez qui peut proposer, exécuter, approuver, réviser, réessayer et arrêter. Consignez les conflits et les rôles indisponibles. | La sortie exige une cartographie des responsabilités. Une décision sans responsable reste un blocage. |
| 4. Planifier dans les limites du périmètre | L’opérateur ou le responsable de la politique décide si le parcours proposé respecte le contrat. | Consignez les étapes, les outils et données autorisés, le périmètre cible, les actions interdites, les déclencheurs d’approbation, le budget et les limites de nouvelle tentative. Transmettez un plan révisable ou une instruction déterministe. | La sortie exige un plan accepté. Toute extension du périmètre est renvoyée au responsable de la décision au lieu d’être déduite. |
| 5. Exécuter et consigner | Le rôle d’exécution n’effectue que les actions autorisées ; le responsable de l’approbation décide des actions à conséquences lorsque cela est requis. | Liez l’action à une cible et à l’identité immuable de la charge utile. Consignez les horodatages, les entrées et sorties des outils, les changements d’état, les erreurs et les preuves des effets produits. | La sortie exige un résultat observable ou une incertitude préservée. Un délai dépassé après une écriture possible déclenche un rapprochement, jamais une nouvelle tentative aveugle. |
| 6. Réviser l’artefact | Une personne nommément chargée de la révision applique des critères d’acceptation écrits. | Comparez la sortie à la demande, aux sources, à la politique, aux preuves et aux résultats interdits. Consignez l’identité et le type de la personne chargée de la révision, l’incertitude et les limites. | La sortie est ACCEPT, REVISE ou HOLD. L’achèvement technique ne suffit pas à établir l’utilité ou l’exactitude. |
| 7. Récupérer ou arrêter | Le responsable de la récupération classe la défaillance et choisit entre nouvelle tentative, réparation, compensation, transfert ou arrêt. | Rapprochez les effets possibles, inspectez la cible exacte, conservez la tentative échouée et associez tout successeur à une nouvelle identité de tentative. | La sortie est RECOVERED, une nouvelle tentative autorisée ou une inconnue terminale ou un arrêt. N’effacez jamais le dossier de l’échec. |
| 8. Clore et transmettre | Le responsable du résultat accepte l’état final et attribue la décision suivante. | Regroupez l’artefact accepté, les preuves, le verdict de révision, les inconnues restantes et le prochain responsable. Ne conservez que les preuves soumises à gouvernance. | La sortie exige un artefact lié à une preuve enregistrée et un état suivant explicite. Un travail « terminé » sans dossier d’acceptation ne clôt pas la tâche métier. |
Le cycle est séquentiel comme modèle de responsabilité, mais sa mise en œuvre peut revenir sur certaines étapes. De nouvelles preuves peuvent renvoyer un brouillon à l’enregistrement des entrées. Une révision négative peut le renvoyer à la planification. Une récupération peut créer une tentative suivante. Le dossier doit montrer ces mouvements au lieu de réécrire l’état précédent.
Exemple pratique : un dossier de recherche sur des fournisseurs
Cet exemple est hypothétique. Il ne décrit ni Toone, ni un déploiement client, ni une exécution de produit testée.
Une équipe achats a besoin d’un dossier de révision couvrant trois fournisseurs de logiciels potentiels. La demande se limite aux sources primaires publiques. L’agent peut rédiger un dossier interne. Il ne peut pas contacter les fournisseurs, créer des comptes, accepter des conditions, modifier les registres d’achats ou publier le dossier.
1. Demande délimitée
Le responsable des opérations d’achats répond du résultat. Le résultat accepté est un dossier unique qui contient, pour chaque fournisseur, la description publique actuelle du produit, la source tarifaire lorsqu’elle est publiée, la documentation sur le traitement des données, les questions non résolues et les citations. Une recommandation d’achat est hors périmètre.
Les critères d’acceptation exigent des liens directs vers les sources, les dates d’observation, la distinction entre les faits de source et l’analyse, ainsi qu’un état d’inconnue visible lorsque des preuves manquent.
2. Entrées enregistrées
L’opérateur consigne les domaines des trois fournisseurs, les espaces de leur documentation publique, la date de révision et les types de sources approuvés. Le manifeste des entrées exclut les avis d’utilisateurs, les synthèses générées dépourvues de liens primaires, les documents privés et les données personnelles.
Chaque instantané de source reçoit une date et une référence stable. Une source inaccessible reste une inconnue non résolue. L’agent n’est pas autorisé à inventer ou à déduire son contenu.
3. Cartographie des responsabilités
| Responsabilité | Responsable hypothétique |
|---|---|
| Résultat métier | Responsable des opérations d’achats |
| Limite des sources | Analyste achats |
| Recherche et rédaction | Agent de recherche fournisseurs, version example-v1 |
| Révision de l’artefact | Analyste achats |
| Approbation des communications externes | Responsable des opérations d’achats |
| Défaillance et récupération | Responsable des systèmes d’achats |
Les intitulés désignent des rôles dans cet exemple fictif. Ce ne sont ni des rôles de Toone ni la preuve d’une révision humaine de ce guide.
4. Plan délimité
L’agent propose quatre étapes : recueillir les sources approuvées, extraire les faits datés, rédiger des sections neutres de comparaison consacrées à chaque fournisseur et assembler le dossier interne. Il peut effectuer des lectures sur le Web public et utiliser une cible de brouillon interne. Toute écriture externe, tout message, envoi de formulaire, création de compte ou changement de registre est interdit.
L’opérateur accepte le plan et lui associe une cible de sortie ainsi que l’identité prévue de la charge utile. L’approbation est une décision de l’opérateur. Elle ne prouve pas que le brouillon a été écrit.
5. Exécution et effet incertain
La collecte des sources s’achève et produit un manifeste des sources. L’agent propose le dossier et déclare avoir écrit le brouillon. Cette déclaration est une assertion de l’agent.
L’outil de rédaction signale un dépassement de délai après que le service distant a peut-être accepté la demande. La réponse d’erreur est un fait de source. L’existence du brouillon est une inconnue non résolue. Une nouvelle tentative immédiate pourrait créer un doublon ou écraser un fichier déjà présent.
6. La révision ne peut pas encore commencer
La personne chargée de la révision ne dispose d’aucun artefact stable à examiner. La révision reste donc bloquée. Une assertion de l’agent et un dépassement de délai ne satisfont pas l’exigence de preuve enregistrée de l’artefact.
7. Branche de récupération
Le responsable des systèmes d’achats vérifie la cible exacte et le hachage attendu de la charge utile avant d’autoriser toute nouvelle tentative.
- Si le brouillon attendu existe avec le hachage approuvé, consignez
RECOVEREDet ne répétez pas l’écriture. - Si la cible peut être inspectée et que le brouillon est absent, autorisez une nouvelle tentative avec un nouvel ID de tentative.
- Si la cible ne peut pas être inspectée, consignez
WRITE_UNCERTAINet arrêtez. L’absence de preuve n’autorise pas une nouvelle tentative.
Le choix de récupération est une décision de l’opérateur. L’observation de la cible qui l’étaye est un fait de source. La règle qui impose un rapprochement avant toute nouvelle tentative est une règle de conception documentée dans le contrat opérationnel de cet exemple.
8. Révision et clôture
Supposons que le brouillon correspondant existe et soit récupéré. La personne chargée de la révision vérifie chaque affirmation importante par rapport au manifeste des sources, signale une comparaison non étayée à supprimer et renvoie REVISE. L’agent produit un brouillon successeur avec une nouvelle somme de contrôle de l’artefact. La personne chargée de la révision accepte cette version.
La preuve de clôture enregistre la somme de contrôle acceptée, le manifeste des sources, l’affirmation supprimée, la décision de révision, les inconnues restantes et le responsable des opérations d’achats comme prochain responsable. Elle n’indique pas que les fournisseurs ont été approuvés ou contactés.
Pourquoi les écritures incertaines nécessitent une voie de récupération distincte
Une nouvelle tentative ne convient que lorsque la défaillance et ses effets rendent la répétition sûre. Le guide pratique d’OpenAI sur la création d’agents recommande d’évaluer le risque d’un outil à partir de facteurs comme l’accès en lecture ou en écriture, la réversibilité, les autorisations et l’impact financier. Il décrit également l’intervention humaine lorsque les seuils d’échec sont atteints et pour les actions à haut risque ou irréversibles.
NIST AI 600-1 comprend des mesures de gouvernance portant sur la définition des rôles, la supervision humaine, la conservation de l’historique des évaluations, la désactivation, la réponse aux incidents et les solutions de repli pour les dépendances. NIST présente le profil d’IA générative comme un guide volontaire et intersectoriel : ces mesures sont donc des recommandations, et non une certification, une obligation juridique ou une preuve relative à un produit.
Dans le cas d’une écriture incertaine, la question opérationnelle n’est pas « L’agent peut-il réessayer ? », mais « Le responsable peut-il établir si le premier effet s’est produit ? ». La réponse détermine la branche :
| État observé | État sûr à consigner | Action suivante |
|---|---|---|
| L’effet attendu existe et correspond à la cible et à la charge utile approuvées | RECOVERED | Conservez l’effet et poursuivez la révision sans le répéter. |
| La cible peut être inspectée et l’effet attendu est absent | RETRY_ELIGIBLE | Autorisez une nouvelle tentative avec une nouvelle identité et un périmètre identique ou révisé. |
| L’effet a eu lieu, mais diffère de ce qui a été approuvé | REMEDIATION_REQUIRED | Arrêtez le travail normal, conservez les preuves et attribuez la réparation ou la compensation. |
| La cible ne peut pas être inspectée ou les preuves se contredisent | WRITE_UNCERTAIN | Arrêtez. Ne réessayez pas tant que des preuves plus solides n’ont pas levé l’incertitude sur l’effet. |
Cette distinction reste nécessaire même si un système d’exécution signale un échec. Une réponse d’échec peut coexister avec un effet externe achevé.
Fiche du contrat opérationnel
Utilisez cette fiche avant d’attribuer à un agent un travail récurrent ou susceptible d’avoir des conséquences. Laissez les champs vides visibles comme travail non résolu.
| Champ | Élément à consigner |
|---|---|
| 1. ID de demande ou de travail | Identité stable commune à la demande, aux tentatives, aux artefacts et aux preuves enregistrées. |
| 2. Résultat visé et responsable | Le résultat métier, la personne qui l’accepte et ce que cette acceptation n’autorise pas. |
| 3. Tâche et objectifs exclus | Le travail inclus, le travail exclu, les résultats interdits et les usages abusifs prévisibles. |
| 4. Entrées et identité des sources | Responsables des sources, versions ou dates, limites de fraîcheur, sommes de contrôle lorsqu’elles sont utiles et règle applicable aux données manquantes. |
| 5. Cartographie des responsabilités | Agent ou rôle du workflow, opérateur, responsable de l’approbation, personne chargée de la révision, responsable de la récupération et prochain responsable. |
| 6. Outils et données autorisés | Périmètre de lecture et d’écriture, cibles autorisées, catégories de données, limite des identifiants d’accès et règle de conservation. |
| 7. Actions interdites | Écritures externes, messages, achats, envois, modifications d’autorisations, publication ou autres effets exclus. |
| 8. Critères d’entrée et preuves de sortie | Ce qui doit être vrai avant le début du travail et la preuve enregistrée qui établit que l’étape peut être close. |
| 9. Identité de l’action à conséquences | Cible exacte, hachage immuable de la charge utile, catégorie d’action, périmètre de l’approbation et expiration de l’approbation. |
| 10. Déclencheur et responsable de l’approbation | L’action qui nécessite une décision, la personne qui décide, les preuves qu’elle examine et la manière dont la décision est consignée. |
| 11. Preuve de l’exécution et de l’effet | ID de tentative, horodatages, résultat de l’outil, observation de la cible, somme de contrôle de l’artefact et toute preuve contradictoire. |
| 12. Dossier de révision | Critères d’acceptation, identité et type de la personne chargée de la révision, preuves vérifiées, verdict, incertitude et limites. |
| 13. Défaillance et récupération | Catégories de défaillance, admissibilité à une nouvelle tentative, limite de tentatives, méthode de rapprochement, responsable de la récupération et voie de compensation. |
| 14. Inconnues et retrait | Faits non résolus, preuves conservées, condition d’arrêt, règle de désactivation et date de révision. |
| 15. Action suivante et état terminal | Artefact accepté, prochain responsable, décision suivante et état du travail : accepté, à réviser, suspendu, arrêté ou retiré. |
Version compacte à copier
ID du travail :
Responsable du résultat :
Résultat :
Limites de la tâche :
Objectifs exclus :
Entrées et versions des sources :
Agent ou rôle du workflow :
Opérateur :
Personne chargée de la révision et type :
Responsable de la récupération :
Outils et données autorisés :
Actions interdites :
Critères d’entrée :
Preuves de sortie :
Identité de la cible et de la charge utile :
Déclencheur et responsable de l’approbation :
Preuve d’exécution :
Critères et verdict de révision :
Catégories de défaillance :
Méthode de rapprochement :
Limite de nouvelles tentatives :
Inconnues :
Condition d’arrêt ou de retrait :
Action suivante et responsable :
Conditions d’arrêt
Arrêtez ou transférez le contrôle si l’une des conditions suivantes s’applique :
- une action à haut risque, sensible ou irréversible nécessite l’approbation d’une personne responsable ;
- la tâche sort de son périmètre accepté ou nécessite un outil, une source, une cible ou une autorisation non approuvés ;
- le seuil d’échec ou la limite de nouvelles tentatives est atteint ;
- un effet externe possible ne peut pas être rapproché ;
- une preuve déterminante manque, est obsolète ou contradictoire, ou ne peut pas être liée à l’artefact ;
- la personne chargée de la révision ou le responsable de la récupération n’est pas disponible ;
- la sortie ne satisfait pas une condition d’acceptation stricte ;
- un workflow déterministe peut effectuer le travail de façon plus prévisible avec moins de jugement ;
- la valeur attendue ne justifie plus le coût, le délai ou le risque ;
- des questions de politique, de droit, de confidentialité, de sécurité ou de domaine nécessitent un responsable qualifié qui dépasse l’autorité de l’agent.
Un arrêt est un résultat valide lorsqu’il préserve les preuves et désigne le prochain responsable. Continuer sans autorisation ne constitue pas un progrès.
Un contrat d’organisation documenté constitue une preuve de conception
L’organisation SEO Growth examinée fournit un exemple de conception opérationnelle documentée. Son manuel et ses dossiers de routines attribuent des responsables d’étape, des entrées, des décisions, des sorties, des verrous, des états de rappel, des sommes de contrôle et des preuves enregistrées. Le contrat documenté réserve également les actions externes à conséquences à une étape d’approbation en direct.
Ces dossiers montrent ce que l’organisation a conçu et consigné. Ils n’établissent pas que Toone Desktop a appliqué le contrat, exécuté chaque étape, conservé un historique complet, assuré automatiquement la récupération ou produit un résultat métier. Cet article les utilise uniquement pour illustrer la différence entre une règle de conception documentée et un fait de source.
Choisissez le prochain responsable en fonction de la question en suspens
Si la question non résolue porte sur la personne autorisée à approuver une action ou à accepter un risque résiduel, consultez la page Gouvernance des agents d’IA (en anglais). Si l’équipe a d’abord besoin de comprendre la catégorie, lisez le Guide de l’entreprise AI-native (en anglais). N’utilisez les cas documentés (en anglais) que comme preuves de ce qui est documenté sur ces pages.
Les pages de référence associées à la connaissance organisationnelle, aux organisations d’agents, aux routines, à l’évaluation et à l’observabilité devront être liées ici lorsque leurs routes canoniques seront publiées. Ce brouillon ne traite pas les routes prévues comme des preuves actuelles.
À propos de ce guide
Qui : Toone Content est l’auteur organisationnel et Hexagonal.io est l’éditeur. L’agent Content Editor est le rôle responsable de la révision éditoriale de ce brouillon. Aucune révision par un être humain, un responsable du domaine, ni par les équipes produit, ingénierie, sécurité, confidentialité ou juridique, ou encore par un spécialiste du sujet, n’est revendiquée.
Comment : Le guide a été préparé à partir d’un brief approuvé en G1 et d’un dossier de revendications et de sources figé par somme de contrôle. Une assistance automatisée a contribué à recueillir, organiser et synthétiser les recommandations primaires actuelles de Microsoft, OpenAI, Anthropic et NIST. Les cinq catégories de preuve, le cycle en huit étapes, l’exemple de défaillance et la fiche de travail sont une synthèse éditoriale. L’exemple de recherche sur les fournisseurs est fictif. Aucun test du produit Toone, déploiement client, étude de performance ou benchmark n’a servi à rédiger l’article.
Pourquoi : Ce guide vise à aider les opérateurs et responsables d’équipe à rendre le travail des agents vérifiable de la demande à la révision, avec une autorité, des preuves, des défaillances, une récupération et des états de sortie clairs.
Limites et corrections : Les besoins opérationnels varient selon la tâche, le risque, la juridiction et le système. Les travaux juridiques, réglementés, sensibles à la sûreté, liés à la confidentialité, à la sécurité ou à fort impact nécessitent une révision qualifiée qui dépasse ce modèle éditorial. Consultez la politique éditoriale, relative aux sources et aux corrections (en anglais). Utilisez la page de contact de Toone (en anglais) pour les questions générales. Envoyez les corrections en indiquant l’URL concernée et les preuves à l’appui à hello@trytoone.com. Toute correction importante doit mettre à jour la date de la source et invalider les versions linguistiques qui en dépendent jusqu’à leur révision.
Sources primaires
- Microsoft Learn : Plan métier pour les agents d’IA, mis à jour le 2026-04-10.
- OpenAI : Guide pratique de création d’agents, consulté le 2026-08-13.
- Anthropic : Créer des agents efficaces, publié le 2024-12-19.
- NIST AI 600-1 : Cadre de gestion des risques liés à l’intelligence artificielle, profil de l’intelligence artificielle générative, publié le 2024-07-26.