Adobe n'a annoncé, à ce jour, aucune date de fin pour Adobe Analytics, et vend Customer Journey Analytics à ses côtés. Faut-il migrer maintenant, attendre, ou faire cohabiter les deux outils ? On vous donne les clés pour décider.
Introduction
Vous utilisez Adobe Analytics et vous vous demandez s'il faut passer à Customer Journey Analytics ? Et si oui, quand ?
Avant d'aller plus loin : migrer n'est pas une obligation. Les deux outils n'ont pas exactement la même finalité : Adobe Analytics sert l'analyse ciblée du web et des apps, CJA les questions qui traversent les canaux et les identités. Adobe les vend côte à côte dans son portfolio CX Analytics. Selon l'éditeur, la plupart des entreprises utilisent les deux, et passer à CJA relève d'une évolution, pas d'une migration forcée (page produit CJA). CJA est même proposé en complément d'une licence Adobe Analytics (offre dédiée).
Spoiler : migrer vers CJA n'est pas une simple montée de version. C'est un changement d'architecture, qui touche la collecte, le modèle de données, l'identité, la gouvernance et même le modèle de coût. Il demande surtout une compétence en plus de la web analytics classique : la modélisation de données. D'où un principe simple : on designe l'infrastructure avant de migrer quoi que ce soit. La bonne question n'est donc pas « faut-il migrer ? », mais « avons-nous des besoins qui justifient CJA, et notre organisation est-elle prête ? ».
1. Adobe Analytics et CJA : deux philosophies, pas deux versions
Les deux outils partagent la même interface, Analysis Workspace. En dessous, ils ne fonctionnent pas du tout de la même façon.
Adobe Analytics a été pensé pour mesurer le web et les apps. L'essentiel du traitement a lieu à la collecte (processing rules, marketing channels, persistance des eVars), et ces règles sont figées dans l'historique.
Customer Journey Analytics lit des datasets stockés dans Adobe Experience Platform (AEP), quelle que soit leur source : web, app, CRM, centre d'appels, à condition d'être modélisés en XDM. La plupart des règles s'appliquent au moment du reporting, dans les data views, y compris sur l'historique. Grâce au stitching, CJA raisonne en personnes, plus seulement en visiteurs.
CJA n'est pas « Adobe Analytics 2 ». La question passe de « que se passe-t-il sur mon site ? » à « que fait mon client, sur tous ses canaux ? ».
Critère | Adobe Analytics | Customer Journey Analytics |
Périmètre de données | Web et app principalement | Toute source ingérée dans AEP et modélisée en XDM |
Traitement | À la collecte, figé dans l'historique | Au reporting, rétroactif via les data views |
Modèle de données | 75 props, jusqu'à 250 eVars, events | Champs XDM libres, avec des garde-fous (5 000 dimensions et 5 000 métriques par data view) |
Identité | Visiteur, visite, hit | Personne, session, événement, avec stitching |
Licence | Server calls | Lignes de données disponibles pour l'analyse |
IA intégrée | Ni AI Assistant ni Data Insights Agent, accès aux données par serveurs MCP depuis mai 2026 | AI Assistant, Data Insights Agent |
Sources : feature support Adobe, garde-fous CJA, licence Adobe Analytics, licence CJA, IA générative dans Experience Cloud, notes de version AA.
2. Adobe Analytics est-il en fin de vie ?
Non. À ce jour, Adobe n'a annoncé aucune date de fin pour le produit : les pages officielles de fin de vie ne listent que des fonctionnalités. En revanche, 2026 a été chargée (notes de version 2026) :
- 2 janvier : fin de l'accès via my.omniture.com et l'ancien SSO, pour renforcer la sécurité. La connexion passe par un identifiant Experience Cloud.
- 13 avril : nouveau format de données pour LiveStream, pour plus de cohérence avec Analysis Workspace.
- 27 mai : retrait de huit suites de chiffrement TLS 1.2 obsolètes, pour renforcer la sécurité.
- Juin : fin de l'ancien Report Builder. Son remplaçant sert les clients Adobe Analytics et CJA (notes de version AA).
- 31 août : arrêt de l'API 1.4 et de l'authentification WSSE. Adobe ne donne pas de raison. Le remplacement passe par l'API 2.0 et une authentification OAuth, la même que pour les API CJA.
Notre lecture : ces retraits ne préparent pas la fin d'Adobe Analytics. La plupart renforcent la sécurité ou alignent l'outil sur des briques communes avec CJA. Pas d'obligation de migrer, donc, mais rester a aussi un coût : chaque retrait impose d'adapter scripts, classeurs Excel et flux de données.
3. ✅ Les signaux qu'il est temps de migrer
Vous avez des use cases cross-canal. Relier web, app, CRM, magasin ou centre d'appels : c'est la raison d'être de CJA.
Vos données sont déjà dans AEP. Si vous utilisez Real-Time CDP ou Journey Optimizer, une partie de vos données est déjà modélisée en XDM, là où CJA va les lire.
Une refonte du tracking est déjà prévue. Adobe recommande le Web SDK pour toute nouvelle implémentation, Adobe Analytics compris. Autant la faire avec un schéma XDM pensé pour CJA.
Vous voulez exploiter l'IA d'Adobe. L'AI Assistant et le Data Insights Agent sont réservés à CJA. Adobe Analytics, lui, s'ouvre aux agents externes via ses serveurs MCP, disponibles depuis mai 2026.
4. ⚠️ Les signaux qu'il vaut mieux attendre (ou préparer d'abord)
Vos besoins sont 100 % web et app, et Adobe Analytics y répond bien. La migration aura un coût sans bénéfice métier évident.
Votre implémentation est peu documentée, ou votre data layer fragile. On nettoie avant de migrer : garbage in, garbage out.
Vous n'avez pas de stratégie d'identité. Quel identifiant pour une personne, quelle gestion du consentement : c'est une décision structurante, difficile à défaire.
Personne dans l'équipe ne sait modéliser des données, et aucun partenaire n'est là pour l'apporter (voir partie 5).
Vos équipes sont très attachées à certains indicateurs d'Adobe Analytics. La plupart existent dans CJA, mais autrement : pas de taux de rebond standard, marketing channels à reconstruire avec des champs dérivés, persistance différente de celle des eVars. Ces écarts sont à expliquer avant la bascule, pas après.
Vous n'avez pas la capacité d'accompagner le changement. Adobe recommande de laisser 3 à 6 mois aux utilisateurs pour se familiariser avec Analysis Workspace dans CJA.
5. Avant de migrer : designer l'infrastructure
Dans Adobe Analytics, le modèle de données est imposé : eVars, props, events, visites. Dans CJA, c'est vous qui le construisez : schémas XDM, datasets, identités, lookups, data views.
On ne migre pas un outil, on construit une infrastructure data. Et une infrastructure se conçoit avant de se déployer.
Cela demande une compétence de modélisation de données, pas seulement de web analytics :
- identifier les entités métier (client, commande, produit, campagne) et leurs relations ;
- distinguer données événementielles (comportements) et données de référence (profils, lookups) ;
- définir l'identifiant personne et les règles de stitching.
Le profil type, selon nous : un binôme web analyst et data architect (ou analytics engineer).
Concevoir avant de déployer, pour trois raisons :
- Un schéma se fige vite. Dès qu'un schéma XDM a servi à créer un dataset, il n'accepte plus que des changements additifs : on peut ajouter des champs, pas en supprimer ni en renommer. Un champ mal typé ou mal placé impose de créer un nouveau champ, voire un nouveau schéma et un nouveau dataset, puis de réingérer les données.
- Les chemins de schéma doivent être cohérents. Un même champ (SKU, ID de campagne) doit avoir le même chemin dans tous les datasets pour que CJA le fusionne automatiquement en une seule dimension.
- Sans design préalable, on recopie le legacy Adobe Analytics dans XDM, et la dette avec.
La démarche recommandée par Adobe (bonnes pratiques de modélisation) : use cases → sources → modèle entité-relation → schémas XDM, de façon itérative. La collecte et CJA ne viennent qu'ensuite.
6. Framework de décision : 6 questions à se poser
- Avons-nous au moins un use case prioritaire qui nécessite des données hors web et app ?
- Notre échéance contractuelle nous laisse-t-elle au moins un an pour préparer la migration et faire tourner les deux outils en parallèle ?
- Notre collecte est-elle prête (data layer, TMS, passage au Web SDK possible) ?
- Avons-nous une stratégie d'identité et de consentement claire ?
- Avons-nous le budget et les ressources (licence en lignes de données, historique à ingérer, conduite du changement) ?
- Avons-nous, en interne ou avec un partenaire, les compétences de modélisation de données pour designer l'architecture cible ?
7. Réussir sa migration : les pièges à éviter
❌ Se contenter de l'Analytics source connector. Il transpose la nomenclature props et eVars dans AEP, avec une forte latence. Adobe le juge la méthode la moins viable à long terme. Il reste utile pour récupérer l'historique, en complément d'une nouvelle implémentation Web SDK.
✅ Choisir l'historique à ramener. Le connecteur importe jusqu'à 13 mois d'historique en production, mais dans CJA, chaque ligne d'historique compte dans le volume licencié. Ramenez ce qui sert vraiment.
✅ Faire tourner les deux outils en parallèle. Adobe le recommande pour comparer les données et comprendre chaque écart. Prévenez tôt les équipes métier : certains chiffres ne seront pas identiques.
⚠️ Recréer ce qui ne migre pas tel quel. Processing rules, filtrage des bots, sérialisation des événements : chacun a un équivalent dans CJA, mais qui fonctionne autrement. L'exclusion par IP, elle, n'a pas d'équivalent direct (feature support Adobe).
✅ Traiter la migration comme un data product : un MVP, des itérations, des entretiens réguliers avec les utilisateurs.
Conclusion
Le choix dépend de votre contexte : vos use cases cross-canal, votre échéance contractuelle, la maturité de votre collecte et vos compétences en modélisation de données. Adobe Analytics n'est pas en fin de vie, et les deux outils cohabitent. Migrer, faire cohabiter les deux ou rester sur Adobe Analytics : c'est une décision stratégique, à planifier.
Quel que soit votre calendrier, un principe : on designe l'infrastructure avant de migrer.
Cet article vous a plu ? Partagez-le sur LinkedIn. Vous vous posez la question pour votre organisation ? Nos consultants peuvent réaliser un audit de préparation CJA.
Hugo Buttiens
Senior Consultant Tracking et Web Analytics chez unnest, Hugo structure la collecte et la gouvernance de la donnée.
Digital analyst depuis 6 ans, j’ai constitué un fort capital de connaissances en travaillant pour certaines grandes entreprises du retail lillois. Mon but est de concevoir et d’industrialiser des dispositifs de collecte web & app fiables, conformes au RGPD. Fort d’une expérience sur un stack Adobe exigeant, je rejoins unnest pour partager et acquérir de nouvelles connaissances.
Adobe Analytics / Piano Analytics / Server-side / Commanders Act / GA4 / Ads
✉️ Me contacter : hugo.buttiens@unnest.co
🎓 Références : Norauto, Boulanger, Oney Bank, Carter-Cash…
⚒️ Outils : Adobe Experience Platform, Adobe Analytics / CJA, Piano Analytics, Google Ads, Meta…