Audit SI, contrôle interne et diagnostic de conformité

Introduction

Dans cette leçon, l’objectif est de comprendre comment conduire une mission d’audit des systèmes d’information (audit SI) afin d’évaluer la performance et la conformité du système d’information, puis de communiquer un diagnostic structuré utile au client ou à la direction.

Cette leçon s’inscrit dans la continuité :

• de la leçon 91 sur la gouvernance des SI ;
• de la leçon 98 sur la gouvernance stratégique de la donnée ;
• de la leçon 99 sur le pilotage de la performance SI ;
• et, plus largement, de la leçon 58 sur la cartographie des risques et le contrôle interne.

Ici, on change de focale : il ne s’agit plus seulement de piloter le SI, mais de porter un regard critique, méthodique et documenté sur son fonctionnement. L’audit SI vise à répondre à une question centrale :

Le système d’information est-il fiable, efficace, sécurisé et conforme aux exigences applicables ?

L’enjeu n’est pas purement technique. Dans le programme, l’audit SI doit permettre :

• d’accompagner le client dans son pilotage de la performance globale des SI ;
• d’analyser et communiquer les résultats ;
• de mettre en œuvre des outils SI au service de la performance organisationnelle ;
• d’auditer, contrôler et évaluer la performance et la conformité des systèmes d’information ;
• de conduire des missions d’audit et de contrôle des systèmes d’information.

Objectifs de la leçon

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

• définir l’audit SI et son périmètre ;
• distinguer performance, conformité, sécurité et contrôle interne dans un contexte SI ;
• structurer une mission d’audit SI à partir d’une cartographie des processus ;
• identifier les risques SI et évaluer les contrôles internes associés ;
• apprécier la fiabilité, l’efficacité et la sécurité d’un système d’information ;
• intégrer la conformité au RGPD dans le diagnostic ;
• rédiger une note de synthèse ou un diagnostic d’audit SI clair, hiérarchisé et exploitable.

1. Définition et finalités de l’audit SI

1.1 Qu’est-ce que l’audit SI ?

L’audit des systèmes d’information est une démarche structurée d’examen visant à apprécier si le SI d’une organisation :

• soutient correctement les processus métiers ;
• produit une information fiable ;
• fonctionne de manière efficace ;
• protège les actifs informationnels et les traitements de manière sécurisée ;
• respecte les exigences de conformité applicables, notamment réglementaires.

L’audit SI ne se limite donc pas à vérifier des outils informatiques. Il porte sur un ensemble :

• processus ;
• applications ;
• données ;
• acteurs ;
• règles de gestion ;
• dispositifs de contrôle interne ;
• gouvernance.

1.2 Pourquoi auditer un système d’information ?

L’audit SI répond à plusieurs besoins.

a) Vérifier la fiabilité de l’information

Un SI défaillant peut produire :

• des données inexactes ;
• des doublons ;
• des ruptures de traçabilité ;
• des indicateurs erronés ;
• des décisions de gestion mal fondées.

b) Évaluer l’efficacité du SI

Un système peut être conforme mais peu performant :

• traitements trop lents ;
• ressaisies multiples ;
• interfaces mal conçues ;
• processus trop dépendants d’actions manuelles ;
• outils sous-utilisés.

c) Apprécier la sécurité

Le SI doit limiter les risques de :

• perte de données ;
• accès non autorisés ;
• fraude ;
• interruption de service ;
• altération de l’information.

d) Contrôler la conformité

Le diagnostic de conformité peut porter, dans le périmètre du programme, sur des exigences telles que :

• le RGPD pour les données à caractère personnel ;
• les règles internes de gouvernance ;
• les procédures documentées ;
• les exigences contractuelles ou organisationnelles.

1.3 Audit SI et pilotage de la performance globale des SI

Le programme insiste sur l’idée d’accompagner le client dans son pilotage de la performance globale des SI. Cela signifie que l’audit SI ne se réduit pas à détecter des anomalies ; il doit aussi :

• éclairer les arbitrages de gestion ;
• hiérarchiser les priorités ;
• relier les constats techniques aux enjeux métiers ;
• proposer des pistes d’amélioration réalistes.

Autrement dit, l’audit SI est un outil d’aide à la décision.

2. Les critères d’évaluation d’un audit SI

Le programme mentionne explicitement plusieurs critères de performance et de conformité : fiabilité, efficacité, sécurité, conformité RGPD.

2.1 La fiabilité

La fiabilité désigne l’aptitude du SI à produire une information exacte, complète, cohérente et traçable.

Un SI fiable permet de répondre positivement à des questions comme :

• les données saisies sont-elles exactes ?
• les traitements sont-ils cohérents avec les règles de gestion ?
• les extractions produisent-elles les bons résultats ?
• les historiques et journaux permettent-ils de reconstituer les opérations ?

Exemples de signes de non-fiabilité

• absence de contrôle de saisie ;
• référentiels non harmonisés ;
• modification libre de données sensibles ;
• interfaces générant des pertes d’information ;
• absence de rapprochement entre systèmes.

2.2 L’efficacité

L’efficacité mesure la capacité du SI à atteindre les objectifs attendus en soutenant les processus métiers de manière pertinente.

Un SI efficace :

• réduit les délais de traitement ;
• fluidifie les échanges ;
• évite les ressaisies ;
• fournit les informations utiles au bon moment ;
• s’intègre aux besoins réels des utilisateurs.

Exemple

Une entreprise dispose d’un outil de gestion des achats. Si les utilisateurs continuent à traiter les validations par courriel et tableur parallèle, le SI existe, mais son efficacité opérationnelle est faible.

2.3 La sécurité

La sécurité du SI vise la protection des systèmes, des données et des traitements.

Dans une approche d’audit, elle s’apprécie notamment au regard de :

• la gestion des habilitations ;
• l’authentification ;
• la traçabilité des accès ;
• la sauvegarde ;
• la continuité d’activité ;
• la prévention des modifications non autorisées.

L’audit SI n’exige pas ici des tests techniques poussés de type test d’intrusion ; le programme précise qu’une telle exécution détaillée n’est pas attendue. En revanche, il faut savoir évaluer l’organisation de la sécurité.

2.4 La conformité

La conformité correspond à l’adéquation entre les pratiques observées et les exigences applicables.

Dans cette leçon, elle inclut notamment :

• la conformité RGPD ;
• la conformité aux procédures internes ;
• la conformité aux règles de gouvernance du SI ;
• la conformité aux engagements documentés.

La conformité ne signifie pas seulement « avoir des documents ». Il faut vérifier la mise en œuvre effective.

3. Le lien entre audit SI et contrôle interne

3.1 Définition du contrôle interne dans un contexte SI

Le contrôle interne regroupe les dispositifs mis en place pour maîtriser les risques et sécuriser les processus.

Dans le cadre du SI, il comprend par exemple :

• les contrôles d’accès ;
• les validations hiérarchiques ;
• les contrôles de cohérence ;
• les rapprochements automatiques ou manuels ;
• la séparation des tâches ;
• la journalisation des opérations ;
• les procédures de sauvegarde et de reprise.

3.2 Pourquoi l’audit SI évalue le contrôle interne

Un audit SI ne peut pas se limiter à observer les outils. Il doit apprécier si les contrôles intégrés au système ou organisés autour du système permettent réellement de réduire les risques.

Le raisonnement est le suivant :

1. identifier le processus ;
2. repérer les risques ;
3. recenser les contrôles existants ;
4. évaluer si ces contrôles sont adaptés, effectifs et suffisants.

3.3 Exemples de contrôles internes SI

Processus ventes

• contrôle de l’existence d’un client avant facturation ;
• blocage des remises au-delà d’un seuil ;
• validation des avoirs ;
• rapprochement entre commandes, livraisons et factures.

Processus paie

• habilitations limitées sur les données salariales ;
• validation des variables de paie ;
• journal des modifications ;
• rapprochement entre paie calculée et écritures comptables.

Processus achats

• séparation entre création fournisseur, saisie de facture et paiement ;
• validation des bons de commande ;
• contrôle des doublons de factures ;
• piste d’audit des modifications.

4. La démarche générale d’une mission d’audit SI

Le programme attend la capacité à conduire des missions d’audit et de contrôle des systèmes d’information. Une mission d’audit SI suit une logique structurée.

4.1 Cadrer la mission

Avant tout travail, il faut définir :

• le périmètre ;
• les objectifs ;
• les processus concernés ;
• les applications visées ;
• les critères d’évaluation ;
• les livrables attendus.

Questions de cadrage

• Audite-t-on un processus précis ou l’ensemble du SI ?
• Cherche-t-on à évaluer la performance, la conformité, la sécurité, ou les trois ?
• Quels sont les risques prioritaires pour le client ?
• À qui sera destiné le rapport ?

Un bon cadrage évite une mission trop vague ou trop large.

4.2 Cartographier les processus

La cartographie des processus est une base essentielle de l’audit SI. Elle permet de visualiser :

• les activités ;
• les acteurs ;
• les flux d’information ;
• les applications utilisées ;
• les points de contrôle.

Pourquoi cartographier ?

Parce qu’on n’évalue correctement un SI qu’en comprenant comment il soutient les processus métiers.

Éléments d’une cartographie utile

• déclencheur du processus ;
• étapes principales ;
• services impliqués ;
• données d’entrée et de sortie ;
• applications mobilisées ;
• contrôles clés ;
• risques associés.

Exemple simplifié : processus achat-fournisseur-paiement

1. expression du besoin ;
2. validation de la demande ;
3. émission de la commande ;
4. réception ;
5. saisie de la facture ;
6. rapprochement commande/réception/facture ;
7. mise en paiement ;
8. comptabilisation.

À chaque étape, l’auditeur identifie les risques et les contrôles.

4.3 Identifier les risques

L’évaluation des risques est au cœur de l’audit SI.

Typologie de risques fréquemment rencontrés

• risque de fiabilité : données erronées, incomplètes ou incohérentes ;
• risque d’efficacité : lenteur, ressaisie, doublons, dysfonctionnements ;
• risque de sécurité : accès non autorisé, perte de données, absence de sauvegarde ;
• risque de conformité : traitement illicite de données personnelles, non-respect d’une procédure ;
• risque de gouvernance : responsabilités floues, absence de supervision.

Exemple

Dans un outil RH, si plusieurs gestionnaires peuvent modifier librement les coordonnées bancaires sans validation ni journalisation, on cumule :

• un risque de fraude ;
• un risque de fiabilité ;
• un risque de sécurité ;
• un risque de contrôle interne insuffisant.

4.4 Évaluer les contrôles existants

Une fois les risques identifiés, il faut analyser les contrôles clés.

On peut se poser quatre questions :

1. Le contrôle existe-t-il ?
2. Est-il correctement conçu ?
3. Est-il effectivement appliqué ?
4. Réduit-il réellement le risque ?

Contrôles préventifs et détectifs

• Contrôle préventif : empêche l’erreur ou l’anomalie.
  • Exemple : blocage automatique d’une commande au-delà d’un plafond.
• Contrôle détectif : repère l’erreur après sa survenance.
  • Exemple : revue mensuelle des accès anormaux.

Les deux sont utiles, mais un dispositif reposant uniquement sur des contrôles détectifs est souvent moins robuste.

4.5 Recueillir les éléments probants

Pour fonder son diagnostic, l’auditeur SI doit recueillir des éléments probants à partir de méthodes adaptées.

Méthodes courantes

• entretiens avec les utilisateurs, responsables métiers, DSI ;
• analyse documentaire (procédures, habilitations, organigrammes, journaux) ;
• observation des traitements ;
• revue de paramétrages ;
• tests de cohérence ;
• rapprochements ;
• analyse des flux et des extractions.

Le programme n’attend pas des tests techniques d’intrusion, mais une approche multidisciplinaire et critique.

4.6 Formuler un diagnostic et des recommandations

Le diagnostic doit relier :

• le constat ;
• le risque ;
• la cause ;
• la conséquence ;
• la recommandation.

C’est cette structuration qui transforme l’observation en outil d’aide à la décision.

5. Cartographie des processus et audit SI

5.1 La cartographie comme support d’audit

Le programme mentionne explicitement les méthodologies d’audit SI : cartographie des processus, évaluation des risques, contrôles internes.

La cartographie permet de :

• comprendre le fonctionnement réel ;
• identifier les interfaces entre métiers et SI ;
• repérer les zones de rupture ;
• visualiser les redondances ou fragilités ;
• localiser les points de contrôle clés.

5.2 Comment construire une cartographie orientée audit

Une cartographie utile en audit SI ne se contente pas d’un schéma applicatif. Elle doit faire apparaître :

• qui fait quoi ;
• dans quel outil ;
• avec quelles données ;
• selon quelles règles ;
• avec quels contrôles.

5.3 Exemple de lecture critique

Supposons un processus de gestion des notes de frais :

• saisie par le salarié dans un portail ;
• validation par le manager ;
• intégration dans l’outil comptable ;
• remboursement par la trésorerie.

Questions d’audit :

• les justificatifs sont-ils obligatoires ?
• les plafonds sont-ils paramétrés ?
• les validations sont-elles réellement nominatives ?
• les rejets sont-ils tracés ?
• les données personnelles sont-elles conservées selon une durée maîtrisée ?

On voit ici le lien direct entre processus, contrôle interne, conformité et performance.

6. L’évaluation de la conformité RGPD dans l’audit SI

La conformité RGPD fait partie des critères explicitement cités dans le programme de l’UE 5.

6.1 Pourquoi le RGPD est central dans un audit SI

Le système d’information est souvent le support principal des traitements de données à caractère personnel. Dès lors, un audit SI doit vérifier si l’organisation maîtrise :

• les données collectées ;
• les finalités ;
• les accès ;
• la conservation ;
• la sécurité ;
• la traçabilité.

6.2 Points d’attention dans un diagnostic de conformité RGPD

Sans refaire toute la leçon 4, l’audit SI doit intégrer, sur le plan opérationnel, plusieurs vérifications.

a) Identification des traitements

• l’organisation sait-elle où se trouvent les données personnelles ?
• les applications concernées sont-elles recensées ?
• les flux de données sont-ils connus ?

b) Gestion des accès

• les habilitations sont-elles limitées au besoin ?
• les accès sont-ils revus périodiquement ?
• les comptes inactifs sont-ils supprimés ?

c) Durées de conservation

• les données sont-elles conservées plus longtemps que nécessaire ?
• existe-t-il des règles d’archivage et de suppression ?

d) Sécurité et traçabilité

• les accès sensibles sont-ils tracés ?
• les extractions massives sont-elles encadrées ?
• les données sont-elles protégées contre les accès non autorisés ?

e) Documentation et gouvernance

• les procédures existent-elles ?
• les responsabilités sont-elles définies ?
• les utilisateurs sont-ils sensibilisés ?

6.3 Exemple de constat RGPD

Constat : l’outil CRM permet l’export intégral des fiches clients par tout utilisateur commercial.

Risque : diffusion non maîtrisée de données personnelles ; non-respect du principe de limitation des accès.

Conséquence possible : atteinte à la confidentialité, incident de sécurité, exposition réglementaire.

Recommandation : restreindre les habilitations d’export, journaliser les extractions et formaliser une procédure d’autorisation.

7. Évaluer la performance du SI au-delà de la conformité

7.1 Un audit SI n’est pas seulement un audit de conformité

Un SI peut être relativement conforme mais mal adapté aux besoins. L’audit doit donc aussi évaluer la performance organisationnelle du SI.

7.2 Questions de performance à se poser

• le SI soutient-il réellement les processus métiers ?
• y a-t-il des ressaisies ou doubles circuits ?
• les utilisateurs contournent-ils l’outil ?
• les délais de traitement sont-ils excessifs ?
• la qualité des données permet-elle un pilotage pertinent ?
• les tableaux de bord sont-ils alimentés de façon fiable ?

7.3 Indicateurs mobilisables dans l’analyse

Dans la continuité de la leçon 99, l’audit peut s’appuyer sur des KPI SI ou indicateurs d’exploitation, par exemple :

• taux d’incidents ;
• délai moyen de traitement ;
• taux de rejets ;
• taux de données incomplètes ;
• nombre de ressaisies ;
• taux d’utilisation des fonctionnalités ;
• fréquence des anomalies d’habilitation.

L’intérêt de ces indicateurs est double :

1. objectiver les constats ;
2. faciliter la communication des résultats.

8. La rédaction du diagnostic d’audit SI

Le programme insiste sur les techniques de rédaction d’un diagnostic d’audit et d’une note de synthèse. C’est une compétence décisive.

8.1 Pourquoi la rédaction est stratégique

Un audit mal communiqué perd une grande partie de sa valeur. Le destinataire n’attend pas une accumulation de détails techniques, mais :

• une compréhension claire des enjeux ;
• une hiérarchisation des risques ;
• des recommandations actionnables.

8.2 Les qualités d’un bon diagnostic

Un bon diagnostic doit être :

• clair ;
• structuré ;
• factuel ;
• hiérarchisé ;
• argumenté ;
• orienté décision.

8.3 Structure possible d’une note de synthèse d’audit SI

1. Contexte et périmètre

• organisation auditée ;
• processus concernés ;
• applications examinées ;
• objectifs de la mission.

2. Méthodologie

• entretiens réalisés ;
• documents analysés ;
• observations et tests effectués.

3. Synthèse exécutive

• forces du dispositif ;
• faiblesses majeures ;
• niveau global de maîtrise.

4. Constats détaillés

Pour chaque constat :

• fait observé ;
• risque associé ;
• impact potentiel ;
• niveau de criticité.

5. Recommandations

• action proposée ;
• priorité ;
• responsable pressenti ;
• horizon de mise en œuvre.

6. Conclusion générale

• appréciation d’ensemble sur la performance et la conformité du SI.

8.4 Formulation attendue

Il faut éviter les phrases vagues du type :

• « le système semble perfectible » ;
• « il conviendrait d’améliorer la sécurité ».

Il faut préférer une formulation précise :

• « l’absence de revue périodique des habilitations sur l’application achats ne permet pas de garantir l’adéquation des droits d’accès au principe du besoin d’en connaître ».

9. Étude de cas guidée : audit SI d’un processus achats

9.1 Contexte

Une PME utilise un progiciel pour gérer ses achats. La direction souhaite un audit SI ciblé sur le processus achats-fournisseurs-paiements à la suite de retards, d’erreurs de saisie et d’un incident de paiement en double.

9.2 Étape 1 : cartographier le processus

Le processus observé est le suivant :

1. demande d’achat par le service demandeur ;
2. validation par le responsable ;
3. émission du bon de commande ;
4. réception de la marchandise ;
5. saisie de la facture ;
6. validation comptable ;
7. paiement.

Applications utilisées :

• outil achats ;
• messagerie ;
• tableur de suivi parallèle ;
• logiciel comptable ;
• portail bancaire.

9.3 Étape 2 : identifier les risques

Risques relevés :

• ressaisie entre l’outil achats et le logiciel comptable ;
• absence de blocage des factures en doublon ;
• création fournisseur possible par plusieurs utilisateurs ;
• validation par courriel hors outil ;
• absence de revue formalisée des habilitations.

9.4 Étape 3 : évaluer les contrôles internes

Contrôles existants :

• validation hiérarchique par courriel ;
• rapprochement manuel mensuel ;
• mot de passe individuel ;
• journal des paiements dans la banque.

Évaluation :

• contrôles partiellement existants ;
• faible traçabilité ;
• séparation des tâches insuffisante ;
• contrôle détectif tardif sur les doublons.

9.5 Étape 4 : apprécier performance et conformité

Performance

• délai de traitement allongé par les ressaisies ;
• tableurs parallèles révélant une mauvaise appropriation du SI ;
• faible intégration applicative.

Fiabilité

• risque d’erreur élevé lors du transfert manuel ;
• référentiel fournisseur non suffisamment contrôlé.

Sécurité

• droits trop larges sur la création fournisseur ;
• absence de revue périodique des habilitations.

Conformité

• traçabilité insuffisante des validations ;
• conservation de pièces et données non clairement encadrée.

9.6 Étape 5 : recommandations

• mettre en place un contrôle de doublon automatique sur les factures ;
• formaliser la séparation des tâches entre création fournisseur, saisie et paiement ;
• intégrer les validations dans l’outil plutôt que par courriel ;
• organiser une revue trimestrielle des habilitations ;
• réduire les circuits parallèles sur tableur ;
• documenter les règles de conservation des données et justificatifs.

9.7 Exemple de synthèse rédigée

Le processus achats présente un niveau de maîtrise intermédiaire. Le SI soutient globalement l’activité, mais plusieurs fragilités affectent sa fiabilité et son efficacité. Les principaux points de vigilance concernent la ressaisie entre applications, l’insuffisance de séparation des tâches et la faible traçabilité des validations. Le dispositif de contrôle interne apparaît partiellement formalisé et insuffisamment automatisé. Une priorisation des actions est recommandée sur les habilitations, le contrôle des doublons et l’intégration des validations dans l’outil.

10. Méthode pratique pour analyser et communiquer les résultats

Le programme demande explicitement de analyser et communiquer les résultats. Voici une méthode simple et professionnelle.

10.1 Étape 1 : classer les constats

Classer les constats par thème :

• gouvernance ;
• fiabilité des données ;
• efficacité des traitements ;
• sécurité ;
• conformité RGPD.

10.2 Étape 2 : hiérarchiser la criticité

On peut utiliser une grille simple :

• critique : risque majeur, action immédiate ;
• élevée : risque important, action prioritaire ;
• modérée : amélioration nécessaire ;
• faible : optimisation souhaitable.

10.3 Étape 3 : relier chaque constat à un impact métier

Un bon auditeur SI ne s’arrête pas à la technique.

Exemple :

• constat technique : absence de contrôle de doublon ;
• impact métier : risque de double paiement, perte financière, surcharge de traitement.

10.4 Étape 4 : formuler des recommandations réalistes

Une recommandation pertinente doit être :

• précise ;
• proportionnée ;
• faisable ;
• reliée à un responsable et à un délai.

10.5 Étape 5 : adapter le langage au destinataire

• pour la DSI : davantage de précision sur les dispositifs ;
• pour la direction générale : synthèse orientée risques, coûts, performance ;
• pour les métiers : impacts opérationnels et changements concrets.

11. Points de vigilance dans une mission d’audit SI

11.1 Ne pas réduire l’audit SI à l’informatique pure

Le SI est au service des processus. Un audit purement technique manquerait l’essentiel si les usages réels ne sont pas étudiés.

11.2 Ne pas confondre documentation et maîtrise réelle

Une procédure peut exister sans être appliquée. Il faut confronter le prescrit au réel.

11.3 Ne pas négliger les contrôles manuels

Un contrôle interne efficace peut être partiellement manuel. L’auditeur doit évaluer sa robustesse, sa fréquence et sa traçabilité.

11.4 Ne pas oublier l’utilisateur

Les contournements, les tableurs parallèles et les validations hors outil sont souvent des signaux majeurs de faiblesse du SI.

11.5 Ne pas produire un rapport inexploitable

Trop de détails techniques sans hiérarchisation nuisent à la décision. Le diagnostic doit rester lisible.

12. Mémo de synthèse

Notions clés

• Audit SI : examen structuré du système d’information pour évaluer sa performance, sa sécurité et sa conformité.
• Contrôle interne SI : ensemble des dispositifs de maîtrise des risques appliqués aux processus, traitements, accès et données.
• Fiabilité : exactitude, complétude, cohérence et traçabilité de l’information.
• Efficacité : capacité du SI à soutenir utilement les processus métiers.
• Conformité : respect des exigences applicables, notamment du RGPD.
• Cartographie des processus : représentation des activités, acteurs, flux, outils et contrôles servant de base à l’analyse d’audit.
• Diagnostic d’audit SI : document structuré présentant constats, risques, impacts et recommandations.

Logique d’une mission d’audit SI

1. cadrer la mission ;
2. cartographier les processus ;
3. identifier les risques ;
4. recenser et évaluer les contrôles internes ;
5. apprécier fiabilité, efficacité, sécurité et conformité ;
6. formuler des recommandations ;
7. communiquer les résultats dans une note de synthèse structurée.

Questions à toujours se poser

• Le SI soutient-il réellement le métier ?
• Les données sont-elles fiables ?
• Les contrôles internes réduisent-ils les risques ?
• Les accès et traitements sont-ils sécurisés ?
• Les données personnelles sont-elles gérées conformément au RGPD ?
• Les constats sont-ils formulés de manière exploitable par le client ?

Conclusion

L’audit SI est une compétence de synthèse, à la croisée de la gouvernance, du contrôle interne, de la gestion des risques, de la conformité et du pilotage de la performance. Dans l’esprit du programme, il ne s’agit pas de devenir un expert technique de cybersécurité, mais de savoir conduire une mission d’audit et de contrôle des systèmes d’information avec une posture professionnelle d’analyse et de conseil.

La valeur de l’audit SI réside dans sa capacité à :

• objectiver les dysfonctionnements ;
• relier les constats aux risques et aux impacts métiers ;
• apprécier la qualité du contrôle interne ;
• évaluer la conformité, notamment au RGPD ;
• produire un diagnostic clair, hiérarchisé et utile à la décision.

C’est précisément ce qui permet d’accompagner le client dans son pilotage de la performance globale des SI.