L’homologation de sécurité des systèmes d’information a longtemps été perçue comme une procédure administrative complexe, mobilisant une documentation importante et de nombreux intervenants. Avec son guide élaboré en collaboration avec la Direction interministérielle du numérique (DINUM), l’Agence nationale de la sécurité des systèmes d’information (ANSSI) propose une approche plus pragmatique.
« L’objectif n’est plus de multiplier les justificatifs, mais de permettre à une autorité responsable de décider, en connaissance de cause, si un système d’information peut être utilisé au regard des risques qu’il présente. »
Cette évolution introduit trois niveaux de démarche, adaptés à la criticité et à l’exposition des systèmes, tout en maintenant un principe fondamental : une homologation constitue une décision formelle d’acceptation des risques, et non une garantie d’absence de vulnérabilités.
Homologuer ne signifie pas certifier qu’un système est sécurisé
La distinction constitue le fondement de la doctrine de l’ANSSI. L’homologation de sécurité consiste à autoriser la mise en service ou le maintien en exploitation d’un système d’information après avoir identifié les risques liés à son utilisation et apprécié les mesures prises pour les maîtriser.
Contrairement à une certification délivrée par un organisme tiers, la décision d’homologation relève d’une autorité compétente, généralement située au niveau de la direction ou disposant d’une délégation appropriée. cela ne signifie pas que le système est exempt de vulnérabilités.
L’ANSSI précise qu’un système peut être homologué alors que certains risques n’ont pas encore été entièrement traités, dès lors qu’ils sont connus et jugés acceptables par l’autorité responsable.
Cette possibilité ne doit pas être interprétée comme une autorisation de négliger la sécurité. Elle suppose que les risques résiduels soient clairement présentés, que les mesures de traitement soient identifiées et que les décisions soient formalisées.
« L’homologation ne fait donc pas disparaître le risque. Elle rend son acceptation explicite et engage l’autorité qui prend la décision. »
Trois niveaux de démarche pour éviter une complexité inutile
L’une des principales évolutions introduites par l’ANSSI concerne la proportionnalité des travaux. La nouvelle doctrine distingue trois niveaux de démarche :
simplifié, intermédiaire et renforcé. Le niveau simplifié s’adresse aux systèmes peu critiques et faiblement exposés. Un site internet vitrine ou un système interne isolé peut, selon son contexte, relever de cette catégorie.
Le niveau intermédiaire concerne les systèmes présentant des enjeux de sécurité ou une exposition plus importants, notamment lorsqu’ils traitent des données personnelles. Enfin, le niveau renforcé s’applique aux systèmes critiques ou particulièrement exposés, pour lesquels une analyse approfondie des risques et des mesures de sécurité est nécessaire.
Le choix du niveau ne dépend pas uniquement de la complexité technique du système. Il repose sur deux critères essentiels : les conséquences potentielles d’un incident pour l’organisation et l’exposition aux différentes sources de risque.
Cette distinction permet d’éviter qu’une application relativement simple mais essentielle à une activité bénéficie d’une évaluation insuffisante, ou qu’un système peu sensible fasse l’objet de travaux disproportionnés. La démarche doit ainsi correspondre aux enjeux réels de sécurité plutôt qu’à la seule dimension technique de l’infrastructure.
Moins de documentation, mais des éléments toujours vérifiables
La simplification proposée par l’ANSSI concerne également la constitution du dossier d’homologation. Le guide recommande de privilégier les documents déjà produits pour concevoir, exploiter et sécuriser le système d’information, plutôt que de créer un ensemble documentaire spécifique à la seule homologation.
Cartographie, analyse de risques, procédures d’exploitation, résultats d’audit et plan d’action doivent être mobilisés en fonction des besoins de la démarche. Le document de synthèse destiné à éclairer la décision doit, selon le guide, rester succinct, généralement limité à une ou deux pages.
Pour les systèmes relevant des niveaux simplifié et intermédiaire, une déclaration des équipes opérationnelles attestant de l’application des mesures de sécurité peut permettre l’émission d’un avis favorable, sous les conditions prévues par la doctrine. Les contrôles peuvent alors être effectués a posteriori.
En revanche, pour les systèmes relevant du niveau renforcé, le comité d’homologation doit examiner les éléments justifiant la maîtrise des risques avant de formuler son avis. Cette évolution repose sur une logique de confiance encadrée.
« La réduction des formalités ne doit pas supprimer la capacité à démontrer que les mesures annoncées sont effectivement appliquées. »
Une déclaration inexacte, une documentation obsolète ou des contrôles insuffisants peuvent compromettre la pertinence de la décision, même lorsque la procédure administrative a été respectée.
La responsabilité du décideur reste centrale
Le guide distingue les responsabilités des équipes opérationnelles, des fonctions de sécurité et des instances chargées d’évaluer les risques. La direction des systèmes d’information assure généralement la mise en œuvre des mesures techniques et organisationnelles. Le RSSI accompagne la démarche, pilote les analyses de risques et contribue à vérifier l’application des exigences de sécurité.
Le comité d’homologation rassemble les compétences nécessaires pour examiner le dossier et formuler un avis, mais la décision d’autoriser l’exploitation revient à l’autorité d’homologation. Cette répartition évite de confondre expertise technique et responsabilité décisionnelle.
Un RSSI peut signaler une vulnérabilité importante, recommander une correction ou formuler un avis défavorable. Il ne lui appartient pas nécessairement de décider si les conséquences métiers d’une interruption du système justifient son maintien en fonctionnement. Cette appréciation relève de l’autorité responsable, qui doit disposer d’informations suffisamment précises pour mesurer les conséquences de son choix.
L’ANSSI insiste sur la nécessité de présenter ouvertement les risques, sans les dissimuler ni les minimiser. Une homologation peut également être prononcée avec des réserves. Dans les situations prévues par le guide, celles-ci doivent être levées dans un délai maximal de douze mois.
L’existence de réserves ne dispense donc pas de traiter les problèmes identifiés, elle permet de formaliser une décision d’exploitation assortie d’engagements précis, dont l’exécution doit être suivie.
Une obligation réglementaire qui ne concerne pas tous les systèmes
L’homologation est obligatoire dans plusieurs cadres réglementaires français. Le guide identifie notamment les systèmes d’information soumis au Référentiel général de sécurité (RGS), certains systèmes de l’État et de ses établissements publics, les systèmes traitant des informations classifiées et les systèmes d’information d’importance vitale (SIIV).
Les exigences diffèrent selon les réglementations applicables, notamment en matière d’autorité compétente, d’audits et de durée de validité.
Il serait toutefois inexact d’en déduire que toutes les entreprises privées sont légalement tenues d’homologuer l’ensemble de leurs systèmes d’information. En dehors des obligations réglementaires spécifiques, l’ANSSI recommande fortement cette démarche pour les systèmes présentant une importance critique pour l’organisation.
L’homologation peut alors constituer un outil de gouvernance permettant de formaliser les arbitrages de sécurité et de documenter l’acceptation des risques. Elle doit néanmoins rester distincte des autres dispositifs de conformité.
La certification ISO/IEC 27001, par exemple, évalue un système de management de la sécurité de l’information selon les exigences d’une norme internationale. L’homologation porte, quant à elle, sur la décision d’utiliser un système d’information déterminé au regard de ses risques.
Ces deux approches peuvent se compléter sans être équivalentes.
Une décision qui ne met pas fin à la surveillance
L’homologation ne constitue pas une autorisation permanente. Le guide recommande de ne pas dépasser une durée de trois ans, sauf exigences réglementaires plus restrictives, et de revoir la sécurité des systèmes d’information au moins une fois par an.
Ces revues doivent notamment examiner l’avancement des mesures de sécurité, les incidents survenus, les évolutions du système et les changements susceptibles de modifier son exposition aux menaces. Une modification importante de l’architecture, l’intégration d’un nouveau prestataire ou l’apparition d’un risque majeur peuvent conduire à réexaminer la décision initiale.
Le renouvellement de l’homologation doit également prendre en compte les actions effectivement réalisées depuis la précédente décision.
L’ANSSI déconseille ainsi de renouveler une homologation lorsque les faiblesses de sécurité identifiées n’ont fait l’objet d’aucune amélioration. Cette exigence replace la démarche dans une logique de suivi continu, depuis la conception du système jusqu’à son décommissionnement.
De la procédure administrative à la décision de gouvernance
L’évolution proposée par l’ANSSI répond à une difficulté concrète : sécuriser un nombre croissant de systèmes d’information sans mobiliser des ressources disproportionnées dans la production et l’examen de documents.
En adaptant les démarches à la criticité et à l’exposition des systèmes, la nouvelle doctrine cherche à concentrer les efforts sur les situations présentant les risques les plus importants. Elle ne remet cependant pas en cause la responsabilité de l’autorité qui autorise l’exploitation. Au contraire, la simplification des travaux rend d’autant plus nécessaire la qualité des informations utilisées pour décider.
Une cartographie incomplète, une analyse de risques insuffisante ou des mesures de sécurité déclarées mais non appliquées peuvent conduire à une appréciation erronée du niveau de protection.
La véritable portée de cette nouvelle doctrine réside dans cette distinction : simplifier la procédure d’homologation ne signifie pas simplifier l’appréciation des risques.
L’enjeu pour les organisations n’est donc pas seulement d’obtenir une décision formelle, mais de s’assurer que celle-ci repose sur une connaissance réelle du système d’information, de ses vulnérabilités et des conséquences possibles de son exploitation.
ANSSI : L’homologation de sécurité des systèmes d’information
