Une gouvernance multi-plateforme

01Gouverner des accès, pas un catalogue d'éditeurs #sec_cae89bbf

Une organisation ne confie jamais tous ses accès à une seule technologie. Les identités vivent dans un annuaire, les équipes travaillent dans des espaces collaboratifs, le code dans des dépôts, les données dans des plateformes métier et les privilèges dans des services d'infrastructure. À mesure que le système d'information évolue, de nouvelles solutions apparaissent sans faire disparaître immédiatement les précédentes.

REVIEWIT est conçu pour gouverner cette diversité sans dépendre du vocabulaire d'un éditeur particulier. Son objet n'est pas Microsoft 365, Google Workspace, GitHub, Jira, Slack ou une autre plateforme prise isolément. Son objet est la relation d'accès qui doit être revue : une identité ou un groupe possède un droit sur une ressource, dans un périmètre donné, avec des éléments qui permettent à une personne d'en juger la légitimité.

Cette séparation est le fondement de l'approche multi-plateforme. Les solutions peuvent changer ; la question de gouvernance reste la même : qui accède à quoi, à quel titre, et cet accès doit-il encore être maintenu ?

02Un modèle commun qui conserve les différences utiles #sec_45846948

Les plateformes ne décrivent pas leurs objets de la même façon. L'une parle de groupes, une autre d'équipes ; l'une expose des sites et des dossiers, une autre des projets, des dépôts ou des canaux ; les niveaux d'accès peuvent s'appeler membre, administrateur, contributeur, éditeur ou lecteur.

REVIEWIT ne remplace pas tous ces termes par un objet générique appauvri. Il les organise selon une hiérarchie stable :

• une solution désigne le système connecté ;
• un workload représente une famille fonctionnelle de cette solution ;
• une ressource est l'objet concret susceptible d'être inventorié et recertifié ;
• les identités, appartenances, rôles et permissions expliquent la relation d'accès ;
• les éléments de preuve , comme le propriétaire ou la dernière activité connue, donnent au reviewer le contexte nécessaire pour décider.

Un site collaboratif, un dépôt de code et un projet ne deviennent donc pas le même objet. Ils restent différents, mais leurs relations d'accès peuvent être traitées par le même cycle de campagne, les mêmes responsabilités et la même exigence de preuve.

03Le connecteur traduit ; il ne redéfinit pas REVIEWIT #sec_4c40d9f9

Chaque solution possède ses API, ses modes d'authentification, ses limites, sa pagination et ses règles de visibilité. Le rôle d'un connecteur est de prendre en charge ces particularités puis de présenter à REVIEWIT des données conformes au contrat commun.

Cette frontière évite de construire une application différente pour chaque éditeur. Une fois les données collectées et qualifiées, le reste de la chaîne demeure partagé : sélection du périmètre, association des politiques, construction de la campagne, affectation aux reviewers, décision, justification, restitution et piste d'audit.

Le principe s'applique aussi à l'expérience de connexion. Les champs et les contrôles propres à une solution sont déclarés par son fournisseur de connectivité autant que possible. Un écran spécifique n'est justifié que lorsqu'un comportement ne peut pas être décrit autrement, par exemple une redirection d'autorisation ou une découverte de périmètre après authentification. L'extension reste ainsi explicite et testable, sans dupliquer toute l'interface.

04Étendre la couverture par contrat #sec_7a65dcc5

Ajouter une plateforme ne consiste pas seulement à appeler une API. Une extension exploitable doit apporter une chaîne complète.

Elle déclare d'abord les solutions, workloads et ressources qu'elle sait réellement observer. Elle décrit ensuite la forme de chaque ressource : son identifiant stable, les informations présentées au reviewer et les attributs qui portent une identité, un propriétaire, des membres ou une activité.

Ces attributs sont rapprochés d'un vocabulaire gouverné. C'est ce rapprochement qui permet aux évaluateurs de comprendre, indépendamment de l'éditeur, qu'un champ représente par exemple des propriétaires, des membres ou des invités. Une politique n'est proposée que lorsque les données nécessaires existent réellement pour le workload concerné.

Enfin, le connecteur doit démontrer son comportement opérationnel : authentification selon le moindre privilège, collecte en lecture seule, pagination, reprise après erreur, réconciliation et traçabilité. Une intégration n'est pas considérée comme complète parce qu'une première réponse API a été obtenue ; elle doit fournir une couverture mesurable et répétable.

Ce contrat crée une extension maîtrisée : une nouvelle solution rejoint la plateforme en ajoutant son langage et sa capacité de collecte, sans réécrire le moteur de campagne ni les règles de responsabilité.

05Une politique commune, seulement lorsqu'elle a du sens #sec_afa8f799

L'agnosticisme ne signifie pas qu'une même politique s'applique indistinctement à tous les objets. Une politique de membership, de propriété, d'inactivité, de partage externe ou d'accès privilégié exige des informations différentes. Certaines ressources portent ces informations ; d'autres non.

REVIEWIT relie donc les politiques aux workloads pour lesquels elles sont fondées. Un workload peut être déclaré dans le catalogue tout en restant non gouvernable tant qu'aucune politique applicable ou donnée suffisante ne lui est associée. Cette distinction empêche de promettre une recertification là où le connecteur ne fournit qu'un inventaire.

La plateforme reste commune, mais l'applicabilité demeure honnête. Deux solutions peuvent participer à une même campagne lorsque leurs objets répondent au même besoin de gouvernance ; elles ne sont jamais forcées dans une équivalence artificielle.

06La couverture est une donnée, pas une supposition #sec_8e9dedd6

Une connexion valide ne garantit pas que tout le tenant est visible. La couverture dépend des permissions accordées, du périmètre d'installation, des capacités de l'API et parfois de l'édition souscrite chez l'éditeur. Un connecteur peut être techniquement sain tout en ne voyant qu'une partie des ressources ou des accès attendus.

REVIEWIT sépare donc la santé de la connexion de la couverture de la collecte . Cette distinction est essentielle dans un environnement multi-plateforme : elle permet de dire qu'une authentification fonctionne sans présenter un inventaire partiel comme exhaustif.

Les campagnes et leurs lecteurs peuvent ainsi connaître la limite de ce qui est observé. L'absence d'un objet ne devient pas silencieusement la preuve d'une absence d'accès.

07Une adoption progressive, sans dépendance à une plateforme unique #sec_d8c98cfe

Une organisation peut commencer par la solution qui porte son risque le plus immédiat, puis étendre progressivement le périmètre. Les nouveaux connecteurs enrichissent la couverture ; ils ne créent pas une nouvelle méthode de gouvernance à apprendre ni une nouvelle piste de preuve à exploiter.

Cette continuité réduit la dépendance à un fournisseur. Un changement d'outil collaboratif, de dépôt de code ou de plateforme métier modifie la source des données, mais pas le principe des campagnes, le rôle des reviewers ni la manière de démontrer les décisions prises.

L'approche couvre aussi bien des services SaaS que des environnements cloud ou des systèmes exploités sur site, dès lors qu'un fournisseur de connectivité satisfait le contrat de collecte et de preuve. REVIEWIT n'impose pas une technologie source ; il impose en revanche la qualité minimale nécessaire pour gouverner ce qu'elle expose.

08Ce que « multi-plateforme » ne promet pas #sec_24071a82

Le catalogue des solutions possibles et la liste des connecteurs effectivement disponibles ne sont pas la même chose. La présence d'une solution dans un référentiel décrit un modèle d'extension ou une cible de couverture ; elle ne constitue pas à elle seule l'annonce d'un connecteur livré et supporté.

De même, REVIEWIT ne devient pas l'annuaire maître des plateformes connectées et n'écrit pas dans leurs contenus pour les harmoniser. Il collecte les relations utiles à la recertification, organise le jugement humain et conserve la preuve de ce jugement. L'exécution d'une révocation dans le système source reste une capacité distincte, qui doit être annoncée et démontrée lorsqu'elle existe.

L'agnosticisme de REVIEWIT est donc une propriété d'architecture et de gouvernance, pas une promesse vague d'universalité.

09En résumé #sec_f36382e4

REVIEWIT sépare le métier de la recertification des particularités des plateformes sources. Les connecteurs traduisent les identités, groupes, rôles, permissions, ressources et preuves vers un contrat commun ; le moteur de campagne, les responsabilités et la piste d'audit restent partagés.

Cette architecture permet d'étendre progressivement la couverture sans construire des silos par éditeur. Elle conserve les différences utiles, mesure les limites de visibilité et n'applique une politique que lorsque les données la rendent réellement gouvernable.

Les solutions changent. Le besoin de savoir qui accède à quoi — et de pouvoir prouver qui a décidé — demeure.