Cet article s'adresse aux pilotes globaux et aux RSSI qui structurent ou font évoluer leur organisation dans Tenacy, que ce soit lors d'un POC, d'une industrialisation ou d'une réorganisation. Il vous aide à anticiper les conséquences de votre découpage en périmètres (l'unité de base sur laquelle Tenacy rattache vos droits, vos mesures de sécurité, vos risques et vos indicateurs), pour arbitrer avec les bonnes informations en main.
🔎 Vous cherchez la procédure pas à pas et des exemples de configurations types (structure plate, arborescence géographique, par BU...) ? Consultez d'abord Modéliser mon organisation. Cet article-ci complète le premier avec les éléments à avoir en tête pour choisir la configuration la plus adaptée à votre contexte.
Ce qui est utile de clarifier avant de modéliser
Une modélisation qui tient dans le temps part rarement d'une page blanche : elle s'appuie sur quelques éléments de contexte réunis en amont.
Le contexte organisationnel : organigramme, liste de vos systèmes d'information, et surtout vos scopes de certification. Un scope de certification (ISO 27001, par exemple) devient quasi systématiquement un périmètre à part entière : c'est souvent le point de départ le plus fiable pour cadrer votre arborescence.
Une vision claire de ce que vous voulez sécuriser : la modélisation gagne à partir de vos objectifs de sécurité (politiques, risques à couvrir) plutôt que de votre organigramme fonctionnel. Les deux se recoupent souvent, mais pas toujours.
Un interlocuteur qui connaît l'organisation dans son ensemble : sur une organisation complexe, une seule personne dédiée à Tenacy mais peu au fait de la structure globale ne suffit généralement pas à cadrer seule la modélisation.
Pourquoi ce découpage influence directement votre usage quotidien de Tenacy
Votre arborescence de périmètres est la première structure que vous construisez dans Tenacy, et plusieurs briques s'appuient directement sur elle :
Droits utilisateurs : les droits des pilotes locaux et des contributeurs suivent l'arborescence. Si vous avez besoin de les gérer selon une logique différente de votre structure principale, un arbre secondaire dédié permet de le faire sans dupliquer vos données.
Campagnes d'évaluation : une campagne, qui permet de collecter des réponses déclaratives auprès de plusieurs périmètres sur un même référentiel, se lance à l'échelle d'un périmètre ou d'un groupement. Pour couvrir en une seule campagne des périmètres dispersés dans votre arbre, pensez à les regrouper au préalable (via un groupement ou un arbre secondaire).
Indicateurs opérationnels : rattachés aux mesures, elles-mêmes rattachées aux périmètres, leur finesse de suivi dépend de celle de votre découpage. Si vous voulez un indicateur clé par système d'information, chaque système d'information gagnera à être modélisé comme un périmètre distinct.
Socle de sécurité : Le socle de sécurité regroupe, pour un périmètre, l'ensemble des mesures de sécurité attendues au regard des politiques et des risques qui lui sont associés. La première déclaration d'un socle de sécurité est souvent le moment où l'on prend conscience concrètement du niveau de détail dont on a besoin. Se projeter dans la construction d'un socle avant de finaliser votre arborescence est un excellent moyen de valider votre granularité.
Comment définir la bonne granularité pour vos objectifs de sécurité
Trois entrées permettent de cadrer la granularité qui vous conviendra le mieux, en complément des 5 configurations types présentées dans l'article Modéliser mon organisation :
Via vos objectifs de sécurité : vos politiques (référentiels comme l'ISO 27001, la NIS2, ou vos politiques internes) et vos risques sont rattachés aux périmètres. Si vos différentes entités visent des niveaux de maturité ou d'autonomie distincts, cela oriente directement le découpage à privilégier.
Via votre reporting : la granularité de vos périmètres détermine celle de vos tableaux de bord. Réfléchir en amont aux axes de reporting que votre direction attend (par pays, par BU, par niveau de criticité) vous aide à choisir le bon niveau de détail dès le départ.
Via vos mesures : identifiez vos mesures centralisées (par exemple un EDR groupe, un IAM central, un SOC mutualisé) par rapport à vos mesures locales. Ces mesures centralisées sont en général portées par un périmètre "opérateur", qui agit pour le compte des autres périmètres. C'est ce que les organisations les plus matures appellent souvent un "process owner", un vocabulaire que vous retrouverez d'ailleurs dans la norme ISO 27001.
💡 Seuls les périmètres internes peuvent porter des mesures de sécurité et jouer ce rôle de process owner. Si vous identifiez qu'un de vos points d'application opérationnels correspond aujourd'hui à un périmètre fournisseur, c'est le signal qu'il gagnerait à être modélisé comme un périmètre interne.
Quelques repères à garder en tête
Certaines caractéristiques de Tenacy méritent d'être connues en amont, car elles gagnent à être anticipées plutôt que découvertes en cours de route :
Chaque périmètre garde le type choisi à sa création (interne, fournisseur ou application). C'est ce qui garantit la cohérence de vos données de sécurité dans le temps, mais cela veut dire qu'il vaut mieux confirmer ce choix dès la création, en particulier pour vos points d'application opérationnels.
Regrouper deux périmètres existants en un seul se fait en migrant leurs objets plutôt que par une fusion automatique. C'est une opération que Tenacy accompagne pas à pas, mais qui reste plus simple à éviter en calibrant bien votre granularité de départ.
Un groupement se vide avant de se supprimer : il faut déplacer ou réaffecter ses périmètres et sous-groupements au préalable. C'est aussi ce qui garantit que rien ne se perd silencieusement lors d'une réorganisation.
L'arborescence principale est verticale, mais rien ne vous empêche de la croiser avec d'autres axes : les arbres secondaires et les propriétés personnalisées avec filtres permettent tous les deux de représenter une organisation matricielle sans dupliquer vos données.
Le périmètre interne consomme votre licence, le fournisseur et l'application non : un critère de plus à prendre en compte au moment de choisir comment modéliser une entité (voir aussi la section licences de Modéliser mon organisation).
Le groupement reste un axe analytique : il structure votre arborescence et votre reporting, mais ne porte pas d'objet de sécurité en propre. C'est le périmètre interne qui porte vos politiques, mesures et risques.
🔎 Pour la procédure de déplacement, de fusion ou de suppression, consultez : Déplacer un périmètre ou un groupement dans votre organisation et Préparer et lancer la réorganisation de son arborescence dans Tenacy. Pour l'alternative aux arbres secondaires par propriétés et filtres, consultez : Utiliser les propriétés d'un périmètre.
Ce que notre expérience client nous apprend selon votre type d'organisation
Au fil des accompagnements, certains profils d'organisation reviennent régulièrement. Voici ce que nous recommandons dans chaque cas :
Organisation en croissance externe ou en réorganisation fréquente : plutôt que de modéliser l'intégralité de votre structure d'un coup, mieux vaut vous positionner sur 2 ou 3 périmètres représentatifs, dérouler vos cas d'usage dessus, puis industrialiser une fois la méthode validée. Cette approche progressive limite le travail de reprise si votre organisation continue de bouger.
Organisation avec des populations terrain difficiles à centraliser (sites industriels, environnements OT) : quand les données sont gérées sur le terrain plutôt que dans des fonctions support centralisées, une évaluation déclarative ou un traitement via des périmètres fournisseurs donnent souvent de meilleurs résultats qu'une modélisation complète en périmètres internes.
Organisation avec un grand nombre de périmètres (plusieurs dizaines et plus) : une hiérarchie d'identifiants cohérente dès le départ facilite grandement les opérations de masse par la suite (import, export, retraitement de données).
Organisation avec une tendance à la centralisation groupe : si vous prévoyez que de plus en plus de mesures seront gérées au niveau groupe puis offertes aux filiales, anticipez dès la modélisation le périmètre "opérateur" qui portera ces mesures pour le compte des autres : cela évite d'avoir à réattribuer les mesures après coup.
Questions fréquentes
Dois-je modéliser toute mon organisation avant de commencer à utiliser Tenacy ?
Non, ce n'est pas nécessaire. Pour les organisations dont la structure évolue souvent, il est même recommandé de démarrer sur quelques périmètres représentatifs avant d'industrialiser le reste.
Un périmètre fournisseur peut-il porter des mesures de sécurité comme un périmètre interne ?
Non. Seuls les périmètres internes ont accès aux mesures, aux risques, aux tâches récurrentes et aux écarts. Les périmètres fournisseurs et applications sont limités aux évaluations (sans mesure) et aux actions simples.
Un groupement peut-il porter une politique ou une mesure de sécurité ?
Non. Le groupement structure votre arborescence et votre reporting, mais seuls les périmètres internes portent des politiques, des mesures et des risques.
Comment représenter une organisation matricielle si l'arborescence principale est verticale ?
Deux options se complètent : un arbre secondaire, qui regroupe vos périmètres existants selon une autre logique sans dupliquer vos données, ou des propriétés personnalisées associées à des filtres, pour isoler un sous-ensemble de périmètres selon un critère donné (une portée de certification, par exemple).
Que se passe-t-il si je change d'avis sur le découpage de mon organisation après coup ?
Tenacy vous accompagne pour faire évoluer votre arborescence (renommer, déplacer, créer, regrouper deux périmètres) sans perte de données, en suivant une procédure dédiée. Consultez Préparer et lancer la réorganisation de son arborescence dans Tenacy pour le détail.