Six bonnes pratiques pour les projets de site web avec Adobe Experience Manager

Mais comme c’est le cas de tout produit aussi complet, il peut facilement mener à de mauvaises décisions. AEM est un produit très souple qui autorise toutes sortes de personnalisations. Autrement dit, toute exigence peut donner lieu à différents types de mise en œuvre, d’une solution entièrement personnalisée à une solution étroitement conditionnée par les principes essentiels du produit.

Ayant largement pratiqué la mise en œuvre d’AEM et de systèmes de gestion de contenu web d’entreprise en général, nous connaissons les pièges que représente le choix d’une solution. Outre l’architecture de la solution et son degré de technicité, il faut également réfléchir à la rentabilité de votre système, aux possibilités de maintenance et à son évolutivité.

Dans cet article, nous évoquons quelques-uns des principaux paramètres à ne pas oublier dans la mise en œuvre d’AEM.

N° 1 : la conception technique et l’architecture

Pour la conception et l’architecture de votre site web, la première chose à faire est d’évaluer soigneusement chaque exigence et de s’aligner le plus tôt possible sur les fonctions que l’on trouve sur le marché. Vous pouvez utiliser des prototypes pour présenter des alternatives à vos professionnels et leur montrer certaines fonctions prêtes à l’emploi. Le plus souvent, on peut gagner en efficacité en adaptant légèrement les exigences initiales.

Quelques exemples :

• Exploitation du cadre de Context-Aware Configuration pour donner à certaines parties de votre site web un look et un comportement différents
• Génération de listes de documents provenant de systèmes extérieurs grâce au cadre Sling Dynamic Include pour permettre la mise en cache des pages qui les contiennent
• Utilisation du Sling Resource Merger pour éviter la duplication d’éléments prêts à l’emploi
• Suppression des CSS dynamiques et recours à des fonctions d’AEM dans ce but
• Mise en œuvre de certaines exigences en dehors d’AEM, par exemple en les intégrant à des (micro)services externes. C’est capital pour éviter l’utilisation abusive d’AEM en tant que WCMS.
• Rendre possible la mise en cache de 95 % des requêtes pour une performance de haut niveau.

N° 2 : les composants de base

Il y a quelques années, Adobe a lancé une initiative intitulée WCM Core Components. L’idée était de se détacher des anciens « composants fondateurs » devenus obsolètes et de proposer à la place une bibliothèque bien fournie de composants sur lesquels baser chaque projet.

Cette bibliothèque de composants de base fournit aux concepteurs un ensemble de blocs de construction de qualité pour des pages web sophistiquées. Nous avons développé notre propre ensemble de blocs sur les mêmes principes, en les adaptant à chaque projet. Par conséquent, nous participons aussi à leur amélioration au fil du temps.

Le fait d’utiliser ces composants en exploitant l’idée qu’ils renferment nous permet de créer des bases de code extrêmement souples et de faire évoluer ces composants les uns après les autres sans bloquer leur rétrocompatibilité.

N° 3 : les modèles adaptables

Auparavant, c’était au développeur de créer des modèles de page pour les utilisateurs de l’entreprise. Avant qu’un modèle puisse être utilisé par un créateur de contenu, le développeur devait l’implémenter et le déployer dans AEM. Cela rallongeait souvent le délai de commercialisation.

Mais depuis quelques années, la fonction « Editable Templates » (modèles adaptables) d’AEM permet de faire moins appel à l’équipe informatique pendant la création des pages. Cette fonction permet aux créateurs de contenu d’assembler eux-mêmes leurs modèles à l’aide de l’interface utilisateur AEM Touch.

N° 4 : la grille réactive et le système de style

Les grilles réactives permettent aux utilisateurs de créer des mises en page et de définir le comportement des composants avec une grande souplesse. Combinées au système de style d’AEM, elles permettent d’appliquer des styles prédéfinis sans sacrifier la cohérence entre les pages.

Avec l’habituel workflow destiné à rendre le contenu dynamique, il fallait qu’un concepteur crée une maquette pour les divers points d’arrêt, que le développeur les implémente pour un modèle donné, et que l’auteur choisisse ce modèle et le remplisse de contenu. Avec la fonction de grille réactive, ce workflow a été grandement simplifié : l’auteur saisit le contenu et peut adapter la mise en page en toute autonomie, sans avoir besoin d’en référer au développeur pour la réactivité ou d’attendre de nouveaux déploiements. Cette fonction, apparue dans la version 6.3 d’AEM, donne aux professionnels une grande souplesse tout en évitant ce travail aux développeurs. Enfin, la modification d’un modèle ne nécessite aucun travail de développement (et de déploiement).

Cela dit, cette souplesse a un prix : les professionnels doivent maintenant gérer les paramètres de mise en page des composants, et cela peut prendre beaucoup de temps. Il est souvent préférable de trouver un compromis où certains paramètres de mise en page sont fixes et où d’autres restent adaptables. Nous pouvons vous aider à trouver le bon équilibre.

N° 5 : les bonnes pratiques du développement web

Les projets AEM nous donnent par ailleurs l’occasion d’instaurer de bonnes pratiques de développement en général ainsi que certains standards AEM techniques. Pour en résumer quelques-uns :

• Qui casse le build le répare
• Effectuer des tests d’unité et d’intégration pour chaque nouvelle fonction
• Envoyer les demandes de fusion lorsqu’une fonction est achevée
• Demander un deuxième contrôle à un responsable technique
• Utiliser Sling Models pour le développement des composants, même si ceux-ci sont très simples
• Utiliser le Proxy Component Pattern
• La documentation utilisateur et technique doit toujours être à jour.
• Le code doit être testé dans AEM ainsi que via le dispatcher.
• Duplication de code désactivée, règles SonarQube configurées, chaque build déclenche un scan SonarQube, etc.

N° 6 : automatisation complète

Pour améliorer notre travail, nous essayons d’automatiser au maximum. Pour les installations d’AEM 6.5 sur site, nous utilisons l’infrastructure en tant que code pour automatiser la configuration des serveurs et nos environnements locaux. Cela signifie que n’importe quel développeur peut devenir opérationnel en quelques minutes et travailler sur un environnement local aussi proche que possible de la production. Cette configuration comprend même une instance locale de Dispatcher afin de repérer immédiatement les pièges de la mise en cache.

Pour les installations d’AEM en tant que service dans le cloud, nous avons été formidablement aidés par Adobe’s Cloud Manager, qui automatise entièrement, met à niveau, assure les correctifs de sécurité et les mises à jour avec des points de contrôle qualité prédéfinis et personnalisés.

Chaque fois qu’une modification de code est intégrée au contrôle de version, un build est exécuté et les développeurs sont instantanément avertis si quelque chose tourne mal. Selon le secteur concerné, le build est déployé dans l’environnement de destination afin que les changements apparaissent immédiatement dans le bon système.

Le respect de ces principes nous donne la souplesse de mises à jour entièrement automatisées. Le déploiement en environnement de production se fait d’un seul clic.

Conclusion

Il est impératif de connaître les bonnes pratiques applicables au développement de sites web dans le WCMS que vous utilisez. Mais surtout, il faut avoir à ses côtés un partenaire qui connaît ces pratiques et les fait respecter par l’équipe de projet pour que votre projet d’expérience digitale réussisse. Ces directives sont précieuses non seulement pour la mise en place de nouveaux sites web, mais aussi lorsque l’on planifie des mises à niveau ou un élargissement de sa plateforme Adobe existante.