Les choses à savoir pour votre plateforme Adobe Commerce et Magento en 2025

Publié le Mis à jour le Par

L’acte européen sur l’accessibilité 2025

À partir du 28 juin 2025, une nouvelle loi européenne sur l’accessibilité entrera en application. Elle élargit les obligations d’accessibilité pour les sites web et applications, et s’appliquera à toutes les entreprises de plus de 10 employés dont le chiffre d’affaires dépasse 2 millions d’euros, mais également les sites de service public. Les sites e-commerce devront respecter les normes actuelles, avec une conformité RGAA totale pour la France, respect de la norme Européenne 3015 49, et comme niveau minimal le AA de la norme WCAG pour le reste du monde (particulièrement les US).

Les services existants avant le 28 juin 2025 auront jusqu’au 28 juin 2030 pour se mettre en conformité, tandis que les nouveaux sites lancés après juin 2025 devront l’appliquer dès leur lancement. Les sanctions pour non-respect seront renforcées et pourront atteindre jusqu’à 300 000€ selon le type de service. Après un délai de 6 mois sans correction, les sanctions peuvent être à nouveau appliquées.

Il est important de commencer dès maintenant la mise en conformité avec à minima :

  • Réaliser un audit, établir une déclaration d’accessibilité
  • Editer le schéma et plan d’action pluriannuel sur 3 ans
  • Faire en sorte que tous les nouveaux contenus soient accessibles

Adobe Commerce 2.4.8 et fin de support

Actuellement en phase de bêta test, la prochaine version “patch” d’Adobe Commerce a prévue de sortir publiquement le 8 avril 2025 sous la numéro 2.4.8. Suivant sa nouvelle politique de release, cette version n’intègrera pas de nouvelle fonctionnalité, mais prévoit d’améliorer les performances, la sécurité et de mettre à jour les librairies qu’elle utilise (ex : composer 3, phpunit 10).

Côté compatibilité PHP, cette version ne supporte plus PHP 8.1, il faudra être sur PHP 8.2 ou 8.3 (nous n’avons pas d’annonce officielle pour la compatibilité 8.4 actuellement). Concernant la base de données, il faudra passer sur MySQL 8.4 ou MariaDB 11.4. À noter que la compatibilité avec ElasticSearch ne sera plus supportée, Adobe préférant se concentrer sur le support d’OpenSearch 2.x.

Quelques améliorations sur les API GraphQL seront embarquées et niveau configuration les indexeurs seront maintenant en mode “Update by Schedule” par défaut afin de suivre les bonnes pratiques Adobe.

Cette version 2.4.8 devrait être supportée jusqu’au 2ème trimestre 2028.

Enfin, 2025 marquera la fin du support de 2 versions :

  • version 2.4.4 le 24 avril
  • version 2.4.5 le 8 août 

Pensez à anticiper la montée de version si vos plateformes les utilisent encore.

Edge Delivery Services

La roadmap 2025 d’Adobe Commerce n’est pas détaillée, mais l’éditeur devrait continuer à améliorer petit à petit ses services Cloud, Live Search, Product Recommandation, Payment Service et Catalog Service mais aussi le nouvel arrivant : Edge Delivery Services. Edge Delivery Services est une nouvelle brique technologique qui devrait être démocratisée en 2025, c’est une nouvelle technologie frontend déjà utilisée sur Adobe Experience Manager.

Elle promet de très bonnes performances, de publier du contenu depuis des documents Microsoft Word ou Google Docs et d’intégrer nativement des fonctionnalités de test A/B et de génération d’images ou de variation de page via intelligence artificielle. Cette technologie est complétée par une librairie de composants e-commerce réutilisables pour les intégrateurs (panier, page produit, dashboard client…) qui sera complétée au fur et à mesure.

Une technologie qui devrait gagner en maturité en 2025 et devrait trouver un intérêt particulier sur les architectures composables.

PCI DSS 4.0

Le 31 mars 2025 la version 4.0 de la norme de sécurité PCI DSS entrera en vigueur et devra être respectée pour prétendre être conforme. Cette version de la norme apporte 2 exigences qui touchent particulièrement les sites Magento 2 / Adobe Commerce et leurs pages de paiement :

  • Exigence 6.4.3 : L’exécution des scripts sur les pages de paiement doit être autorisée et justifiée
  • Exigence 11.6.1 : Les scripts sur les pages de paiement ne doivent pas avoir subi de changements non autorisés

Ces exigences permettent de sécuriser la saisie des informations de paiement par les utilisateurs du site et minimisent considérablement les attaques de type Magecart. Ces attaques, qui ciblent les sites mal sécurisés, consistent à modifier la page de paiement dans le navigateur de la victime en la remplaçant par un formulaire malveillant qui récupère ses informations de carte bancaire.

Ces exigences sont de la responsabilité du prestataire de service de paiement, mais aussi du e-commerçant. Ainsi pour les satisfaire, 2 fonctionnalités techniques ont été introduites dans Adobe Commerce :

  • Le CSP (Content Security Policy) en mode strict qui permet de définir explicitement quels domaines et quels scripts sont autorisés à interagir avec la page.
  • Le Subresource Integrity qui permet de vérifier l’intégrité des scripts présents sur la page.

Ces fonctionnalités ont été introduites et activées par défaut depuis Adobe Commerce 2.4.7. Des ajustements sur la plateforme peuvent être nécessaires par votre intégrateur pour ne pas bloquer les scripts légitimes, tels que les services de tracking ou de paiement.

Cette politique de sécurité nécessite surtout d’adapter les procédures d’ajout de scripts (par le service marketing par exemple) et de mettre en place un suivi des erreurs remontées par le site. Bien que ces fonctionnalités puissent être désactivées pour faciliter l’intégration de la plateforme, il est recommandé de les maintenir actives afin d’assurer un niveau de sécurité optimal et la conformité avec la norme PCI.

Des outils comme Sansec Watch ou CSP whitelist generator permettent de simplifier la procédure.

Hyvä commerce

L’année 2025 marquera la sortie du nouveau produit Hyvä Commerce, un package de module pour Magento 2 Open Source améliorant l’expérience front et back office via l’ajout de nouvelles fonctionnalités, ainsi que de Hyvä Theme et Hyvä Checkout. La roadmap des fonctionnalités n’est pas encore connue, mais ils souhaitent mettre l’accent sur des fonctionnalités dédiées au marketing.

Connaissant l’éditeur, nul doute que la qualité de ce produit sera au rendez-vous permettant une installation et intégration simple ainsi qu’un prix de licence compétitif.

Blocage cookies tiers et tracking server side

Les cookies tiers ont longtemps été une solution de base pour le suivi des utilisateurs sur différents sites web. Leur blocage déjà en place sur Firefox et Safari et maintenant suivi par Google Chrome (qui détient une grande part de marché des navigateurs) met fin à cette approche largement utilisée. Cela pousse les entreprises à rechercher des alternatives pour collecter des données fiables sans dépendre des cookies tiers.

Ce blocage par Chrome devrait être appliqué en 2025, accélérant la mise en place du tracking côté serveur (server-side tracking). Voici les avantages de cette méthode :

Adaptation du suivi publicitaire (SEA)

Avec la disparition des cookies tiers, les plateformes publicitaires (Google Ads, Meta, etc.) encouragent leurs clients à adapter les scripts de suivi pour pouvoir continuer à alimenter leurs algorithmes avec des données pertinentes (first party).

La mise en place de ces adaptations est grandement simplifiée via du tracking server-side. Les entreprises doivent s’adapter rapidement pour rester compétitives.

Meilleure précision des données

Les bloqueurs de publicités et les restrictions des navigateurs rendent les données collectées via le suivi client (côté navigateur) moins fiables. Avec le server-side tracking, les données sont collectées directement depuis le serveur, ce qui réduit les risques de perte ou de manipulation. De plus, la précision et la complétude des données augmentent, car cette méthode contourne les limites imposées par les navigateurs (ITP, ETP).

Optimisation des performances techniques

Le blocage des cookies tiers est également une opportunité d’améliorer les performances des sites web, en réduisant le nombre de requêtes envoyées côté client et en centralisant le traitement des données sur des serveurs dédiés, ce qui allège la charge pour les navigateurs des utilisateurs.

Enfin, bien comprendre que le tracking côté serveur reste conforme aux normes de confidentialité (RGPD, CCPA) puisque le consentement utilisateur via les bandeaux de cookies demeure.