Que contient un bon audit AEM ? Savoir le lire et l'exploiter

Un audit AEM coûte du temps à votre équipe et un budget à votre entreprise. Il n’a de valeur que si son rapport permet de décider : quoi corriger, dans quel ordre, avec quel effort. La checklist technique d’audit AEM détaille ce qu’il faut examiner ; cet article explique ce que le rapport doit contenir et comment reconnaître un audit utile.

Quand un audit est-il utile ?

Un audit répond à une question précise. Les situations les plus fréquentes :

• avant une migration vers AEM as a Cloud Service ou une montée de version, pour connaître l’effort réel ;
• lors d’un changement de prestataire, pour savoir ce dont on hérite ;
• quand les performances ou les livraisons se dégradent sans cause identifiée ;
• à l’approche de la fin de support de la version utilisée.

Formulez cette question avant de lancer l’audit : elle détermine le périmètre et évite un rapport exhaustif mais inexploitable.

Ce que l’audit doit couvrir

Selon la question posée, l’audit examine tout ou partie de ces domaines :

1. architecture, versions et service packs ;
2. composants et qualité du code (HTL, Sling Models, services OSGi) ;
3. configuration du Dispatcher et règles de cache ;
4. requêtes Oak, index et performances du référentiel ;
5. workflows et réplication ;
6. sécurité : comptes, droits, filtres, versions vulnérables ;
7. rendu côté client et Core Web Vitals ;
8. DAM, renditions et poids des images.

Le détail des contrôles de chaque domaine est dans la checklist.

Les cinq livrables à exiger

1. Des constats prouvés

Chaque problème doit être accompagné de sa preuve : l’extrait de code, la ligne de configuration, le message de journal ou la mesure qui le démontre. Un constat sans preuve ne peut ni être vérifié ni être corrigé efficacement.

2. Un classement par gravité

Tous les problèmes ne se valent pas. Un bon rapport les classe, par exemple en trois niveaux :

• critique : risque de sécurité, de perte de données ou d’indisponibilité, à traiter immédiatement ;
• important : dégrade les performances, la stabilité ou la capacité à livrer ;
• amélioration : dette technique à résorber au fil de l’eau.

3. Une estimation de l’effort

Pour chaque constat, une estimation de l’effort de correction, même approximative. C’est elle qui permet d’arbitrer : un problème important corrigé en une heure passe avant un problème moyen qui demande trois semaines.

4. Les corrections rapides

Une liste des actions à faible effort et à fort impact, à lancer dès la remise du rapport. Elles montrent rapidement des résultats et donnent de l’élan à la suite.

5. Une feuille de route et une restitution

Un plan qui regroupe les corrections en chantiers ordonnés, puis une restitution avec vos équipes. Le rapport doit être lisible par les développeurs comme par la direction ; la restitution sert à répondre aux questions et à arbitrer ensemble.

Les signaux d’un rapport inutile

Méfiez-vous d’un rapport qui :

• aligne des généralités (« améliorer les performances », « renforcer la sécurité ») sans les relier à votre code ;
• recopie la sortie brute d’un outil automatique, sans tri ni vérification ;
• liste des dizaines de problèmes sans priorité ni effort estimé ;
• ne dit rien de ce qui fonctionne bien et doit être préservé ;
• ne peut pas être rejoué : sans preuves, impossible de vérifier que la correction a résolu le problème.

Préparer l’audit côté client

Un audit avance plus vite quand les accès sont prêts dès le départ :

• accès en lecture au dépôt de code ;
• configuration du Dispatcher et journaux des environnements ;
• Cloud Manager pour AEM as a Cloud Service ;
• un interlocuteur technique disponible pour les questions.

Aucun accès en écriture à la production n’est nécessaire. Un accord de confidentialité peut être signé avant tout accès.

Du rapport à l’action

Le rapport n’est qu’un point de départ. Pour qu’il produise des résultats :

1. traitez les constats critiques sans attendre ;
2. lancez les corrections rapides dans le sprint suivant ;
3. planifiez les chantiers de la feuille de route, avec une mesure avant et après pour vérifier le gain ;
4. refaites un point quelques mois plus tard sur les domaines corrigés.

En résumé

Un bon audit AEM se juge à son rapport : des constats prouvés, classés, chiffrés en effort, et transformés en feuille de route. Si vous avez besoin d’un état des lieux de votre plateforme, l’audit AEM au forfait suit cette méthode, sur un périmètre et un prix fixés avant le démarrage. Si l’audit prépare une migration, voir aussi les questions à trancher avant de migrer vers AEM as a Cloud Service.