L'audit de sécurité réglementaire est vécu par la plupart des organisations comme une formalité subie, préparée trois semaines avant l'échéance. C'est ce qui le rend coûteux. Voici comment il se déroule réellement, et ce qui se prépare en amont.
De quoi parle-t-on
L'Agence nationale de la cybersécurité — l'ANCS, anciennement ANSI — encadre en Tunisie une mission d'audit de sécurité des systèmes d'information. Cet audit est périodique, il est conduit par un expert auditeur certifié inscrit auprès de l'agence, et il donne lieu à un rapport assorti d'un plan de correction que l'organisme s'engage à mettre en œuvre.
Le périmètre exact des organismes concernés, la périodicité et le contenu attendu sont fixés par le cadre réglementaire, que l'ANCS publie et met à jour sur son site. C'est la seule source à consulter avant de s'engager : un prestataire qui vous cite un texte de mémoire vous fait perdre du temps.
Que l'auditeur pressenti figure bien au registre des experts auditeurs certifiés publié par l'ANCS. Un audit conduit par un intervenant non inscrit ne vaut rien réglementairement, quelle qu'ait été sa qualité technique — et cela se découvre après paiement.
Ce que l'auditeur va regarder
Le détail varie selon la nature du système, mais la structure de l'examen est stable. En connaître les axes permet de savoir ce qu'on doit être capable de montrer.
- L'organisation. Qui est responsable de la sécurité, avec quelle lettre de mission, quels moyens. Une organisation sans responsable désigné se fait relever ce point avant même tout examen technique.
- L'inventaire. La liste des serveurs, applications, bases, comptes à privilèges et prestataires ayant un accès. C'est le document que personne n'a à jour, et c'est le premier demandé.
- Les accès. Qui peut faire quoi, depuis quand, et ce qui se passe quand quelqu'un quitte l'organisation. Les comptes d'anciens salariés encore actifs sont le constat le plus fréquent, tous secteurs confondus.
- Les sauvegardes. Non pas leur existence, mais la preuve d'une restauration réussie. Une sauvegarde jamais restaurée est une hypothèse, pas une garantie.
- Les mises à jour. Systèmes, applicatifs, composants tiers. Une faille publiée est exploitée automatiquement dans les jours qui suivent ; l'auditeur regarde votre délai moyen d'application, pas votre intention.
- La journalisation. Ce que vous conservez, combien de temps, et si quelqu'un le lit. Des journaux que personne n'exploite comptent pour très peu.
- La continuité. Ce qui se passe en cas d'incident majeur : qui décide, qui prévient, dans quel ordre. Un document de continuité jamais éprouvé sera relevé comme tel.
Les six semaines qui précèdent
La préparation utile n'est pas un chantier de sécurité, c'est un travail de mise en ordre. Elle se mène en interne et elle change le résultat davantage que n'importe quel achat d'outil.
- Reconstituer l'inventaire. Tout ce qui tourne, où, sous quelle version, avec qui comme responsable. Rien ne fait perdre plus de temps pendant l'audit qu'un système découvert en séance.
- Faire le tri dans les comptes. Passer en revue chaque compte d'administration, chaque accès prestataire, chaque clé d'API. Supprimer ce qui ne sert plus. C'est gratuit et c'est le poste qui fait baisser le plus de constats.
- Restaurer une sauvegarde pour de vrai. Sur un environnement de test, chronomètre en main, et consigner le résultat. Vous obtenez au passage la réponse à la question « en combien de temps redémarrons-nous », que la direction pose toujours et à laquelle personne ne sait répondre.
- Rassembler les preuves. Captures, exports de configuration, procès-verbaux de réunion, contrats de prestataires avec leurs clauses de sécurité. Un dispositif réel mais non documenté est noté comme absent : l'auditeur constate ce qu'on lui montre.
- Désigner un interlocuteur unique. Une personne qui connaît le système et qui a le mandat de répondre. Un audit mené à cinq interlocuteurs qui se renvoient les questions dure deux fois plus longtemps.
Acheter des outils dans les semaines qui précèdent. Un pare-feu neuf mal configuré, installé trois semaines avant l'audit, produit plus de constats qu'il n'en évite. Ce qui est valorisé, c'est un dispositif modeste, compris, documenté et effectivement suivi.
Le plan de correction, qui est le vrai livrable
Le rapport n'est pas la fin du travail : c'est le plan de correction qui engage. Trois principes le rendent tenable.
Classez par risque réel, pas par facilité. La tentation est de traiter d'abord les points rapides pour faire du volume ; l'agence, comme votre direction, regarde si les points critiques ont bougé.
Datez chaque action et nommez un responsable. Un plan sans date ni nom n'est pas un plan, et c'est ce qui vous sera opposé à l'audit suivant.
Distinguez ce que vous corrigez de ce que vous acceptez. Certains risques ne seront pas traités — coût, contrainte métier, dépendance à un tiers. Les assumer par écrit, avec la justification et la personne qui l'assume, vaut infiniment mieux que de les laisser en suspens d'un audit à l'autre.
Ce que ça change pour vos projets numériques
Une organisation soumise à cet audit ne peut pas confier un développement à un prestataire qui découvre le sujet à la livraison. Trois exigences doivent figurer dans le cahier des charges dès le départ : la journalisation des accès et des actions sensibles, la gestion des rôles et des habilitations, et la réversibilité — code livré, documentation, aucun composant dont vous ne détenez pas la maîtrise.
Ajoutées au départ, ces exigences représentent quelques jours. Ajoutées après la recette, elles imposent de reprendre l'architecture. C'est l'arbitrage le plus rentable de tout le projet, et c'est aussi le premier que l'on sacrifie quand on compare deux devis sur le seul prix.
Nous ne sommes pas auditeurs certifiés — ce rôle appartient aux experts inscrits auprès de l'ANCS. Nous intervenons de l'autre côté : préparer le système d'information avant le passage, et mettre en œuvre le plan de correction sur la partie applicative et web. Intégration SI, ERP et CRM — marchés publics et coopération — nous écrire.