Copilotes et agents autonomes : concilier gouvernance, conformité et souveraineté des données
Les copilotes d’IA et les agents autonomes passent rapidement du statut de démonstrateurs de productivité à celui de composants actifs du système d’information. Un copilote peut résumer une réunion, rechercher une procédure ou préparer un brouillon à partir des contenus auxquels un collaborateur a déjà accès. Un agent, lui, peut enchaîner des étapes, conserver une mémoire, interroger plusieurs services et agir au nom d’un utilisateur. Cette évolution ouvre des perspectives concrètes pour les équipes métiers, produit, IT et support. Elle impose aussi une discipline de pilotage : dès lors qu’une IA accède à des documents, à des données clients, à des outils collaboratifs ou à des applications métier, la question n’est plus seulement « que peut-elle produire ? », mais « dans quelles limites peut-elle lire, décider, transmettre et agir ? ».
Pour un chef de projet web ou IT, concilier gouvernance, conformité et souveraineté des données ne consiste pas à ralentir l’adoption de l’IA. C’est la condition pour la rendre durable, explicable et défendable devant la direction, les métiers, la sécurité et les fonctions juridiques. Le sujet exige de relier les choix d’architecture aux droits d’accès, à la qualité documentaire, aux règles de conservation, aux flux de données et au niveau d’autonomie réellement accordé. Les évolutions européennes et les positions récentes de la CNIL rendent cette approche particulièrement actuelle : l’IA se gouverne désormais comme une capacité transverse, avec des exigences qui portent autant sur les données et les opérations que sur le modèle lui-même.
Copilote et agent autonome : une différence qui change l’analyse des risques
Employer indifféremment les mots « copilote » et « agent » conduit à sous-estimer certains risques. Un copilote conversationnel reste généralement dans une logique d’assistance : il répond à une demande, propose un contenu, synthétise des informations ou aide à rechercher des connaissances. Sa valeur dépend déjà de la qualité de ses sources et du périmètre de données auquel il est connecté. Mais son action est, en principe, plus directement déclenchée et supervisée par l’utilisateur. La gouvernance doit alors s’intéresser aux droits hérités, aux contenus récupérés, aux prompts, aux réponses générées et aux possibilités de partage ou d’export.
L’IA agentique ajoute une couche de complexité. Dans une note exploratoire publiée le 20 juillet 2026, la CNIL et le CIANum soulignent notamment l’autonomie décisionnelle, la mémoire persistante et la capacité des agents à interagir avec plusieurs services. Ces caractéristiques peuvent permettre à un agent d’interpréter un objectif, de choisir une séquence d’actions, de consulter différentes sources puis d’exécuter des opérations. Lorsqu’un système agit au nom d’un utilisateur, l’organisation doit pouvoir répondre à des questions très opérationnelles : quels outils l’agent peut-il appeler, quelles données peut-il conserver, dans quelles conditions peut-il déclencher une action, et qui est responsable de son paramétrage ?
La bonne pratique consiste donc à qualifier chaque cas d’usage avant de choisir les contrôles. Un assistant de rédaction connecté à une base documentaire ne présente pas le même profil qu’un agent capable de créer un ticket, de modifier une fiche client ou de transmettre un fichier. Il est utile de décrire, pour chaque solution, le niveau d’autonomie, les connecteurs activés, la mémoire, les actions autorisées, les données manipulées et les validations humaines requises. Cette fiche de qualification crée un langage commun entre sécurité, conformité, métiers et équipes techniques. Elle évite aussi de traiter un agent comme un simple chatbot alors que sa portée fonctionnelle et les conséquences de ses actions sont très différentes.
Un cadre européen multi-couches pour l’IA, les données et le cloud
La conformité des copilotes et des agents ne se résume pas à une unique réglementation. L’approche européenne devient clairement multi-couches. L’AI Act traite notamment de la sûreté, de la robustesse et de la gouvernance des données. Sa mise en œuvre entre dans une phase concrète : la Commission européenne rappelle l’existence du Pacte IA, du Code of Practice GPAI et du modèle de résumé public des données d’entraînement. Elle s’appuie également sur une gouvernance associant l’AI Board, le Scientific Panel et l’Advisory Forum. Pour les organisations, le message est clair : les exigences relatives à l’IA doivent être intégrées dans les processus projet et non examinées uniquement à la veille d’une mise en production.
À cette première couche s’ajoutent les règles de protection des données et les attentes des autorités de contrôle. En février 2025, une déclaration commune relayée par la CNIL, portée par 20 autorités de protection des données, a recommandé d’intégrer les principes de protection des données dès la conception et d’établir des cadres internes robustes de gouvernance des données. Cette position ne demande pas de choisir entre innovation et vie privée. Elle place au contraire la protection des données comme un facteur de qualité pour les systèmes d’IA : les données doivent être connues, encadrées, accessibles de manière proportionnée et gérées selon des règles compréhensibles.
Enfin, la souveraineté du cloud et de l’IA devient un axe à part entière. Le 28 août 2026, la Commission a présenté le Cloud and AI Development Act, ou CADA, afin de renforcer les capacités européennes de cloud et d’IA. Le texte est présenté comme un complément à l’AI Act sur la souveraineté des services de calcul cloud et IA. Son cadre unique d’évaluation couvre notamment les dimensions juridique, donnée et IA, opérationnelle, chaîne d’approvisionnement, sécurité et conformité. Cette grille est précieuse pour un projet : elle rappelle qu’un déploiement ne peut pas être qualifié de souverain sur la seule base de la localisation d’un datacenter ou de la nationalité d’un fournisseur.
Commencer par la donnée : cartographier, classifier et réduire l’exposition
La gouvernance d’un copilote commence rarement par le paramétrage de l’outil ; elle commence par l’état réel des données. Un assistant connecté à un espace documentaire respecte souvent les permissions déjà en place, mais il rend les informations plus facilement trouvables, synthétisables et réutilisables. Cette capacité peut révéler des défauts historiques de gouvernance documentaire : dossiers trop largement partagés, documents anciens toujours accessibles, absence d’étiquetage, fichiers contenant des informations sensibles dans des emplacements généralistes. L’IA ne crée pas nécessairement ces problèmes ; elle peut néanmoins les rendre plus visibles et plus faciles à exploiter.
Avant un pilote, il est pertinent de produire une cartographie pragmatique des sources : espaces collaboratifs, messageries, CRM, outils de tickets, bases de connaissances, GED, entrepôts de données et interfaces externes. Pour chaque source, l’équipe projet peut identifier les catégories de données, le propriétaire métier, les droits d’accès, les règles de conservation et la présence éventuelle de données personnelles ou sensibles. L’objectif n’est pas de construire une documentation théorique exhaustive. Il s’agit de savoir quelles données pourront être recherchées, résumées, copiées dans une réponse ou transmises à un autre service par l’IA.
La classification est ensuite le lien entre cette cartographie et les contrôles techniques. Les documents les plus sensibles doivent pouvoir être identifiés afin de déclencher des règles de prévention de fuite, de partage ou de rétention adaptées. Les supports Microsoft consacrés à la gouvernance de Copilot évoquent explicitement la surveillance des prompts IA, la journalisation des interactions, la conservation ou la suppression des échanges et la prévention des partages de données sensibles dans les applications génératives. Ces possibilités ne dispensent pas d’une politique interne : il faut décider quelles informations ne doivent jamais être saisies, quelles données peuvent être consultées mais non exportées, et quels usages doivent faire l’objet d’une validation renforcée.
Souveraineté des données : évaluer les garanties au-delà de la résidence
La résidence des données est importante, mais elle ne suffit pas à définir la souveraineté. Les organisations régulées recherchent des garanties sur la localisation, la juridiction, la sécurité opérationnelle et la conformité. Microsoft annonce par exemple un traitement « in-country » des interactions Microsoft 365 Copilot prévu dans 15 pays, avec un déploiement par étapes entre 2025 et 2028. Cette offre répond explicitement aux besoins de secteurs gouvernementaux et fortement régulés. Pour un décideur, cette information doit être examinée comme une capacité parmi d’autres : elle ne remplace ni l’analyse des flux, ni l’étude des engagements contractuels, ni la vérification du périmètre exact de traitement concerné.
Une évaluation robuste doit distinguer les différentes données et opérations. Où sont hébergés les contenus de l’entreprise ? Où sont traitées les interactions, les prompts et les réponses ? Quels journaux sont produits, combien de temps sont-ils conservés et dans quel environnement ? Les données transitent-elles par des services tiers, des connecteurs, des services de recherche ou des fonctions de navigation web ? Quel droit est applicable, quelles entités peuvent administrer le service et quelles dépendances existent dans la chaîne d’approvisionnement ? Ces questions transforment un débat abstrait sur la souveraineté en une revue d’architecture exploitable.
Le cadre de souveraineté cloud et IA associé au CADA donne justement une méthode de lecture utile. Ses catégories relatives au juridique, à la donnée et l’IA, aux opérations, à la chaîne d’approvisionnement, à la sécurité et à la conformité peuvent être converties en critères de sélection fournisseur et en exigences de recette. La Commission européenne affirme par ailleurs, dans son agenda data, que la souveraineté des données est au cœur de l’avenir numérique de l’Union européenne. Pour une entreprise, cela implique de documenter les arbitrages plutôt que de promettre une souveraineté absolue. Le niveau recherché doit être proportionné au cas d’usage, aux données et aux obligations de l’organisation.
Concevoir des garde-fous techniques avant l’ouverture à grande échelle
Un déploiement responsable privilégie des contrôles préventifs. La doctrine de protection des données et les outils de gouvernance IA convergent sur ce point : il est préférable de réduire la probabilité d’une fuite, de détecter un usage non conforme et de disposer de traces fiables, plutôt que de découvrir l’incident après sa diffusion. Dans Microsoft 365, les guides 2026 décrivent l’usage combiné de Purview, Defender, Entra et d’un Security Dashboard for AI pour gouverner les données Copilot, prévenir les fuites, traiter le risque interne et soutenir la conformité. L’intérêt d’une telle approche est d’articuler la sécurité des identités, la protection des données et la supervision des usages d’IA.
Les contrôles doivent être construits par couches. La première couche est l’identité : authentification, groupes, moindre privilège et séparation des rôles d’administration. La deuxième porte sur les données : étiquettes, règles de partage, protections contre l’exfiltration et accès conditionnels selon la sensibilité. La troisième concerne l’IA elle-même : périmètre des connecteurs, restrictions sur les actions disponibles, surveillance des interactions et exigences de validation humaine. Enfin, les journaux et alertes permettent de relier une action à un contexte, à une identité et à une source. Cette architecture évite de confier toute la maîtrise du risque à une simple charte d’usage.
Le principe de contrôle au runtime est particulièrement structurant. Microsoft indique que Purview peut sécuriser Copilot au runtime ainsi que les données Microsoft 365 auxquelles Copilot fait référence. En termes de projet, cela relie directement la qualité de la gouvernance documentaire à la sécurité de l’IA : une règle de DLP, une étiquette de confidentialité ou un droit d’accès n’est pas un sujet périphérique, mais une partie du fonctionnement du copilote. Les équipes doivent tester ces garde-fous avec des scénarios représentatifs, y compris des demandes ambiguës, des tentatives de partage de données sensibles et des utilisateurs disposant de droits différents.
Gouverner les agents : permissions, mémoire, actions et supervision humaine
Les agents autonomes exigent un modèle d’autorisation plus précis que les assistants classiques. Il faut éviter de leur donner un accès global à des outils au motif qu’ils doivent être utiles. Chaque capacité doit être explicitement justifiée : lecture d’un référentiel, création d’un brouillon, ouverture d’un ticket, mise à jour d’un statut, envoi d’une notification ou lancement d’un flux. Le principe du moindre privilège s’applique aux agents comme aux utilisateurs humains. Un agent qui prépare une réponse peut ne pas avoir à l’envoyer ; un agent qui détecte un incident peut ne pas avoir à fermer le dossier sans validation.
La mémoire persistante est un second point de vigilance. La note CNIL/CIANum de juillet 2026 met en avant cette caractéristique parmi les éléments qui compliquent la maîtrise des risques. Un projet doit préciser ce qui peut être mémorisé, pour quelle finalité, pendant quelle durée et avec quelles possibilités d’effacement ou de révision. Il est aussi essentiel de distinguer la mémoire de travail nécessaire à l’exécution d’une tâche, l’historique des interactions et la connaissance durable qui serait réutilisée ultérieurement. Sans cette distinction, les équipes risquent de conserver par défaut des informations qu’elles n’auraient pas accepté de stocker dans un système métier classique.
La supervision humaine ne doit pas être une formule générale ; elle doit être traduite en points de contrôle. Pour les actions ayant un impact métier, juridique, financier, RH ou sur des données sensibles, un mécanisme d’approbation explicite doit être prévu. Les seuils peuvent varier selon le contexte : consultation, recommandation, préparation, exécution réversible ou exécution difficilement réversible. Il faut aussi organiser l’arrêt d’urgence, la révocation des accès et la désactivation d’un connecteur lorsqu’un comportement inattendu apparaît. Cette capacité de reprise en main est déterminante pour inspirer confiance aux métiers et pour démontrer que l’autonomie reste encadrée.
Mettre en place une gouvernance de projet qui relie IT, métier, sécurité et conformité
La gouvernance ne doit pas reposer sur une seule équipe. Un déploiement de copilote ou d’agent touche les propriétaires de données, les utilisateurs métier, l’IT, la cybersécurité, la conformité, le juridique et, selon les cas, le DPO. Le chef de projet a un rôle de coordination : il transforme les exigences parfois dispersées en décisions, jalons et livrables compréhensibles. Un comité de gouvernance peut examiner les cas d’usage, les données concernées, les règles d’accès, le niveau d’autonomie, les exigences de souveraineté et les résultats de tests avant toute généralisation.
Une matrice de responsabilités est utile pour éviter les zones grises. Le métier doit assumer la finalité et la pertinence opérationnelle du cas d’usage. Le propriétaire de données doit valider le périmètre de sources. L’IT et la sécurité définissent l’intégration, les identités, les contrôles et la supervision. Les fonctions conformité et protection des données apportent leur analyse sur les règles applicables et les garanties attendues. Le fournisseur, quant à lui, doit être évalué sur ses engagements, sa documentation et ses capacités techniques. Cette répartition ne dilue pas la responsabilité ; elle rend les décisions traçables et permet d’arbitrer plus tôt.
La sécurité des données mérite une attention constante. Dans son rapport annuel 2025 publié en 2026, la CNIL indique consacrer la moitié de ses contrôles et actions répressives à la sécurité des données en 2026, avec un focus explicite sur l’IA, la cybersécurité et la coopération européenne. Cette orientation plaide pour une gouvernance qui produit des preuves : registre des cas d’usage, analyse des flux, décisions d’habilitation, résultats de tests, règles de rétention, procédures d’incident et revues périodiques. Une politique écrite sans contrôle effectif est insuffisante ; à l’inverse, des réglages techniques sans responsabilité métier clairement définie le sont tout autant.
Déployer par étapes et mesurer une adoption qui reste maîtrisée
Un déploiement progressif permet de concilier vitesse d’apprentissage et maîtrise des risques. La première étape consiste à sélectionner quelques cas d’usage dont la valeur et les données sont bien comprises : recherche dans une base de connaissances validée, préparation de synthèses à partir de documents accessibles, assistance à la rédaction ou support interne encadré. Les cas impliquant une forte autonomie, des données particulièrement sensibles ou une action directe dans des systèmes de production peuvent être étudiés dans un second temps. Cette priorisation ne repose pas sur la popularité d’un outil, mais sur une analyse conjointe de la valeur, de l’exposition des données et de la réversibilité des actions.
Chaque pilote doit disposer de critères d’acceptation précis. Il est pertinent de vérifier la qualité des réponses, le respect des droits d’accès, le comportement face à des données étiquetées, la capacité à empêcher ou signaler un partage inapproprié, la disponibilité des journaux et le bon fonctionnement des validations humaines. Les utilisateurs pilotes doivent être formés à la fois aux possibilités et aux limites du système : vérifier les résultats, ne pas saisir de données non autorisées, signaler les comportements inattendus et comprendre qu’une réponse convaincante n’est pas automatiquement exacte ou exploitable. Une adoption responsable suppose que les utilisateurs deviennent des acteurs de la sécurité.
Enfin, les indicateurs doivent mesurer autre chose que le nombre d’utilisateurs ou de requêtes. Un tableau de bord de gouvernance peut suivre le nombre de cas d’usage approuvés, les sources de données connectées, les incidents ou alertes, les exceptions accordées, les revues de droits réalisées, les demandes d’effacement liées aux interactions lorsque cela s’applique, et le taux de formation des populations concernées. Ces éléments permettent de montrer que la performance et la conformité progressent ensemble. Ils aident également à décider si un cas d’usage doit être étendu, ajusté, mis sous surveillance renforcée ou arrêté.
Copilotes et agents autonomes peuvent apporter un gain réel aux organisations, à condition d’être traités comme des produits et des services gouvernés, non comme de simples fonctionnalités activées dans une suite logicielle. La distinction entre assistance et autonomie, la cartographie des données, les contrôles au runtime, l’évaluation de souveraineté et la supervision humaine forment un socle cohérent. Les textes, doctrines et initiatives européennes récentes confirment que ce socle doit relier l’AI Act, la protection des données et la souveraineté des infrastructures cloud et IA.
La démarche la plus crédible est pragmatique : commencer par des usages délimités, documenter les flux et les responsabilités, tester les garde-fous, puis élargir uniquement lorsque les preuves sont suffisantes. Pour les responsables de projets web et IT, cette méthode transforme une contrainte apparente en avantage de pilotage. Une IA dont les données, les permissions, les journaux, les limites d’action et les garanties de traitement sont maîtrisés sera plus facile à adopter par les équipes, plus robuste face aux évolutions réglementaires et plus digne de confiance pour l’entreprise comme pour ses clients.
