Audit

Un audit dit ce qui ne va pas, ce que ça risque de coûter, et dans quel ordre le corriger. S’il s’arrête au constat, il ne sert à rien : chaque point remonté part avec sa remédiation.

Audit de sécurité

Reconnaissance, surface exposée, versions et correctifs, en-têtes HTTP, DNS et messagerie (SPF, DKIM, DMARC, CAA), droits de fichiers, comptes et accès. Sur les applicatifs courants — WordPress, PrestaShop, Dolibarr, Nextcloud, Rocket.Chat, Roundcube, Symfony — les contrôles sont ceux d’un référentiel tenu à jour d’un client à l’autre : un défaut trouvé quelque part devient un contrôle systématique partout.

Audit d’infrastructure

Ce qui tourne, où, sur quoi, et ce qui arrive si ça s’arrête : dimensionnement, sauvegardes réellement restaurables, supervision, réplication, certificats, dépendance à un prestataire ou à un hébergeur. Le même socle sert aux audits comparatifs — choisir un hébergeur, du matériel, une brique logicielle — où la comparaison porte sur des mesures et non sur des plaquettes.

Ce que vous recevez

  • Un état de départ daté, qui fixe ce qui a été observé et quand.
  • Des constats numérotés, chacun avec sa gravité, sa preuve et sa remédiation.
  • Un rapport lisible par un décideur, avec l’ordre de traitement.
  • Sur demande, la mise en œuvre des correctifs : durcissement Apache ou Nginx, en-têtes, DNS, comptes.

Le retest, qui est le vrai livrable

Rejouer la campagne quelques mois plus tard et montrer ce qui a bougé : c’est la seule preuve qu’un audit a servi à quelque chose. Sans état de départ ni rejeu, il reste un document, et six mois plus tard personne ne sait ce qui a été corrigé.

L’outillage qui porte tout ça est décrit sur Outillage d’audit. Ce qui circule d’un client à l’autre, c’est le contrôle ; jamais les données trouvées ailleurs.

Voir aussi Supervision & alertes, Sauvegardes et Infrastructure & hébergement.