Audit d’infrastructure : la checklist en 7 points

Un audit d’infrastructure utile n’est pas une liste de “bonnes pratiques” génériques. Il doit produire de la clarté et du séquençage : une liste priorisée de ce qu’il faut corriger, dans quel ordre, avec des responsables.

Voici la checklist (niveau “pratique”) que nous utilisons pour évaluer sécurité, fiabilité, coûts et pratiques d’exploitation.

Les questions auxquelles un bon audit répond

Un audit doit vous dire, clairement :

• Ce qui est risqué aujourd’hui (et pourquoi)
• Ce qui coûte trop cher (et où)
• Ce qui cassera au prochain palier de scale
• Quoi faire en 1, 2, 3 (priorités, responsables, effort)

Livrables attendus

Même pour un audit “léger”, vous devriez obtenir :

• Un backlog priorisé (quick wins + chantiers structurants)
• Un registre de risques (sévérité, probabilité, blast radius)
• Des opportunités de coûts (par service/environnement)
• Un plan 30/60/90 jours d’implémentation

Si vous ne pouvez rien en faire, ce n’est pas un audit, c’est de la recherche.

Checklist (haut niveau)

• Identité & accès : SSO, moindre privilège, break-glass, audit trails
• Périmètre réseau : segmentation, contrôle ingress/egress, hygiène firewall/WAF
• Protection des données : chiffrement, KMS, backups + tests de restauration (restore)
• Runtime & supply chain : images, scanning, secrets, intégrité des artefacts
• Observabilité : SLO, logs, alerting, on-call, gestion d’incident
• Coûts : right-sizing, idle spend, engagements, lifecycle storage

Checklist (détaillée)

1) Identité & accès (IAM)

Le levier le plus rapide pour réduire le risque cloud.

• SSO + MFA sur consoles et SaaS critiques
• Rôles par responsabilité (pas d’admin généralisé)
• Accès break-glass contrôlé et loggé
• Offboarding fiable (cloud + SaaS + Git)
• Identités machine distinctes (pas de secrets partagés)
• Audit centralisé des changements de politiques et authentifications

2) Frontières réseau

Les frontières ne protègent pas de tout, mais réduisent la propagation.

• Segmentation prod/staging/dev
• Inventaire d’exposition publique (LB, gateways, ports)
• Contrôles ingress/egress et justification
• Hygiène firewall/WAF (règles obsolètes, listes d’autorisation (allowlists) trop larges)

3) Données & reprise

Une sauvegarde sans test de restauration est une hypothèse.

• Chiffrement au repos et en transit
• Gestion des clés (responsabilité, rotation, accès)
• Stratégie backup (RPO/RTO réalistes)
• Tests de restauration (restore) : rythme + preuves
• Rétention/suppression (selon contraintes légales et clients)

4) Runtime, conteneurs, supply chain

Zone où l’opérationnel rencontre le risque sécurité.

• Hygiène des images de base et cadence de patch
• Scanning avec owners (pas “scan and ignore”)
• Gestion des secrets (pas dans repo, image, logs)
• Build unique + promotion (pas de rebuild par environnement)
• Approche SBOM/provenance adaptée à votre stade

5) Observabilité et préparation incident

Objectif : détecter vite, restaurer vite.

• Signaux clairs sur les flux critiques client
• SLO (ou golden signals) + logique d’erreur budget
• Alerting actionnable, non-bruyant, avec responsabilité claire
• Astreinte et chaîne d’escalade adaptées à la taille de l’équipe
• Docs incident, timelines, postmortems

6) Change management / delivery

Audit du chemin jusqu’à la prod.

• CI/CD robuste, rollback fiable, protections d’environnement
• Infrastructure-as-code et revue des changements
• Sécurité des releases (feature flags, progressive delivery quand utile)
• Modèle “qui peut déployer quoi” (accès et traçabilité)

7) Coûts et capacité

Les problèmes de coûts sont souvent des problèmes de gouvernance.

• Right-sizing (Kubernetes requests/limits, tailles instances VM)
• Idle spend (environnements inutilisés, volumes orphelins, snapshots oubliés)
• Lifecycle storage (hot vs cold, rétention bornée)
• Stratégie d’engagement (RI/Savings Plans si pertinent)
• Unit economics (coût par client / requête / environnement)

Patterns fréquents

• Rôles IAM trop larges, credentials partagés
• Restore jamais testé
• Dépense non-prod + observabilité hors contrôle
• CI/CD fragile et environnements incohérents
• Alerting qui réveille pour des choses non actionnables

Quand faire un audit ?

Bons déclencheurs :

• Avant de vendre aux grands comptes (exigences sécurité/conformité)
• Après migration/architecture majeure
• Quand incidents ou dépenses augmentent
• Quand vous scalez l’équipe et devez standardiser

Pour que nous appliquions cette checklist à votre stack, notre audit d’infrastructure est à périmètre fixe : 15 000 $, 2 à 4 semaines, avec un backlog priorisé et un plan à 30/60/90 jours.