Note de l’auteur : à partir du principe « ne solliciter une personne que pour supprimer des données, dépenser de l’argent ou changer de direction », nous examinons trois critères pour définir les limites de décision humaine dans un système automatisé par des agents, ainsi que la conception du circuit d’approbation et le partage des vérifications avec la CI.
Quand un agent passe de « discuter avec vous » à « travailler pour vous », le plus difficile n’est souvent pas de le faire fonctionner, mais de déterminer quand il doit s’arrêter. Trop de points d’approbation, et l’automatisation se réduit à une succession de confirmations manuelles ; trop peu, et une suppression accidentelle ou une dépense incontrôlée peut effacer des mois de gains d’efficacité. Cet article propose une méthode réutilisable pour définir les limites de décision humaine autour d’une question : quand un agent doit-il s’arrêter pour demander l’avis d’une personne ?
Ce n’est pas une discussion vague sur les dangers de l’IA et la nécessité d’être prudent. Nous partons d’un système réel présenté publiquement : le créateur de contenu Kazike développe depuis près d’un an un système automatisé par des agents. Il ne reçoit des cartes Feishu pour trancher que trois types de décisions clés : supprimer des données, dépenser de l’argent et changer de direction. Nous déclinons ce principe en critères de décision et y ajoutons une méthode pour concevoir le circuit d’approbation.
Ce que vous allez en tirer : à la fin de cet article, vous saurez quelles opérations confier à un agent en autonomie, lesquelles nécessitent une confirmation humaine et comment concevoir un circuit d’approbation qui maîtrise les risques sans interrompre inutilement l’automatisation.
Quand un Agent doit-il s’arrêter pour demander l’avis d’un humain ? Les 3 décisions clés
Le système de Kazik apporte une réponse mesurée : l’humain n’intervient que dans trois situations. Le tableau ci-dessous relie chacune de ces décisions à la nature du risque associé.
| Décision | Opérations typiques | Nature du risque | Pourquoi un humain est nécessaire |
|---|---|---|---|
| Supprimer des données | Nettoyer des enregistrements en base de données, supprimer des fichiers, écraser des versions antérieures | Irréversibilité | Une fois l’opération exécutée, le retour en arrière peut être très coûteux, voire impossible |
| Dépenser de l’argent | Appeler des services payants, acheter des ressources, consommer des quotas de modèles en masse | Sortie de fonds | Des coûts réels sont en jeu, et une boucle peut les amplifier |
| Changer de direction | Modifier les sujets traités, changer la stratégie produit, réécrire les règles établies | Impact sur les objectifs | L’Agent ne dispose pas de tout le contexte métier ni des éléments nécessaires pour porter un jugement de valeur |
Où se situe la limite de décision humaine dans l’architecture à quatre couches ?
D’après le résumé public, l’idée centrale du système de Kazik est de « ne plus faire de l’humain le point de départ des tâches » : ce sont des événements qui déclenchent le travail des Agents, plutôt qu’une personne qui lance chaque tâche. Le système comporte quatre couches. La décision humaine intervient dans la dernière, comme un « frein » plutôt qu’un « accélérateur » pour l’ensemble de la chaîne.
| Couche | Responsabilités | Mise en œuvre décrite dans les informations publiques |
|---|---|---|
| Plateforme d’automatisation | Gérer de façon centralisée le déclenchement des événements et l’orchestration des Agents | Règles configurées de manière centralisée dans rules.json |
| Couche d’exécution des Agents | Exécuter les tâches des Agents | Exécution locale sur un Mac Mini |
| Plateforme CI | Assurer cinq étapes : revue, contrôle, fusion, publication et vérification | Développée en interne |
| Couche de décision Feishu | Demander une décision humaine aux moments clés | Cartes Feishu |
Cette organisation révèle un choix de conception important : la plupart des questions du type « est-ce correct ? » sont confiées aux vérifications automatisées de la plateforme CI. Seules les questions du type « faut-il le faire ? » sont soumises à un humain. Les premières peuvent être contrôlées selon des critères objectifs ; les secondes impliquent des arbitrages et des responsabilités. C’est là que se situe la limite essentielle de la décision humaine.
À noter : la source originale n’est qu’un résumé. Elle ne précise ni les champs des cartes Feishu, ni la fréquence des décisions humaines et les délais de réponse, ni la définition exacte de « changer de direction ». Les propositions qui suivent sur la conception des cartes et les critères de décision sont donc des pistes que nous avons élaborées à partir de ce principe, et non une description du système d’origine.
Comment savoir quand un agent doit s’arrêter pour demander à un humain : trois critères
« Supprimer des données, dépenser de l’argent, changer de direction » : c’est un bon point de départ, mais les opérations d’un système réel vont bien au-delà. En les ramenant à trois critères réutilisables, vous pouvez rapidement classer toute nouvelle opération : la réversibilité, l’impact sur les coûts et l’orientation.
Premier critère : la réversibilité détermine si l’on peut revenir en arrière
La réversibilité pose une question simple : « Si l’opération est mal exécutée, peut-on revenir en arrière ? » Rédiger un brouillon, créer une branche ou exécuter un script dans un environnement de test sont des opérations réversibles : en cas d’erreur, il suffit de tout reprendre. En revanche, supprimer des données de production, envoyer un courriel à l’extérieur ou publier officiellement du contenu sont des opérations irréversibles ou partiellement réversibles. Revenir en arrière coûte alors bien plus cher que l’exécution elle-même.
Pour évaluer une opération, posez-vous cette question concrète : si l’agent remarque une erreur immédiatement après l’avoir exécutée, combien de temps et de personnes faudra-t-il pour rétablir la situation ? Si la réponse dépasse ce que vous jugez acceptable, l’opération doit être soumise à une approbation.
Deuxième dimension : l’impact financier détermine s’il faut un seuil budgétaire
L’impact financier ne se limite pas à « combien coûte cette action ? » : il faut aussi se demander si le coût risque de s’amplifier. Pour un agent, le principal risque financier vient souvent des boucles : une erreur dans la logique de nouvelle tentative ou une condition de déclenchement trop large peut entraîner des invocations répétées du modèle pendant des heures. Une opération peu coûteuse à l’unité peut devenir inacceptable si elle est répétée de façon incontrôlée.
Une approche plus pratique consiste donc à fixer des seuils budgétaires : l’agent agit de manière autonome tant que les dépenses par opération et cumulées restent dans les limites, puis s’arrête pour demander une validation humaine en cas de dépassement. Si votre agent doit invoquer plusieurs grands modèles de langage, une plateforme d’interface unifiée comme APIYI apiyi.com permet de centraliser les invocations et de regrouper la consommation en un seul endroit. Il devient ainsi plus facile de suivre les dépenses cumulées par rapport aux seuils, sans passer d’une interface fournisseur à l’autre.
Troisième dimension : l’orientation détermine qui est responsable des objectifs
L’orientation est la plus floue des trois dimensions. Elle concerne les opérations susceptibles de changer « où nous allons » : modifier la stratégie de choix des sujets, ajuster la configuration des règles ou changer les priorités du produit, par exemple. Un agent sait trouver la meilleure voie vers un objectif donné, mais il est moins bien placé pour juger si cet objectif doit lui-même changer. Cette décision exige une connaissance du contexte métier, une appréciation de la marque et une prise de responsabilité.
Pour délimiter ce qui relève d’un changement d’orientation, voici une règle pratique : si une opération modifie les règles ou les objectifs de l’agent lui-même — par exemple, en réécrivant les conditions de déclenchement dans rules.json — ou si son résultat sert de point de départ à de nombreuses tâches ultérieures, considérez qu’elle « change l’orientation ».
| Dimension | Caractéristiques à faible risque | Caractéristiques à haut risque | Traitement recommandé |
|---|---|---|---|
| Réversibilité | Brouillon, branche, environnement de test, retour arrière en un clic | Suppression, écrasement, publication externe, envoi de messages | Approbation obligatoire en cas de risque élevé |
| Impact financier | Faible coût par opération, total dans le budget | Dépassement du seuil, risque d’amplification en boucle | Autonomie dans les limites, approbation au-delà |
| Orientation | Exécution dans le cadre des objectifs fixés | Modification des règles, des objectifs ou de la stratégie à long terme | Toujours confier la décision à une personne |
| Évaluation combinée | Risque faible sur les trois dimensions | Risque élevé sur au moins une dimension | S’arrêter et demander une validation humaine dès qu’une dimension présente un risque élevé |
Le coût d’un excès ou d’un manque d’approbations
Définir les limites consiste à trouver un équilibre entre deux risques. Trop ou trop peu d’approbations peuvent faire échouer un projet d’automatisation par agents, mais pas de la même façon.
| Situation | Manifestations typiques | Conséquences immédiates | Effets à long terme |
|---|---|---|---|
| Trop d’approbations | Une confirmation à chaque étape, les cartes s’accumulent | L’automatisation se résume à « cliquer sur des boutons » | Fatigue d’approbation : on finit par accepter sans lire |
| Trop peu d’approbations | Même les opérations critiques sont exécutées de manière autonome | Suppressions accidentelles, dépassements de budget, dérives | Un seul incident détruit la confiance dans le système |
| Limites adaptées | L’agent ne s’arrête que dans trois types de situations à haut risque | Les humains ne traitent que les décisions qui exigent vraiment leur jugement | La confiance s’installe progressivement, ce qui permet d’accorder plus d’autonomie |
Le danger le plus insidieux d’un excès d’approbations est la « fatigue d’approbation ». Quand on reçoit chaque jour des dizaines de cartes de confirmation, on prend vite l’habitude d’accepter sans lire. L’approbation devient alors une simple formalité, parfois plus dangereuse que son absence : tout le monde croit à tort que quelqu’un vérifie. Si le système 卡兹克 ne sollicite les humains que dans trois types de situations, c’est précisément pour que chaque demande mérite toute leur attention.
Bien démarrer avec les limites de décision humaine d’un Agent : cinq étapes pour mettre en place un circuit d’approbation
Voici comment concevoir un circuit d’approbation à partir de zéro. Ces étapes ne dépendent d’aucun framework particulier : vous pouvez les mettre en œuvre avec n’importe quel outil d’orchestration d’événements et plateforme de messagerie instantanée.
Première étape : recenser toutes les actions de l’Agent
Listez tous les outils et actions accessibles à l’Agent : lire ou écrire des fichiers, supprimer des enregistrements, appeler des API externes, envoyer des messages ou modifier des configurations, par exemple. Étiquetez chaque action selon trois critères pour établir une « liste des risques liés aux actions ». Cette liste servira de base à toutes les règles à venir et donnera à l’équipe un langage commun pour discuter des limites à fixer.
Deuxième étape : centraliser les règles
En suivant l’exemple de Kazik, qui utilise rules.json pour gérer les déclencheurs et l’ordonnancement, inscrivez aussi les actions qui nécessitent une approbation dans une configuration centralisée, plutôt que de les disperser dans les invites de chaque agent. Cette approche a deux avantages :
- Auditable : tout le monde peut voir quelles opérations nécessitent une confirmation humaine ;
- Facile à ajuster : si les règles doivent être durcies ou assouplies, il suffit de les modifier à un seul endroit.
Attention : modifier cette configuration revient en soi à « changer de cap ». Seul un humain devrait donc pouvoir le faire.
Troisième étape : laisser la CI effectuer les vérifications automatiques
Avant de solliciter une personne, laissez les contrôles automatisés vérifier tout ce qu’ils peuvent. La plateforme CI de Kazik comprend cinq étapes : revue, contrôle, fusion, publication et vérification. Ainsi, les décisions soumises à un humain ont déjà été débarrassées des problèmes élémentaires, comme les erreurs de format ou les échecs de tests. Les humains ne devraient pas faire les vérifications à la place des machines, et les machines ne devraient pas faire les arbitrages à la place des humains.
Quatrième étape : concevoir les cartes de décision
Voici nos recommandations pour concevoir les cartes de décision, et non les détails du système d’origine. Le principe : permettre à une personne de prendre une décision en quelques dizaines de secondes.
- Une phrase pour expliquer l’action : par exemple, « Supprimer les brouillons datant d’avant mars » ;
- Les types de risques détectés : préciser si l’action est irréversible, dépasse le budget ou change l’orientation du projet ;
- La portée et le coût : combien d’enregistrements sont concernés et quelle est la dépense prévue ;
- Les raisons et les éléments de preuve de l’Agent : pourquoi il propose cette action et quels sont les résultats de la vérification par la CI ;
- Des boutons d’action explicites : accepter, refuser et, si nécessaire, « Modifier puis exécuter ».
Cinquième étape : définir le délai d’expiration et le comportement par défaut
Personne n’est disponible en permanence. Il faut donc définir à l’avance au bout de combien de temps une carte non traitée expire, puis décider du comportement par défaut : « ne pas exécuter » ou « exécuter en mode dégradé ». Pour les opérations qui suppriment des données ou engagent des dépenses, le choix par défaut devrait être « ne pas exécuter ». Mieux vaut laisser la tâche en attente que de considérer le silence comme une autorisation.
🚀 Pour démarrer rapidement : au stade du prototype, nous vous conseillons d’utiliser d’abord un point d’accès unique aux modèles pour tester toute la chaîne « exécution par l’Agent → vérification par la CI → approbation sur carte ». APIYI apiyi.com permet d’appeler plusieurs modèles majeurs et de passer de l’un à l’autre sans modifier la logique d’approbation. Vous pouvez ainsi comparer la fréquence à laquelle chaque modèle déclenche une demande d’approbation et la qualité des raisons qu’il fournit.
Répartition des rôles entre vérification par la CI et décision humaine
Beaucoup d’équipes se demandent pourquoi une intervention humaine reste nécessaire si la CI peut effectuer les contrôles. La réponse est simple : elles ne répondent pas aux mêmes questions. Voici comment se répartissent les rôles :
| Étape | Question | Critère de décision | Responsable |
|---|---|---|---|
| Revue / contrôle | Le résultat est-il conforme aux normes ? | Règles, tests, format | Plateforme CI |
| Fusion / publication | Peut-on passer à l’étape suivante ? | Tous les contrôles ont-ils réussi ? | Plateforme CI |
| Vérification | Le résultat est-il vraiment effectif ? | Vérification a posteriori | Plateforme CI |
| Suppression de données / dépenses / changement de direction | Faut-il le faire ? | Jugement métier et responsabilité | Décision humaine |
| Source d’invocation du modèle | Quel modèle utiliser et à quel coût ? | Seuils budgétaires | Règles de configuration + intervention humaine en dernier recours ; APIYI apiyi.com peut aider à centraliser les données d’utilisation |
Questions fréquentes (FAQ)
Q1 : Qu’est-ce que la limite de décision humaine pour un Agent ?
C’est la règle qui distingue les actions qu’un Agent peut exécuter seul de celles qui nécessitent une confirmation humaine. Tant qu’il reste dans cette limite, l’Agent avance sans attendre. Lorsqu’il l’atteint, il s’arrête et confie la décision à une personne. Cette limite se définit généralement selon trois critères : la réversibilité, l’impact sur les coûts et le changement de direction.
Q2 : Quelle est la différence entre une approbation humaine et les vérifications automatiques de CI ?
La CI répond à la question « Est-ce correct ? » à partir de règles et de tests : c’est un travail adapté aux machines. L’approbation humaine répond à « Faut-il le faire ? », en s’appuyant sur le jugement métier et la prise de responsabilité. Les premières devraient être automatisées autant que possible ; les secondes, limitées aux décisions qui le justifient. Combinées, elles permettent d’avancer vite et avec fiabilité.
Q3 : Comment définir une catégorie aussi floue que le « changement de direction » ?
La source ne précise pas comment l’auteur la définit. Nous suggérons de traiter comme un « changement de direction » toute action qui modifie les règles ou les objectifs de l’Agent, ainsi que toute action dont le résultat servira de base à de nombreuses tâches ultérieures. En cas de doute, mieux vaut d’abord exiger une approbation, puis accorder progressivement plus d’autonomie selon les résultats observés.
Q4 : Dans quelles situations faut-il surtout prévoir des points de décision humaine ?
Les principales situations sont :
– **Nettoyage des données** : suppression régulière de fichiers ou d’enregistrements expirés ;
– **Publication automatique de contenu** : confirmation finale avant une publication externe ;
– **Invocations du modèle par lots** : appels payants dont le nombre peut être amplifié par une boucle ;
– **Ajustements stratégiques** : modification de la ligne éditoriale, des règles de planification, etc.
Q5 : Comment maîtriser les dépenses liées aux appels d’un Grand modèle de langage par un Agent ?
Il est conseillé de définir deux seuils budgétaires : un par appel et un autre cumulé. L’Agent peut agir seul tant qu’il reste sous ces seuils et demande une approbation dès qu’il les dépasse. En centralisant l’invocation du modèle sur une plateforme d’interface unifiée comme APIYI apiyi.com, l’utilisation est regroupée en un seul endroit, ce qui facilite son suivi par rapport aux seuils et son analyse a posteriori.
Q6 : Comment vérifier rapidement que sa limite d’approbation est adaptée ?
Commencez par un essai à petite échelle sur des tâches réelles, en consignant chaque jour le nombre de demandes d’approbation, le taux de refus et le temps de réponse moyen. Si les demandes sont nombreuses mais que le taux de refus est très faible, la limite est trop stricte. Si des problèmes ne sont découverts qu’après coup, elle est trop souple. Au début, vous pouvez utiliser APIYI apiyi.com pour faire exécuter le même lot de tâches par plusieurs modèles et observer les différences dans leurs demandes d’approbation.
Q7 : Quelles sont les limites de cette approche ?
L’approbation humaine dépend de la disponibilité et de la réactivité des personnes : la nuit ou les jours fériés, les tâches risquent donc de s’accumuler. Si les informations de la fiche sont incomplètes, une personne peut aussi se tromper. Par ailleurs, la source sur laquelle repose cet article est un résumé : les détails des cas d’exécution erronée sans approbation et des mécanismes de protection ne sont pas publics. Lors de la mise en place, il faut donc prévoir des mécanismes de délai d’attente, de journalisation et de retour arrière adaptés à son système.
Quand un agent doit-il s’arrêter pour demander l’avis d’une personne ? Points clés
- Principe central : ne sollicitez une personne que dans trois cas : supprimer des données, dépenser de l’argent ou changer de direction. Chaque demande d’approbation conserve ainsi son importance.
- Trois critères de décision : classez rapidement toute nouvelle opération selon sa réversibilité, son impact financier et son effet sur la direction du projet.
- Rôles bien définis : la CI vérifie si c’est correct ; la personne décide si c’est souhaitable. L’une ne remplace pas l’autre.
- Attention à la fatigue d’approbation : trop de demandes poussent à approuver par habitude, ce qui peut être plus dangereux qu’une absence d’approbation.
- Prudence par défaut : si le délai expire sans réponse, les opérations à haut risque ne sont pas exécutées.
- Point d’accès unique : utilisez APIYI apiyi.com pour invoquer plusieurs modèles au même endroit, gérer plus facilement les seuils de coût et comparer les modèles.
En résumé
Déterminer quand un agent doit s’arrêter pour demander l’avis d’une personne revient à tracer une limite claire entre efficacité et risque :
- Commencez par trois types de décisions : supprimer des données, dépenser de l’argent et changer de direction couvrent la grande majorité des situations à haut risque ;
- Élargissez la règle avec trois critères : la réversibilité, l’impact financier et l’effet sur la direction du projet permettent de l’appliquer à toute nouvelle opération ;
- Allégez la charge grâce aux vérifications automatisées : laissez la CI filtrer les problèmes élémentaires, pour que les personnes ne traitent que les décisions qui demandent réellement leur jugement.
Ces limites ne sont pas gravées dans le marbre : elles peuvent être assouplies progressivement, à mesure que la confiance s’installe. Commencez par un essai avec des limites strictes, puis appuyez-vous sur les données pour décider où accorder plus d’autonomie. Pendant la mise en place et l’ajustement, APIYI apiyi.com permet d’accéder à plusieurs modèles depuis un même point d’entrée et de comparer rapidement leurs performances dans votre circuit d’approbation.
📚 Références
- L’architecture du système d’automatisation par agents, peaufiné pendant un an par 数字生命卡兹克 : source des principes et des informations sur l’architecture présentés dans cet article
- Lien :
aihot.news/items/dzwfvd9xp6v4qaj6olxezpier - Description : présente une architecture à quatre couches — plateforme d’automatisation, exécution des agents, plateforme CI et prise de décision dans Feishu — ainsi que le principe « ne solliciter un humain que pour supprimer des données, dépenser de l’argent ou changer de direction ». Il s’agit d’un résumé : consultez l’article original pour vérifier les détails.
Auteur : équipe technique APIYI
Échanges techniques : contactez-nous depuis la page d’accueil d’APIYI, apiyi.com, pour échanger sur la mise en pratique de l’automatisation par agents et de la collaboration humain-machine. Retrouvez d’autres ressources dans le centre de documentation docs.apiyi.com.
