Agent IA : la fiche de délégation en 7 décisions avant de le connecter

Connecter un agent IA à une messagerie, un CRM ou un espace documentaire ne revient pas seulement à choisir un modèle. Vous lui déléguez une capacité d’observer, de décider et parfois d’agir. Avant le premier accès, sept décisions doivent donc être écrites : son objectif, ses données, ses outils, les actions à valider, sa mémoire, ses preuves et sa procédure d’arrêt.

Cette fiche se remplit en environ 20 minutes sur un workflow précis. Elle ne remplace ni une analyse de sécurité, ni une analyse d’impact, ni un avis juridique. Elle fournit un contrat opérationnel assez concret pour lancer un test limité, détecter les zones floues et savoir quand reprendre la main.

Les sept décisions de la fiche de délégation : objectif, données, outils, validations, mémoire, preuves et arrêt, autour d’un contrôle humain

Schéma original BâtisseurIA, copyright Aymane Abdennour. Les sept décisions sont tirées d’une synthèse opérationnelle des risques documentés par la CNIL, le Conseil de l’IA et du Numérique, l’Autorité de la concurrence et l’OCDE.

Pourquoi un bon prompt ne suffit pas

Un assistant qui rédige un texte à partir d’une consigne reste relativement contenu. Un agent connecté peut enchaîner plusieurs étapes, consulter des sources, conserver un historique et appeler des services externes. La note exploratoire de la CNIL et du Conseil de l’IA et du Numérique, publiée le 20 juillet 2026, insiste sur ce changement d’échelle : les données circulent entre plusieurs services, les mémoires persistantes augmentent les informations conservées et la délégation complique le partage des responsabilités.

L’avis 26-A-05 de l’Autorité de la concurrence, publié le 17 juillet 2026, décrit aussi l’agent comme une nouvelle couche d’intermédiation. Ses recommandations peuvent dépendre des données accessibles, de partenariats ou des règles de visibilité du service. La bonne question n’est donc pas seulement « répond-il correctement ? », mais « avec quelles ressources agit-il, qui peut vérifier son choix et comment sortir de cette dépendance ? »

Une fiche de délégation transforme ces risques généraux en limites testables. Remplissez-la pour un seul workflow, pas pour « notre agent IA » en général.

Décision 1 : quel résultat précis lui déléguez-vous ?

Écrivez une phrase avec une entrée, une sortie et un critère de réussite.

À partir d’un nouveau message reçu sur l’adresse support, préparer un brouillon de réponse fondé uniquement sur la base d’aide validée, puis le soumettre à un conseiller.

Cette formulation est meilleure que « gérer le support ». Elle exclut implicitement l’envoi autonome, le remboursement et la modification du dossier client. Ajoutez trois frontières : ce qui déclenche le workflow, ce qui le termine et ce qui doit provoquer une escalade.

Un objectif utile est observable. Vous pourrez mesurer le taux de brouillons acceptés, les corrections nécessaires, les réponses sans source et les cas correctement transmis à un humain. Évitez de mesurer seulement le temps gagné : une accélération qui augmente les erreurs ou les réclamations n’est pas un succès.

Décision 2 : quelles données peut-il voir ?

Listez les sources par nom et par niveau d’accès. « Le CRM » est trop vague. Précisez les objets et les champs : identité du contact, historique des tickets, statut du contrat, notes internes, pièces jointes.

Appliquez ensuite trois filtres :

nécessité : la donnée est-elle indispensable au résultat défini ?
sensibilité : contient-elle des informations personnelles, financières, médicales, contractuelles ou confidentielles ?
propagation : vers quels fournisseurs, journaux ou sous-traitants peut-elle circuler ?

Commencez avec une source documentaire approuvée et des données fictives. Ajoutez les données réelles une par une. Un compte en lecture seule, limité à un dossier ou à une vue, est préférable à un accès large protégé uniquement par une consigne textuelle.

Pour une organisation opérant entre la France et l’Afrique francophone, ne supposez pas qu’un même cadre juridique couvre tous les traitements. Le RGPD peut s’appliquer dans certaines situations transfrontalières, mais les règles locales, les transferts et les responsabilités doivent être vérifiés pays par pays.

Décision 3 : quels outils peut-il appeler ?

Un outil est une capacité d’action : rechercher un document, créer une ligne, envoyer un message, déclencher un workflow, modifier un calendrier ou lancer un paiement. Pour chacun, notez :

l’identité technique utilisée ;
les opérations autorisées ;
la portée des données ;
la limite de fréquence ou de montant ;
la personne responsable de l’accès.

Le principe du moindre privilège devient ici très concret. Si l’agent doit préparer une réponse, il n’a pas besoin du droit d’envoyer. S’il doit proposer un créneau, il peut lire les disponibilités sans pouvoir supprimer un rendez-vous. S’il doit classer une demande, il peut écrire un tag dans une file de test sans modifier le dossier principal.

Prévoyez aussi la portabilité. L’Autorité de la concurrence avertit que l’historique et la personnalisation peuvent rendre la migration coûteuse. Conservez donc les règles métier, les instructions, les journaux utiles et les données de référence dans des formats exportables, hors de l’interface d’un seul fournisseur lorsque c’est possible.

Décision 4 : quelles actions exigent une validation humaine ?

Classez chaque action selon deux axes : réversibilité et impact. Plus une action est difficile à annuler ou touche une personne, de l’argent, un engagement contractuel ou une donnée sensible, plus la validation doit être forte.

Pour le support client, le brouillon peut être automatique, mais l’envoi reste soumis à un conseiller. Pour un achat, l’agent peut comparer des offres, mais le choix du fournisseur et le paiement restent humains. Pour le recrutement, la santé, le crédit ou l’accès à un service essentiel, une simple confirmation en un clic ne constitue pas nécessairement une supervision suffisante.

Décrivez la validation attendue : qui vérifie, quoi doit être visible, combien de temps la décision reste ouverte et que se passe-t-il sans réponse. La valeur par défaut doit être sûre. Une validation expirée ne doit pas se transformer en autorisation implicite.

Décision 5 : que mémorise-t-il, où et combien de temps ?

La mémoire n’est pas une fonction abstraite. Elle peut être un historique de conversation, une base vectorielle, un profil utilisateur, un cache ou un journal chez un fournisseur. La CNIL souligne que la mémoire persistante favorise l’hyperpersonnalisation, mais augmente aussi les données conservées et le risque de perte de maîtrise.

Pour chaque mémoire, écrivez : contenu, finalité, emplacement, durée, accès et méthode d’effacement. Distinguez la mémoire nécessaire à la tâche en cours de la connaissance durable. Dans notre exemple, le texte du ticket peut vivre pendant le traitement, tandis que les règles de réponse approuvées vivent dans une base documentaire versionnée. Rien n’impose de transformer toutes les conversations en mémoire permanente.

Testez l’effacement. Une politique « 30 jours » n’est utile que si les copies, index, sauvegardes et journaux concernés sont identifiés et si la suppression est vérifiable.

Décision 6 : quelle preuve conserve-t-il ?

Un journal utile permet de reconstituer une décision sans enregistrer tout le contenu sensible. Conservez au minimum : l’heure, la version du workflow, l’identité du demandeur ou du service, les outils appelés, le résultat, la validation humaine et l’état final.

Ajoutez les références utilisées pour produire une recommandation. Dans un support client, chaque affirmation importante devrait pointer vers une page d’aide approuvée. Un brouillon sans source doit être bloqué ou signalé, pas maquillé en réponse sûre.

Le rapport de l’OCDE publié le 14 novembre 2025 rappelle que l’autonomie complique l’attribution des résultats et que l’explicabilité ne suffit pas sans possibilité de contester, corriger ou remplacer une décision. La preuve doit donc servir une action : comprendre, annuler, corriger et améliorer.

Décision 7 : comment l’arrêter et reprendre la main ?

Définissez un bouton d’arrêt logique avant le pilote. Il doit couper les nouveaux appels, révoquer ou suspendre les accès, préserver les éléments nécessaires à l’enquête et transférer les tâches ouvertes à une file humaine.

Fixez des seuils simples : trois erreurs consécutives, une source introuvable, une tentative d’accès hors périmètre, une hausse anormale des appels ou toute action refusée par le système cible. N’attendez pas un incident majeur pour tester l’arrêt.

La reprise comprend aussi le retour à un processus manuel documenté. Si personne ne sait répondre aux demandes sans l’agent, vous avez créé une dépendance avant d’avoir prouvé la fiabilité.

Exemple rempli : préparer une réponse client sans l’envoyer

Voici une version compacte de la fiche pour une petite entreprise :

Objectif : produire un brouillon en français à partir d’un ticket entrant et de la base d’aide approuvée.
Données : message du client, numéro de dossier pseudonymisé, pages d’aide publiées ; aucune donnée de paiement ni note commerciale interne.
Outils : lecture de la file de test et recherche dans la documentation ; aucune fonction d’envoi ou de modification du CRM.
Validation : un conseiller voit le message original, les sources et le brouillon ; lui seul copie ou envoie la réponse.
Mémoire : contexte conservé pendant le ticket, effacé après 30 jours ; aucune mémoire de profil entre clients.
Preuve : version du workflow, pages citées, brouillon, corrections du conseiller et décision finale.
Arrêt : suspension après une source absente, une donnée hors périmètre ou trois brouillons rejetés ; retour immédiat à la file manuelle.

Ce pilote ne prouve pas que l’agent peut gérer le support. Il vérifie une capacité limitée : préparer des réponses fondées sur une documentation contrôlée. L’élargissement suivant doit être une nouvelle décision, pas une permission glissante.

Le test en quatre passages avant les données réelles

Commencez avec une vingtaine de cas représentatifs et quelques cas volontairement difficiles.

Parcours normal : demande claire, information présente, sortie attendue.
Information absente : l’agent doit reconnaître la limite et transmettre.
Instruction hostile ou hors sujet : une pièce jointe ou un message tente de modifier ses règles ou d’obtenir un accès interdit.
Panne et reprise : outil indisponible, validation expirée, journal incomplet ou arrêt manuel.

Pour chaque cas, vérifiez le résultat, mais aussi les outils appelés, les données consultées et le comportement de repli. Un agent peut donner une bonne réponse par un mauvais chemin. Ce chemin devient dangereux dès que les permissions augmentent.

Sur BâtisseurIA, la page Automatisation replace cette étape dans une démarche plus large : stabiliser d’abord le processus, choisir ensuite ce qui mérite d’être automatisé. Le guide IA pratique aide à distinguer démonstration séduisante et capacité réellement exploitable.

Ce que cette fiche ne garantit pas

Elle ne démontre pas la conformité au RGPD ou au règlement européen sur l’IA. Elle ne remplace pas une analyse d’impact, un audit de cybersécurité, la revue d’un contrat fournisseur ou l’intervention d’un spécialiste. Elle ne rend pas acceptable un cas à haut impact simplement parce qu’une case « validation humaine » est cochée.

Elle ne supprime pas non plus l’incertitude propre aux modèles. Les sorties peuvent varier, les outils évoluer et les dépendances changer. Révisez la fiche à chaque nouvelle source de données, nouvelle action, nouvelle mémoire, changement de fournisseur ou incident significatif.

Votre plan d’action en 20 minutes

Prenez un workflow à faible risque et ouvrez une feuille blanche.

En 3 minutes, écrivez l’entrée, la sortie et le critère de réussite.
En 4 minutes, listez les données et retirez celles qui ne sont pas nécessaires.
En 3 minutes, listez les outils et réduisez chaque permission.
En 3 minutes, placez les validations avant les actions irréversibles.
En 3 minutes, fixez mémoire, durée et effacement.
En 2 minutes, choisissez les événements à journaliser.
En 2 minutes, écrivez le seuil d’arrêt et le retour manuel.

Si une case reste floue, ne connectez pas encore l’outil concerné. Cette hésitation est une information utile : elle montre où votre processus, votre responsabilité ou votre architecture doit être clarifié avant l’automatisation.

Sources et bibliographie utile

Sources vérifiées le 7 août 2026. Article de méthode générale, pas un avis juridique. Révision prévue au plus tard le 7 novembre 2026.