L’évolution importante de l’IA au travail ne tient pas au fait qu’un modèle puisse rédiger un meilleur paragraphe. Elle tient au fait qu’un système peut de plus en plus poursuivre un objectif en plusieurs étapes : examiner des fichiers, effectuer des recherches dans des services connectés, créer un livrable, mettre à jour un enregistrement et envoyer un message.
Cela fait passer la question professionnelle de « Cette réponse est-elle correcte ? » à « Que suis-je autorisé à laisser faire à ce système avant qu’il ne doive me demander mon accord ? »
Zapier décrit ChatGPT Work comme un mode agentique capable de travailler sur de longues périodes avec des fichiers et des applications connectées, tandis que son mode Plan propose une stratégie à faire approuver avant l’exécution. Microsoft présente de même Copilot, les connaissances organisationnelles et la gouvernance comme des éléments complémentaires d’une pile d’IA opérationnelle. Ces exemples mettent en évidence une distinction pratique : l’IA passe du rôle de partenaire de conversation à celui d’opérateur auquel on délègue des tâches.
La délégation peut faire gagner du temps, mais elle modifie aussi la nature de la responsabilité. Un chatbot produit généralement un résultat qu’une personne doit examiner. Un agent peut produire plusieurs actions intermédiaires, dont certaines sont difficiles à repérer a posteriori. La stratégie d’adoption la plus sûre n’est donc pas l’autonomie maximale. C’est une autorité explicite et progressive.
Raisonner en termes d’actions, pas de prompts
Une première étape utile consiste à dresser la liste des actions qu’un système d’IA pourrait effectuer dans un flux de travail. « Gérer l’intégration des clients » est trop général pour être encadré. Un inventaire plus utile pourrait inclure :
- lire une politique interne et en extraire les exigences ;
- effectuer une recherche dans une base de connaissances approuvée ;
- rédiger un e-mail ou un résumé de contrat ;
- créer un ticket ou une ligne de feuille de calcul ;
- modifier une fiche client ou un enregistrement financier ;
- inviter un utilisateur, publier un document ou envoyer un message externe ;
- approuver un paiement, supprimer des données ou prendre un engagement au nom de l’organisation.
Chaque action présente une combinaison différente de réversibilité, de sensibilité, d’impact externe et de coût. Les traiter toutes comme une simple « assistance de l’IA » masque la véritable décision.
Une classification simple est plus pratique qu’une vague promesse selon laquelle un humain supervisera tout :
- Peut effectuer : des actions à faible risque et réversibles dans un espace de travail clairement limité.
- Doit proposer : les actions qui modifient un travail partagé, communiquent avec l’extérieur ou créent un engagement significatif.
- Ne doit jamais effectuer seul : les actions impliquant des décisions réglementées, une suppression irréversible, des transferts de valeur élevée, des modifications des contrôles d’accès ou des questions sensibles concernant le personnel.
Le programme d’IA agentique du gouvernement des Émirats arabes unis fournit un exemple de politique pertinent : il comprend des règles permettant de déterminer quelles tâches les agents peuvent effectuer et lesquelles ils peuvent seulement recommander. L’idée sous-jacente s’applique bien à une équipe : l’autorisation doit être associée à la tâche, et non accordée simplement parce que le système semble capable.
Utiliser des étapes de validation lorsque les conséquences changent
Toutes les étapes ne méritent pas une boîte de dialogue de confirmation. Si un système demande une approbation après chaque lecture de fichier, les utilisateurs approuveront machinalement ou désactiveront le contrôle. Placez l’étape de validation juste avant une transition lourde de conséquences.
Par exemple, un agent pourrait être autorisé à recueillir des informations, comparer des options et préparer un brouillon sans interruption. Il devrait s’arrêter avant de :
- envoyer quoi que ce soit à l’extérieur de l’organisation ;
- publier ou partager un document avec un nouveau public ;
- modifier un enregistrement faisant foi ;
- dépense de l’argent ou applique une remise ;
- modifie des autorisations ou crée des identifiants ;
- supprime, écrase ou exporte des données ;
- prend une décision qui affecte l’emploi, l’admissibilité, le crédit, la sécurité ou les droits légaux.
La demande d’approbation doit présenter l’action proposée, la cible exacte, les éléments importants et la conséquence probable. « Continuer ? » est un contrôle faible. « Envoyer ce message à 2 400 clients, en utilisant la liste jointe, pour un coût de campagne estimé à X $ » fournit à une personne des éléments significatifs à examiner.
Pour les actions à fort impact, exigez un approbateur désigné plutôt que la personne qui se trouve par hasard à regarder l’écran. Séparez la personne qui a conçu le flux de travail de celle qui autorise son résultat le plus lourd de conséquences lorsque le risque le justifie.
Définir le périmètre opérationnel de l’agent
Les professionnels n’ont pas besoin de comprendre chaque détail du modèle pour établir des limites utiles. Ils doivent en revanche préciser le périmètre opérationnel du système :
- Périmètre : quels projets, dossiers, comptes et sources de données sont disponibles ?
- Outils : le système peut-il lire, écrire, envoyer, acheter, exécuter du code ou modifier des autorisations ?
- Limites : quelle limite de dépenses, de volume, de fréquence ou de durée s’applique ?
- Sources : quels domaines, référentiels ou bases de données font autorité ?
- Escalade : quelle incertitude, quel conflit ou quelle information manquante nécessite l’intervention d’une personne ?
- Conditions d’arrêt : quand le système doit-il s’arrêter plutôt que d’improviser ?
L’accès aux outils devrait être plus restreint que l’accès général du compte de l’utilisateur chaque fois que possible. Un agent qui peut lire un lecteur partagé n’a pas automatiquement besoin de l’autorisation d’envoyer des courriels à tous les contacts. Un agent qui peut rédiger du code n’a pas automatiquement besoin d’identifiants de production. Un compte de service distinct, un espace de travail limité ou une connexion en lecture seule peuvent rendre une erreur moins coûteuse.
Rédigez la limite dans un langage opérationnel. « Faites preuve de discernement » n’est pas un contrôle. « N’envoyez pas de courriels externes sans approbation ; ne modifiez pas la base de données clients ; utilisez uniquement la grille tarifaire approuvée datée du [date] ; arrêtez-vous si deux sources sont en conflit » est vérifiable.
Rendre les plans vérifiables avant leur exécution
La planification est l’une des fonctionnalités utiles de l’IA déléguée, mais un plan ne prouve pas que le plan est solide. Examinez-le comme une séquence d’actions proposée.
Posez quatre questions :
- Quel résultat le système cherche-t-il à obtenir ?
- Quelles hypothèses formule-t-il ?
- Quels outils appellera-t-il, et avec quelles autorisations ?
- À quelle étape une erreur peut-elle devenir coûteuse ou difficile à annuler ?
Un bon écran d’approbation doit exposer les limites du plan, et pas seulement son texte final. Si le système indique qu’il va « mettre le compte en ordre », l’examinateur devrait pouvoir voir si cela signifie étiqueter des enregistrements, fusionner des doublons, archiver des messages ou supprimer des données.
Pour les tâches récurrentes, n’approuvez une règle plutôt que chaque instance que lorsque cette règle est suffisamment étroite pour être testée. « Classer automatiquement les factures de ces fournisseurs sous ce montant, sans supprimer les originaux » en est un exemple possible. « Gérer les factures » ne l’est pas.
Partir du principe que le contexte peut être perdu
Les systèmes en plusieurs étapes peuvent perdre le fil des instructions précédentes, mal interpréter les informations récupérées ou conserver une hypothèse erronée. Les recommandations issues de la recherche et de l’ingénierie présentées dans le digest mettent en évidence des modes de défaillance tels que la perte de contexte, l’injection de prompts, la non-terminaison, les erreurs de sortie structurée et les problèmes de réhydratation de l’état. Les travaux ABBEL de Berkeley soutiennent également que la condensation des historiques d’interaction en états de croyance peut être préférable au transport répété d’un historique complet, mais la gestion du contexte reste un enjeu de performance et de fiabilité.
Cela a une implication directe au travail : ne faites pas dépendre une approbation critique du souvenir, par l’agent, d’une contrainte énoncée à la deuxième étape d’une longue exécution. Placez les contraintes importantes près de l’appel d’outil ou du point de contrôle d’approbation. Exigez des champs structurés pour les actions sensibles, tels que le destinataire, le montant, la source, la justification et la date d’expiration. Si une tâche s’exécute pendant longtemps, exigez un point de contrôle qui récapitule l’objectif actuel, les étapes terminées, les actions en attente et les incertitudes non résolues.
Soyez particulièrement prudent lorsqu’un agent lit des contenus non fiables. Une page web, un e-mail, un document ou un commentaire de code peut contenir des instructions visant à manipuler le système plutôt qu’à contribuer à l’accomplissement de la tâche. Le texte récupéré doit être traité comme une donnée, sauf si le processus l’identifie explicitement comme une instruction autorisée.
Prévoir l’arrêt et la reprise
Le travail délégué nécessite un mécanisme d’arrêt visible et un plan de reprise. Fixez un nombre maximal d’itérations, d’appels d’outils ou une durée maximale pour les tâches susceptibles de boucler. Rendez les nouvelles tentatives sûres : créer deux fois le même ticket ou envoyer deux fois le même e-mail n’est pas une défaillance anodine. Lorsque cela est possible, utilisez des opérations idempotentes ou demandez au système de vérifier si une action a déjà été effectuée avant de la répéter.
Tenez un registre d’activité lisible par un humain : la demande, le plan, les outils utilisés, les sources de données consultées, les approbations accordées, les modifications effectuées et le résultat final. Ce registre ne sert pas uniquement aux analyses post-incident. Il permet à un collègue de prendre le relais lorsque l’opérateur initial n’est pas disponible et rend possible la contestation d’un résultat sans devoir reconstituer toute une chaîne invisible.
Pour les processus importants, testez délibérément les mauvais scénarios avant d’accorder de l’autonomie. Essayez des données manquantes, des politiques contradictoires, une source expirée, une instruction malveillante dans un document, une demande en double, une autorisation révoquée et un outil qui renvoie une erreur. L’objectif n’est pas de prouver que l’agent ne tombe jamais en panne. Il s’agit de vérifier qu’une défaillance entraîne une pause, une escalade claire ou une restauration sûre.
Une échelle pratique de délégation
Vous pouvez introduire un agent par étapes :
- Observer : le système lit les informations approuvées et explique ce qu’il ferait.
- Rédiger : il prépare les résultats, mais une personne exécute chaque action externe.
- Agir dans un bac à sable : il crée des enregistrements, des branches ou des fichiers de test dans un espace de travail isolé.
- Agir avec des autorisations limitées : il effectue des actions réversibles et peu risquées, dans des limites de volume et de temps.
- Agir dans le respect d’une politique : il prend en charge une catégorie de tâches bien testée et s’interrompt à des points de contrôle d’approbation définis.
Ne passez à l’étape supérieure que lorsque l’étape inférieure a produit des éléments démontrant que le processus fonctionne de manière acceptable. Si la tâche change, si les outils changent ou si les données deviennent plus sensibles, redescendez d’un niveau dans l’échelle.
Ce que cela signifie pour votre carrière
La compétence précieuse ne consiste pas simplement à savoir demander un résultat à une IA. Elle consiste à savoir transformer une délégation vague en procédure opérationnelle clairement délimitée. Cela inclut la décomposition du travail en actions, l’identification des transitions irréversibles, la rédaction de règles d’escalade, la conception de demandes d’approbation et la capacité à reconnaître le moment où un agent doit s’arrêter.
Lors des entretiens ou des évaluations de performance, décrivez la limite que vous avez conçue, et pas seulement l’automatisation que vous avez mise en place : « Le système effectue les recherches et prépare les brouillons ; un évaluateur nommé approuve les communications externes ; les écritures dans la base de données sont limitées à ces champs ; les actions en double sont vérifiées ; les conflits non résolus interrompent l’exécution. » Ce langage témoigne d’un jugement opérationnel.
Le travail avec des agents ne supprimera pas le besoin de responsabilité professionnelle. Il rend la responsabilité plus concrète. Avant de confier une tâche, décidez ce que le système peut faire, ce qu’il doit d’abord vous montrer et ce qu’il ne doit jamais faire seul. Puis rendez ces décisions visibles dans le processus lui-même.
Maya Chen est la rédactrice humaine responsable de AI Career Brief, qui traite des compétences, des fonctions et des choix judicieux pour travailler à l’ère de l’IA.
