La confiance dans l’IA vient de chuter de 17 points. La gouvernance des identités non humaines en est la cause.

Une baisse de 17 points de la maturité de l’IA déclarée peut sembler inquiétante. Ce n’est pas le cas. C’est ce qui se produit lorsque les responsables IT cessent d’évaluer leurs programmes d’IA sur la base de leurs ambitions et commencent à les évaluer sur la base de preuves concrètes.

L’enquête sur les tendances T3 2026 de VentureBeat, menée auprès de 800 responsables IT aux États-Unis et au Royaume-Uni, révèle que la part des répondants qualifiant leur organisation de « mature » en matière de déploiement de l’IA est passée de 40 % il y a six mois à 23 % aujourd’hui. Ce n’est pas le signe d’une dégradation des programmes d’IA. C’est le signe que les responsables ont enfin examiné de près la réalité : des agents déployés sans propriétaire, des autorisations jamais réévaluées, et une main-d’œuvre non humaine qui a grandi plus vite que quiconque ne l’a suivie.

Le chiffre qui motive cette réévaluation est sans appel. Les identités non humaines, c’est-à-dire les comptes de service, les clés API et les agents d’IA agissant pour le compte des employés et des systèmes, sont désormais plus nombreuses que les utilisateurs humains dans 83 % des organisations interrogées par VentureBeat. Et le contrôle le moins souvent mis en place pour les gérer, la gouvernance des identités non humaines, n’atteint que 21 % d’adoption, soit le taux le plus bas de toutes les pratiques de sécurité de l’IA étudiées. Ces deux chiffres réunis dressent un constat sans équivoque : la plupart des entreprises comptent plus d’identités machines que de personnes, et moins d’une sur quatre dispose d’un véritable programme de gouvernance pour les encadrer.

C’est aussi la raison pour laquelle cette enquête intéresse Kiteworks. Kiteworks secure data exchange offre aux organisations un point de contrôle gouverné pour les échanges de données sensibles entre humains, systèmes et agents d’IA, au lieu de laisser ce trafic se disperser via des identifiants partagés et des connexions non gouvernées. Cette baisse de confiance n’est pas un revers. C’est le signal que le vrai travail, à savoir combler le fossé des identités non humaines, ne fait que commencer.

Résumé des points clés

1. Les auto-évaluations de maturité de l’IA se sont effondrées en six mois.

L’enquête T3 2026 de VentureBeat menée auprès de 800 responsables IT aux États-Unis et au Royaume-Uni montre que la part qualifiant leur organisation de « mature » en matière de déploiement de l’IA est passée de 40 % à 23 %, soit une baisse de 17 points, preuve que les responsables évaluent enfin leurs programmes à l’aune de la réalité et non plus de l’ambition.

2. Les identités non humaines ont déjà dépassé les utilisateurs humains.

Dans 83 % des organisations interrogées, les identités machines et agents sont désormais plus nombreuses que les humains en poste, alors que les contrôles conçus pour gérer les comptes humains n’ont jamais été pensés pour une main-d’œuvre générant de nouvelles identités à la chaîne.

3. La gouvernance de ces identités est le contrôle le moins avancé.

Seules 21 % des organisations disposent d’une gouvernance des identités non humaines, ce qui en fait la principale lacune du modèle de maturité de la sécurité de l’IA de VentureBeat, et celle que la plupart des entreprises n’ont même pas encore envisagée.

4. La maturité est directement corrélée à la capacité de passer à l’échelle.

Les organisations appartenant au niveau de maturité le plus élevé de l’enquête étaient cinq fois plus susceptibles de déclarer n’avoir aucun obstacle à l’expansion du déploiement de leurs agents d’IA, faisant de la gouvernance un levier de croissance plutôt qu’une simple case à cocher pour la conformité.

5. Le partage d’identifiants est la norme, pas l’exception.

Faute de contrôles d’accès et d’identités par agent, la plupart des organisations continuent de faire passer les agents d’IA par des comptes de service partagés ou des identifiants humains, effaçant toute traçabilité dès qu’un incident survient.

Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?

Pour en savoir plus :

La baisse de 17 points : qu’est-ce qui a changé entre deux enquêtes à six mois d’intervalle ?

Il y a six mois, 40 % des responsables IT interrogés par VentureBeat qualifiaient le déploiement de l’IA dans leur organisation de mature. Dans l’enquête T3 2026, ce chiffre tombe à 23 %. Pris isolément, ce recul de 17 points peut donner l’impression que les programmes d’IA régressent. Mais à la lumière de tout ce qui a changé en six mois, l’interprétation est toute autre.

La plupart des entreprises n’ont pas ralenti leurs déploiements d’IA sur cette période. Elles les ont accélérés. Les départements ont continué à déployer des agents pour le support client, l’aide au développement, le traitement documentaire, la recherche interne, bref, pour tout cas d’usage justifiable. Les fournisseurs ont continué à activer par défaut des fonctionnalités agentiques. Et à chaque nouveau déploiement, une identité non humaine supplémentaire s’est ajoutée à l’environnement, souvent sans demande formelle, sans validation, ni désignation de propriétaire. Dans ce contexte, la confiance devait logiquement baisser, car les personnes les plus proches de ces déploiements constataient que la gouvernance ne suivait pas le rythme effréné de la création d’identités.

C’est la lecture la plus saine des données. Un score de maturité qui continuerait de grimper alors que la gouvernance des identités non humaines stagne à 21 % d’adoption serait en réalité un très mauvais signal, car cela signifierait que les responsables IT évaluent leurs programmes selon des critères ignorant la catégorie de risques à la croissance la plus rapide. Un score qui baisse à mesure que les responsables découvrent l’étendue du chemin restant à parcourir signifie que l’évaluation elle-même est devenue plus rigoureuse. VentureBeat le formule bien : cette baisse traduit une auto-évaluation honnête plutôt que confiante, étape indispensable pour combler le fossé mis en lumière par l’enquête.

Cette nuance est essentielle pour la façon dont les équipes sécurité et conformité doivent présenter ces résultats en interne. Un membre du conseil d’administration ou un DAF qui lit « la maturité de l’IA a chuté de 17 points » sans contexte peut y voir la preuve que les investissements dans l’IA ne portent pas leurs fruits. L’interprétation la plus juste, à défendre lors des discussions budgétaires, est que le programme de gouvernance des données IA de l’organisation est désormais évalué à l’aune de la croissance réelle des identités non humaines, et non plus sur la base bien plus restreinte du précédent audit. Une évaluation formelle des risques qui cartographie chaque agent actif, ses autorisations actuelles et sa justification métier, fournit aux équipes conformité la base de preuves nécessaire pour combler les écarts de façon stratégique plutôt que réactive.

Les identités non humaines sont discrètement devenues majoritaires

La statistique qui devrait bouleverser toutes les feuilles de route sécurité IA pour 2026 est la suivante : les identités non humaines dépassent désormais les utilisateurs humains dans 83 % des organisations interrogées. Ce n’est pas une curiosité réservée à quelques entreprises pionnières de l’IA. C’est la norme.

Chaque agent d’IA déployé par une organisation a généralement besoin de sa propre identité, ou plus souvent, hérite de celle d’un autre. Chaque intégration API entre un grand modèle de langage et un système interne requiert des identifiants. Chaque workflow automatisé qui extrait un document, résume un contrat ou rédige un e-mail pour le compte d’un humain fonctionne sous une identité, qu’elle ait été provisionnée délibérément ou empruntée à un compte de service disponible. Multipliez cela par les bots de support client, copilotes de développement, agents de synthèse documentaire, assistants de recherche interne et la liste croissante d’outils fournisseurs activant par défaut des fonctions agentiques, et il devient évident que le nombre d’identités non humaines dans une entreprise adoptant l’IA à grande échelle peut rapidement dépasser le nombre d’humains en quelques mois.

La plupart des programmes de gestion des identités et des accès n’ont jamais été conçus pour cela. Les systèmes IAM, les contrôles d’accès et les workflows de provisionnement reposaient sur un schéma prévisible : un employé arrive, obtient un compte, des accès adaptés à son rôle, puis repart, et son compte est supprimé. Les identités non humaines ne suivent pas ce cycle. Un agent peut être créé en une après-midi par un développeur testant une nouvelle intégration, recevoir des droits étendus pour aller vite, puis tourner indéfiniment parce que personne n’a la charge de le retirer. Aucun système RH ne suit la date de création d’un agent, et bien souvent, personne ne sait combien d’agents tournent ni ce qu’ils peuvent atteindre. Le CISO Dashboard offre une visibilité unifiée et en temps réel sur tous les accès aux données via l’IA, rendant cet inventaire d’agents visible pour la direction sécurité — condition préalable à toute gouvernance efficace sur ce qui reste encore invisible.

C’est la raison structurelle pour laquelle la gouvernance des identités non humaines accuse un retard sur toutes les autres pratiques de sécurité IA dans l’enquête VentureBeat. Ce n’est pas que les équipes sécurité s’en désintéressent. C’est que les outils et processus sur lesquels reposent la plupart des organisations pour la gouvernance des identités ont été pensés pour une population humaine stable et prévisible, alors que la croissance des identités non humaines fait voler en éclats toutes ces hypothèses.

Pourquoi la gouvernance des identités non humaines est la pratique de sécurité IA la moins adoptée

Parmi toutes les pratiques de sécurité IA mesurées par VentureBeat, la gouvernance des identités non humaines arrive en dernière position, avec seulement 21 % des organisations déclarant l’avoir mise en place. Ce classement mérite réflexion, car il signifie que le contrôle le plus directement lié à la catégorie d’identités à la croissance la plus rapide dans l’entreprise est aussi celui que les organisations ont le plus tardé à instaurer.

Plusieurs facteurs expliquent ce fossé. La gouvernance des identités non humaines nécessite un modèle mental différent de celui appliqué aux humains : l’accès d’un employé peut être limité à un rôle qui évolue peu, alors que les besoins d’un agent d’IA changent à chaque tâche, et un agent surdoté « au cas où » crée un risque qui se multiplie à chaque exécution, pas seulement lors du provisionnement. La plupart des organisations ne tiennent pas non plus de registre pour les agents comme elles le font pour les employés, ce qui empêche toute gouvernance de démarrer : on ne peut pas gouverner ce qu’on ne voit pas. Et la responsabilité des agents IA se répartit entre des équipes qui collaborent rarement — sécurité, gouvernance des données, développement applicatif, et l’unité métier à l’origine de la demande —, chacune supposant que le problème relève d’un autre.

Les conséquences de ce fossé de 79 % ne sont pas théoriques. Un agent non gouverné disposant d’un accès permanent à un référentiel de fichiers, un CRM ou un système de gestion documentaire représente une exposition, qu’il soit mal utilisé ou non. Ses identifiants peuvent être exfiltrés. Ses autorisations survivent généralement à la tâche pour laquelle elles ont été accordées. Et sans traçabilité claire, l’équipe conformité ne peut reconstituer les événements a posteriori. L’architecture Zero trust — vérifier explicitement, accorder le minimum de privilèges, supposer la compromission — s’applique autant aux identités non humaines qu’aux identités humaines. La plupart des organisations n’ont pas encore étendu ce modèle aux agents. La minimisation des données appliquée aux autorisations des agents — c’est-à-dire ne provisionner chaque agent que pour les sources de données strictement nécessaires à sa mission — est la mise en œuvre opérationnelle du principe du moindre privilège pour les identités non humaines, et elle réduit directement le rayon d’impact en cas d’exfiltration ou de mauvaise utilisation d’un identifiant agent.

Le piège du partage d’identifiants : comment l’accès partagé multiplie les risques

Lorsqu’une organisation n’a pas mis en place de gouvernance dédiée pour les identités de ses agents IA, le réflexe par défaut est presque toujours le même : les agents héritent d’identifiants existants. Imaginez un schéma courant dans la plupart des entreprises aujourd’hui : un développeur réutilise un compte de service déjà doté d’un large accès à la base de données parce que créer un compte dédié prend trop de temps, un agent reçoit le jeton API d’un employé pour extraire des données en son nom, ou la fonctionnalité agentique d’un fournisseur arrive avec un identifiant d’intégration par défaut doté de droits trop larges.

Chacune de ces solutions de facilité résout un problème immédiat mais en crée un durable. Les identifiants partagés signifient un rayon d’impact partagé : si un compte de service est compromis, tous les agents qui l’utilisent le sont aussi, et tous les systèmes accessibles par ce compte sont exposés, pas seulement celui que l’agent était censé atteindre. Cela efface aussi toute responsabilité. Lorsque trois agents et deux workflows automatisés s’authentifient avec le même compte de service, un journal d’audit indiquant que ce compte a accédé à un fichier sensible ne permet pas de savoir quel agent l’a fait, pour quelle tâche, ni si cet accès était légitime. C’est l’exact opposé de ce qu’attendent les régulateurs et les équipes de gestion des risques d’une traçabilité, et c’est précisément ce que la gouvernance des identités non humaines vise à éviter. Une violation de données confirmée via un compte de service partagé utilisé par plusieurs agents crée un périmètre d’exfiltration impossible à circonscrire avec certitude — les obligations de notification au titre de HIPAA, RGPD ou d’autres cadres s’appliquent à la portée maximale, sauf preuve formelle permettant de la réduire.

Le Shadow AI aggrave encore la situation. Les employés qui adoptent des outils IA de leur propre initiative, en dehors de tout déploiement officiel, collent régulièrement des données sensibles dans des interfaces IA grand public ou connectent des outils IA personnels aux systèmes de l’entreprise avec leurs propres identifiants. Chacune de ces connexions non autorisées constitue une identité non humaine supplémentaire que l’organisation ignore et ne peut gouverner. Les programmes de prévention des pertes de données axés sur la surveillance des applications et points de sortie connus ont une visibilité limitée sur ce que fait un agent non gouverné une fois les données en main, d’où la nécessité d’intégrer la gouvernance au niveau de l’identité, et pas seulement au niveau du contenu. Une plateforme SIEM recevant en temps réel la télémétrie des accès agents depuis des points de connexion gouvernés fournit la base comportementale permettant de détecter les activités anormales avant qu’elles ne dégénèrent en incident majeur.

Ce qui distingue les meilleurs : la gouvernance comme levier de croissance

Le constat le plus utile de l’enquête VentureBeat n’est pas la baisse de confiance en elle-même. C’est ce que les données révèlent sur les organisations les plus matures. Ces organisations étaient cinq fois plus susceptibles que la moyenne de déclarer n’avoir aucun obstacle à l’expansion de leurs déploiements d’agents IA.

Ce lien rebat les cartes du débat sur la gouvernance. L’intuition voudrait que la gouvernance freine l’adoption de l’IA, que chaque contrôle ajouté entre un agent et les données dont il a besoin soit une friction ralentissant la création de valeur. Les données prouvent l’inverse à grande échelle. Les organisations ayant mis en place une véritable gouvernance de leurs identités non humaines — c’est-à-dire capables de visualiser chaque agent, de limiter ses accès à ce que sa tâche exige réellement et d’auditer ses actions — sont les mieux placées pour ajouter des agents sans se heurter à un plafond. La gouvernance ne les freine pas. C’est ce qui leur permet de continuer à croître, car elles ont déjà résolu le problème sur lequel les autres butent encore : savoir ce qu’elles possèdent et contrôler ce que cela peut toucher.

Celles qui n’ont pas cette base solide se heurtent à un autre plafond. Elles peuvent déployer quelques agents facilement, souvent en empruntant des identifiants existants, car le risque n’a pas encore rattrapé la pratique. Mais chaque agent supplémentaire déployé sur cette base non gouvernée ajoute plus de risque que de valeur, jusqu’à ce que les équipes sécurité, juridique ou conformité interviennent et ralentissent tout le programme, précisément parce que personne ne peut répondre aux questions de base sur ce qui tourne déjà. C’est ce plafond que les organisations les plus avancées de l’enquête VentureBeat ont déjà franchi, et c’est un argument fort pour instaurer la gouvernance des identités non humaines dès le départ, plutôt que de la bricoler après un incident. Kiteworks fournit un environnement de gouvernance unifié — un moteur de règles, une traçabilité unique sur tous les flux de contenu humains et IA — qui rend possible le passage à l’échelle des agents sans buter sur un mur de conformité.

Combler le fossé : ce que requiert réellement la gouvernance des accès par agent

Faire passer la gouvernance des identités non humaines de 21 % d’adoption à un niveau quasi universel suppose de partir sur des bases différentes de la plupart des investissements IAM actuels : considérer chaque agent IA comme une identité gouvernée à part entière, et non comme une extension du compte humain ou de service qui lui a donné accès.

Tout commence par la visibilité. Une organisation ne peut pas gouverner des agents dont elle ignore l’existence, ce qui implique comme première étape de constituer un inventaire réel de chaque agent ayant accès à des données ou systèmes sensibles, d’identifier qui en a fait la demande, ce qu’il peut atteindre et pourquoi. Ensuite, il faut limiter l’accès de chaque agent à sa tâche précise, et non lui faire hériter des droits globaux. Un agent qui résume des contrats n’a pas besoin de droits d’écriture sur les systèmes qui les stockent. Un agent qui répond aux clients n’a pas besoin du même accès que toute l’équipe support sur le CRM. Les modèles ABAC et RBAC offrent une voie pour cette granularité, à condition d’être appliqués aux agents de façon délibérée et non par défaut. L’application de labels de classification aux contenus accessibles par les agents — pour que les moteurs de règles puissent imposer des restrictions selon la sensibilité à chaque requête — est la condition préalable à une gouvernance ABAC précise et non approximative.

Chaque interaction doit aussi être journalisée au niveau de l’agent, et non du compte partagé, afin que l’équipe conformité ou l’auditeur puisse reconstituer les faits sur la base d’une action précise d’un agent précis, et non d’un compte partagé. C’est le principe de conception du Secure MCP Server, qui offre aux agents IA un point de connexion gouverné et audité vers les contenus sensibles de l’organisation, au lieu d’un identifiant permanent et non limité. Plutôt que de faire hériter à un agent les accès d’un humain ou d’un compte de service étendu, il s’authentifie via OAuth 2.0 avec des jetons stockés dans l’OS et non exposés au modèle IA, chaque requête étant évaluée en temps réel selon les règles RBAC et ABAC, avec limitation du débit pour contenir ce qu’un agent peut extraire.

Le même principe s’applique à la gouvernance de ce que les modèles ou agents IA peuvent voir et traiter dès le départ. Kiteworks Compliant AI applique les règles là où le contenu sensible rencontre le système IA, en imposant la classification des données et un moteur de règles pour que chaque décision d’accès soit prise à la demande et non sur la base d’un droit permanent. Cette combinaison — un point d’accès gouverné pour les agents et l’application des règles au niveau des données — transforme la « gouvernance des identités non humaines » d’une catégorie d’enquête en réalité opérationnelle : chaque agent a sa propre identité, ses autorisations limitées et sa traçabilité, sans jamais emprunter les identifiants d’un humain pour accomplir sa mission.

Tout cela n’oblige pas les organisations à ralentir l’adoption de l’IA. Il s’agit de construire la couche de gouvernance en même temps que les agents, et non après coup, ce qui fait toute la différence entre les organisations les plus avancées de l’enquête VentureBeat et la moyenne qui attend encore que la gouvernance rattrape une population d’agents déjà hors de contrôle.

Pour en savoir plus sur la façon de combler le fossé de la gouvernance des identités non humaines grâce à des contrôles d’accès par agent et des connexions IA auditées, réservez votre démo personnalisée dès aujourd’hui.

Foire aux questions

Cette baisse reflète une auto-évaluation plus honnête, et non un recul de l’adoption de l’IA. À mesure que les identités non humaines et les agents IA se sont multipliés dans les organisations, les responsables IT ont pris conscience de l’ampleur du travail de gouvernance des données IA restant à accomplir, et les scores de maturité ont chuté pour refléter cette réalité, au lieu de l’estimation optimiste précédente. L’adoption des outils IA a continué de progresser sur la même période ; ce qui a changé, c’est la rigueur avec laquelle les responsables ont évalué leur propre gouvernance. Les organisations soumises à des obligations de conformité réglementaire — HIPAA, RGPD, CMMC — devraient utiliser cette enquête comme déclencheur externe pour réaliser une évaluation formelle des risques liés à leurs identités non humaines, car les régulateurs finiront par évaluer la gouvernance des accès IA selon les mêmes cadres que pour les accès utilisateurs humains.

La gouvernance des identités non humaines désigne l’ensemble des règles, outils et processus permettant d’inventorier, de cadrer, de surveiller et de retirer les identités attribuées aux agents IA, comptes de service et intégrations API, par opposition à celles attribuées aux employés humains. Cela recouvre des questions comme : qui est responsable d’un agent donné, à quelles données et systèmes peut-il accéder, cet accès correspond-il à sa mission réelle, et son activité est-elle journalisée de façon à permettre un audit. Kiteworks répond à ces enjeux via des contrôles d’accès et des points de connexion gouvernés qui limitent l’accès des agents à chaque tâche au lieu d’accorder des autorisations larges et permanentes. Les programmes de gestion des risques supply chain doivent également étendre cette gouvernance aux agents IA déployés par des fournisseurs tiers — un agent fournisseur opérant dans votre environnement avec des identifiants larges constitue un risque supply chain que la plupart des cadres actuels de gouvernance fournisseur n’adressent pas explicitement.

Chaque agent IA, workflow automatisé et intégration système-à-système nécessite généralement sa propre identité pour s’authentifier et fonctionner, et les organisations en déploient à un rythme bien supérieur à leurs recrutements. Une seule unité métier adoptant l’IA agentique pour le support client, le traitement documentaire ou l’assistance au développement peut ajouter des dizaines d’identités non humaines en moins de temps qu’il n’en faut pour intégrer un nouvel employé, ce qui explique pourquoi VentureBeat observe déjà cette majorité dans 83 % des organisations interrogées. La plupart des programmes de gestion des identités et des accès n’ont pas été conçus pour ce rythme de croissance. Les cadres de gouvernance des données qui incluent explicitement les identités non humaines — avec des responsables désignés, des revues de périmètre d’accès et des procédures de retrait — sont le mécanisme organisationnel permettant d’étendre les disciplines IAM à une population d’identités qui croît plus vite que les processus de provisionnement pilotés par les RH.

Les données de l’enquête suggèrent l’inverse. Les organisations les plus matures, disposant d’une gouvernance avancée, étaient cinq fois plus susceptibles de déclarer n’avoir aucun obstacle à l’expansion de leurs déploiements d’agents IA, car elles disposent déjà de la visibilité et des contrôles d’accès nécessaires pour ajouter des agents sans introduire de risques non maîtrisés. Les organisations dépourvues de cette base solide se retrouvent bloquées plus tard, lorsque les équipes sécurité ou conformité doivent intervenir précisément parce que personne ne sait ce qui tourne déjà, ce qui ralentit bien plus le programme que de construire la gouvernance dès le départ. Instaurer cette base en amont, plutôt que de la bricoler après coup, fait toute la différence entre gérer le risque IA de façon proactive ou y réagir sous pression. Un plan de réponse aux incidents couvrant explicitement les scénarios de dysfonctionnement d’agent et d’exfiltration d’identifiants — avec procédures de retour arrière et seuils de notification réglementaire — complète l’architecture de gouvernance : il définit ce qui se passe après détection, et pas seulement comment la détection fonctionne.

Commencez par un inventaire : identifiez chaque agent IA, compte de service et intégration disposant actuellement d’un accès à des systèmes ou données sensibles, et vérifiez qui en est responsable et pourquoi il dispose de ces accès. Ensuite, limitez les autorisations de chaque agent à sa tâche précise, au lieu de lui faire hériter des identifiants partagés, et faites transiter l’accès des agents aux contenus sensibles par un point de connexion gouverné comme le Secure MCP Server afin que chaque action soit journalisée pour une identité précise et responsable, et non partagée. La classification des contenus accessibles par les agents est la condition préalable à l’application de la granularité ABAC — sans elle, un moteur de règles ne peut pas imposer de restrictions selon la sensibilité aux requêtes des agents. L’envoi en temps réel des journaux d’accès agents vers une plateforme SIEM donne aux équipes sécurité la base comportementale nécessaire pour détecter toute activité anormale avant qu’elle ne dégénère en incident à déclarer.

Ressources complémentaires

  • Article de blog
    Stratégies Zero Trust pour une protection abordable de la confidentialité IA
  • Article de blog
    Comment 77 % des organisations échouent à sécuriser les données IA
  • eBook
    AI Governance Gap : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025
  • Article de blog
    Il n’existe pas de « –dangerously-skip-permissions » pour vos données
  • Article de blog
    Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves de son efficacité.

Lancez-vous.

Il est facile de commencer à garantir la conformité réglementaire et à gérer efficacement les risques avec Kiteworks. Rejoignez les milliers d’organisations qui ont confiance dans la manière dont elles échangent des données privées entre personnes, machines et systèmes. Commencez dès aujourd’hui.

Table of Content
Partagez
Tweetez
Partagez
Explore Kiteworks