Adobe Experience Manager : le CMS qui rend les sites moins bons

Depuis des années, je regarde des sites passer sous Adobe Experience Manager. Des sites de grands groupes, de marques, d’institutions. À chaque fois, la même scène : la version d’avant était plus rapide, plus lisible ou plus simple à parcourir. La version AEM est plus lourde, plus lente à réagir ou plus confuse. Parfois les trois à la fois.

Je n’en fais pas une loi. C’est une observation, répétée assez souvent pour que je finisse par la noter, et jamais contredite par un cas convaincant parmi les sites publics que j’ai pu comparer avant et après, ou qui sont assez connus pour que n’importe qui les examine. J’ai cherché. Quand on me présente un site AEM « qui marche bien », il marche bien par rapport à d’autres sites AEM. Pas par rapport à ce que le même site faisait avant, ni par rapport à ce qu’une stack plus sobre produit avec le même budget.

Ce billet n’est pas un article sur le prix d’AEM, ni sur sa maintenance. Il porte sur un point plus simple et plus gênant : le produit final, celui que l’internaute a sous les yeux, est moins bon. Et sur la raison pour laquelle ce résultat n’a rien d’un accident.

Ce que je regarde, et comment n’importe qui peut le refaire

Je ne parle pas d’un ressenti d’expert. Je regarde quatre choses, dont trois se mesurent.

D’abord les Core Web Vitals en données terrain, c’est-à-dire celles de vrais utilisateurs de Chrome remontées dans le Chrome UX Report (CrUX), pas un test de laboratoire lancé une fois depuis un poste rapide. Le LCP (Largest Contentful Paint) dit en combien de temps le contenu principal s’affiche ; le seuil « bon » est de 2,5 s au 75e centile. L’INP (Interaction to Next Paint) mesure la réactivité à chaque clic ou saisie ; le seuil est de 200 ms. Le CLS mesure les sauts de mise en page. PageSpeed Insights affiche ces valeurs terrain pour toute origine suffisamment visitée, gratuitement, sans compte.

Ensuite la fluidité perçue : le délai entre un clic sur un menu et la réaction visible, le défilement qui accroche ou non, les carrousels qui se chargent par à-coups.

Ensuite la clarté de la navigation : combien de niveaux, combien de clics pour atteindre une fiche produit ou un formulaire, et si l’architecture de l’information a survécu à la migration ou si elle a été refaite pour entrer dans les templates.

Enfin le temps de réponse ressenti sur les pages qui ne sortent pas du cache : résultats de recherche, espace client, formulaires.

Pour comparer des familles de sites entre elles, HTTP Archive publie un Core Web Vitals Technology Report qui croise CrUX avec la détection des technologies ; AEM y figure. Je l’utilise avec prudence : la détection d’AEM derrière un Dispatcher et un CDN est partielle, et comparer la moyenne des sites AEM à la moyenne des sites WordPress revient à comparer des grands comptes à des blogs. La mesure qui compte est celle du même site, avant et après. C’est celle que je fais, et celle que je vous invite à faire.

Le schéma qui se répète après la migration

Le premier symptôme est le poids du front. Un site AEM charge ses ClientLibs, le mécanisme maison qui agrège JavaScript et CSS par composant, puis les scripts de l’écosystème Adobe (Launch, Analytics, Target), puis les scripts tiers que le marketing ajoute depuis Launch sans passer par un développeur. Chaque composant apporte sa librairie, chaque équipe ajoute son tag, personne n’en retire. Le total atteint souvent plusieurs mégaoctets de JavaScript là où la version précédente en chargeait quelques centaines de kilooctets.

Le deuxième symptôme est l’INP. Ce JavaScript s’exécute au moment précis où l’utilisateur veut interagir. Menu qui s’ouvre avec un temps mort, onglet qui réagit après coup, filtre de catalogue qui fige la page. Le LCP peut rester passable grâce au CDN ; l’INP, lui, se dégrade presque systématiquement parce qu’il dépend de ce qui tourne dans le navigateur.

Le troisième symptôme est côté auteur. AEM promet l’autonomie des équipes marketing. En pratique, tout nouveau besoin passe par un composant : code Java ou HTL, dialogue d’édition, ClientLib, politique de template, puis un pipeline de déploiement. Les équipes contenu finissent par dépendre davantage des développeurs qu’avant, et contournent en empilant des composants génériques ou du HTML brut. Le site public en hérite.

Le quatrième symptôme est le cache. L’architecture AEM repose sur le Dispatcher, un module Apache qui sert des pages pré-rendues. Dès qu’on active la personnalisation, les segments Target, les contenus par profil ou les publications à la demande, une part croissante des pages ne peut plus être servie depuis ce cache. Le temps de réponse redevient celui de l’instance de publication, et il se voit.

Un exemple que je consulte régulièrement : le site presse d’un constructeur munichois. Un site presse n’a qu’un métier, permettre à un journaliste de trouver un communiqué et de télécharger ses photos en deux clics. L’ancienne version le faisait. La version AEM ouvre sur un carrousel de cinq actualités à faire défiler, une poignée de liens en dessous, des filtres par marque et par thème, et une bannière de cookies qui prévient que certains modules seront désactivés si on refuse. Sous le capot, la panoplie Adobe au complet : Launch, le Client Data Layer, la plateforme de données clients, plus jQuery et core-js côte à côte. Tout cela pour afficher des communiqués. Le contenu n’a pas changé ; la distance entre le journaliste et le communiqué, si.

Rien de tout cela ne relève d’un prestataire maladroit. Je l’ai vu avec des intégrateurs certifiés, des budgets confortables et des équipes compétentes. Le résultat est quasi mécanique.

Pourquoi c’est structurel, et non une mauvaise implémentation

AEM n’a pas été conçu pour produire des pages web rapides. Il a été conçu pour gouverner du contenu dans une grande organisation : droits, workflows de validation, multi-sites et multi-langues, fragments réutilisables, intégration avec Analytics, Target, la DAM et le reste de l’Experience Cloud. Ce sont des qualités réelles, pour la DSI. Aucune ne concerne l’internaute.

Son socle technique vient de Day Software, racheté par Adobe en 2010 : un référentiel JCR (Jackrabbit, puis Oak), le framework Apache Sling, des bundles OSGi. Adobe a ensuite empilé : Touch UI, templates éditables, Content Fragments, Experience Fragments, Cloud Manager, puis la version Cloud Service. Chaque couche ajoute des concepts et aucune ne retire les précédentes. J’avais décrit le même empilement chez Meta, où quinze ans de rachats et de pivots ont produit un labyrinthe que même les développeurs chevronnés peinent à traverser. Le mécanisme est identique, le résultat aussi.

Cette complexité pousse mécaniquement au code sur mesure. Les Core Components d’Adobe couvrent les cas simples ; tout le reste, c’est-à-dire ce qui fait la singularité d’un site de marque, devient du code spécifique, écrit par un intégrateur, livré avec ses ClientLibs et rarement revisité. Trois ans plus tard, personne ne sait plus quelle librairie sert encore à quelque chose.

Enfin, pour le dire simplement, un site AEM rapide suppose quatre mécanismes réglés ensemble et maintenus accordés dans le temps : le code des composants, l’agrégation de leurs librairies, le cache du Dispatcher et le CDN devant. Le jour du lancement, quelqu’un les a accordés. Ensuite, personne n’est payé pour le refaire. Dans le détail, il faut maîtriser en même temps l’agrégation des librairies, les règles de cache du Dispatcher, leur invalidation, la configuration du CDN et la personnalisation qui traverse tout cela. Chaque équipe en maîtrise une partie. L’état optimal existe le jour du lancement, quand l’intégrateur est encore là, puis il se dégrade.

Adobe le sait. Depuis 2023, l’éditeur pousse Edge Delivery Services (ex-Franklin, ex-Helix), une chaîne de livraison séparée : contenu rédigé dans Word ou Google Docs, code JavaScript sans framework dans un dépôt Git, aucune ClientLib, et un score Lighthouse de 100 contrôlé à chaque pull request. Adobe publie même un guide intitulé Keeping it 100 et affirme dans sa FAQ que tout site EDS peut et doit atteindre ce score. Dans un communiqué, un client cité par Adobe passe d’un score Lighthouse de 35 à 100 en basculant vers EDS. Le chiffre intéressant n’est pas le 100, c’est le 35 : c’est le point de départ, sous AEM classique. Un éditeur qui construit un second produit pour obtenir des pages rapides reconnaît que le premier n’y arrivait pas. Et EDS ne corrige pas AEM, il le contourne, en déplaçant la complexité vers Git et des documents bureautiques. J’ai déjà écrit que déplacer la complexité n’est pas la supprimer.

Des décisions prises par des gens qui n’ouvriront jamais l’outil

Qui choisit AEM ? Rarement les rédacteurs qui vont y passer leurs journées, jamais les internautes. Le choix se fait en DSI ou en direction digitale, souvent dans un groupe déjà client d’Adobe pour Analytics, la Creative Cloud ou Target. La décision se prend sur des critères de gouvernance, d’intégration et de référence : le logo rassure, le cabinet de conseil le recommande, l’intégrateur partenaire est déjà référencé aux achats.

Le critère « le site sera-t-il meilleur pour l’utilisateur » n’apparaît pas dans la grille, ou alors sous forme de promesse de l’éditeur, jamais sous forme de mesure. L’ergonomie de l’interface d’authoring non plus : ceux qui signent ne rédigeront pas une page.

Le prix n’aide pas à ramener la décision sur terre. Adobe ne publie aucune grille. Tout passe par un devis négocié, par modules (Sites, Assets, Forms), par mode de déploiement et par volume. Les retours d’acheteurs parlent d’un tarif opaque et élevé. Les estimations publiées par des intégrateurs et des comparateurs situent la licence annuelle entre cinq et six chiffres, l’intégration initiale de plusieurs centaines de milliers à plusieurs millions de dollars, et le support récurrent autour de 15 à 25 % de la licence. Je ne connais pas les chiffres des contrats français et je n’en inventerai pas. Mais une dépense de cette taille, engagée sans grille publique et sans mesure de ce qu’elle produit côté utilisateur, dit quelque chose du processus de décision. La politique tarifaire d’Adobe, je l’avais déjà regardée côté Creative Cloud ; elle est au moins lisible. Ici, elle ne l’est même pas.

Ce que ce coût achète, c’est la tranquillité de celui qui signe. Pas la qualité de ce que voit l’internaute.

Ce que ça raconte au-delà d’Adobe

Le premier sujet est la souveraineté, au sens le plus concret. Un site AEM, c’est un modèle technique propriétaire de bout en bout : référentiel, structure de contenu, composants, pipeline de déploiement dans Cloud Manager, CDN fourni, et désormais hébergement sur l’infrastructure d’Adobe avec la version Cloud Service. En sortir demande une réécriture. Le contenu est récupérable, le site ne l’est pas. Pour un groupe français ou une institution, cela veut dire confier son canal public à un éditeur américain, avec une porte de sortie qui coûte le prix d’une nouvelle migration.

Le deuxième est la fausse promesse de « l’expérience digitale ». Le nom du produit contient le mot expérience. Ce qu’il vend, c’est de la gouvernance interne : qui peut publier quoi, dans quelle langue, après quelle validation. Tout cela améliore la vie de l’organisation. Rien de cela n’améliore la page que charge l’utilisateur, et on vient de voir que c’est l’inverse qui se produit.

Le troisième dépasse Adobe. Les outils enterprise, CMS compris, produisent des sites moyens à médiocres dès qu’ils sont déployés à grande échelle. J’aime le mot simplexité, cette complexité domptée qui se présente simple à l’utilisateur. AEM en est l’exact contraire : la complexité n’est pas domptée sous la surface, elle remonte jusqu’à l’écran de l’internaute, en kilooctets de JavaScript et en centaines de millisecondes. On a optimisé le processus, pas le résultat.

Vérifiez, ne me croyez pas

AEM n’est pas inutilisable. Des sites AEM tiennent la route, et une excellente équipe peut en tirer quelque chose de propre pendant un temps. Mais structurellement, pour les raisons décrites ici, il produit des sites moins bons en ergonomie, en expérience et en performance que ce que le même site faisait avant, ou que ce qu’une stack plus sobre produit avec le même budget. J’avais fait la même démonstration sur le WordPress headless : un outil simple bien mis en cache bat une architecture savante mal maîtrisée, et la seconde est la règle, pas l’exception.

Ne me croyez pas sur parole. Prenez un site dont vous savez qu’il est passé sous AEM. Ouvrez PageSpeed Insights, regardez les données terrain, l’INP en particulier. Comparez avec une capture Wayback de la version précédente si vous le pouvez, ou simplement avec le site d’un concurrent qui n’a pas fait ce choix. Comptez les clics pour arriver à ce que vous cherchez.

Et si vous connaissez un site qui a gagné en passant sous AEM, en données terrain et pas sur une diapositive, envoyez-le-moi. Je le cherche depuis des années. Je publierai le contre-exemple avec plaisir, parce qu’il m’apprendrait quelque chose. Pour l’instant, la liste est vide.