Une IA agentique ne se limite pas à produire une réponse dans une fenêtre de discussion. Elle peut lire une boîte de réception, conserver un contexte, interroger un CRM, appeler un service externe et déclencher une action au nom d’une personne. La bonne première question n’est donc pas « quel modèle choisir ? », mais « quelles données circulent, entre quels services, pour quelle action et sous quelle responsabilité ? ».
La méthode ci-dessous permet de construire une carte exploitable avant un pilote. Elle ne remplace pas l’analyse juridique de votre organisation. Elle évite toutefois un angle mort fréquent : documenter le texte envoyé au modèle, tout en oubliant la mémoire persistante, les journaux, les pièces jointes, les réponses d’outils et les copies créées par les prestataires.
La différence entre un assistant et une chaîne agentique
Un assistant peut répondre à une question à partir d’un contexte fourni par l’utilisateur. Une chaîne agentique ajoute des étapes : elle sélectionne une source, choisit un outil, lit un résultat, conserve éventuellement un état et propose une suite. Chaque étape peut créer un nouveau traitement de données personnelles.
La note exploratoire de la CNIL sur l’IA agentique souligne précisément ce changement d’échelle : mémoire persistante, pluralité de services, circulation entre acteurs et délégation d’actions. Ce n’est pas une raison pour bannir l’automatisation. C’est une raison pour dessiner la chaîne complète.
Un exemple simple : un agent reçoit une demande de rendez-vous. Il lit le message, retrouve le contact dans le CRM, consulte l’agenda, propose une plage et crée une tâche. La donnée personnelle n’est pas seulement le texte initial. Elle peut se retrouver dans la requête du modèle, le résultat de recherche, le journal d’appel, l’événement d’agenda et le ticket de suivi.
Étape 1 : écrire la finalité en une phrase
Commencez par une phrase qui décrit le résultat attendu, pas la technologie. « Aider le support à proposer une réponse à une demande de garantie » est une finalité exploitable. « Améliorer l’entreprise grâce à l’IA » ne permet pas de décider quelles données sont nécessaires ni qui peut agir.
La CNIL rappelle dans ses recommandations sur le développement des systèmes d’IA qu’une finalité doit être définie, explicite et légitime. Même lorsqu’un agent utilise un modèle général, l’équipe doit préciser les capacités envisagées, les usages exclus et les conditions de fonctionnement.
Écrivez ensuite trois limites :
- ce que l’agent peut consulter ;
- ce qu’il peut proposer ou modifier ;
- ce qui doit toujours rester sous validation humaine.
Cette phrase devient le test de cohérence du reste du dossier. Si une source ou une permission ne sert pas la finalité, elle doit être retirée ou justifiée séparément.
Étape 2 : inventorier les catégories de données
Ne commencez pas par les applications. Commencez par les informations. Listez les catégories réellement rencontrées : identité, coordonnées professionnelles, historique de relation, contenu de messages, pièces jointes, données de contrat, informations de santé ou données financières lorsqu’elles existent. Notez aussi les données indirectes comme une adresse IP, un identifiant de ticket ou une trace d’action.
Pour chaque catégorie, indiquez si elle est indispensable, utile mais remplaçable, ou inutile. Un agent de qualification peut parfois fonctionner avec le secteur et le motif de contact sans recevoir l’intégralité de l’historique. Un agent de support peut utiliser une référence de produit sans conserver le nom complet de la personne dans chaque étape.
Ajoutez une colonne « donnée absente ». Un bon système doit pouvoir reconnaître qu’une information manque et demander une précision ou passer la main. Cette colonne transforme la minimisation en comportement observable.
Étape 3 : dessiner les points de passage
Dessinez une ligne par flux, avec un point de départ et un point d’arrivée. Les points utiles sont : canal entrant, orchestrateur, modèle, base documentaire, mémoire courte, mémoire persistante, CRM, agenda, service d’envoi, outil d’observabilité et poste du conseiller.
Pour chaque flèche, écrivez :
- la catégorie de données transportée ;
- l’opération réalisée ;
- la durée de conservation prévue ;
- le responsable de la configuration ;
- le signal qui permet de vérifier que le flux a eu lieu.
La carte doit montrer les flux secondaires. Une erreur envoyée à un outil de suivi est encore un flux. Une conversation conservée pour améliorer les consignes est encore un flux. Une capture utilisée par une équipe technique est encore un flux.
Étape 4 : séparer mémoire, journal et preuve
Ces trois éléments sont souvent confondus. La mémoire sert à conserver un contexte utile pour une interaction ultérieure. Le journal retrace les événements nécessaires à l’exploitation et au contrôle. La preuve est l’élément qui permet à un humain de comprendre pourquoi une action a été proposée ou exécutée.
Une mémoire ne doit pas devenir un entrepôt général. Définissez une règle d’écriture, une durée, un droit de correction et une règle de suppression. Pour le journal, limitez les contenus sensibles et privilégiez des identifiants techniques lorsqu’ils suffisent. Pour la preuve, conservez la source, la règle métier ou l’étape de validation qui justifie la sortie.
La question à poser au fournisseur est concrète : « que se passe-t-il lorsque cette personne demande une correction ou une suppression ? » Demandez la réponse pour la conversation, la mémoire, les sauvegardes, les exports et les journaux. Une politique qui ne décrit qu’un écran utilisateur ne couvre pas toute la chaîne.
Étape 5 : attribuer les rôles sans supposer la responsabilité
Une PME peut utiliser un service développé par un éditeur, configuré par un intégrateur et exploité par une équipe interne. Ces rôles techniques ne suffisent pas à établir les responsabilités au sens du RGPD. La CNIL décrit les cas où les acteurs peuvent agir comme responsable, responsables conjoints ou sous-traitants, selon qui détermine les finalités et les moyens.
Construisez un tableau de travail avec une ligne par traitement : décision de la finalité, choix des catégories de données, configuration de la mémoire, administration des droits, gestion des incidents, réponse aux demandes des personnes. Pour chaque ligne, nommez une organisation et une personne de contact. Si la réponse est « le fournisseur s’en occupe », demandez quel geste précis est couvert et quelle preuve est fournie.
Étape 6 : vérifier les actions au nom de l’utilisateur
Plus l’agent agit, plus la carte doit décrire la confirmation. Lire une fiche n’est pas modifier une fiche. Préparer un message n’est pas l’envoyer. Recommander un créneau n’est pas le réserver. Créer une tâche interne n’est pas prendre une décision sur une personne.
Créez des niveaux d’action : lecture, proposition, écriture réversible, écriture sensible et action externe. Pour chaque niveau, définissez une authentification, une approbation et un journal. Une action sensible doit pouvoir être stoppée sans ambiguïté et son contexte doit être transmis à la personne qui reprend.
La Commission européenne décrit les exigences de traçabilité, de documentation, de supervision humaine, de robustesse et de cybersécurité pour les systèmes à haut risque. Toutes les PME ne relèvent pas de ce niveau de risque, mais ces exigences donnent un bon test de maturité : qui sait ce que le système a fait, avec quelles données, et comment revenir sur son action ?
Tester la carte avec des cas négatifs
Une carte qui ne fonctionne que pour le cas normal est incomplète. Ajoutez une demande sans identité, un document contradictoire, une source indisponible, une donnée sensible non nécessaire et une demande de suppression. Notez le point où l’agent doit s’abstenir.
Pour chaque cas, vérifiez quatre sorties : la réponse visible, les appels d’outils, les données conservées et l’information transmise à l’humain. Un agent peut refuser correctement dans l’interface tout en laissant une trace excessive dans un outil secondaire. La carte rend cette différence visible.
Distinguer nécessité et simple disponibilité
Une donnée accessible n’est pas forcément nécessaire. Pour chaque étape, demandez quelle information permet réellement de répondre ou d’exécuter l’action. Un nom peut suffire pour une orientation ; une adresse complète, un historique détaillé ou une pièce jointe peuvent être inutiles. Cette question limite le périmètre et rend la justification plus claire.
Tracez les données qui apparaissent dans les instructions envoyées au système, les résultats intermédiaires, les outils appelés et les journaux. Les systèmes agentiques multiplient les endroits où une information peut être copiée ou conservée. La carte doit inclure les erreurs, les reprises et les exports, pas seulement le parcours nominal.
Cartographier les décisions et les validations
Pour chaque étape, écrivez qui décide, sur quelle information et avec quel droit. L’agent peut proposer une catégorie sans décider d’une conséquence. Il peut rechercher un document sans pouvoir transmettre son contenu. Il peut préparer un brouillon sans l’envoyer. Ces distinctions permettent de relier la finalité à des actions précises.
Ajoutez un point d’arrêt avant toute action qui modifie un dossier, communique avec une personne ou crée une obligation pour l’entreprise. Le point d’arrêt indique le responsable, les éléments à relire et le journal à conserver. Une validation vague, cachée dans une interface, n’est pas une procédure fiable.
Examiner mémoire, cache et observabilité
Demandez combien de temps les messages, résultats d’outils et mémoires sont conservés, qui peut les consulter et comment les retirer. Distinguez la mémoire utile au parcours de la trace nécessaire pour enquêter sur un incident. Une équipe doit savoir où se trouve une information avant de promettre qu’elle peut la corriger ou la supprimer.
Testez un scénario de séparation : deux dossiers proches, deux utilisateurs et une reprise différée. Vérifiez que le second parcours ne réutilise pas une information du premier. Testez également un export de la trace, avec des droits réservés aux personnes qui en ont besoin.
Préparer les questions aux fournisseurs
Demandez une description du rôle de chaque partie, des sous-traitants impliqués, des zones de traitement, des mesures de sécurité et des modalités de suppression. Exigez une réponse liée à votre flux, pas seulement une page générale. Lorsque la réponse reste imprécise, marquez le point comme non vérifié dans la fiche de décision.
La documentation ne remplace pas l’analyse de votre cas. Elle sert à vérifier les capacités déclarées ; l’entreprise doit encore déterminer la finalité, les données nécessaires, les personnes autorisées et la durée de conservation pertinente.
Rejouer la carte après chaque changement
Une nouvelle intégration, une mémoire activée ou une consigne modifiée peut changer le parcours de données. Rejouez la carte et comparez les points de passage. Ajoutez un test lorsque la modification concerne une nouvelle catégorie de personne, un nouveau canal ou une nouvelle action.
Conservez une version datée de la carte et la décision associée. En cas d’incident, l’équipe pourra expliquer quel flux était prévu, ce qui s’est produit et quelle mesure a été prise. Cette traçabilité est plus utile qu’une affirmation générale selon laquelle le système serait « conforme ».
Décrire les accès par étape
Pour chaque outil, indiquez le compte utilisé, le rôle, les champs nécessaires et la durée d’accès. Un agent n’a pas besoin d’un accès global parce qu’une étape lit un seul objet. Si plusieurs outils sont appelés, décrivez la frontière entre leurs données et la raison du passage.
Testez une demande qui tente de faire lire un champ non nécessaire. Le système doit refuser ou ignorer ce champ sans le recopier dans une mémoire ou un journal. Testez aussi la révocation pendant une exécution et vérifiez que l’agent ne poursuit pas avec une autorisation supposée.
Préparer l’information destinée aux personnes
Lorsque l’agent interagit avec une personne, expliquez son rôle, la nature de l’assistance et la possibilité de demander une reprise humaine. La formulation doit correspondre au canal et au contexte. Vérifiez que la personne peut exprimer une correction ou un refus sans devoir connaître une commande spéciale.
Le parcours d’information doit rester cohérent avec le flux technique. Un message visible ne compense pas une collecte excessive ou une conservation mal expliquée. Reliez donc la présentation, la source utilisée, la finalité et la destination de la reprise dans la même fiche.
Analyser les incidents de mémoire
Un incident peut venir d’une mémoire trop longue, d’un mauvais rattachement de dossier, d’un journal accessible au mauvais rôle ou d’une copie laissée dans un outil secondaire. Reconstituez les étapes et identifiez la première frontière où l’information aurait dû être arrêtée.
Ajoutez un test de séparation après chaque correction. Deux demandes proches peuvent sembler identiques pour le modèle alors qu’elles concernent des personnes différentes. L’identité, le dossier et l’autorisation doivent être des éléments vérifiés, pas seulement déduits de la conversation.
Distinguer analyse et avis juridique
La carte de données aide à poser les questions et à repérer les responsabilités. Elle ne constitue pas à elle seule une décision juridique ou une preuve de conformité. Lorsque le traitement présente un risque particulier, faites intervenir les personnes compétentes et conservez leur décision dans le dossier.
Évitez les formulations absolues dans les consignes de l’agent. Préférez une règle opérationnelle observable : « demander une reprise lorsque la source n’est pas datée » ou « ne pas envoyer le document sans validation ». Cette précision protège l’utilisateur sans prétendre résoudre toutes les obligations applicables.
Revoir les sous-traitants et les changements
Un nouveau connecteur peut ajouter un destinataire, une zone de traitement ou une durée de conservation. Rejouez l’inventaire lorsque le fournisseur change son architecture, son modèle, ses journaux ou ses conditions d’usage. Demandez une information exploitable sur les changements qui affectent votre flux.
La fiche doit indiquer qui reçoit la notification, qui analyse l’effet et qui autorise la reprise. Sans ce rôle, une carte peut rester correcte sur le papier mais ne jamais être actualisée lorsque le parcours évolue.
Relier la carte aux droits des personnes
La carte doit permettre de répondre à une question simple : où une information apparaît-elle dans le parcours ? Listez l’entrée, les copies intermédiaires, les outils appelés, la mémoire, le journal et la sortie. Ajoutez la personne qui peut localiser chaque élément et celle qui peut décider de la suite.
Testez la réponse avec un dossier fictif qui traverse plusieurs outils. Demandez à l’équipe de retrouver les occurrences et de distinguer les copies actives des traces de sécurité. Si elle ne peut pas localiser une donnée, elle ne doit pas prétendre que le parcours est maîtrisé.
Vérifier les règles de suppression opérationnelles
Une demande de suppression ne se traite pas uniquement dans la base principale. Vérifiez les files d’attente, les exports, les mémoires, les journaux et les environnements de test. Décrivez ce qui est retiré, ce qui doit être conservé pour une raison documentée et qui valide la procédure.
Faites un essai de retrait sans utiliser de données réelles. Contrôlez ensuite les réponses que l’agent produit pour un cas proche. Il ne doit pas réutiliser une information supprimée par une copie restée active.
Conserver les preuves de cadrage
Archivez la finalité, la carte, les décisions de minimisation, les rôles, les tests négatifs et les changements. Une liste de fournisseurs ou une page de documentation ne remplace pas ce dossier. Il doit montrer comment l’organisation a relié la technologie à son propre parcours.
Quand le flux change, marquez la raison et les éléments réévalués. Cette version permet de distinguer une évolution du système d’un défaut présent depuis le début et d’organiser une revue proportionnée.
La fiche de contrôle avant mise en service
La fiche finale reprend la finalité, les catégories de données, les outils traversés, les comptes utilisés, les actions, la mémoire, les journaux, les droits de reprise et la procédure de retrait. Pour chaque point, indiquez la source de la décision et la date de vérification.
Ajoutez les cas négatifs et leurs sorties attendues. Une carte est exploitable lorsque l’équipe peut expliquer pourquoi le système répond, s’abstient, demande une précision ou transmet. Elle ne doit pas promettre une conformité générale ; elle documente un flux déterminé et ses limites.
Faites relire la fiche par une personne qui n’a pas configuré l’agent. Elle doit retrouver les copies possibles, les propriétaires et le geste de suspension. Si un élément dépend d’une connaissance orale, inscrivez-le comme travail restant avant l’ouverture.
La fiche doit distinguer ce qui a été observé de ce qui a été déclaré par un fournisseur. Ajoutez les questions non résolues et la date de la prochaine revue. Cette pratique permet de faire évoluer la carte sans transformer une analyse locale en affirmation générale.
Pour terminer, faites un exercice de reprise : désactivez un outil, retirez une source et demandez à l’équipe de reconstituer le parcours avec une donnée fictive. Elle doit identifier ce qui a été lu, ce qui a été conservé, ce qui peut être supprimé et qui décide de la suite. Cet exercice transforme la carte en procédure réellement utilisable.
Suivre un dossier nominatif sans le multiplier inutilement
Prenez un dossier fictif comportant un nom, une demande et un document joint. Faites-le passer par le parcours prévu, puis dessinez la carte à partir de ce qui se produit réellement : l’endroit où le contenu est lu, les outils qui reçoivent un extrait, les journaux créés et les personnes qui peuvent les consulter. Ne partez pas du discours général sur la solution. Une carte utile montre les objets concrets qui restent après l’action et le lien qui permet de les retrouver. Si une copie n’a ni propriétaire ni fonction identifiée, elle mérite une décision avant l’ouverture du flux.
Ajoutez un test de changement de fournisseur ou de connecteur. Sans transférer de donnée réelle, demandez ce qui devrait être exporté, arrêté, effacé ou repris à la main. L’exercice révèle souvent une dépendance à un paramètre, un historique de conversation ou une bibliothèque de fichiers que personne n’avait mis sur la carte. Notez aussi qui valide la nouvelle configuration et comment l’équipe informe les personnes concernées lorsque le parcours de leurs données change. L’objectif est d’éviter qu’une évolution technique crée un nouveau flux invisible dans la pratique quotidienne.
La carte doit enfin distinguer les informations nécessaires à l’action de celles qui ne le sont pas. Pour chaque champ, demandez : sert-il à préparer ce résultat, à vérifier une exception ou seulement à rendre la réponse plus confortable ? Cette question oblige l’équipe à justifier la présence de chaque donnée dans le parcours. Elle ne remplace pas l’analyse juridique propre à l’organisation ; elle fournit un support concret pour la mener, la mettre à jour et arrêter un traitement lorsque son utilité n’est plus établie.
Conservez la réponse à ces questions avec la date de revue et le responsable du flux. Quand une étape change, l’équipe peut comparer l’ancienne carte, vérifier l’incidence réelle et décider si une nouvelle analyse est nécessaire.
Lors de cette revue, faites relever les écarts entre la carte et la configuration : un nouveau champ, un journal ajouté, un accès provisoire ou une copie de test. Un écart ne prouve pas à lui seul un problème ; il doit être expliqué, attribué et intégré à la décision. Cette vérification donne à la PME une image fidèle du flux au lieu d’un schéma rassurant mais devenu incomplet.
FAQ
Une PME doit-elle tout bloquer avant de cartographier ?
Non. Elle doit commencer par un périmètre limité, des données fictives si possible et des permissions de lecture. La carte sert justement à choisir ce qui peut être testé sans ouvrir toute la chaîne.
Une donnée publique est-elle automatiquement libre pour un agent ?
Non. Le contexte de collecte, la finalité, les restrictions du site, la minimisation et les droits des personnes restent à examiner. La CNIL rappelle que l’accessibilité publique ne supprime pas l’analyse nécessaire.
Qui doit valider la carte ?
Le responsable du processus, la personne compétente en protection des données et la personne responsable de la sécurité ou de l’intégration doivent au minimum relire les flux qui les concernent. Une seule équipe ne voit pas toujours les copies et les dépendances externes.
La fiche de sortie à conserver
Terminez par une fiche d’une page : finalité, catégories de données, systèmes traversés, mémoire, journal, permissions, responsable de chaque étape, cas d’abstention, durée de conservation à confirmer, méthode de suppression, date de revue et incident à notifier. Cette fiche doit être compréhensible par le métier, pas seulement par l’intégrateur.
Pour transformer cette carte en test exploitable, consultez le protocole de comparaison de deux agents IA et le guide de préparation des connaissances support. Si vous voulez vérifier votre chaîne sur un cas réel, contactez Agents-IA.pro pour un audit de trente minutes.