Diagnostic et audit du SI : méthode et restitution

Définir la question avant de collecter

Le périmètre dépend de la décision à préparer. Un diagnostic préalable à un schéma directeur peut examiner l’adéquation du SI aux besoins, ses coûts et sa capacité d’évolution. Un audit de sécurité ou une revue de continuité mobilisent des critères et des compétences plus spécifiques.

Fixez les objectifs, les interlocuteurs, les sources d’information et les limites de l’intervention. Précisez les critères utilisés et la période observée. Le fait de ne pas avoir trouvé une information ne prouve pas qu’un dispositif n’existe pas : cette limite doit apparaître dans la restitution.

Croiser les entretiens avec les preuves

Les entretiens font émerger les irritants, les usages réels et les attentes. Ils doivent être confrontés à des éléments vérifiables : incidents, contrats, inventaires, schémas, rapports de tests, coûts et documents d’exploitation. Plusieurs personnes peuvent décrire différemment un même service parce qu’elles n’en voient pas les mêmes étapes.

Pour chaque constat, notez ce qui a été observé, la source, la date et les conséquences possibles. Séparez l’observation de son interprétation et de la recommandation. Une alerte exprimée par un utilisateur est une piste à examiner ; elle n’est pas automatiquement une conclusion d’audit.

Cartographier ce qui explique les impacts

La cartographie relie les activités aux applications, aux données, aux échanges et aux fournisseurs qui les soutiennent. Elle permet de comprendre pourquoi la défaillance d’un composant peut affecter plusieurs services ou pourquoi un changement apparemment local exige plusieurs projets.

Adaptez le niveau de détail aux enjeux. Pour une application critique, il peut être nécessaire de connaître les interfaces, les responsabilités d’exploitation et les conditions de restauration. Pour un outil secondaire, une description synthétique peut suffire. Documentez les relations incertaines au lieu de leur donner une précision artificielle.

Hiérarchiser les constats selon les conséquences

La priorité dépend de l’impact sur l’activité, de l’exposition au risque et des moyens nécessaires au traitement. L’âge d’un outil ou l’absence d’une technologie récente ne suffisent pas à établir une urgence. Examinez les incidents observés, la maintenabilité, les compétences et les dépendances.

Exemple fictif : une sauvegarde quotidienne est déclarée opérationnelle, mais aucun compte rendu récent ne démontre qu’un dossier complet a été restauré. Le constat porte sur la capacité de reprise non démontrée. La recommandation peut être d’organiser un test documenté, puis d’ajuster les moyens selon ses résultats. Il serait prématuré de conclure que toutes les sauvegardes sont inutilisables.

Restituer pour obtenir des décisions

La synthèse destinée à la direction doit montrer les décisions à prendre et les risques à accepter. Les annexes conservent le détail nécessaire aux équipes. Donner un responsable à une recommandation ne signifie pas que les ressources ont été réservées : ce point doit être arbitré explicitement.

Relier le diagnostic à la trajectoire

Les recommandations doivent rejoindre le portefeuille d’initiatives. Certaines actions corrigent rapidement une faiblesse ; d’autres exigent une évolution d’architecture, une modification contractuelle ou un changement d’organisation. Il faut distinguer l’urgence du traitement et la durée de sa réalisation.

Un diagnostic général ne remplace ni une expertise spécialisée ni une évaluation de conformité lorsqu’elles sont nécessaires. Son intérêt est de donner une base commune aux échanges et de rendre les hypothèses visibles. Les constats doivent ensuite être suivis pour vérifier que les actions ont produit les effets attendus.