Cadre de classification des risques applicatifs pour les organisations réglementées

Pourquoi la classification des risques applicatifs est importante pour les organisations réglementées

Les organisations réglementées exploitent des dizaines — parfois des centaines — d’applications, chacune portant un profil de risque différent. Sans un cadre de classification structuré, les ressources de sécurité sont trop dispersées : les applications critiques reçoivent le même niveau de contrôle que les utilitaires internes, et les auditeurs trouvent impossible d’évaluer si les contrôles sont proportionnés au risque réel.

La classification des risques applicatifs est le fondement qui relie le risque business aux exigences de contrôle de sécurité. Pour les auditeurs et les responsables conformité, elle répond à une question simple : l’organisation sait-elle quelles applications comptent le plus, et applique-t-elle les contrôles en conséquence ?

Les régulateurs l’attendent de plus en plus. DORA exige la classification des actifs ICT par criticité. NIS2 exige des mesures proportionnées au risque. PCI DSS impose des contrôles renforcés pour les environnements de données de titulaires de cartes. Sans un cadre défendable, une organisation ne peut pas démontrer sa conformité.

Un cadre bien implémenté prévient deux défaillances courantes : la sur-classification (tout est « critique ») et la sous-classification (les applications critiques traitées comme routinières).

Critères de classification des risques

Un cadre robuste évalue les applications selon plusieurs dimensions. Aucun critère unique n’est suffisant.

Sensibilité des données

Données personnelles identifiables (PII) : Nom, adresse, numéros d’identification, données biométriques
Données financières : Numéros de cartes, détails de comptes, transactions
Informations de santé : Dossiers patients, données diagnostiques
Données commerciales confidentielles : Secrets commerciaux, plans stratégiques
Identifiants d’authentification : Mots de passe, tokens, clés API, certificats

Périmètre réglementaire

DORA : Systèmes ICT soutenant des fonctions critiques dans les services financiers
NIS2 : Systèmes des entités essentielles ou importantes
PCI DSS : Systèmes dans l’environnement de données de titulaires de cartes
RGPD : Systèmes traitant des données personnelles de résidents UE
Réglementation sectorielle : Santé, énergie, télécommunications

Criticité business

Impact sur le chiffre d’affaires si indisponible
Face client vs. support interne
RTO et RPO
Obligations contractuelles de disponibilité

Exposition

Exposée au public : Accessible depuis Internet sans authentification
Externe avec authentification : Portails clients, API partenaires
Interne : Réseau d’entreprise uniquement
Interne restreinte : Segments réseau ou postes spécifiques

Complexité d’intégration

Connexions systèmes en amont et en aval
Accès à des bases de données partagées
Exposition d’API à des tiers
Comptes de service ou identifiants partagés

Niveaux de classification

Niveau	Label	Critères	Exemples	Contrôles requis
Niveau 1	Critique	Données hautement sensibles ; multiples mandats réglementaires ; exposé au public ; RTO <4h ; intégrations étendues	Plateforme bancaire, système de paiement, portail santé, plateforme de trading	Suite complète (SAST, DAST, SCA, pentest) ; threat modelling ; approbation sécurité par release ; surveillance continue
Niveau 2	Élevé	Données sensibles ; au moins un mandat réglementaire ; externe avec authentification ; impact significatif	CRM, plateforme RH avec PII, passerelle API partenaires, reporting financier interne	SAST et SCA par build ; DAST trimestriel ; pentest annuel ; threat model pour changements majeurs
Niveau 3	Modéré	Données sensibles limitées ; périmètre réglementaire minimal ; interne ; impact modéré	Gestion de projets interne, intranet, gestion documentaire	SAST et SCA par build ; DAST annuel ; revue sécurité pour changements d’architecture
Niveau 4	Faible	Pas de données sensibles ; pas de périmètre réglementaire ; interne restreint ; impact faible	Bacs à sable de dev, wikis internes non sensibles, environnements de test	SCA pour dépendances ; codage sécurisé standard ; revue périodique

Comment la classification pilote les contrôles de sécurité

Le principe est simple : les applications de niveau supérieur nécessitent plus de contrôles, des tests plus fréquents, une gestion des changements plus stricte et une collecte de preuves plus rigoureuse. Ce mappage doit être documenté dans la politique.

Domaine	Niveau 1	Niveau 2	Niveau 3	Niveau 4
Fréquence SAST	Chaque commit / PR	Chaque build	Chaque build	Périodique
Fréquence DAST	Hebdomadaire + avant release	Trimestriel	Annuel	Non requis
Fréquence SCA	Surveillance continue	Chaque build	Chaque build	Trimestriel
Tests d’intrusion	Semestriel	Annuel	Basé sur le risque	Non requis
Threat modelling	Requis ; mis à jour	Changements majeurs	Recommandé	Non requis
Approbation release	Responsable sécurité	Revue pour changements significatifs	Gestion standard	Gestion standard
Rétention preuves	7 ans	5 ans	3 ans	1 an
Revue d’audit	Trimestriel	Semestriel	Annuel	Revue périodique du programme

Modèle de gouvernance pour la classification

Qui classifie

Le propriétaire de l’application propose la classification initiale. Ne pas laisser aux seules équipes de développement.

Qui revoit et approuve

Sécurité de l’information : Valide le risque technique
Conformité / Risque : Confirme le périmètre réglementaire
Direction business : Confirme la criticité business

Processus d’escalade

En cas de désaccord, escalade au comité des risques ou au CISO. Décisions documentées avec justification.

Déclencheurs de reclassification

Nouvelle catégorie de données sensibles traitées
Nouveau mandat réglementaire applicable
Passage d’exposition interne à externe
Incident de sécurité significatif
Changements architecturaux majeurs
Changement de criticité business identifié lors de la revue annuelle

Ce que les auditeurs doivent vérifier

Politique de classification documentée avec critères, niveaux et contrôles associés
Inventaire complet : Toutes les applications classifiées — pas seulement les « importantes »
Application cohérente : Applications similaires au même niveau
Contrôles conformes au niveau : Échantillonner et vérifier que les contrôles sont opérationnels
Cadence de revue maintenue avec résultats documentés
Enregistrements de reclassification avec déclencheur, revue et ajustement des contrôles
Enregistrements de gouvernance : Procès-verbaux, décisions d’escalade, approbations

Signaux d’alerte

Toutes les applications au même niveau : Le cadre n’est pas appliqué de manière significative.
Pas de reclassification : Le processus n’existe pas ou les changements de risque ne sont pas surveillés.
Contrôles non différenciés : Niveau 1 et Niveau 3 avec des tests identiques — classification décorative.
Classification par les seules équipes de dev : Risque réglementaire et business sous-pondéré.
Pas de supervision de gouvernance : Pas de revue ni d’approbation par sécurité ou risque.
Classifications obsolètes : Plus de deux ans sans revue malgré des changements connus.