# Audit et réglementation : une responsabilité que vous pouvez prouver · Stilla > Un auditeur ne demande pas si vous avez un processus, mais si vous pouvez montrer qui a fait quoi, quand, et qui a approuvé cela. URL: https://stilla.eywo.digital/fr/blog/audit-and-accountability/ Language: fr Last updated: 2026-10-25 [← Retour au blog](https://stilla.eywo.digital/fr/blog/) Gouvernance8 octobre 2026Mis à jour 25 octobre 20264 min luÉquipe Eywo # Audit et réglementation : une responsabilité que vous pouvez prouver Un auditeur ne demande pas si vous avez un processus, mais si vous pouvez montrer qui a fait quoi, quand, et qui a approuvé cela. Voici comment avoir les réponses prêtes avant que la question ne se pose. Dans de nombreux départements informatiques, les semaines précédant un audit suivent le même rituel. Plusieurs personnes mettent de côté leur travail habituel et rassemblent des preuves. Qui a approuvé ce changement ? Pourquoi cet utilisateur avait-il des droits d'administrateur ? Quand la configuration du pare-feu a-t-elle changé et qui l'a modifiée ? Les réponses existent, mais elles sont dispersées dans des e-mails, des discussions, des exports de différents outils et les souvenirs de personnes, dont certaines ont depuis quitté l'entreprise. Dans le même temps, la pression pour fournir des preuves ne cesse de croître. La réglementation de la cybersécurité, telle que NIS2 et la législation nationale qui la met en œuvre, met généralement l'accent sur la gestion des risques, la responsabilité de la direction et la capacité à démontrer que les mesures de sécurité fonctionnent réellement. Les obligations spécifiques varient selon le type d'organisation et sont mieux évaluées avec des spécialistes juridiques ou de la conformité. Le fil conducteur, cependant, est clair : faire les choses correctement ne suffit pas. Vous devez être en mesure de le prouver. ## Pourquoi l'assemblage de preuves après coup échoue Le problème ne vient rarement du fait qu'une organisation n'a pas de processus. Le problème vient du fait que ces processus ne laissent pas de traces par eux-mêmes. - **Les approbations se produisent en dehors du système.** Le consentement à une interruption est reçu par e-mail, le changement est effectué ailleurs, et le lien entre eux n'existe que dans la tête du gestionnaire des changements. - **L'historique est écrasé.** L'outil montre l'état actuel, mais pas ce qu'il était avant. - **Les actions automatisées sont invisibles.** Les tâches planifiées modifient les données, mais personne ne sait exactement quand ou quoi elles ont fait. - **Les responsabilités restent sur papier.** Une matrice RACI est contenue dans un document, et personne ne vérifie si elle correspond aux autorisations réelles. Le résultat est un audit mené comme un projet, au lieu d'un audit comme un examen de routine des enregistrements. ## Comment aborder la probabilité La véritable préparation à l'audit est un sous-produit du travail quotidien. Si chaque action se produit dans un système qui l'enregistre, les preuves existent au moment où les choses se produisent. Quelques principes : - enregistrer non seulement « qui et quand » mais aussi « ce qui a exactement changé », c'est-à-dire l'état avant et après, - auditer ce que les machines font, pas seulement ce que les gens font, - conserver les enregistrements suffisamment longtemps, - décrire les responsabilités de manière à pouvoir être comparée avec les autorisations réelles. ## Comment Stilla gère cela Stilla conserve une traçabilité de toutes les actions, conservée pendant cinq ans. Pour les changements de configuration, il enregistre l'état avant et après, afin que vous puissiez voir non seulement que quelque chose a changé, mais exactement quoi. Les actions du planificateur, les tâches automatisées qui s'exécutent sans intervention humaine, sont également auditées. Les éléments de la CMDB ont leur propre historique de version. Pour chaque changement, vous pouvez voir qui l'a effectué, quand, quoi a changé et d'où il vient : l'API de découverte, une importation, une modification manuelle ou une synchronisation avec une CMDB principale. Les approbations se produisent dans le système. Les interruptions dans les changements, les demandes et d'autres éléments qui nécessitent une décision sont regroupés dans une file d'approbation unique. Une règle définit qui est le propriétaire, et un rejet est toujours accompagné d'une raison. L'enregistrement de qui a accepté quoi est créé en même temps que le changement. Les responsabilités sont décrites dans une matrice RACI, et Stilla vérifie qu'elle est cohérente avec les autorisations. Si quelqu'un est répertorié comme responsable mais n'a pas de rôle qui lui permettrait d'approuver ou d'exécuter la tâche, cela apparaît. Les rôles sont définis (tout, client, équipe, élément), afin qu'il soit clair non seulement ce que quelqu'un peut faire, mais aussi sur quoi. ## Conclusion Un audit ne devrait pas être un projet. Lorsque la traçabilité est créée automatiquement, les approbations vivent dans le système et les responsabilités sont liées aux autorisations, la réponse à une question d'un auditeur est à quelques clics de distance. L'équipe continue de travailler, et la direction peut être confiante que la responsabilité peut être prouvée. La traçabilité, l'historique de la CMDB et la matrice RACI sont inclus dans l'édition Standard. **Stilla Standard** Pour les organisations qui souhaitent une CMDB fiable et des processus ITSM gérés. [Comparer les éditions →](https://stilla.eywo.digital/fr/editions/) ## Plus d'articles [Gouvernance·25 octobre 2026 ### NIS2 et DORA : ce que l’exploitation IT doit pouvoir prouver Les deux réglementations posent la même question : savez-vous quels services sont impactés par une interruption, qui en est responsable et qu'est-ce qui a changé et quand ? Sans cartographie des dépendances fiable, les réponses sont compilées manuellement, souvent sous pression de temps. Standard3 min lu](https://stilla.eywo.digital/fr/blog/nis2-dora-evidence/)[Gouvernance·17 septembre 2026 ### Plateforme partagée, données client séparées Un fournisseur de services partagés a besoin d'une plateforme pour chaque client, tandis que chaque client souhaite ne voir que ses propres serveurs, incidents et coûts. Voici comment avoir les deux sans compromettre la sécurité. Enterprise4 min lu](https://stilla.eywo.digital/fr/blog/shared-platform-separated-data/)[Gouvernance·25 juin 2026 ### Qui est le propriétaire de ce service ? Une responsabilité que vous pouvez suivre Lorsque personne n'est certain d'être responsable d'un service, les changements sont retardés, les incidents sont renvoyés entre les équipes et les approbations sont bloquées. La propriété claire est le fondement sur lequel repose le reste des opérations. Standard4 min lu](https://stilla.eywo.digital/fr/blog/who-owns-the-service/)