Contrôlez ce que chaque utilisateur voit. Contrôlez ce que chaque utilisateur peut faire. À tous les niveaux.

Pourquoi c'est important

Lors d'un processus d'examen multipartite à l'échelle de l'entreprise, les problèmes d'autorisation se manifestent de deux manières principales.

La première est la fuite de contenu. Une personne consulte du contenu auquel elle ne devrait pas avoir accès. Par exemple : des sections sensibles d'un dossier réglementaire sont visibles par les responsables marketing ; des informations de santé protégées sont visibles par des personnes non habilitées ; des documents de pré-lancement sont visibles par des équipes qui ne devraient pas encore en avoir connaissance. Les conséquences de ces fuites peuvent être simplement gênantes, constituer une violation de la conformité, voire donner lieu à des poursuites judiciaires.

La seconde est le dépassement de pouvoir. Une personne ayant accès au contenu peut effectuer une action qu'elle ne devrait pas. Par exemple : un examinateur junior qui passe outre l'approbation d'un supérieur ; un responsable de marque qui prend une décision réglementaire ; un contact d'une agence externe qui invoque un agent d'IA qui devrait être réservé à un usage interne. Même en l'absence de mauvaise intention, le dépassement de pouvoir corrompt la piste d'audit et érode la confiance dans le processus.

Le modèle d'autorisation bidimensionnel d'Aproove permet de résoudre ces deux types de problèmes. Les autorisations de contenu contrôlent les fuites. Les autorisations d'action contrôlent les dépassements de pouvoir. Les deux fonctionnent avec une grande précision. Les deux sont appliqués au niveau de la plateforme, et non au niveau de l'application, ce qui signifie qu'ils restent valides même lorsque les utilisateurs accèdent au système via des API, des intégrations ou des voies d'accès non conventionnelles. Ceci est important pour les équipes qui évaluent les logiciels de gestion de versions de documents pour les organismes publics.

Deux dimensions de contrôle

Les permissions de contenu répondent à la question : que peut voir cet utilisateur ?

• Un projet entier (l’utilisateur a-t-il un accès au niveau du projet ?)
• Des fichiers spécifiques au sein d’un projet (certains fichiers sont visibles, d’autres non, même au sein du même projet)
• Des sections spécifiques d’un fichier (les sections juridiques sont visibles par le service juridique, les sections relatives à la marque sont visibles par le service de la marque)
• Des pages spécifiques d’une section (les pages 12 à 18 sont visibles, les autres non)
• Des composants spécifiques d’une page (une image, un paragraphe ou une zone spécifique)

Les permissions d’action répondent à la question : que peut faire cet utilisateur ?

• Les outils d’annotation qu’il peut utiliser (extraction de texte, marquage de zone, annotation à main levée, etc.)
• Les notes qu’il peut créer, modifier ou supprimer
• Les boutons de décision qu’il voit dans un flux de travail donné Étape (Approuver, Refuser, Approuver avec commentaires, Envoyer à l'expert, Mettre en attente pour conformité, etc.)
• Quels agents d'IA peuvent être invoqués (un examinateur de marque peut voir les agents de marque, mais pas les agents juridiques)
• Quelles autorisations d'exportation et de téléchargement sont disponibles (certains utilisateurs peuvent exporter le PDF de preuve, d'autres non)
• Quelles fonctions d'administration peuvent effectuer (modification du flux de travail, gestion des utilisateurs, configuration du schéma)

Les dimensions se multiplient : un utilisateur disposant d'autorisations de contenu étendues peut avoir des autorisations d'action restreintes, et inversement. C'est cette combinaison qui définit l'expérience de cet utilisateur.

Ce que vous pouvez contrôler au niveau des actions

Exemples précis de ce que les autorisations d'action contrôlent :

• Accès aux agents d'IA. Quels ensembles de modèles d'invite l'utilisateur peut invoquer. Un examinateur réglementaire peut avoir accès uniquement aux agents réglementaires. Un examinateur de marque peut avoir accès uniquement aux agents de marque. L'accès à l'IA est indépendant de l'accès aux fichiers.
• Création, modification et suppression de notes. Certains rôles peuvent créer et modifier leurs propres notes. D'autres rôles peuvent modifier n'importe quelle note. D'autres encore peuvent supprimer des notes. Chaque fonctionnalité est configurable.
• Boutons de décision disponibles. Une étape du flux de travail peut définir des boutons de décision tels que Approuver, Refuser, Approuver sous conditions et Escalader. Différents rôles peuvent voir différents sous-ensembles. Un relecteur junior peut ne voir que les options Approuver et Refuser. Un relecteur senior voit l'ensemble complet, y compris Escalader.
• Outils d'annotation disponibles. L'interface de révision offre plusieurs outils d'annotation (extraction de texte, sélection de région, annotation à main levée, sélecteur de couleurs). Les rôles peuvent se voir accorder l'accès à des outils spécifiques plutôt qu'à l'ensemble.
• Exportation et téléchargement. Certains rôles peuvent télécharger les fichiers originaux ; d'autres peuvent uniquement les visualiser dans le visualiseur en flux continu. Certains peuvent exporter des PDF des épreuves et des commentaires ; D'autres ne le peuvent pas.
• Fonctions de flux de travail et d'administration. La modification des flux de travail, la gestion des utilisateurs, la configuration du schéma et d'autres fonctionnalités d'administration sont réservées aux rôles d'administrateur, avec des sous-niveaux optionnels (par exemple, un administrateur de flux de travail qui peut modifier les flux de travail mais pas gérer les utilisateurs).

Ce que vous pouvez restreindre côté contenu

Exemples précis de ce que les permissions de contenu contrôlent :

• Visibilité du projet. Indique si l'utilisateur peut voir un projet. Les utilisateurs qui n'ont pas accès au niveau du projet ne voient pas le projet dans leur tableau de bord.
• Visibilité au niveau du fichier. Au sein d'un projet, les fichiers que l'utilisateur peut ouvrir. Un projet peut contenir plusieurs épreuves ; tous les relecteurs n'ont pas besoin de toutes les voir.
• Visibilité au niveau de la section. Au sein d'un fichier à plusieurs sections, les sections que l'utilisateur peut voir. Différentes sections d'un document réglementaire complexe peuvent être acheminées vers différentes équipes spécialisées, chacune ne voyant que sa section.
• Visibilité au niveau de la page. Au sein d'un fichier, quelles pages l'utilisateur peut consulter. Les pages marquées comme confidentielles, réglementées ou sensibles peuvent être soumises à un contrôle d'accès réservé aux rôles disposant des autorisations appropriées.
• Visibilité au niveau du composant. Au sein d'une page, quels composants l'utilisateur peut consulter. Une image spécifique signalée comme information de santé protégée (ISP), un paragraphe contenant des informations financières confidentielles, une zone contenant des informations restreintes. C'est le composant qui est soumis à un contrôle d'accès, et non la page entière.

Comment les autorisations sont associées aux rôles, aux équipes et aux utilisateurs

Les autorisations sont attribuées à plusieurs niveaux du modèle utilisateur et résolues conformément à votre gouvernance.

• Basé sur les rôles. Le modèle le plus courant. Les autorisations sont définies par rôle et les utilisateurs les héritent lorsqu'ils sont affectés à ce rôle. Un rôle de « Réviseur juridique » confère un ensemble défini de droits d'accès au contenu et de capacités d'action. L'ajout d'une personne à un rôle lui confère tous les droits associés. Les autorisations peuvent être limitées aux équipes, et les autorisations d'une équipe s'appliquent à ses membres. Utile pour les groupes interfonctionnels nécessitant un profil d'autorisation partagé. Lorsque les rôles et les équipes ne suffisent pas, les autorisations peuvent être accordées directement aux utilisateurs. Rare en pratique, mais disponible lorsque le travail l'exige. Les autorisations peuvent être déterminées en fonction des métadonnées du projet ou du composant. Un utilisateur peut avoir accès à la révision juridique de documents relevant de la juridiction américaine, mais pas de la juridiction européenne. L'autorisation est conditionnelle aux métadonnées du contenu examiné.

La combinaison est résolue de manière transparente : l'utilisateur obtient l'ensemble des autorisations auxquelles il a droit via son rôle, son équipe et l'attribution directe, en fonction des conditions de métadonnées applicables.

Modèles courants

Gestion des autorisations de sécurité. Un document contient des sections à différents niveaux de sensibilité. Les autorisations sont configurées de sorte que les utilisateurs ne voient que les sections autorisées par leur niveau d'habilitation. Le même document est utilisé par plusieurs groupes de réviseurs, chacun voyant ce qui lui est dû.

Restriction des actions basée sur les rôles. Une étape de flux de travail comporte plusieurs boutons de décision. Les réviseurs juniors voient uniquement « Approuver » et « Rejeter ». Les réviseurs seniors voient « Approuver », « Rejeter », « Approuver sous conditions » et « Escalader ». Les gestionnaires de conflits disposent d'une option supplémentaire « Remplacer ». Même étape, vocabulaires d'actions différents.

Routage au niveau des composants avec application des autorisations. Les agents d'IA signalent les risques sur des composants spécifiques. Ces éléments sont acheminés vers des spécialistes en fonction du type de risque. Les autorisations garantissent que le spécialiste ne voit que les éléments signalés et non le reste du fichier. Les autres examinateurs poursuivent l'analyse du contenu non signalé.

Contrôle des utilisateurs externes. Les utilisateurs de l'agence ou les partenaires externes disposent d'un profil d'autorisation restreint : accès limité au contenu, capacité d'action limitée, interdiction d'invoquer l'agent IA et absence de fonctions d'administration. Ils participent à l'examen, mais ne peuvent pas dépasser les limites qui leur sont définies.

Avantages

• Deux dimensions de contrôle, un seul modèle. La visibilité du contenu et les capacités d'action sont configurées ensemble, avec une correspondance cohérente des rôles, des équipes et des utilisateurs.
• Granularité au niveau du composant. Les permissions vont au-delà du niveau du fichier. Des pages, sections ou composants spécifiques peuvent être restreints indépendamment. L'accès à l'IA est contrôlé par les permissions. Les agents pouvant être invoqués sont gérés au niveau des rôles, indépendamment de l'accès aux fichiers. Le pouvoir de décision est contrôlé par les permissions. Les boutons de décision visibles par un utilisateur varient selon son rôle, permettant ainsi aux réviseurs juniors et seniors d'opérer dans le cadre de leurs pouvoirs respectifs. Le contenu sensible reste protégé. Les données de santé protégées (PHI), les données personnelles identifiables (PII), les documents réglementés ou le contenu en pré-lancement peuvent être configurés pour être diffusés uniquement aux rôles autorisés. Les utilisateurs externes bénéficient d'une expérience limitée. Les partenaires de l'agence, les réviseurs clients et les autres participants externes opèrent dans le cadre de profils de permissions restreints. L'historique d'audit enregistre les événements de permission. Les octrois, les modifications et les événements d'accès aux permissions font partie de l'historique d'audit du projet, facilitant ainsi la gouvernance et le contrôle de conformité.

À qui s'adresse ce produit ?

• Aux équipes de conformité, juridiques et réglementaires des secteurs où le contrôle d'accès au contenu est obligatoire.
• Aux équipes de gouvernance de marque gérant les revues impliquant de nombreux groupes de parties prenantes aux niveaux d'autorité variés.
• Aux équipes informatiques et de sécurité évaluant les plateformes au regard des exigences de contrôle d'accès, de résidence des données et de moindre privilège.
• Aux responsables des opérations pilotant des programmes de revue avec de multiples équipes internes, des partenaires externes et différents niveaux d'autorité.
• Aux clients des secteurs réglementés (pharmaceutique, santé, services financiers, secteur public) où le contrôle d'accès multicouche est une exigence d'approvisionnement.

Fonctionnement interne

Le contrôle d'accès par couches est implémenté via le modèle d'autorisations à deux niveaux d'Aproove : autorisations de contenu et autorisations d'action. Les autorisations de contenu sont stockées aux niveaux du projet, du fichier, de la section, de la page et du composant, et leur résolution est calculée pour chaque utilisateur en fonction des rôles attribués, des appartenances aux équipes, des autorisations directes accordées et des conditions basées sur les métadonnées. Les autorisations d'action sont définies par rôle et régissent les boutons de décision disponibles, les outils d'annotation, les invocations d'agents IA, les opérations sur les notes, les fonctionnalités d'exportation et de téléchargement, ainsi que les fonctions d'administration. La résolution des autorisations calcule l'ensemble des autorisations auxquelles un utilisateur a droit, quel que soit le chemin d'accès, en fonction des conditions des métadonnées. Les autorisations sont appliquées au niveau de la plateforme et non au niveau de l'application ; elles s'appliquent donc à l'accès API, à l'accès aux intégrations et à tout autre chemin d'accès. La couche de diffusion applique les autorisations de contenu pour chaque requête de vignette, afin que le contenu auquel l'utilisateur n'est pas autorisé à accéder ne soit jamais diffusé sur son appareil. Les attributions d'autorisations, les modifications et les événements d'accès sont enregistrés dans l'historique d'audit du projet. Le livre blanc sur la transformation du centre d'excellence en exécution promotionnelle de Kroger (Aproove, octobre 2021) cite la plateforme gérant « plus de cent millions d'ensembles d'autorisations pour des centaines de milliers de tâches » comme preuve de l'évolutivité du modèle.