AEM as a Cloud Service : ce qui change vraiment par rapport à l'on-premise

La migration d’AEM on-premise vers AEM as a Cloud Service (AEMaaCS) n’est pas un simple lift-and-shift. L’architecture change fondamentalement, et certaines pratiques qui fonctionnaient parfaitement en on-premise doivent être repensées. Voici les points de friction réels identifiés sur des projets de migration.

L’architecture immuable/mutable

C’est le changement le plus impactant. En AEMaaCS, le code et la configuration sont immuables : ils ne peuvent pas être modifiés après déploiement. Seul le contenu (sous /content et /conf) est mutable.

Immuable (déployé via Cloud Manager) :
/apps    ← composants, templates, OSGi configs
/libs    ← AEM core
/oak:index ← définitions d'index

Mutable (géré par les auteurs, packages de contenu) :
/content ← pages, assets, fragments
/conf    ← configurations Cloud-aware
/var     ← spool, workflows en cours

Conséquence pratique : vous ne pouvez plus déposer un bundle OSGi via la console Felix en production pour un hotfix rapide. Tout passe par Cloud Manager. Les cycles de déploiement doivent être maîtrisés.

Cloud Manager : le seul chemin de déploiement

Cloud Manager est le pipeline CI/CD d’Adobe. Il remplace Jenkins ou Bamboo pour les déploiements AEM. La structure de pipeline est imposée :

1. Build (Maven)
2. Tests unitaires
3. Scan de sécurité (SonarQube intégré)
4. Déploiement sur Dev
5. Tests fonctionnels (Selenium/Cypress)
6. Promotion sur Stage puis Production

Le pipeline peut être déclenché manuellement ou sur push. Les tests de qualité de code (couverture, dette technique) sont configurables avec des seuils de blocage.

Point d’attention : le build Cloud Manager tourne sur une image spécifique Adobe. Si votre pom.xml utilise des plugins Maven non supportés, vous le découvrez en intégration. Il faut anticiper la compatibilité.

OSGi et configurations d’environnement

En on-premise, les configurations OSGi étaient souvent gérées manuellement dans la console Felix, ou via des packages de contenu. En AEMaaCS, elles doivent être dans le code, avec une organisation par environnement.

/apps/monprojet/osgiconfig/
  config/                      ← tous environnements
    com.day.cq.dam.api.s7dam.config.DynamicMediaReplicationConfig.cfg.json
  config.dev/                  ← dev uniquement
    com.adobe.granite.auth.oauth.impl.OAuth2AuthenticationHandlerImpl.cfg.json
  config.stage/                ← stage
  config.prod/                 ← production

Les valeurs sensibles (mots de passe, tokens) passent par des variables d’environnement Cloud Manager, référencées dans les configs avec la syntaxe $[env:MA_VARIABLE].

Index Oak : définissez-les dans le code

En on-premise, on pouvait créer un index Oak depuis la console (CRXDE ou l’interface d’administration). En AEMaaCS, les index personnalisés doivent être dans le code, sous /oak:index.

{
  "jcr:primaryType": "oak:QueryIndexDefinition",
  "type": "lucene",
  "async": "async",
  "includedPaths": ["/content/monprojet"],
  "indexRules": {
    "jcr:primaryType": "nt:unstructured",
    "nt:base": {
      "jcr:primaryType": "nt:unstructured",
      "properties": {
        "jcr:primaryType": "nt:unstructured",
        "statut": {
          "jcr:primaryType": "nt:unstructured",
          "name": "statut",
          "propertyIndex": true
        }
      }
    }
  }
}

Un index mal défini peut dégrader les performances globales. Adobe fournit des outils d’analyse des requêtes (explain query dans la console de développement) pour valider avant déploiement.

Dynamic Media et Assets

Si vous utilisez Scene7/Dynamic Media, la configuration diffère entre on-premise et Cloud Service. En AEMaaCS, Dynamic Media est activé au niveau du tenant, pas de l’instance. Les rendus sont générés à la demande par le CDN Adobe, pas par l’instance AEM.

Cela change la façon de référencer les assets dans les composants et les requêtes DAM.

Le Repository Modernizer

Adobe fournit un outil officiel pour migrer la structure de votre dépôt on-premise vers le format attendu par AEMaaCS : le Repository Modernizer.

# Installation
npm install -g @adobe/aio-cli
aio plugins:install @adobe/aio-cli-plugin-aem-cloud-service-migration

# Analyse et migration automatique
aio aem-migration:repository-modernizer

Il réorganise automatiquement /apps, /content, /conf et adapte la structure Maven. Aucun outil ne fait 100% du travail, mais il couvre la majorité des cas standard.

Les pièges fréquents à éviter

Écriture dans /apps au runtime : interdit en AEMaaCS. Si votre code écrit des nœuds sous /apps dynamiquement (certaines configurations générées), il faut refactorer.

Scheduler OSGi non compatible Cloud : certains schedulers OSGi custom doivent être adaptés pour être compatibles avec le mode autoscaling.

Sessions JCR non fermées : en on-premise, une fuite de session peut passer inaperçue. En AEMaaCS, cela peut déclencher des alertes et dégrader les performances visibles dans Adobe Cloud Manager.

Conclusion

AEM as a Cloud Service est plus contraignant à court terme, mais plus robuste à long terme : déploiements automatisés, scalabilité gérée par Adobe, mises à jour continues sans interruption. La migration demande un audit sérieux du code existant et une réécriture partielle dans les cas complexes. Anticiper les contraintes dès le développement on-premise facilite considérablement le passage au cloud.