• Audit de conformité: Ce type d'audit évalue la conformité du SI aux réglementations et normes en vigueur, permettant d'assurer le respect des obligations légales de l'entreprise
• Audit de sécurité: Cet audit se concentre sur l'évaluation de la fiabilité des contrôles de sécurité mis en place pour protéger les données de l'entreprise garantissant ainsi une meilleure prévention contre les menaces potentielles.

Voir qui a accès à quoi, les droits etc... Voir même engager un pen tester pour tester la sécurité du SI.

Ex: un mec se barre de la boîte, comment on fait pour supprimer le compte du gars

• Audit opérationnel: Avec cet audit, il s'agit d'évaluer l'efficacité des processus opérationnels du SI afin d'optimiser les performances de l'entreprise
• Audit Stratégique: L'objectif de cet audit est d'évaluer dans quelle mesure le SI soutient la stratégie globale de l'entreprise et contribue à la réalisation de ses objectifs.

Adapter l'audit aux enjeux stratégiques et aux processus clés de l'entreprise -> pas totalement, il faut se mettre un peu à côté de la plaque pour trouver les failles (s'il y en a)

[En gros: s'adapter oui, aller dans leur sens non]

Cette étape semble évidente, elle n'est cependant pas toujours respectée.

Pour un audit de SI qui ne se contente pas d'un catalogue de bonnes pratiques, il est indispensable de connaître les enjeux et les processus spécifiques à la structure

Les recommandations obtenues via le SI doivent être utiles, nécessaires et œuvrer à la performances globale de l'entreprise

Elles permettront d'évaluer véritablement l'adaptation du SI et sa performance au regard de l'utilisation qui en est faite et des besoins des collaborateurs.

-> Il sera nécessaire de réaliser une véritable cartographie des processus de l'organisation et des données associées.

"Un bon dev c'est pas celui qui sait tout, c'est celui qui sait où ça pète"

D'où le fait qu'il faut faire un audit où tu vas chercher un peu la merde pour remettre en question ton organisation

Se baser sur un cahier des charges et sur des référentiels

Des éléments supplémentaires peuvent être utiles à la fiabilisation de l'audit, comme l'utilisation d'un CDC au recours de l'audit.

On peut se fier à des référentiels pour faire son cdc:

COBIT, ITIL, ISO/CEI 27000,

• COBIT:
• ITIL: propose un ensemble de bonnes pratiques pour la gestion des services informatiques.

Il vise à améliorer l'efficacité et l'efficience de la prestation des services informatiques, en se concentrant sur la satisfaction des besoins des utilisateurs et des clients

Mettre en place un audit basé sur les risques ( humain, financier, technique)

Cela démontre une volonté de comprendre les risques potentiels et de les gérer de manière poractive. Cette transparence et cette démarche proactive renforcent la confiance des clients, des employés et des partenaires ou investisseurs.

(Genre la NASA a des retours sur le rythme cardiaque de ses gars)

Faire effectuer l'audit par un prestataire indépendant de la DSI

En gros, toi t'es dans ta boîte donc tu sais comment ça fonctionne et t'es pas neutre

La matrice des risques est un outil qui permet de mieux visualiser les niveaux de criticité des risques

Elle sert à apprécier et hiérarchiser les risques éventuels liés à un projet ou à une entreprise

https://blog-gestion-de-projet.com/matrice-gestion-des-risques/

Pourquoi on en fait ?

Parce que c'est important d'anticiper les risques qui peuvent survenir au cours du projet

Comment on fait?

1. Identifier les risques
2. Risques techniques: le projet implique des technologies que nos parties prenantes ne maîtrisent pas.
3. Risques humain: Maladie/décès d'une ressource projet importante, réaffectation de vos ressources projet sur d'autres priorités opérationnelles ou sur d'autres projet par le Top management. Comme action préventive, on peut prévoir des personnes "backup" qui auraient les mêmes compétences que vos ressources projet et pourraient les remplacer en cas d'absence prolongée. Exemple: matrice de compétence. Genre moi si je me barre de blueconfig, le service dev est dans la merde.
4. Risques juridiques: faillite d'un fournisseur, nouvelle législation qui s'applique au projet
5. Risques liés au planning
6. Evaluation des risques

On détermine pour chaque risque une échelle de 1 à 4:

1. Risque improbable : jamais vu
2. Risque peu probable : vu dans d'autres organisations
3. Risque probable : survient dans l'organisation
4. Risque très probable : vécu dans mon secteur d'activité

Ensuite on évalue le niveau d'impact (mineur, majeur, critique, catastrophique)

Une fois notre matrice faite, les risques catastrophiques/critique sont sensés être gérés en premier et c'est eux qui vont nous guider pour: l'estimation des charges, la planning etc...

La solution au risque: c'est sur le papier, celle qui répond au problème, dans la vraie vie c'est celle qui rentre dans le budget (:

Rien ne nous empêche de proposer une solution qui ne rentre pas dans le budget on sait jamais

Il faut aussi voir si la meilleure solution est difficile à rentabiliser