🚀 Agent IA en entreprise : sécurité & gouvernance
Découvrez Arc (ServiceNow & Nvidia) : usages en entreprise, sécurité multicouche, limites et gouvernance. Évaluez la sécurité des agents IA : apprenez vite.
Arc, l'agent IA de ServiceNow et Nvidia : la sécurité avant l'autonomie
Un agent d'intelligence artificielle qui consulte des courriels, lit des comptes rendus de réunion et agit dans les outils d'une entreprise peut vraiment faire gagner du temps. Mais il peut aussi toucher à des données sensibles, déclencher une action non autorisée ou continuer à exécuter une tâche malgré une mauvaise configuration. C'est précisément le risque que ServiceNow et Nvidia disent vouloir réduire avec Arc, un agent pensé pour le travail quotidien.
Annoncé en mai, Arc est présenté comme un agent personnel persistant : il conserverait du contexte et « apprendrait » au fil des interactions. Selon les deux entreprises, il peut fonctionner localement sur un ordinateur de bureau ou dans Nvidia OpenShell. La promesse centrale repose sur plusieurs niveaux de contrôle : politiques d'accès, environnement d'exécution isolé et mécanismes appliqués au niveau matériel. L'idée est simple : éviter que la sécurité dépende uniquement du logiciel.
Sauf qu'une architecture décrite par les fournisseurs n'est pas, à elle seule, une preuve. La question, pour une entreprise française ou européenne, est très concrète : quelles données l'agent consulte, quelles actions il peut réellement faire, et comment les équipes peuvent l'arrêter ou vérifier ce qu'il fait. Voici ce que l'approche d'Arc change, ce qu'elle ne garantit pas, et les points à vérifier avant tout déploiement.
Arc : un agent pensé pour le travail quotidien
Arc n'est pas présenté comme un simple assistant qui répond à une question dans une fenêtre de discussion. L'objectif est plutôt de gérer des tâches suivies dans le temps, à partir d'outils utilisés au quotidien : la messagerie et Microsoft Teams en particulier. L'agent peut analyser des courriels et des notes de réunion pour faire remonter des actions à traiter. Il est aussi conçu pour garder de la mémoire et des « compétences » afin d'être plus efficace au fil des échanges.
Cette différence compte. Un chatbot répond à une demande ponctuelle. Un agent, lui, peut recevoir un objectif, consulter plusieurs sources, choisir une étape suivante et intervenir dans plusieurs systèmes. Il peut donc être plus utile, mais aussi plus risqué : une erreur ne reste pas forcément une réponse incorrecte. Elle peut se traduire par une action dans un outil métier.
Des tâches utiles, mais dépendantes des permissions
Les exemples mis en avant par ServiceNow et Nvidia restent plutôt « familiers » : organiser le travail à partir de la boîte de réception, repérer des éléments d'action dans un compte rendu, interagir avec des services autorisés. On est sur des cas d'usage plausibles dans une équipe projet, une fonction support ou une direction commerciale.
Mais la valeur ne vient pas du fait que l'agent puisse « tout faire ». Tout dépend du périmètre qu'on lui donne. Un agent qui résume un courriel n'a pas besoin des mêmes droits qu'un agent autorisé à envoyer une réponse, modifier un dossier client ou créer une demande dans un outil interne. Chaque capacité supplémentaire élargit le risque et le nombre de tests à mener.
Pour une entreprise française, le bon point de départ n'est donc pas une promesse générale d'automatisation, mais un processus défini au millimètre. Par exemple : l'agent doit-il pouvoir extraire des tâches d'un compte rendu sans envoyer de message ? Peut-il proposer une réponse à un fournisseur sans l'expédier ? Peut-il préparer une demande interne qui devra ensuite être validée par un salarié ? Ces distinctions permettent de mesurer le gain de temps sans donner d'emblée une autonomie disproportionnée.
Une exécution locale ne veut pas dire « zéro transfert »
Les entreprises indiquent qu'Arc est conçu pour tourner efficacement sur les nouveaux appareils Nvidia RTX Spark. Il peut s'exécuter localement sur le poste d'un employé, ou dans Nvidia OpenShell sur un appareil dédié. Elles décrivent aussi une logique « au besoin » : sur certains cas, on ferait appel à des modèles de pointe, pendant que les données resteraient locales autant que possible.
« Autant que possible » est précisément le genre d'expression qu'il faut lire sans la flatter. Avant de tester ou de déployer, il faut identifier : quelles opérations restent réellement locales, à quel moment un modèle externe est sollicité, quelles données sont transmises, et quelles règles s'appliquent ensuite (conservation, traitement, etc.). Le fait que l'agent s'exécute « localement » ne suffit pas à reconstituer le parcours complet des informations.
Autre point : la disponibilité annoncée concerne Mac, et Windows est présenté comme à venir. Arc peut aussi s'exécuter dans OpenShell sur un appareil dédié. Pour un projet pilote, ce sont des contraintes qui changent vraiment la donne : postes compatibles, gestion du parc, support aux utilisateurs, et coûts d'exploitation. La disponibilité générale annoncée par les fournisseurs ne signifie pas forcément que le produit correspond déjà à votre environnement.
Une sécurité construite sur plusieurs couches
ServiceNow et Nvidia mettent en avant une architecture où la sécurité est répartie entre des politiques côté entreprise, l'environnement d'exécution et des contrôles au niveau matériel. L'idée est de ne pas compter uniquement sur la capacité de l'agent à respecter des règles formulées « dans l'absolu ». Des composants distincts doivent limiter les ressources que l'agent peut utiliser et bloquer certaines actions.
Dans le dispositif décrit, ServiceNow Super Intelligence Control Tower sert à définir et administrer les politiques. Nvidia OpenShell applique ces politiques pendant l'exécution. En pratique, il faut que les équipes puissent préciser : quels systèmes sont accessibles, quelles API l'agent peut appeler, et quelles données il peut lire. L'enjeu est de transformer une règle en restriction réelle, vérifiable, puis maintenue dans le temps. Par exemple : « l'agent ne doit pas accéder aux dossiers de paie » doit devenir une contrainte technique, pas juste une consigne.
Le rĂ´le du Control Tower et d'OpenShell
Le Control Tower est présenté comme l'endroit où l'entreprise définit ses règles et son niveau de tolérance au risque. OpenShell intervient au moment où l'agent agit, pour restreindre son comportement si nécessaire. Cette séparation est logique : une politique n'est utile que si elle s'applique effectivement aux opérations.
Les fournisseurs mentionnent aussi AI Passport : un mécanisme qui associe à un agent un ensemble de règles sur les services accessibles. Dans cette architecture, le passeport relie ce que ServiceNow administre aux points de contrôle gérés par Nvidia. L'objectif est d'aider les composants de sécurité à déterminer si une action reste autorisée.
Concrètement, cela peut faciliter la révocation : si le Control Tower invalide le passeport d'un agent, OpenShell peut contenir la tâche concernée dans un environnement isolé afin qu'elle soit examinée. La suspension est décrite comme ciblée : d'autres actions autorisées pourraient continuer, plutôt que d'obliger au redémarrage complet.
Le contrôle au niveau matériel : un renfort, pas une baguette magique
Nvidia BlueField est présenté comme capable d'appliquer une révocation à très grande vitesse, avant que l'agent n'achève une action. C'est censé réduire la dépendance à un seul logiciel, qui pourrait être contourné ou compromis. Sur le papier, c'est un vrai plus par rapport à une sécurité basée uniquement sur des instructions données au modèle.
Mais le matériel ne « comprend » pas vos intérêts métier. Il exécute des règles définies à l'avance. Si les droits sont trop larges, si les données classifiées sont mal identifiées, ou si la politique est incomplète, une application rapide peut aussi verrouiller (ou interrompre) quelque chose... de manière incorrecte. En bref : la sécurité dépend autant de la qualité de la configuration, de la gestion des identités et des processus de révision.
Les annonces des fournisseurs décrivent une architecture et des objectifs. Elles ne remplacent pas une évaluation indépendante, des tests de résistance et une analyse de l'intégration avec vos systèmes existants. Pour les détails, il faut se référer aux informations publiées par ServiceNow et Nvidia, puis les confronter à votre réalité.
Ce que l'approche change, et ce qu'elle ne garantit pas
Arc répond à une faiblesse fréquente des agents : une instruction en langage naturel (« ne fais pas X ») n'est pas une frontière technique fiable. Dire à un agent de ne pas consulter un système ne remplace pas une restriction qui lui interdit réellement l'accès. En répartissant les contrôles entre politiques, exécution et matériel, les fournisseurs cherchent à réduire le risque d'actions hors périmètre.
C'est une direction utile, mais elle ne supprime pas les arbitrages. Des permissions plus limitées rendent le système plus contrôlable, mais peuvent aussi multiplier les blocages et rendre certaines tâches difficiles à mener jusqu'au bout. À l'inverse, des accès plus larges fluidifient certains processus, tout en augmentant les conséquences si quelque chose tourne mal ou si un compte est compromis. Le « bon » niveau n'est pas l'autonomie maximale : c'est l'autonomie qui apporte un bénéfice mesurable sans créer un risque que l'organisation n'a pas les moyens de gérer.
Les questions de gouvernance et de conformité restent entières
Pour une organisation européenne, il faut regarder le déploiement à travers vos obligations, notamment en matière de protection des données. Le fait que l'exécution soit locale ou qu'il existe un contrôle matériel ne suffit pas à démontrer la conformité au RGPD. Il faut analyser : les finalités, les catégories de données, les accès, les transferts éventuels, les durées de conservation, et les responsabilités respectives du fournisseur et du client.
Il faut aussi décider qui « porte » l'agent en production : qui approuve ses permissions ? Qui reçoit une alerte quand l'agent tente une action bloquée ? Qui consulte les journaux ? Qui peut suspendre l'agent si quelque chose sort du cadre ? Sans réponse claire, la sécurité technique peut donner l'illusion de la maîtrise, sans qu'il y ait un contrôle opérationnel réel.
Et attention : les données d'entreprise peuvent se retrouver dans des contextes inattendus. Un courriel contient une pièce jointe confidentielle. Une note de réunion mentionne des données personnelles. Un message cherche à influencer l'agent avec de fausses instructions. L'architecture doit donc être testée avec des scénarios représentatifs : informations ambiguës, contradictions, et contenus potentiellement malveillants.
Enfin, la mémoire persistante est à la fois utile et sensible. Elle rend l'agent plus performant, mais crée une nouvelle surface de risque. Il faut clarifier : quelles informations sont mémorisées, pendant combien de temps, comment elles sont corrigées ou supprimées, et si la mémoire est partagée entre utilisateurs. Sans ça, on ne peut pas relier « mémoire » à une gestion des risques sérieuse.
Conclusion : Ă©valuer le contrĂ´le autant que l'autonomie
Arc met en avant une réponse intéressante à un enjeu central des agents IA : limiter les accès et encadrer les actions pendant l'exécution, plutôt que de s'en remettre uniquement à des consignes « dans le logiciel ». L'association des politiques d'entreprise, d'OpenShell, d'AI Passport et des contrôles matériels annoncés par Nvidia mérite d'être étudiée par les organisations qui envisagent des agents persistants.
Mais l'architecture ne remplace ni une gouvernance claire, ni une validation dans vos conditions réelles d'utilisation. Avant de déployer, choisissez un périmètre limité, cartographiez les données et les permissions, mesurez le gain net et testez des scénarios de révocation et d'erreur. Commencez par des actions réversibles, avec validation humaine ; élargissez seulement si les résultats tiennent la route.
La vraie question n'est pas de savoir si un agent peut agir seul. C'est de savoir : quelles actions il peut faire, comment l'entreprise peut les interrompre, et si le bénéfice reste supérieur au coût du contrôle. Pour aller plus loin, comparez les engagements des fournisseurs à votre analyse de risques et aux exigences de vos équipes sécurité, juridique et métier.
Comment évaluer Arc avant un déploiement
La méthode la plus saine consiste à traiter Arc comme un composant métier connecté à vos systèmes, pas comme une application qu'on « installe et ça marche ». Le pilote doit répondre à une question précise : quelle tâche améliorer, avec quelles données, quelles permissions et quel contrôle humain ? Sans définition, on risque de confondre une démo séduisante avec un outil réellement exploitable.
Une grille de décision pour le projet pilote
Avant d'ouvrir l'accès à des utilisateurs, documentez au minimum :
Le périmètre initial doit rester assez étroit pour être auditable. Commencez par préparer des comptes rendus ou détecter des tâches à suivre, sans autoriser l'agent à envoyer des messages ni à modifier des données métier. Si les résultats sont solides, élargissez progressivement, mais uniquement avec un test et une validation à chaque étape.
Les indicateurs qui comptent vraiment
Le nombre de tâches « faites » ne suffit pas. Regardez aussi : le taux d'actions acceptées sans correction, les erreurs qui auraient eu un impact réel, le temps de vérification humaine, et la fréquence des blocages injustifiés. Un agent peut produire vite... tout en déplaçant le travail vers une relecture intégrale.
Suivez aussi les coûts complets : matériel compatible, intégration, administration des politiques, surveillance, traitement des incidents. Le fait qu'une partie du traitement soit locale ne rend pas l'exploitation gratuite. À petite échelle, ça peut paraître simple ; à plus grande échelle, la gestion des identités, des règles et des exceptions devient un sujet à part entière.
Arc est intéressant parce qu'il tente d'aller au-delà de la seule sécurité « logicielle » de l'agent. Reste que sa pertinence dépendra de la précision des mécanismes, de leur intégration avec vos outils, et de la capacité de vos équipes à les administrer correctement. Pour élargir la réflexion sur la protection des données, consultez aussi les ressources de la CNIL.