Le périmètre d’homologation doit être défini

Le périmètre du système d’information à homologuer est l’ensemble des composants du système d’information dans lequel l’information est traitée et pour lequel son responsable en a la maîtrise.

Le périmètre est défini librement

Le périmètre d’une homologation est défini au cas par cas par l’organisation. Néanmoins, pour des raisons de simplification, il peut sembler opportun de r grouper plusieurs systèmes d’information ayant une mission commune ou de les scinder.
Il n’existe donc pas a priori de « bonne manière » de définir le périmètre d’une homologation.

Plusieurs approches possibles

On peut, à titre d’exemple, évoquer plusieurs approches possibles en matière de définition d’un périmètre d’homologation.

L’homologation d’un système d’information dans ses différentes dimensions, par exemple, l’homologation d’un service numérique tel qu’un site web ainsi que de l’infrastructure l’hébergeant et les services tiers participant à son fonctionnement (ex. service de mailing).

L’homologation d’un « socle » commun à plusieurs systèmes d’information d’une part puis séparément de chaque système d’information prenant appui sur le socle. Par exemple, l’homologation de l’infrastructure d’hébergement, distinct des homologations des applicatifs prenant appui dessus. Cette approche permet d’accélérer les homologations de chaque brique prenant appui sur le socle.

L’homologation simultanée de plusieurs systèmes d’information distincts rassemblés dans une même « capacité » partageant la même finalité. Par exemple, l’homologation d’un système complexe réunissant plusieurs systèmes et dont la mise en service doit être décidée simultanément.

L’adoption d’une décision homologation de « référence » consistant en l’homologation d’un système d’information pouvant être dupliqué en vue d’accélérer l’homologation d’autres systèmes d’information partageant les mêmes caractéristiques et besoins de sécurité.

L’homologation d’un environnement technique et organisationnel « global » pouvant être modifié (ajout de nouvelles briques) sans nécessité d’homologation systématique à chaque ajout, sous réserve que :
- Les besoins de sécurité soient similaires.
- La brique additionnelle se conforme aux mesures de sécurité communes à l’ensemble des applicatifs et services gérés dans l’environnement.
- Cet ajout ne suscite pas de vulnérabilités nouvelles ou une plus grande exposition à des sources de risque.

Contraintes sur le périmètre de l’homologation

La profondeur de l’homologation dépend du niveau de maîtrise du système concerné. Dans le cas des systèmes d’information hébergés, le périmètre de l’homologation est condition au niveau de responsabilité du contractant.


Dans le cas extrême des systèmes hébergés en SaaS, l’entité adoptant la décision d’homologation doit concentrer son effort à deux niveaux :

Avant la sélection du fournisseur de service, en évaluant ou en fixant les garanties de sécurité offertes (pouvant prendre la forme d’un « plan d’assurance sécurité ») et en se penchant sur plusieurs offres afin d’identifier le choix le plus sûr.
Une fois le fournisseur sélectionné en concentrant l’effort d’homologation sur les dimensions du projet sur lesquels l’entité contractante dispose d’une marge de manœuvre sur laquelle doit se concentrer l’effort de sécurisation et l’homologation : ex. : identification des données à protéger, configuration du système en vue d’en renforcer la sécurité ; sécurisation de l’environnement informatique d’utilisateur du système, etc

Mis à jour le : 31/03/2025