AEM Content Fragments vs Experience Fragments : quand utiliser quoi ?

Content Fragments et Experience Fragments sont deux fonctionnalités AEM souvent confondues. Elles ont des finalités radicalement différentes. Comprendre la distinction est essentiel pour architecturer correctement votre contenu.

Content Fragments : du contenu pur, sans présentation

Un Content Fragment (CF) est du contenu structuré découplé de toute présentation. C’est du texte, des chiffres, des références, organisés selon un modèle défini. Pas de HTML, pas de style — uniquement des données.

Où ils vivent : sous /content/dam/ (dans le DAM, pas dans les pages)

Structure : définie par un Content Fragment Model (cfm), créé dans Outils > Assets > Modèles de fragment de contenu.

Modèle "Article de blog" :
- titre (texte court, obligatoire)
- resume (texte court)
- contenu (éditeur de texte riche)
- auteur (référence → modèle "Auteur")
- tags (texte multiple)
- datePublication (date)
- imageHero (référence → Asset)

Usage typique : création de contenu réutilisable sur plusieurs canaux (web, app mobile, email, affichage digital) depuis un seul endroit.

Experience Fragments : du contenu avec sa présentation

Un Experience Fragment (XF) est un fragment de page AEM — un groupe de composants avec leur contenu et leur mise en forme. C’est une section de page réutilisable.

Où ils vivent : sous /content/experience-fragments/

Structure : une variation de page AEM classique, avec des composants (texte, image, bouton, etc.)

Usage typique : header, footer, bannières promotionnelles, sections récurrentes qu’on réutilise sur plusieurs pages du même site, ou exporte vers des canaux tiers (Adobe Target, Adobe Campaign).

Comparaison directe

	Content Fragment	Experience Fragment
Contenu	Structuré, sans HTML	Composants AEM avec mise en forme
Édition	Éditeur de CF dédié	Éditeur de page AEM standard
Stockage	DAM (/content/dam)	Pages (/content/experience-fragments)
Rendu	Via GraphQL ou API REST	Via un composant <ExperienceFragment> ou iframe
Multi-canal	Natif (même CF, 10 canaux)	Limité (rendu HTML AEM)
Variations	Plusieurs versions du même CF	Plusieurs variantes de présentation
Headless	Idéal pour AEM headless	Pas adapté

Quand utiliser les Content Fragments ?

Architecture headless ou hybride : votre front-end React, Angular ou mobile consomme du contenu via l’API GraphQL AEM. Les CFs sont la brique fondamentale.

# Requête GraphQL pour récupérer des articles
query GetArticles($path: String) {
  articleList(filter: { _path: { _expressions: [{ value: $path, _operator: STARTS_WITH }] } }) {
    items {
      titre
      resume
      auteur {
        ... on AuteurModel {
          nom
          photo { _publishUrl }
        }
      }
      datePublication
      imageHero { _publishUrl width height }
    }
  }
}

Contenu multi-canal : le même article de blog publié sur le site, dans la newsletter et dans l’app mobile. Un seul CF, trois canaux, zéro duplication.

Contenu de référence : produits, auteurs, catégories, lieux — des entités métier réutilisées dans d’autres CFs.

Quand utiliser les Experience Fragments ?

Sections réutilisées entre pages : un bloc promotionnel “Soldes d’été” qui apparaît sur la homepage, la page catégorie et la page produit. Modifiez l’XF, toutes les pages se mettent à jour.

Personnalisation avec Adobe Target : les XFs s’exportent vers Target pour des tests A/B et la personnalisation. C’est leur cas d’usage primaire dans l’écosystème Adobe.

XF "Bannière Promo Été" → Export vers Adobe Target
                        → Test A/B : variante A (rouge) vs variante B (bleue)
                        → Personnalisation par segment (clients premium)

En-têtes et pieds de page transverses : un footer commun à toutes les pages du site géré depuis un seul XF.

Fragments pour email (Adobe Campaign) : des XFs peuvent être exportés comme modèles d’email vers Adobe Campaign.

Utiliser un Content Fragment dans une page

Pour afficher un CF dans une page AEM classique, utilisez le composant Core “Fragment de contenu” ou créez un composant custom qui utilise ContentFragment API.

@Model(adaptables = SlingHttpServletRequest.class)
public class ArticleDisplayModel {

    @SlingObject
    private Resource resource;

    public ContentFragment getFragment() {
        Resource cfResource = resource.getChild("fragmentReference");
        if (cfResource == null) return null;
        return cfResource.adaptTo(ContentFragment.class);
    }

    public String getTitre() {
        ContentFragment cf = getFragment();
        if (cf == null) return null;
        ContentElement element = cf.getElement("titre");
        return element != null ? element.getContent() : null;
    }
}

Modèles de CF et permissions

Un point souvent négligé : les Content Fragment Models contrôlent quelles équipes créent quel type de contenu. Configurez les permissions par modèle pour que les rédacteurs ne voient que les modèles qui les concernent.

Chemin : Outils > Assets > Modèles de fragment de contenu > [Votre dossier] > Propriétés > Permissions

Conclusion

Content Fragment = données (pour le headless, le multi-canal, le contenu réutilisable sans présentation)

Experience Fragment = présentation (pour les sections de pages réutilisables, Target, Campaign)

Dans une architecture moderne, les deux coexistent : les CFs portent le contenu structuré, les XFs portent les modules éditoriaux avec mise en forme. Ne les interchangez pas — la confusion architecturale crée une dette de contenu difficile à résorber.