L’homologation de sécurité formalise la décision d’une autorité d’autoriser l’emploi d’un système d’information au regard de ses risques. Elle concerne un système, des usages et un contexte identifiés. Elle ne certifie pas l’absence de vulnérabilité et ne consiste pas simplement à faire signer un rapport d’audit.
Le guide ANSSI–DINUM publié en 2025 a renouvelé la démarche. Son organisation comporte quatre étapes d’homologation, précédées des travaux de sécurisation. Pour préparer un dossier en 2026, il faut partir de cette édition, puis appliquer les exigences particulières du régime dont relève le système. Une méthode recommandée ne transforme pas, à elle seule, toute organisation privée en organisme légalement soumis à homologation.
Commencer par établir pourquoi le système doit être homologué
La première pièce utile est une note d’applicabilité. Elle identifie le système, l’organisme qui l’exploite, la nature des informations, les échanges réalisés et les textes ou engagements concernés. Écrire seulement « conformité ANSSI » ne permet pas de savoir qui peut décider, quels contrôles sont nécessaires ni quelle durée est autorisée.
Dans le cadre du référentiel général de sécurité, les autorités administratives doivent analyser les risques, déterminer leurs objectifs et les fonctions de sécurité correspondantes, puis réexaminer régulièrement la sécurité. Le décret du 2 février 2010, articles 3 à 5, prévoit également une attestation formelle auprès des utilisateurs. Pour un téléservice, cette attestation est rendue accessible aux usagers selon les modalités prévues. Cela n’implique pas de publier les vulnérabilités ou l’intégralité du dossier technique.
Le champ doit être étudié au-delà de la seule page web visible du public. Des échanges entre administrations et les composants qui les soutiennent peuvent être concernés. Il faut préciser la frontière retenue : application, interfaces, identité, hébergement, exploitation et dépendances. Une homologation limitée à l’interface alors que les données sont administrées ailleurs risquerait de masquer une partie déterminante des risques.
D’autres situations relèvent de règles spécifiques, notamment les systèmes sensibles entrant dans le champ de l’II 901, les informations classifiées couvertes par l’IGI 1300 ou certains systèmes d’importance vitale. Ne confondez pas la mention Diffusion Restreinte avec une classification Secret. Pour les obligations des OIV, examinez le système et les prescriptions applicables à l’opérateur ; une liste générale ne remplace pas cette analyse sectorielle.
Dans la santé, rapprochez également le projet de la PGSSI-S et des règles propres au service. Une certification d’hébergement, une politique sectorielle et une décision d’homologation ont des objets différents. Leur présence dans un même dossier ne permet pas de considérer automatiquement les autres obligations comme satisfaites.
Désigner une autorité capable de prendre la décision
L’autorité doit comprendre les conséquences métier des risques et disposer de la compétence nécessaire pour engager l’organisation. Sa désignation doit respecter les règles applicables et les délégations valables. La personne qui maîtrise le mieux la technique n’est pas nécessairement celle qui peut accepter l’interruption d’un service essentiel ou financer les mesures indispensables.
Le RSSI organise et éclaire les travaux ; les responsables métier décrivent les conséquences ; les équipes techniques mettent en œuvre les protections. Cette répartition ne signifie pas qu’un titre de poste décide universellement de la qualité du signataire. Vérifiez la compétence et les éventuelles conditions particulières du régime applicable, puis conservez l’acte de désignation ou de délégation pertinent.
La politique de sécurité du système d’information devrait préciser comment ces acteurs travaillent ensemble. Elle peut identifier les changements qui nécessitent une nouvelle décision et le circuit d’escalade lorsqu’une action n’avance pas. Un prestataire peut préparer des éléments ou réaliser un audit ; il ne reçoit pas pour autant le pouvoir d’accepter à la place du client les risques que ce dernier supporte.
Dans un projet mutualisé, évitez que chaque participant suppose que l’autre a homologué l’ensemble. L’hébergeur peut documenter son infrastructure, l’éditeur son logiciel et l’organisme son usage. Le dossier doit montrer comment ces contributions s’articulent, quelles dépendances restent externes et qui décide du périmètre réellement exploité.
Construire les preuves avant la réunion de décision
Décrire le système tel qu’il fonctionne
Une cartographie du SI utile montre les composants, les flux et les zones de confiance. Ajoutez les interfaces d’administration, les sauvegardes et les connexions temporaires du support. Un schéma limité aux échanges fonctionnels peut omettre le chemin par lequel une compromission se propagerait.
Rattachez cette cartographie à une version et à une date. Lorsqu’un service est externalisé, précisez ce que vous pouvez vérifier directement et ce que vous connaissez par les engagements ou preuves du prestataire. Signalez les incertitudes restantes : une hypothèse explicite est plus utile à la décision qu’une assurance générale impossible à démontrer.
La sous-traitance cloud demande notamment de répartir les responsabilités sur les identités, les configurations et les incidents. La qualification SecNumCloud d’une offre peut étayer une partie de l’analyse ; elle ne couvre pas automatiquement l’application déployée ni les choix d’habilitation du client. Le périmètre qualifié doit donc apparaître clairement dans le dossier.
Exprimer les risques en conséquences compréhensibles
Une analyse de risques doit permettre de décider. « Vulnérabilité critique sur un serveur » décrit un constat technique ; « possibilité d’altérer les décisions produites par le service sans détection » explique un risque métier. Reliez chaque scénario aux personnes, aux missions ou aux actifs qui pourraient être affectés.
La méthode EBIOS Risk Manager peut structurer ce travail selon le contexte. Elle n’est pas automatiquement la méthode obligatoire pour chaque homologation. L’effort doit correspondre au système, à son exposition et aux règles applicables. Une petite application et une chaîne industrielle critique ne demandent pas le même niveau de démonstration.
Distinguez les mesures en place des mesures seulement prévues. Un achat budgété ou une commande passée ne réduit pas encore un risque comme le ferait une protection déployée et vérifiée. Pour chaque action future, indiquez le responsable, l’échéance, les dépendances et la mesure temporaire éventuelle. Le guide d’hygiène ANSSI aide à identifier des protections de base ; leur pertinence doit ensuite être confrontée au scénario étudié.
Utiliser les audits pour lever des incertitudes
L’audit apporte des constats dans un périmètre et à une date. Expliquez ce qui a été examiné, avec quels accès et quelles limites. L’absence de vulnérabilité détectée lors d’un test court ne démontre pas que toutes les configurations ou dépendances sont maîtrisées. De même, une revue documentaire ne démontre pas à elle seule que les mesures déclarées fonctionnent.
Déterminez les audits imposés par votre régime et ceux justifiés par les risques. La qualification PASSI du prestataire d’audit doit correspondre à la prestation attendue lorsqu’elle est exigée. Ne transformez pas cette exigence circonstanciée en obligation universelle de faire réaliser chaque contrôle par un cabinet externe.
Le dossier doit surtout montrer le traitement des constats : correction vérifiée, mesure compensatoire, risque restant ou point encore non instruit. Un rapport volumineux sans décision sur ses principales conclusions ne permet pas une acceptation éclairée. Pour une faiblesse majeure, une vérification ciblée après correction peut apporter une preuve plus utile qu’une nouvelle revue générale des documents.
Adapter les quatre étapes du guide actuel
Le guide de 2025 distingue la constitution du comité, le choix du niveau de démarche et du dossier, l’évaluation des pièces, puis la commission de décision. Il prévoit trois niveaux adaptés à la criticité et à l’exposition, avec des possibilités de fonctionnement dématérialisé. Les modalités particulières imposées par un texte restent prioritaires.
Dans la pratique, commencez par réunir les compétences nécessaires. Un représentant métier est indispensable pour expliquer l’impact d’une interruption ; un juriste ou le DPO peut éclairer une contrainte particulière ; l’exploitation doit pouvoir confirmer les capacités réelles. La participation doit répondre aux questions du dossier, sans multiplier les intervenants sans fonction définie.
Choisissez ensuite un niveau d’instruction justifié. Une démarche simplifiée ne devrait pas résulter uniquement d’une échéance commerciale proche. Consignez pourquoi la criticité et l’exposition permettent ce niveau et quelles limites restent à vérifier. Si le périmètre change pendant l’instruction, réexaminez ce choix au lieu de maintenir artificiellement le dossier initial.
Organisez la lecture des pièces avant la décision. Les participants doivent pouvoir demander un complément et distinguer une information manquante d’un risque connu. Le premier cas peut empêcher de conclure ; le second peut conduire à une acceptation motivée si le risque est acceptable et si les règles applicables sont respectées. Une homologation n’autorise pas à écarter une obligation légale impérative.
Enfin, présentez une synthèse qui rende les arbitrages visibles. Une fiche par risque important peut relier conséquence, mesures existantes, incertitude, action proposée et décision attendue. Cette présentation est une recommandation pratique, pas un formulaire réglementaire universel. Elle évite de demander à l’autorité de déduire seule les conséquences d’annexes techniques dispersées.
Rédiger une décision qui puisse être suivie
Une décision motivée peut renvoyer à une fiche de risque inhérent et résiduel où hypothèses, preuves des contrôles et incertitudes restent lisibles hors de la réunion.
La méthode de seuils d’appétence au risque cyber distingue les cas acceptables, les dépassements à escalader et les limites d’une simple signature.
La décision identifie le système et sa version de référence, les usages autorisés, les exclusions, la période d’emploi et les conditions éventuelles. Elle renvoie au dossier examiné et au plan d’action. Elle précise les événements susceptibles de conduire à un réexamen. Sans ces éléments, une signature peut être réutilisée abusivement pour un usage ou une extension jamais examinés.
Le risque résiduel doit être intelligible. Évitez les formules « tous les risques sont acceptés » lorsque certaines dépendances n’ont pas été analysées. Indiquez ce que l’autorité sait et accepte, les protections sur lesquelles elle fonde sa décision et ce qui doit encore être réalisé. Une réserve doit avoir un responsable et une suite concrète, sinon elle restera une phrase sans effet opérationnel.
La durée ne se déduit pas d’une règle unique « trois ans obligatoires, cinq ans si mature ». Des régimes imposent leurs propres plafonds. Lorsque aucun maximum réglementaire ne s’applique, l’ANSSI recommande de ne pas dépasser trois ans. Une durée plus courte peut être pertinente face à des changements proches ou à un plan d’action important. Le renouvellement n’est pas automatique.
Il est utile de fixer dès la décision les preuves nécessaires pour constater l’exécution des actions. Pour une restauration, demandez un résultat d’exercice vérifiable ; pour les habilitations, la preuve d’une revue et des retraits effectués. Ne confondez pas une procédure approuvée avec la démonstration de son application. Une certification ISO 27001 peut fournir des éléments sur un système de management, sous réserve de son périmètre ; elle ne prend pas cette décision à votre place.
Exemple : un téléservice change de mode d’hébergement
Supposons qu’un organisme transfère un téléservice vers une infrastructure cloud. L’interface et les fonctionnalités restent identiques, mais l’administration distante, les sauvegardes et les dépendances réseau changent. Reprendre la décision précédente au seul motif que l’application n’a pas évolué ferait disparaître ces modifications de l’analyse.
L’équipe établit une cartographie des nouveaux accès, compare les responsabilités contractuelles et vérifie la restauration dans l’environnement cible. Elle identifie aussi une dépendance à un service d’identité externe. Le responsable métier examine les conséquences d’une indisponibilité de ce service et les moyens de poursuivre les opérations prioritaires.
Si une mesure importante n’est pas encore disponible, l’autorité doit disposer de plusieurs options concrètes : différer la mise en service, limiter certains usages ou accepter un risque résiduel précisément décrit lorsque cela est juridiquement possible. L’urgence du calendrier ne constitue pas une mesure de sécurité. Le choix retenu doit correspondre aux faits présentés et aux moyens réellement engagés.
Le DPO examine parallèlement les conséquences sur les personnes. Une analyse d’impact relative à la protection des données, lorsqu’elle est requise, poursuit un objet propre. Elle peut partager des constats de sécurité avec le dossier d’homologation sans être remplacée par celui-ci. Les exigences de sécurité du RGPD continuent également de s’appliquer pendant l’exploitation.
Maintenir la décision à jour pendant l’exploitation
Le suivi doit permettre de détecter ce qui invalide une hypothèse du dossier : changement de prestataire, ouverture à de nouveaux utilisateurs, incident majeur, suppression d’un mécanisme de protection ou nouvelles données. Prévoyez un interlocuteur qui évalue ces événements et sollicite l’autorité lorsque le risque ou le périmètre change substantiellement.
Une revue périodique rassemble les actions achevées, les retards, les incidents et les changements à venir. Le rythme doit respecter les règles applicables et l’organisation retenue. Il ne dispense pas d’agir entre deux réunions lorsqu’une vulnérabilité importante apparaît. Les preuves anciennes doivent rester consultables, avec les versions qui ont fondé chaque décision.
En matière de NIS2, ne fondez pas le dossier sur une transposition française supposée achevée en octobre 2024. Au 28 septembre 2026, le dossier parlementaire situe encore le projet de loi dans son parcours législatif et l’ordre du jour annonce une discussion le 7 octobre. Cette programmation peut évoluer et ne vaut pas adoption. La veille sur la transposition NIS2 doit rester distincte de l’application des obligations déjà en vigueur.
Questions fréquentes
L’ANSSI signe-t-elle chaque homologation ?
Non. L’autorité compétente dépend du régime et de l’organisation. Certains systèmes soumis à des règles particulières appellent l’intervention d’autorités désignées. Pour votre projet, identifiez le fondement de compétence et les délégations avant de préparer la signature.
Une commission physique est-elle toujours nécessaire ?
Les modalités dépendent du régime et du niveau de démarche. Le guide actuel admet certaines décisions par voie dématérialisée. L’essentiel reste une instruction adaptée, un avis exploitable et une décision formelle traçable ; une réunion ne compense pas un dossier insuffisant.
Peut-on homologuer avec des actions restantes ?
Cela peut être possible lorsque les risques restants sont connus et acceptables pour l’autorité, dans le respect des exigences applicables. Le plan d’action et les conditions d’emploi doivent alors être explicites. Une obligation impérative non respectée ne devient pas facultative par la signature d’une acceptation de risque.