Quelle est la différence en une phrase ?
Une plateforme de données client (CDP) collecte les données client de chaque source, les réconcilie en une identité par personne et synchronise des audiences vers d'autres outils — une infrastructure de données qui n'envoie rien aux clients. Une plateforme d'engagement client (CEP) est la couche d'activation : sa propre base de profils et d'événements, plus les segments, parcours et messages qui touchent les clients. Ce guide compare les deux catégories ; pour la grille de décision — seuils, signaux, coûts — voyez notre guide « Avez-vous besoin d'un CDP ? ».
Que fait un CDP qu'une CEP ne fait pas ?
Un CDP collecte événements et attributs depuis chaque source — SDK sur votre site et votre app, flux côté serveur, imports depuis votre entrepôt et vos outils de facturation —, les réconcilie en une identité par personne, puis synchronise les audiences obtenues vers les outils de destination. Le CDP Institute définit un CDP comme un logiciel qui crée et maintient un enregistrement client persistant et unifié, accessible aux autres systèmes, et cette dernière proposition dit tout : le produit final est un enregistrement que d'autres systèmes consomment. Un CDP est une infrastructure de données — il collecte, réconcilie et achemine — l'envoi se fait dans les outils qu'il alimente. Ce qu'il ne répare pas, c'est une collecte négligée, d'où l'importance d'un plan de tracking propre, avec ou sans CDP.
Que fait une CEP de ces données ?
Une CEP détient sa propre base first-party de profils et d'événements, calcule des segments par-dessus — y compris des segments dynamiques recalculés à mesure que les événements arrivent — et fait tourner les parcours qui envoient e-mail, SMS, messages in-app et push. Il possède le dernier kilomètre que le CDP évite délibérément : transformer des données en un message que le client reçoit réellement. Cette base n'est pas un détail d'implémentation. Des profils et des événements qui vivent dans un système que vous contrôlez, c'est l'essentiel de ce que signifie posséder ses données client en pratique.
CDP vs CEP : le face-à-face
La confusion CDP vs CEP est commerciale, pas conceptuelle — les fournisseurs de chaque camp absorbent le vocabulaire de l'autre. Le marché leur en donne des raisons : la mise à jour sectorielle de juillet 2025 du CDP Institute recense 208 fournisseurs de CDP, et les estimations d'analystes compilées par CDP.com situent le marché des CDP en 2026 entre 4 et 10,5 milliards de dollars, selon qui mesure. Les métiers, eux, restent distincts. Le tableau, c'est la séparation qui survit au marketing.
| Plateforme de données client | Plateforme d'engagement client | |
|---|---|---|
| Rôle principal | Collecter, réconcilier et acheminer les données client | Activer les données — segmenter, orchestrer, envoyer |
| Ce qui entre | Événements et attributs venus des SDK, du back end, de l'entrepôt et des outils SaaS | Événements de son propre SDK et de son API, plus les attributs de profil |
| Ce qui sort | Profils propres et audiences, synchronisés vers les outils de destination | E-mails, SMS, messages in-app, push — et leurs analytics |
| Résolution d'identité | Fonction centrale — fusionne la même personne entre sources et appareils | Basique — en général une identité par profil dans sa propre base |
| Envoie des messages ? | Non — par définition, il transmet des audiences aux outils qui envoient | Oui — l'envoi est la raison d'être |
| Qui le pilote | Des ingénieurs data ou growth | Marketeurs et fondateurs, avec un ingénieur pour l'installation |
| Quand il se rentabilise | Plusieurs destinations exigeant le même profil réconcilié | Dès que vous avez des utilisateurs à accueillir et à retenir |
À quoi ressemble un problème taillé pour un CDP ?
- Plusieurs outils de destination — publicité, analytics, support, messagerie — ont besoin du même profil propre, et chacun reconstruit le sien aujourd'hui.
- Votre stack analytique est warehouse-first : l'entrepôt est la source de vérité, et chaque outil en aval a besoin d'une tranche gouvernée de celui-ci.
- Les identités sont fragmentées entre produits : le même client existe dans deux applications sous trois e-mails, et aucun système ne peut dire qu'il s'agit d'une seule personne.
- La collecte d'événements est dupliquée : chaque outil embarque son propre snippet, son propre schéma et sa propre version du même funnel.
Un seul système peut-il faire les deux ?
Pour une petite équipe, en général oui — côté CEP. La base first-party de la CEP assure déjà la partie collecte : un SDK pour les événements côté client, une API pour ceux côté serveur, des profils et des segments dans la même base que les parcours. Ajoutez un CDP par-dessus et vous obtenez une seconde couche de données à entretenir — un schéma de plus, une synchronisation de plus à déboguer — sans capacité nouvelle. Pour une équipe avec un seul produit et une seule plateforme d'activation, un CDP est une seconde couche de données, pas une couche manquante. Quand les signaux d'architecture ci-dessus sont réels, les deux se composent proprement : le CDP collecte et réconcilie, puis alimente la CEP, qui possède le dernier kilomètre. Savoir si votre équipe a franchi cette ligne, c'est exactement ce que détaille notre guide « Avez-vous besoin d'un CDP ? ».
Où se situe fromHello ?
fromHello est une plateforme d'engagement client avec sa propre base first-party. Le SDK JS/TS suit les événements côté client avec une file d'attente hors ligne, l'API d'événements accepte les événements côté serveur, et profils, segments, parcours et messages vivent dans une seule base que vous pouvez auto-héberger. Ce n'est pas un CDP et il ne prétend pas l'être — pas de graphe d'identité inter-outils, pas de catalogue de destinations. Si votre architecture présente les signaux taillés pour un CDP ci-dessus, fromHello prend la position de la CEP dans ce schéma : en aval du CDP, consommant ses profils réconciliés et assurant l'activation. Si vous cherchez encore la plateforme qui tiendra ce rôle, notre comparatif des outils open-source d'automatisation marketing est un bon point de départ.