Risques SI, conformité et fiabilisation des systèmes

Identifier les cybermenaces, défaillances opérationnelles, risques réglementaires et risques métiers associés au SI. La leçon aborde l’analyse d’impact, la continuité de service, les états financiers, le RGPD, ISO 27001, les NEP et les apports de l’IA.

Introduction

À ce stade du programme, le système d’information (SI) ne doit plus être vu comme un simple ensemble d’outils techniques. Il constitue une infrastructure de fonctionnement, de décision et de contrôle qui soutient le pilotage, la sécurisation et l’évolution des systèmes d’information dans l’organisation. Dès lors, tout défaut du SI peut produire des effets en chaîne : interruption d’activité, perte de données, non-conformité réglementaire, atteinte à l’image, erreurs comptables, voire altération des états financiers.

Dans la continuité des leçons précédentes sur la gouvernance des SI, la gouvernance de la donnée et l’audit SI, cette leçon se concentre sur un bloc précis : identifier, analyser et gérer les risques liés aux systèmes d’information. L’enjeu n’est pas seulement de constater un danger, mais de détecter, évaluer et traiter les risques associés aux systèmes d'information dans une logique de fiabilisation et de continuité.

L’approche attendue en DSCG est résolument managériale et professionnelle : il faut être capable d’alerter, de hiérarchiser, de proposer des mesures de maîtrise et d’apprécier les conséquences d’un risque SI sur les processus, la conformité et la performance globale.

Objectifs d’apprentissage

À l’issue de cette leçon, vous devez être capable de :

  • définir les risques liés aux systèmes d’information ;
  • distinguer les principales catégories de risques : cybermenaces, défaillances opérationnelles, risques réglementaires et risques métiers ;
  • comprendre pourquoi la gestion des risques de cybersécurité est devenue centrale ;
  • relier les risques SI à la continuité de service, à la conformité et à la fiabilité de l’information ;
  • structurer une démarche pour détecter, évaluer et traiter un risque SI ;
  • apprécier les apports de référentiels comme ISO 27001, du RGPD et, lorsque cela éclaire le raisonnement, des NEP sur la fiabilisation des systèmes d’information ;
  • comprendre comment l’intelligence artificielle peut contribuer à la détection et à la prévention de certains risques.

1. Pourquoi les risques SI sont devenus un sujet stratégique

1.1 Le SI comme support de l’activité

Le système d’information organise la circulation, le traitement, le stockage et la restitution de l’information. Il soutient :

  • les processus opérationnels ;
  • les processus de gestion ;
  • les processus comptables et financiers ;
  • les processus de pilotage et de décision.

Un SI défaillant n’affecte donc pas seulement l’informatique. Il affecte l’entreprise elle-même.

1.2 Le risque SI : définition

Un risque lié aux systèmes d’information est la possibilité qu’un événement ou qu’une vulnérabilité affecte le fonctionnement du SI et produise des conséquences négatives sur l’organisation.

Ces conséquences peuvent porter sur :

  • la disponibilité des services ;
  • l’intégrité des données ;
  • la confidentialité des informations ;
  • la traçabilité des opérations ;
  • la conformité réglementaire ;
  • la fiabilité des traitements comptables et décisionnels.

Autrement dit, la gestion des risques SI est au cœur de la capacité à sécuriser et rendre durable le système d'information.

1.3 Pourquoi il faut raisonner en management du risque

Une organisation ne peut pas supprimer tout risque. En revanche, elle peut :

  1. détecter les menaces et vulnérabilités ;
  2. évaluer leur probabilité et leur impact ;
  3. traiter les risques par des mesures adaptées ;
  4. surveiller l’évolution de l’exposition au risque.

Cette logique est cohérente avec les enseignements antérieurs sur le contrôle interne et l’audit : un SI fiable est un SI où les risques significatifs sont identifiés et maîtrisés de manière proportionnée.


2. Les grandes catégories de risques liés aux systèmes d’information

2.1 Les cybermenaces

Les cybermenaces regroupent les attaques ou actes malveillants visant le SI, ses composants ou ses données.

Exemples fréquents :

  • hameçonnage ;
  • rançongiciel ;
  • vol d’identifiants ;
  • compromission de comptes à privilèges ;
  • exfiltration de données ;
  • sabotage logique ;
  • attaque par déni de service.

Pourquoi ces risques sont majeurs

Parce qu’ils combinent souvent :

  • un effet immédiat sur la disponibilité ;
  • une atteinte potentielle à la confidentialité ;
  • un coût élevé de remédiation ;
  • un risque juridique et réputationnel.

Exemple

Une PME reçoit un courriel frauduleux imitant un fournisseur. Un collaborateur clique sur une pièce jointe piégée. Le logiciel malveillant chiffre les serveurs de production et le répertoire comptable. Résultat :

  • arrêt temporaire de l’activité ;
  • impossibilité d’émettre des factures ;
  • retard de clôture ;
  • risque de fuite de données clients ;
  • déclaration potentielle à la CNIL si des données à caractère personnel sont concernées.

On voit ici que gérer les risques de cybersécurité ne relève pas seulement de l’informatique : c’est un enjeu de continuité, de conformité et de gouvernance.

2.2 Les défaillances opérationnelles

Les défaillances opérationnelles correspondent aux dysfonctionnements non nécessairement malveillants qui perturbent le SI.

Exemples :

  • panne matérielle ;
  • indisponibilité réseau ;
  • erreur de paramétrage ;
  • défaut de sauvegarde ;
  • mise à jour mal maîtrisée ;
  • rupture chez un prestataire critique ;
  • mauvaise gestion des habilitations.

Pourquoi elles sont sous-estimées

Parce qu’elles paraissent moins spectaculaires qu’une cyberattaque. Pourtant, elles produisent souvent des effets comparables :

  • interruption d’activité ;
  • perte de données ;
  • retards de traitement ;
  • erreurs dans les restitutions ;
  • désorganisation des équipes.

2.3 Les risques réglementaires

Les risques réglementaires naissent du non-respect d’exigences légales, normatives ou contractuelles applicables au SI.

Ils concernent notamment :

  • le RGPD pour la protection des données à caractère personnel ;
  • les obligations de sécurité et de traçabilité ;
  • les règles d’archivage et de conservation ;
  • certaines attentes liées aux référentiels de sécurité tels que ISO 27001 ;
  • les exigences de documentation, de contrôle et de fiabilité utiles à l’audit.

Exemple

Une entreprise conserve des données personnelles sans base légale claire, sans durée de conservation définie et sans contrôle d’accès satisfaisant. Même sans incident majeur, elle s’expose à :

  • un manquement au RGPD ;
  • une sanction administrative ;
  • une mise en cause de sa gouvernance ;
  • une perte de confiance des clients.

2.4 Les risques métiers

Les risques métiers sont les risques SI qui compromettent directement l’exécution des processus de l’organisation.

Exemples :

  • un ERP indisponible bloque les achats et la facturation ;
  • une erreur de données fausse les indicateurs de pilotage ;
  • un défaut d’interface perturbe la chaîne logistique ;
  • un système comptable non fiabilisé altère les arrêtés.

Le point essentiel est le suivant : le risque SI n’a de sens qu’au regard de ses effets sur les métiers. C’est pourquoi l’analyse ne doit jamais rester purement technique.


3. Détecter les risques associés aux systèmes d’information

3.1 Détecter : de quoi parle-t-on ?

Détecter un risque, ce n’est pas attendre qu’un incident survienne. C’est repérer en amont :

  • les actifs critiques ;
  • les vulnérabilités ;
  • les menaces plausibles ;
  • les scénarios de rupture ;
  • les zones de non-conformité.

3.2 Les questions à poser

Pour détecter les risques SI, on peut structurer l’analyse autour de quelques questions simples :

  1. Quels processus dépendent du SI ?
  2. Quelles données sont critiques ?
  3. Quels composants sont indispensables ?
  4. Quelles menaces peuvent les affecter ?
  5. Quels contrôles existent déjà ?
  6. Où se situent les vulnérabilités ?

3.3 Méthode pratique de repérage

Étape 1 : identifier les actifs critiques

Un actif peut être :

  • une application ;
  • une base de données ;
  • un serveur ;
  • une interface ;
  • un processus ;
  • une compétence clé ;
  • un prestataire essentiel.

Étape 2 : identifier les dépendances

Il faut relier les actifs entre eux :

  • application de vente ↔ base clients ↔ passerelle de paiement ;
  • ERP ↔ comptabilité ↔ reporting ;
  • annuaire d’identités ↔ habilitations ↔ accès métiers.

Étape 3 : repérer les menaces

Pour chaque actif, on recherche :

  • cyberattaque ;
  • panne ;
  • erreur humaine ;
  • défaut de prestataire ;
  • non-conformité ;
  • obsolescence.

Étape 4 : repérer les vulnérabilités

Exemples :

  • mots de passe faibles ;
  • absence de journalisation ;
  • sauvegardes non testées ;
  • droits excessifs ;
  • documentation insuffisante ;
  • absence de procédure de continuité.

Étape 5 : formaliser une cartographie

La cartographie des risques SI permet de visualiser les expositions principales et de prioriser le traitement.


4. Évaluer les risques : probabilité, impact, criticité

4.1 L’évaluation ne se limite pas à une intuition

Une fois les risques repérés, il faut les évaluer. L’enjeu est de distinguer :

  • les risques mineurs, acceptables ;
  • les risques significatifs, à traiter rapidement ;
  • les risques critiques, qui menacent la continuité ou la conformité.

4.2 Les deux dimensions classiques

La probabilité

La probabilité correspond à la vraisemblance de survenance du risque.

Elle dépend par exemple :

  • de l’exposition de l’organisation ;
  • de la fréquence des incidents ;
  • du niveau d’attractivité de la cible ;
  • de la maturité des contrôles existants.

L’impact

L’impact mesure les conséquences si le risque se réalise.

Il peut être :

  • financier ;
  • opérationnel ;
  • juridique ;
  • réputationnel ;
  • comptable ;
  • social.

4.3 La criticité

La criticité résulte du croisement entre probabilité et impact. Elle sert à hiérarchiser les actions.

Exemple de lecture :

  • probabilité faible + impact faible = risque surveillé ;
  • probabilité moyenne + impact élevé = risque prioritaire ;
  • probabilité élevée + impact très élevé = risque critique.

4.4 Intégrer l’impact sur la continuité de service

L’évaluation doit intégrer la continuité de service. Une panne de quelques minutes n’a pas le même effet selon le processus concerné.

Exemple :

  • 15 minutes d’indisponibilité d’un intranet documentaire : impact modéré ;
  • 15 minutes d’indisponibilité d’une plateforme d’encaissement en période de forte activité : impact potentiellement majeur.

4.5 Intégrer l’impact sur les états financiers

Certains risques SI affectent directement la qualité de l’information financière :

  • erreurs d’interface entre modules ;
  • paramétrages comptables erronés ;
  • absence de séparation des tâches ;
  • journalisation insuffisante ;
  • altération des données sources.

Pourquoi est-ce important ? Parce qu’un SI défaillant peut produire :

  • des écritures inexactes ;
  • des omissions ;
  • des retraitements erronés ;
  • une information financière non fiable.

Le lien avec l’audit est évident : les NEP, sans être un référentiel de cybersécurité, rappellent l’importance de l’analyse des risques, du contrôle interne et de la fiabilité des traitements lorsqu’ils influencent l’information comptable et financière.


5. Traiter les risques : la logique de maîtrise

5.1 Les quatre réponses classiques

Une fois le risque évalué, l’organisation peut :

  • éviter le risque ;
  • réduire le risque ;
  • transférer le risque ;
  • accepter le risque.

5.2 Éviter le risque

On supprime la situation génératrice du risque.

Exemple : abandonner une application obsolète et non maintenue devenue trop vulnérable.

5.3 Réduire le risque

C’est la réponse la plus fréquente. Elle consiste à mettre en place des mesures de sécurité ou de contrôle.

Exemples :

  • authentification renforcée ;
  • revue périodique des habilitations ;
  • segmentation des accès ;
  • sauvegardes régulières et testées ;
  • supervision et journalisation ;
  • procédures d’escalade en cas d’incident ;
  • sensibilisation des utilisateurs.

5.4 Transférer le risque

Le transfert peut passer par :

  • l’assurance ;
  • certaines clauses contractuelles ;
  • l’externalisation encadrée.

Attention : transférer le risque ne supprime pas la responsabilité de pilotage.

5.5 Accepter le risque

L’acceptation n’est légitime que si le risque :

  • est faible ou maîtrisé ;
  • coûte trop cher à réduire au regard de son impact ;
  • fait l’objet d’une décision explicite.

6. Gérer les risques de cybersécurité

6.1 Pourquoi la cybersécurité est centrale

La cybersécurité vise à protéger le SI contre les atteintes à :

  • la confidentialité ;
  • l’intégrité ;
  • la disponibilité.

Ces trois dimensions structurent l’essentiel du raisonnement en sécurité.

6.2 Mesures organisationnelles essentielles

La cybersécurité n’est pas seulement technique. Elle repose d’abord sur l’organisation.

Mesures clés :

  • politique de sécurité formalisée ;
  • définition des rôles et responsabilités ;
  • gestion des habilitations ;
  • séparation des tâches ;
  • sensibilisation des utilisateurs ;
  • gestion des incidents ;
  • plan de continuité et plan de reprise.

6.3 Mesures de contrôle courantes

Sans entrer dans un détail technique excessif, les mesures de base comprennent notamment :

  • gestion rigoureuse des identités et des accès ;
  • sauvegardes protégées et testées ;
  • mise à jour des systèmes ;
  • journalisation des événements ;
  • surveillance des comportements anormaux ;
  • limitation des privilèges.

6.4 Exemple de traitement d’un risque cyber

Situation

L’entreprise constate plusieurs tentatives de connexion suspectes sur son application de trésorerie.

Analyse

  • actif critique : application de trésorerie ;
  • menace : compromission de compte ;
  • vulnérabilité : mot de passe seul, sans authentification renforcée ;
  • impact : fraude potentielle, interruption, atteinte financière et réputationnelle.

Réponse

  • mise en place d’une authentification multifacteur ;
  • revue des droits d’accès ;
  • alerte automatique sur connexions inhabituelles ;
  • journalisation renforcée ;
  • sensibilisation des utilisateurs ;
  • procédure de réaction immédiate.

7. La conformité : RGPD, ISO 27001 et fiabilisation

7.1 Le RGPD : une logique de responsabilité

Le RGPD impose une gestion maîtrisée des données à caractère personnel. En matière de risques SI, il faut retenir quelques idées structurantes :

  • les données personnelles doivent être protégées ;
  • les accès doivent être justifiés et maîtrisés ;
  • les incidents peuvent devoir être notifiés ;
  • la sécurité doit être adaptée au risque.

Le RGPD ne se réduit donc pas à une formalité documentaire : il participe à la fiabilisation du SI.

7.2 ISO 27001 : un cadre de management de la sécurité de l’information

ISO 27001 est un référentiel international de système de management de la sécurité de l’information. Son intérêt, pour le raisonnement DSCG, est de fournir une logique structurée :

  • identifier les actifs ;
  • analyser les risques ;
  • choisir des mesures de sécurité ;
  • documenter les responsabilités ;
  • améliorer en continu.

Pourquoi ce référentiel est utile ?

Parce qu’il rappelle que la sécurité ne repose pas sur une mesure isolée mais sur un système cohérent de pilotage.

7.3 Les NEP et la fiabilité du SI

Les normes d’exercice professionnel (NEP) concernent l’audit légal. Elles ne constituent pas un référentiel de cybersécurité, mais elles sont utiles pour comprendre une exigence fondamentale : lorsque le SI contribue à la production de l’information financière, sa fiabilité devient un enjeu d’audit.

Ainsi, un auditeur s’intéressera notamment à :

  • la qualité du contrôle interne ;
  • les habilitations ;
  • la traçabilité ;
  • la sécurisation des traitements automatisés ;
  • le risque d’anomalies significatives lié au SI.

Le lien est donc clair : mieux le SI est maîtrisé, plus l’information financière produite est fiable.


8. Analyse d’impact sur les processus, la continuité et l’information financière

8.1 L’analyse d’impact : définition

Une analyse d’impact consiste à mesurer les conséquences d’un incident SI sur l’organisation.

Elle répond notamment aux questions suivantes :

  • quel processus serait interrompu ?
  • pendant combien de temps ?
  • avec quelles conséquences financières ou réglementaires ?
  • quelles données seraient affectées ?
  • quelles obligations de réaction seraient déclenchées ?

8.2 Impact sur les processus

Exemple : panne d’un outil de gestion commerciale.

Conséquences possibles :

  • impossibilité de saisir les commandes ;
  • retard de livraison ;
  • perte de chiffre d’affaires ;
  • surcharge des équipes ;
  • tensions clients.

8.3 Impact sur la continuité de service

La continuité de service désigne la capacité à maintenir ou à rétablir les fonctions essentielles dans un délai acceptable.

Une organisation doit donc distinguer :

  • les processus critiques ;
  • les délais maximums d’interruption acceptables ;
  • les ressources minimales nécessaires ;
  • les solutions de secours.

8.4 Impact sur les états financiers

Un incident SI peut avoir des effets comptables directs ou indirects :

  • retard de clôture ;
  • pertes de pièces justificatives ;
  • erreurs de valorisation ;
  • incohérences entre modules ;
  • rupture de piste d’audit.

Cas simple

Une interface entre le système de gestion commerciale et la comptabilité échoue silencieusement pendant trois jours.

Effets possibles :

  • chiffre d’affaires incomplet ;
  • TVA mal calculée ;
  • comptes clients erronés ;
  • besoin de retraitement manuel ;
  • risque d’anomalie significative dans les comptes.

9. L’apport de l’intelligence artificielle dans la détection et la prévention des risques

9.1 Ce que l’IA peut apporter

L’intelligence artificielle peut contribuer à la gestion des risques SI en aidant à :

  • détecter des comportements anormaux ;
  • repérer des schémas inhabituels de connexion ;
  • analyser de grands volumes de journaux d’événements ;
  • prioriser des alertes ;
  • accélérer l’investigation.

9.2 Pourquoi l’IA est utile

Les environnements SI génèrent un volume d’événements souvent impossible à traiter manuellement. L’IA peut améliorer :

  • la rapidité de détection ;
  • la capacité de corrélation ;
  • la réactivité opérationnelle.

9.3 Les limites de l’IA

Il ne faut pas idéaliser l’IA. Elle présente aussi des risques :

  • faux positifs ;
  • faux négatifs ;
  • opacité des modèles ;
  • dépendance à la qualité des données ;
  • risques éthiques et de gouvernance.

L’IA doit donc être considérée comme un outil d’aide, non comme un substitut complet au jugement humain.


10. Démarche complète de gestion des risques SI

10.1 Vue d’ensemble

Pour identifier, analyser et gérer les risques liés aux systèmes d'information, une démarche professionnelle peut être structurée en sept étapes.

10.2 Étape 1 : cadrer le périmètre

Déterminer :

  • les processus concernés ;
  • les applications critiques ;
  • les données sensibles ;
  • les acteurs impliqués.

10.3 Étape 2 : recenser les actifs et dépendances

Établir une vision claire de :

  • l’architecture fonctionnelle ;
  • l’architecture applicative ;
  • les prestataires ;
  • les points de concentration du risque.

10.4 Étape 3 : détecter les menaces et vulnérabilités

Repérer :

  • cybermenaces ;
  • erreurs humaines ;
  • défauts de processus ;
  • non-conformités ;
  • obsolescences.

10.5 Étape 4 : évaluer la criticité

Pour chaque scénario :

  • probabilité ;
  • impact ;
  • niveau de maîtrise existant ;
  • criticité résiduelle.

10.6 Étape 5 : définir les traitements

Choisir les réponses adaptées :

  • mesures préventives ;
  • mesures détectives ;
  • mesures correctives ;
  • mesures de continuité.

10.7 Étape 6 : mettre en œuvre et documenter

La documentation est essentielle :

  • registre des risques ;
  • procédures ;
  • responsabilités ;
  • plans d’action ;
  • indicateurs de suivi.

10.8 Étape 7 : surveiller et améliorer

Un risque SI évolue. Il faut donc :

  • suivre les incidents ;
  • mettre à jour la cartographie ;
  • tester les dispositifs ;
  • réviser les contrôles ;
  • intégrer les retours d’expérience.

11. Cas pratique transversal

Situation

Une entreprise de distribution utilise un ERP central pour les achats, les ventes, les stocks et la comptabilité. Elle externalise l’hébergement de certaines applications et gère des données clients. Plusieurs incidents récents ont été signalés :

  • ralentissements fréquents ;
  • droits d’accès trop larges pour certains utilisateurs ;
  • sauvegardes non testées depuis un an ;
  • absence de procédure claire en cas de fuite de données ;
  • rapprochements comptables manuels de plus en plus nombreux.

11.1 Détection des risques

Risques identifiés :

  • risque de cybersécurité lié aux habilitations ;
  • risque opérationnel lié à l’indisponibilité ;
  • risque réglementaire lié au RGPD ;
  • risque comptable lié à la fiabilité des interfaces et traitements.

11.2 Évaluation

  • habilitations excessives : probabilité moyenne, impact élevé ;
  • sauvegardes non testées : probabilité moyenne, impact très élevé ;
  • procédure de fuite absente : probabilité moyenne, impact élevé ;
  • rapprochements manuels croissants : probabilité élevée, impact moyen à élevé.

11.3 Traitement

Plan d’action :

  1. revue immédiate des habilitations ;
  2. test de restauration des sauvegardes ;
  3. formalisation d’une procédure de gestion des violations de données ;
  4. analyse des causes des rapprochements manuels ;
  5. mise en place d’indicateurs de disponibilité et d’incident ;
  6. documentation des contrôles clés.

11.4 Pourquoi ce plan est pertinent

Parce qu’il agit simultanément sur :

  • la sécurité ;
  • la continuité ;
  • la conformité ;
  • la fiabilité comptable.

Il illustre bien la logique attendue : détecter, évaluer et traiter les risques associés aux systèmes d'information dans une perspective de pilotage global.


12. Points de vigilance méthodologiques

12.1 Ne pas réduire le risque SI à la technique

Un risque SI est toujours aussi :

  • organisationnel ;
  • humain ;
  • juridique ;
  • financier ;
  • managérial.

12.2 Ne pas confondre conformité et sécurité

Un système peut être documenté sans être réellement sécurisé. À l’inverse, des mesures techniques peuvent exister sans cadre de conformité suffisant. Il faut articuler les deux.

12.3 Ne pas négliger les impacts comptables

Dans l’univers DSCG, un SI mal maîtrisé peut compromettre la qualité de l’information financière. C’est un point central.

12.4 Ne pas oublier l’amélioration continue

La sécurité n’est jamais acquise. Elle se pilote dans le temps.


Mémo de synthèse

Notions essentielles

  • Risque SI : possibilité qu’un événement affecte le système d’information et nuise à l’organisation.
  • Cybermenace : menace malveillante visant le SI ou ses données.
  • Défaillance opérationnelle : dysfonctionnement interne ou externe perturbant le fonctionnement du SI.
  • Risque réglementaire : exposition au non-respect d’exigences légales ou normatives.
  • Risque métier : conséquence du risque SI sur les processus et objectifs de l’organisation.
  • Criticité : combinaison de la probabilité et de l’impact.
  • Continuité de service : capacité à maintenir ou rétablir les fonctions essentielles.
  • RGPD : cadre de protection des données à caractère personnel.
  • ISO 27001 : référentiel de système de management de la sécurité de l’information.
  • NEP : normes d’exercice professionnel utiles pour penser la fiabilité du SI lorsqu’il influence l’information financière.

Logique d’action

  1. Détecter les actifs, menaces, vulnérabilités.
  2. Évaluer probabilité, impact, criticité.
  3. Traiter par évitement, réduction, transfert ou acceptation.
  4. Surveiller et améliorer en continu.

Idée directrice

La gestion des risques SI sert à sécuriser et rendre durable le système d'information. Elle soutient la continuité d’activité, la conformité réglementaire, la confiance des parties prenantes et la fiabilité des traitements comptables et décisionnels.

Conclusion

Dans une organisation numérisée, la maîtrise des risques SI est une condition de fonctionnement normal. Savoir identifier, analyser et gérer les risques liés aux systèmes d'information revient à protéger non seulement les outils, mais aussi les processus, les données, la conformité et la qualité de l’information produite.

La leçon à retenir est simple : un SI fiable n’est pas seulement un SI performant ; c’est un SI dont les risques sont détectés, évalués et traités avec méthode. C’est précisément cette logique qui permet d’assurer le pilotage, la sécurisation et l’évolution des systèmes d’information dans la durée.