{"id":1445,"date":"2026-03-25T17:23:39","date_gmt":"2026-03-25T16:23:39","guid":{"rendered":"https:\/\/regulated-devsecops.com\/uncategorized\/application-risk-classification-framework-2\/"},"modified":"2026-03-26T00:38:14","modified_gmt":"2026-03-25T23:38:14","slug":"application-risk-classification-framework","status":"publish","type":"post","link":"https:\/\/regulated-devsecops.com\/fr\/application-security-governance\/application-risk-classification-framework\/","title":{"rendered":"Cadre de classification des risques applicatifs pour les organisations r\u00e9glement\u00e9es"},"content":{"rendered":"<h2>Pourquoi la classification des risques applicatifs est importante pour les organisations r\u00e9glement\u00e9es<\/h2>\n<p>Les organisations r\u00e9glement\u00e9es exploitent des dizaines \u2014 parfois des centaines \u2014 d&rsquo;applications, chacune portant un profil de risque diff\u00e9rent. Sans un cadre de classification structur\u00e9, les ressources de s\u00e9curit\u00e9 sont trop dispers\u00e9es : les applications critiques re\u00e7oivent le m\u00eame niveau de contr\u00f4le que les utilitaires internes, et les auditeurs trouvent impossible d&rsquo;\u00e9valuer si les contr\u00f4les sont proportionn\u00e9s au risque r\u00e9el.<\/p>\n<p>La classification des risques applicatifs est le fondement qui relie le risque business aux exigences de contr\u00f4le de s\u00e9curit\u00e9. Pour les auditeurs et les responsables conformit\u00e9, elle r\u00e9pond \u00e0 une question simple : <strong>l&rsquo;organisation sait-elle quelles applications comptent le plus, et applique-t-elle les contr\u00f4les en cons\u00e9quence ?<\/strong><\/p>\n<p>Les r\u00e9gulateurs l&rsquo;attendent de plus en plus. DORA exige la classification des actifs ICT par criticit\u00e9. NIS2 exige des mesures proportionn\u00e9es au risque. PCI DSS impose des contr\u00f4les renforc\u00e9s pour les environnements de donn\u00e9es de titulaires de cartes. Sans un cadre d\u00e9fendable, une organisation ne peut pas d\u00e9montrer sa conformit\u00e9.<\/p>\n<p>Un cadre bien impl\u00e9ment\u00e9 pr\u00e9vient deux d\u00e9faillances courantes : la sur-classification (tout est \u00ab critique \u00bb) et la sous-classification (les applications critiques trait\u00e9es comme routini\u00e8res).<\/p>\n<h2>Crit\u00e8res de classification des risques<\/h2>\n<p>Un cadre robuste \u00e9value les applications selon plusieurs dimensions. Aucun crit\u00e8re unique n&rsquo;est suffisant.<\/p>\n<h3>Sensibilit\u00e9 des donn\u00e9es<\/h3>\n<ul>\n<li><strong>Donn\u00e9es personnelles identifiables (PII) :<\/strong> Nom, adresse, num\u00e9ros d&rsquo;identification, donn\u00e9es biom\u00e9triques<\/li>\n<li><strong>Donn\u00e9es financi\u00e8res :<\/strong> Num\u00e9ros de cartes, d\u00e9tails de comptes, transactions<\/li>\n<li><strong>Informations de sant\u00e9 :<\/strong> Dossiers patients, donn\u00e9es diagnostiques<\/li>\n<li><strong>Donn\u00e9es commerciales confidentielles :<\/strong> Secrets commerciaux, plans strat\u00e9giques<\/li>\n<li><strong>Identifiants d&rsquo;authentification :<\/strong> Mots de passe, tokens, cl\u00e9s API, certificats<\/li>\n<\/ul>\n<h3>P\u00e9rim\u00e8tre r\u00e9glementaire<\/h3>\n<ul>\n<li><strong>DORA :<\/strong> Syst\u00e8mes ICT soutenant des fonctions critiques dans les services financiers<\/li>\n<li><strong>NIS2 :<\/strong> Syst\u00e8mes des entit\u00e9s essentielles ou importantes<\/li>\n<li><strong>PCI DSS :<\/strong> Syst\u00e8mes dans l&rsquo;environnement de donn\u00e9es de titulaires de cartes<\/li>\n<li><strong>RGPD :<\/strong> Syst\u00e8mes traitant des donn\u00e9es personnelles de r\u00e9sidents UE<\/li>\n<li><strong>R\u00e9glementation sectorielle :<\/strong> Sant\u00e9, \u00e9nergie, t\u00e9l\u00e9communications<\/li>\n<\/ul>\n<h3>Criticit\u00e9 business<\/h3>\n<ul>\n<li>Impact sur le chiffre d&rsquo;affaires si indisponible<\/li>\n<li>Face client vs. support interne<\/li>\n<li>RTO et RPO<\/li>\n<li>Obligations contractuelles de disponibilit\u00e9<\/li>\n<\/ul>\n<h3>Exposition<\/h3>\n<ul>\n<li><strong>Expos\u00e9e au public :<\/strong> Accessible depuis Internet sans authentification<\/li>\n<li><strong>Externe avec authentification :<\/strong> Portails clients, API partenaires<\/li>\n<li><strong>Interne :<\/strong> R\u00e9seau d&rsquo;entreprise uniquement<\/li>\n<li><strong>Interne restreinte :<\/strong> Segments r\u00e9seau ou postes sp\u00e9cifiques<\/li>\n<\/ul>\n<h3>Complexit\u00e9 d&rsquo;int\u00e9gration<\/h3>\n<ul>\n<li>Connexions syst\u00e8mes en amont et en aval<\/li>\n<li>Acc\u00e8s \u00e0 des bases de donn\u00e9es partag\u00e9es<\/li>\n<li>Exposition d&rsquo;API \u00e0 des tiers<\/li>\n<li>Comptes de service ou identifiants partag\u00e9s<\/li>\n<\/ul>\n<h2>Niveaux de classification<\/h2>\n<table>\n<thead>\n<tr>\n<th>Niveau<\/th>\n<th>Label<\/th>\n<th>Crit\u00e8res<\/th>\n<th>Exemples<\/th>\n<th>Contr\u00f4les requis<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Niveau 1<\/strong><\/td>\n<td>Critique<\/td>\n<td>Donn\u00e9es hautement sensibles ; multiples mandats r\u00e9glementaires ; expos\u00e9 au public ; RTO &lt;4h ; int\u00e9grations \u00e9tendues<\/td>\n<td>Plateforme bancaire, syst\u00e8me de paiement, portail sant\u00e9, plateforme de trading<\/td>\n<td>Suite compl\u00e8te (SAST, DAST, SCA, pentest) ; threat modelling ; approbation s\u00e9curit\u00e9 par release ; surveillance continue<\/td>\n<\/tr>\n<tr>\n<td><strong>Niveau 2<\/strong><\/td>\n<td>\u00c9lev\u00e9<\/td>\n<td>Donn\u00e9es sensibles ; au moins un mandat r\u00e9glementaire ; externe avec authentification ; impact significatif<\/td>\n<td>CRM, plateforme RH avec PII, passerelle API partenaires, reporting financier interne<\/td>\n<td>SAST et SCA par build ; DAST trimestriel ; pentest annuel ; threat model pour changements majeurs<\/td>\n<\/tr>\n<tr>\n<td><strong>Niveau 3<\/strong><\/td>\n<td>Mod\u00e9r\u00e9<\/td>\n<td>Donn\u00e9es sensibles limit\u00e9es ; p\u00e9rim\u00e8tre r\u00e9glementaire minimal ; interne ; impact mod\u00e9r\u00e9<\/td>\n<td>Gestion de projets interne, intranet, gestion documentaire<\/td>\n<td>SAST et SCA par build ; DAST annuel ; revue s\u00e9curit\u00e9 pour changements d&rsquo;architecture<\/td>\n<\/tr>\n<tr>\n<td><strong>Niveau 4<\/strong><\/td>\n<td>Faible<\/td>\n<td>Pas de donn\u00e9es sensibles ; pas de p\u00e9rim\u00e8tre r\u00e9glementaire ; interne restreint ; impact faible<\/td>\n<td>Bacs \u00e0 sable de dev, wikis internes non sensibles, environnements de test<\/td>\n<td>SCA pour d\u00e9pendances ; codage s\u00e9curis\u00e9 standard ; revue p\u00e9riodique<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Comment la classification pilote les contr\u00f4les de s\u00e9curit\u00e9<\/h2>\n<p>Le principe est simple : <strong>les applications de niveau sup\u00e9rieur n\u00e9cessitent plus de contr\u00f4les, des tests plus fr\u00e9quents, une gestion des changements plus stricte et une collecte de preuves plus rigoureuse<\/strong>. Ce mappage doit \u00eatre document\u00e9 dans la politique.<\/p>\n<table>\n<thead>\n<tr>\n<th>Domaine<\/th>\n<th>Niveau 1<\/th>\n<th>Niveau 2<\/th>\n<th>Niveau 3<\/th>\n<th>Niveau 4<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Fr\u00e9quence SAST<\/strong><\/td>\n<td>Chaque commit \/ PR<\/td>\n<td>Chaque build<\/td>\n<td>Chaque build<\/td>\n<td>P\u00e9riodique<\/td>\n<\/tr>\n<tr>\n<td><strong>Fr\u00e9quence DAST<\/strong><\/td>\n<td>Hebdomadaire + avant release<\/td>\n<td>Trimestriel<\/td>\n<td>Annuel<\/td>\n<td>Non requis<\/td>\n<\/tr>\n<tr>\n<td><strong>Fr\u00e9quence SCA<\/strong><\/td>\n<td>Surveillance continue<\/td>\n<td>Chaque build<\/td>\n<td>Chaque build<\/td>\n<td>Trimestriel<\/td>\n<\/tr>\n<tr>\n<td><strong>Tests d&rsquo;intrusion<\/strong><\/td>\n<td>Semestriel<\/td>\n<td>Annuel<\/td>\n<td>Bas\u00e9 sur le risque<\/td>\n<td>Non requis<\/td>\n<\/tr>\n<tr>\n<td><strong>Threat modelling<\/strong><\/td>\n<td>Requis ; mis \u00e0 jour<\/td>\n<td>Changements majeurs<\/td>\n<td>Recommand\u00e9<\/td>\n<td>Non requis<\/td>\n<\/tr>\n<tr>\n<td><strong>Approbation release<\/strong><\/td>\n<td>Responsable s\u00e9curit\u00e9<\/td>\n<td>Revue pour changements significatifs<\/td>\n<td>Gestion standard<\/td>\n<td>Gestion standard<\/td>\n<\/tr>\n<tr>\n<td><strong>R\u00e9tention preuves<\/strong><\/td>\n<td>7 ans<\/td>\n<td>5 ans<\/td>\n<td>3 ans<\/td>\n<td>1 an<\/td>\n<\/tr>\n<tr>\n<td><strong>Revue d&rsquo;audit<\/strong><\/td>\n<td>Trimestriel<\/td>\n<td>Semestriel<\/td>\n<td>Annuel<\/td>\n<td>Revue p\u00e9riodique du programme<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Mod\u00e8le de gouvernance pour la classification<\/h2>\n<h3>Qui classifie<\/h3>\n<p>Le <strong>propri\u00e9taire de l&rsquo;application<\/strong> propose la classification initiale. Ne pas laisser aux seules \u00e9quipes de d\u00e9veloppement.<\/p>\n<h3>Qui revoit et approuve<\/h3>\n<ul>\n<li><strong>S\u00e9curit\u00e9 de l&rsquo;information :<\/strong> Valide le risque technique<\/li>\n<li><strong>Conformit\u00e9 \/ Risque :<\/strong> Confirme le p\u00e9rim\u00e8tre r\u00e9glementaire<\/li>\n<li><strong>Direction business :<\/strong> Confirme la criticit\u00e9 business<\/li>\n<\/ul>\n<h3>Processus d&rsquo;escalade<\/h3>\n<p>En cas de d\u00e9saccord, escalade au comit\u00e9 des risques ou au CISO. D\u00e9cisions document\u00e9es avec justification.<\/p>\n<h3>D\u00e9clencheurs de reclassification<\/h3>\n<ul>\n<li>Nouvelle cat\u00e9gorie de donn\u00e9es sensibles trait\u00e9es<\/li>\n<li>Nouveau mandat r\u00e9glementaire applicable<\/li>\n<li>Passage d&rsquo;exposition interne \u00e0 externe<\/li>\n<li>Incident de s\u00e9curit\u00e9 significatif<\/li>\n<li>Changements architecturaux majeurs<\/li>\n<li>Changement de criticit\u00e9 business identifi\u00e9 lors de la revue annuelle<\/li>\n<\/ul>\n<h2>Ce que les auditeurs doivent v\u00e9rifier<\/h2>\n<ul>\n<li><strong>Politique de classification document\u00e9e<\/strong> avec crit\u00e8res, niveaux et contr\u00f4les associ\u00e9s<\/li>\n<li><strong>Inventaire complet :<\/strong> Toutes les applications classifi\u00e9es \u2014 pas seulement les \u00ab importantes \u00bb<\/li>\n<li><strong>Application coh\u00e9rente :<\/strong> Applications similaires au m\u00eame niveau<\/li>\n<li><strong>Contr\u00f4les conformes au niveau :<\/strong> \u00c9chantillonner et v\u00e9rifier que les contr\u00f4les sont op\u00e9rationnels<\/li>\n<li><strong>Cadence de revue maintenue<\/strong> avec r\u00e9sultats document\u00e9s<\/li>\n<li><strong>Enregistrements de reclassification<\/strong> avec d\u00e9clencheur, revue et ajustement des contr\u00f4les<\/li>\n<li><strong>Enregistrements de gouvernance :<\/strong> Proc\u00e8s-verbaux, d\u00e9cisions d&rsquo;escalade, approbations<\/li>\n<\/ul>\n<h2>Signaux d&rsquo;alerte<\/h2>\n<ul>\n<li><strong>Toutes les applications au m\u00eame niveau :<\/strong> Le cadre n&rsquo;est pas appliqu\u00e9 de mani\u00e8re significative.<\/li>\n<li><strong>Pas de reclassification :<\/strong> Le processus n&rsquo;existe pas ou les changements de risque ne sont pas surveill\u00e9s.<\/li>\n<li><strong>Contr\u00f4les non diff\u00e9renci\u00e9s :<\/strong> Niveau 1 et Niveau 3 avec des tests identiques \u2014 classification d\u00e9corative.<\/li>\n<li><strong>Classification par les seules \u00e9quipes de dev :<\/strong> Risque r\u00e9glementaire et business sous-pond\u00e9r\u00e9.<\/li>\n<li><strong>Pas de supervision de gouvernance :<\/strong> Pas de revue ni d&rsquo;approbation par s\u00e9curit\u00e9 ou risque.<\/li>\n<li><strong>Classifications obsol\u00e8tes :<\/strong> Plus de deux ans sans revue malgr\u00e9 des changements connus.<\/li>\n<\/ul>\n<h2>Lectures compl\u00e9mentaires<\/h2>\n<ul>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/application-security\/\">Vue d&rsquo;ensemble de la s\u00e9curit\u00e9 applicative<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/application-security-governance\/secure-sdlc-fundamentals\/\">Fondamentaux du SDLC s\u00e9curis\u00e9<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/how-auditors-assess-application-security-controls\/\">Comment les auditeurs \u00e9valuent les contr\u00f4les de s\u00e9curit\u00e9 applicative<\/a><\/li>\n<\/ul>\n<hr\/>\n<h3>Articles connexes pour les auditeurs<\/h3>\n<ul>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/\">Glossaire<\/a> \u2014 D\u00e9finitions en langage clair des termes techniques<\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/nis2-security-architecture-explained-2\/\">Architecture de s\u00e9curit\u00e9 NIS2<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/dora-article-28-explained-managing-ict-third-party-risk-in-ci-cd-and-cloud-environments\/\">DORA Article 28 \u2014 Gestion des risques ICT tiers<\/a><\/li>\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/core-ci-cd-security-controls\/\">Contr\u00f4les de s\u00e9curit\u00e9 CI\/CD fondamentaux<\/a><\/li>\n<\/ul>\n<p><em>Nouveau dans l&rsquo;audit CI\/CD ? Commencez par notre <a href=\"https:\/\/regulated-devsecops.com\/fr\/start-here\/\">Guide de l&rsquo;auditeur<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Pourquoi la classification des risques applicatifs est importante pour les organisations r\u00e9glement\u00e9es Les organisations r\u00e9glement\u00e9es exploitent des dizaines \u2014 parfois des centaines \u2014 d&rsquo;applications, chacune portant un profil de risque diff\u00e9rent. Sans un cadre de classification structur\u00e9, les ressources de s\u00e9curit\u00e9 sont trop dispers\u00e9es : les applications critiques re\u00e7oivent le m\u00eame niveau de contr\u00f4le que &#8230; <a title=\"Cadre de classification des risques applicatifs pour les organisations r\u00e9glement\u00e9es\" class=\"read-more\" href=\"https:\/\/regulated-devsecops.com\/fr\/application-security-governance\/application-risk-classification-framework\/\" aria-label=\"En savoir plus sur Cadre de classification des risques applicatifs pour les organisations r\u00e9glement\u00e9es\">Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[126,121],"tags":[],"post_folder":[],"class_list":["post-1445","post","type-post","status-publish","format-standard","hentry","category-regulatory-frameworks","category-application-security-governance"],"_links":{"self":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/posts\/1445","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/comments?post=1445"}],"version-history":[{"count":0,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/posts\/1445\/revisions"}],"wp:attachment":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/media?parent=1445"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/categories?post=1445"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/tags?post=1445"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/post_folder?post=1445"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}