Audit AEM : checklist complète pour évaluer une plateforme Adobe Experience Manager

Auditer une plateforme AEM, c’est regarder simultanément un CMS, un moteur de rendu Java, un DAM, un moteur de workflow et une couche de cache. La complexité de l’écosystème rend les problèmes difficiles à localiser sans méthode. Cette checklist est issue de plusieurs audits réels sur des plateformes AEM 6.5 et AEM Cloud Service, principalement dans les secteurs retail et bancaire.

1. Architecture et versions

Versions et support

# Version AEM installée
curl -u admin:admin http://localhost:4502/system/console/productinfo.json | jq '.data.version'

# Packages installés
curl -u admin:admin "http://localhost:4502/crx/packmgr/list.jsp?q=&_charset_=utf-8" | jq '.results[] | {name, version, lastModified}'

Vérifier :

• AEM est sur une version toujours supportée par Adobe (fin de support = risque sécurité)
• Les Service Packs sont à jour (les SP contiennent des correctifs de sécurité critiques)
• Le JDK est compatible et supporté (Java 11 minimum pour AEM 6.5 SP13+)
• La version de l’Oak JCR est cohérente avec la version AEM

Topologie des instances

• Author → Publisher → Dispatcher : chaîne complète fonctionnelle ?
• Reverse replication configurée pour les assets DAM ?
• Load balancer vérifié (sticky sessions si nécessaire) ?
• En Cloud Service : pipeline CI/CD Cloud Manager configuré ?

2. Composants et développement

Core Components vs Foundation Components

# Lister les composants Foundation encore utilisés
curl -u admin:admin "http://localhost:4502/bin/querybuilder.json?type=cq:Component&path=/apps&property=sling:resourceSuperType&property.value=foundation/components/*&p.limit=-1"

Les composants Foundation sont dépréciés depuis AEM 6.5. Chaque composant Foundation utilisé est une dette technique : pas d’accessibilité native, pas de Style System, modèles HTL anciens.

Qualité des composants custom Points à vérifier dans le code des composants :

• Sling Models correctement annotés (@Model, @Inject, @Via)
• HTL (Sling Template Language) sans logique Java dans les templates
• Pas de scriptlet JSP dans les nouveaux composants (JSP est déprécié)
• Dialogs Coral UI 3 (pas Coral UI 2 ou ExtJS)
• Style System implémenté pour la flexibilité éditoriale

// ✅ Bonne pratique — Sling Model
@Model(adaptables = Resource.class, adapters = MonComposantModel.class,
       defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL)
public class MonComposantImpl implements MonComposantModel {

    @Inject
    @Via(type = ResourceSuperType.class)
    private ComponentContext componentContext;

    @ValueMapValue
    private String titre;

    @ValueMapValue
    @Default(values = "Lire la suite")
    private String labelCta;
    
    // Getter...
}

EditConfig et comportement éditeur

• Les composants ont-ils un cq:editConfig configuré (actions drag-and-drop, inserts) ?
• Le comportement en mode Édition est-il cohérent (placeholder, overlays) ?
• Les composants sont-ils correctement placés dans les groupes de la sidebar ?

3. Performance du Dispatcher

Le Dispatcher est le premier levier de performance AEM. Un Dispatcher mal configuré annule tous les efforts d’optimisation backend.

Taux de cache (cache ratio)

# Analyser les logs Apache pour calculer le cache hit ratio
grep "GET" /var/log/apache2/access.log | \
  awk '{print $9}' | sort | uniq -c
# 200 = cache miss (livraison par le Publisher)
# 304 = cache hit avec validation

Un cache ratio sous 80 % sur les pages publiées signale un problème de configuration.

Règles d’invalidation

# /etc/httpd/conf.dispatcher.d/cache/ams_publish_farm.any
/cache {
    /docroot "/mnt/var/www/html"
    
    /rules {
        /0001 { /type "deny" /glob "*" }
        /0002 { /type "allow" /glob "*.html" }
        /0003 { /type "allow" /glob "*.json" }
        # ⚠️ Ne pas cacher les pages personnalisées
        /0004 { /type "deny" /glob "/content/monsite/fr/mon-compte*" }
    }
    
    /invalidate {
        /0001 { /type "allow" /glob "*" }
    }
    
    /headers {
        "Cache-Control"
        "Content-Disposition"
        "Content-Type"
        "Expires"
    }
}

Points critiques à vérifier :

• Les pages avec contenu personnalisé (espace client, panier) sont-elles exclues du cache ?
• Les règles allowedClients de réplication sont-elles restreintes aux IPs des Publishers ?
• Le serveStaleOnError est-il activé pour la résilience ?
• Les assets (/content/dam) sont-ils mis en cache avec des TTL longs ?

4. Performance JCR et requêtes Oak

Requêtes lentes

# Activer la journalisation des requêtes lentes (> 1000ms)
curl -u admin:admin -X POST "http://localhost:4502/system/console/configMgr/org.apache.jackrabbit.oak.query.QueryEngineSettingsService" \
  -d "slowQueryThresholdInMs=1000" \
  -d "failForUnknownQueryLanguage=false"

# Consulter les requêtes lentes
curl -u admin:admin "http://localhost:4502/system/console/slinglog" | grep "slow query"

Index Oak manquants

# Vérifier les requêtes sans index (traversal queries)
curl -u admin:admin "http://localhost:4502/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3DQuery+Engine+Settings%2Ctype%3DQueryEngineSettings"

Une “traversal query” signifie qu’Oak parcourt le référentiel complet au lieu d’utiliser un index — catastrophique sur des repos de plusieurs millions de nœuds.

<!-- Exemple d'index Oak pour rechercher des pages par template -->
<oak:index xmlns:jcr="http://www.jcp.org/jcr/1.0"
           xmlns:oak="http://jackrabbit.apache.org/oak/ns/1.0">
    <pagesByTemplate
        jcr:primaryType="oak:QueryIndexDefinition"
        type="lucene"
        async="async">
        <indexRules jcr:primaryType="nt:unstructured">
            <cq:PageContent jcr:primaryType="nt:unstructured">
                <properties jcr:primaryType="nt:unstructured">
                    <sling:resourceType
                        jcr:primaryType="nt:unstructured"
                        name="sling:resourceType"
                        propertyIndex="{Boolean}true"/>
                </properties>
            </cq:PageContent>
        </indexRules>
    </pagesByTemplate>
</oak:index>

Taille du référentiel

• Vérifier la taille du segment store (crx-quickstart/repository/segmentstore)
• Compaction oak planifiée (Revision Cleanup) ? En AEM 6.5, configurer le Maintenance Window
• En Cloud Service : la compaction est gérée par Adobe

5. Workflows et réplication

Workflows bloqués

# Lister les instances de workflow en échec
curl -u admin:admin "http://localhost:4502/bin/querybuilder.json?type=cq:WorkflowInstance&property=status&property.value=RUNNING&daterange.property=startTime&daterange.lowerBound=-30d&p.limit=100" | jq '.hits[] | {title, startTime}'

Des workflows “RUNNING” depuis plusieurs jours signalent des blocages. En production, les workflows bloqués peuvent saturer la file et empêcher toute publication.

Files de réplication

• Les agents de réplication Publish sont-ils actifs ?
• Y a-t-il un backlog important dans la queue ? (> 1000 éléments = problème)
• Les timeouts de réplication sont-ils configurés ?

6. Sécurité

Service Users (pas d’admin dans le code)

// ❌ Ne jamais faire en production
ResourceResolver resolver = resolverFactory.getAdministrativeResourceResolver(null);

// ✅ Service User avec droits minimaux
Map<String, Object> params = new HashMap<>();
params.put(ResourceResolverFactory.SUBSERVICE, "mon-service-user");
ResourceResolver resolver = resolverFactory.getServiceResourceResolver(params);

Packages CRX non nécessaires Les packages suivants ne doivent PAS être installés en production :

• crx-explorer
• crx-de-libs
• content-upgrade-tools
• Tout package -dev ou -debug

Utilisateurs par défaut

• L’utilisateur admin avec le mot de passe admin est-il désactivé ?
• Les comptes de service ont-ils des mots de passe forts ?
• L’accès à /crx/de et /system/console est-il restreint par IP ou désactivé en production ?

7. Core Web Vitals et rendu côté client

# Lighthouse sur les pages clés
npx lighthouse https://www.monsite.com/fr/accueil.html \
  --output json --output-path ./lighthouse-accueil.json

npx lighthouse https://www.monsite.com/fr/catalogue.html \
  --output json --output-path ./lighthouse-catalogue.json

Sources de ralentissement fréquentes dans AEM :

• Client Libraries (clientlibs) non minifiées et non concaténées
• Images DAM servies sans redimensionnement adaptatif (balise <img> sans srcset)
• Experience Fragments imbriqués avec de multiples includes Sling
• Scripts third-party (analytics Adobe, Target, Launch) bloquant le rendu

Configuration des clientlibs

# Vérifier la concaténation des clientlibs en production
curl -I "http://localhost:4502/etc.clientlibs/monsite/clientlibs/main.min.js"
# Doit contenir : Content-Encoding: gzip

8. DAM et assets

• Les assets originaux > 5 MB ont-ils des rendus adaptatifs générés ?
• Le Dynamic Media est-il configuré pour servir les images via CDN ?
• Les métadonnées des assets sont-elles complètes (alt text, copyright) ?
• Le purge automatique des assets non référencés est-il configuré ?

Rapport d’audit type

Score global : ██████████░░ 8/12

✅ Core Components à jour
✅ Dispatcher cache ratio > 85%
✅ Service Users correctement configurés

⚠️ 3 Foundation Components encore en production (p.footer, p.responsivegrid, p.image)
⚠️ 2 index Oak manquants sur les requêtes de recherche
⚠️ LCP > 4s sur les pages catalogue (images non redimensionnées)

❌ Package crx-de-libs installé en production
❌ Workflows bloqués : 47 instances RUNNING depuis > 7 jours
❌ Mot de passe admin par défaut non modifié sur le Publisher

Un audit AEM de ce niveau prend 2 à 3 jours selon la taille de la plateforme et la disponibilité des accès. Il aboutit à un plan de remédiation priorisé avec estimation de l’effort par problème.