Un agent IA en entreprise ne se pilote pas seulement avec un bon prompt. Avant de lui donner accès à un CRM, à une boîte mail, à des documents ou à un outil de gestion, il faut définir ce qu’il peut lire, ce qu’il peut préparer, ce qu’il peut exécuter et ce qui doit rester validé par une personne. Le premier pilote doit être limité, observable et facile à interrompre.
Le cadre AI RMF du NIST propose de gouverner, cartographier, mesurer et gérer les risques d’un système d’IA. Pour une TPE ou une PME, cette logique peut se traduire par une fiche de cadrage simple et une revue progressive des accès.
Choisir une mission qui se prête à un pilote
Ne partez pas d’une technologie ou d’un accès global aux données. Partez d’une tâche répétitive dont le résultat attendu peut être décrit. Un agent peut par exemple classer des demandes entrantes, extraire des informations de documents, préparer une réponse à relire ou signaler les dossiers incomplets.
Écrivez la mission en une phrase : « à partir des demandes reçues sur ce canal, l’agent identifie le sujet, rassemble les informations utiles et prépare une proposition de réponse ». Ajoutez ce qui est explicitement hors périmètre : décider d’un remboursement, modifier un contrat, répondre seul à un litige ou supprimer une donnée.
Un bon premier périmètre comporte :
- une source d’entrée identifiée ;
- un nombre limité de types de demandes ;
- un résultat vérifiable par un membre de l’équipe ;
- une procédure de reprise lorsque l’information manque ;
- une possibilité d’arrêter le traitement sans bloquer l’activité.
Cette précision évite de confondre un agent IA avec un assistant général capable de « gérer l’entreprise ». Elle donne aussi une base pour comparer le fonctionnement avant et pendant le pilote.
Inventorier les données réellement nécessaires
Listez les informations dont l’agent a besoin pour produire son résultat, puis retirez le reste. Pour chaque source, indiquez son propriétaire, son contenu, sa sensibilité, sa fréquence de mise à jour et la durée pendant laquelle l’accès est utile.
Un agent chargé de préparer des réponses commerciales peut avoir besoin du catalogue de services, des zones d’intervention et de l’historique d’une demande. Il n’a pas nécessairement besoin de toute la comptabilité, des dossiers de ressources humaines ou des conversations sans rapport avec la tâche.
Classez les données en quatre groupes :
- données indispensables au raisonnement ou à l’extraction ;
- données utiles mais consultables seulement sur demande ;
- données interdites dans le pilote ;
- données de test, anonymisées ou fictives.
Cette étape doit aussi couvrir les documents joints, les exports temporaires, les journaux et les résultats générés. Les fiches pratiques IA de la CNIL rappellent que les responsabilités et les obligations dépendent notamment de la manière dont les données sont collectées, réutilisées et traitées. Pour un projet réel, vérifiez le rôle de chaque acteur et les traitements concernés au lieu de conclure trop vite qu’un outil est « conforme ».
Séparer lecture, préparation et action
Un accès en lecture n’a pas le même impact qu’un droit d’écriture ou d’envoi. Décrivez les capacités de l’agent dans cet ordre : consulter, extraire, proposer, créer un brouillon, modifier, déclencher une action externe.
Pour un premier pilote, privilégiez souvent la lecture de sources limitées et la production d’un brouillon. Un utilisateur peut ensuite contrôler les informations, corriger le contenu et effectuer lui-même l’action finale. Si une action automatisée est nécessaire, commencez par une action réversible et traçable, avec un périmètre réduit.
Formalisez une matrice simple : outil, données visibles, action permise, validation requise, preuve conservée. Par exemple, l’agent peut lire les nouveaux tickets, proposer une catégorie et rédiger une réponse, mais ne peut ni fermer le ticket ni l’envoyer sans validation.
Le NIST AI RMF recommande de documenter les rôles et responsabilités de la configuration humain-IA ainsi que les processus de supervision. Ce n’est pas une garantie de bon fonctionnement ; c’est un moyen de rendre les décisions et les limites discutables avant le déploiement.
Préparer les validations humaines et les escalades
La validation humaine doit être une étape réelle, pas un bouton décoratif. Nommez la personne ou le rôle qui relit, les critères de contrôle et la conduite à tenir si l’agent hésite ou produit une réponse incomplète.
Prévoyez une escalade lorsque :
- une information obligatoire manque ou se contredit ;
- la demande sort des catégories testées ;
- le document contient une donnée sensible non prévue ;
- la réponse peut engager l’entreprise ;
- l’agent propose une action irréversible ;
- l’utilisateur signale une erreur ou une réponse inadaptée.
La consigne peut être simple : « ne pas répondre, ne pas modifier, créer une tâche de revue avec les éléments retrouvés ». Testez également le refus : l’agent doit savoir dire qu’il ne dispose pas des informations ou qu’une validation est nécessaire.
Encadrer le fournisseur et les accès techniques
Lorsque le pilote utilise un service externe, vérifiez les comptes, les sous-traitants, les données transmises, les journaux, les durées de conservation, les incidents et la sortie du service. La CNIL rappelle les points à encadrer avec un sous-traitant, notamment les responsabilités, l’authentification, la notification des incidents et la restitution ou destruction des données en fin de relation.
Sur le plan pratique, évitez de relier le pilote à un compte personnel ou à un accès administrateur général. Utilisez un compte ou une clé dédiée, des permissions minimales, des secrets stockés séparément et une procédure de révocation. Notez qui peut modifier les consignes, les connecteurs et les règles de validation.
Ne promettez pas une confidentialité absolue sur la seule base du nom d’un outil. Examinez les conditions et la configuration réellement utilisées, puis faites relire les aspects contractuels ou réglementaires sensibles par le professionnel compétent.
Mesurer la qualité avant de mesurer la vitesse
Définissez un échantillon de demandes représentatives avant l’ouverture du pilote. Pour chacune, notez le résultat attendu, les informations nécessaires, les erreurs acceptables et le rôle qui valide. Rejouez ensuite ces cas avec l’agent et consignez les écarts.
Suivez quelques indicateurs compréhensibles :
- proportion de sorties correctes au premier contrôle ;
- types et gravité des erreurs ;
- demandes nécessitant une escalade ;
- temps de revue humaine ;
- actions bloquées ou annulées ;
- incidents d’accès ou de données ;
- avis des utilisateurs concernés.
Le profil NIST consacré à l’IA générative insiste sur l’identification et la mesure des risques propres aux usages de modèles génératifs. Dans une petite structure, l’objectif n’est pas de créer un programme de recherche : c’est de conserver des exemples, d’expliquer les erreurs et de décider sur des faits observés.
Organiser un pilote réversible
Fixez une durée, un périmètre, un responsable et une date de revue. Conservez une procédure manuelle de secours et informez les utilisateurs de ce que l’agent fait réellement. Au terme du pilote, choisissez entre trois suites : arrêter, corriger et retester, ou élargir progressivement.
Un élargissement doit ajouter une capacité à la fois : une nouvelle source, un nouveau type de demande ou une action supplémentaire. Après chaque changement, vérifiez les résultats sur un nouvel échantillon. Si les erreurs deviennent difficiles à détecter ou si les accès dépassent la mission, revenez au périmètre précédent.
Pour préparer la suite, rassemblez dans une fiche : mission, données, accès, règles de refus, validations, exemples testés, incidents, mesures et décision. Vous disposez ainsi d’un socle concret pour parler d’un projet d’agent IA avec l’Agence Digi, comparer une intégration aux outils existants et décider si une première version mérite d’être étendue.
À retenir avant de connecter un nouvel outil
Un agent IA utile commence par un processus bien choisi et des limites explicites. Donnez-lui uniquement les données nécessaires, séparez la lecture de l’action, prévoyez une validation humaine pour les conséquences importantes et mesurez les erreurs autant que le temps gagné. Un pilote réussi n’est pas celui qui automatise le plus vite : c’est celui dont l’entreprise comprend le périmètre, peut contrôler les résultats et peut interrompre le fonctionnement sans perdre la maîtrise de ses données.