Choisir une CDP : rédiger un cahier des charges qui teste les vrais usages

Partir de trois usages vérifiables, pas d’une liste de fonctionnalités

La Customer Data Platform peut unifier des profils, calculer des audiences et transmettre des informations aux outils opérationnels. Mais cocher ces fonctions dans un appel d’offres ne permet pas de départager les solutions. Une démonstration réussie sur des données préparées ne dit presque rien sur le fonctionnement avec vos identifiants, vos contraintes et vos équipes.

Retenez trois usages représentatifs : exclure une personne ayant acheté d’une relance commerciale, équiper un conseiller d’un contexte client fiable, alimenter une audience quotidienne depuis les ventes et le CRM. Pour chacun, écrivez la décision attendue, le responsable métier, les données nécessaires, la destination et le délai utile. Une audience hebdomadaire et une décision pendant une visite web n’appellent pas la même architecture.

Documentez aussi les conditions de départ : systèmes existants, volumes courants et de pointe, qualité des identifiants, historique utile, disponibilité des équipes. Fixez les critères d’acceptation avant de rencontrer les fournisseurs. Une exigence devient alors une phrase testable : après réception d’un achat confirmé, cette personne sort de cette audience dans ce délai, et l’exclusion est appliquée dans l’outil destinataire.

Construire une matrice courte qui relie besoin, test et preuve

Donnez un identifiant à chaque exigence. Associez-lui une priorité, un propriétaire, un scénario d’essai et une preuve à conserver. Les seuils doivent venir du risque métier et de la faisabilité des systèmes concernés. Les valeurs ci-dessous illustrent une consultation fictive : elles ne constituent ni un standard du marché ni un engagement universellement réaliste.

Demandez une réponse structurée : disponible dans l’offre chiffrée, configuration nécessaire, développement spécifique, dépendance externe ou fonction absente. Une fonction annoncée sur une feuille de route reste indisponible pour la décision présente. Toute réserve doit préciser coût, délai, responsable et effet sur le test. Conservez les versions du questionnaire et les réponses qui soutiennent la sélection.

Tester les faux rapprochements autant que les profils unifiés

Préparez une vérité de référence : un ensemble de fiches et d’événements dont le rattachement attendu a été validé. Incluez connexion après navigation anonyme, changement d’adresse électronique, compte partagé, téléphone réattribué et identifiants contradictoires. Le jeu doit contenir des personnes à réunir et des personnes à maintenir séparées. Un taux de rapprochement élevé peut simplement révéler des règles trop permissives.

La documentation de Twilio Segment illustre que la résolution d’identité dépend notamment des identifiants admis, des règles d’unicité et de protections contre certaines fusions. Dans votre consultation, faites préciser ces règles pour chaque solution. Demandez comment une relation appareil-personne devient une preuve d’identité, dans quelles circonstances elle ne doit pas l’être et quel système fait autorité.

Mesurez séparément les rapprochements incorrects et les doublons manqués sur ce jeu, avec leurs dénominateurs. Zéro erreur observée sur un petit échantillon ne prouve pas un risque nul en production. Faites expliquer chaque décision, puis simulez une fusion erronée : peut-on séparer les profils, reconstruire leurs historiques et corriger les destinations ? Exigez les limites et le coût de cette opération avant signature.

Éprouver les événements dupliqués, tardifs et rejoués

Les flux réels contiennent des reprises et des retards. AWS rappelle, dans sa documentation sur les échanges événementiels, que des messages peuvent être livrés plusieurs fois et que le consommateur doit gérer cette situation. Une intégration CDP doit donc préciser ce qui identifie un événement et comment elle évite qu’une répétition produise une seconde action métier.

Rejouez un achat portant le même identifiant, puis envoyez un remboursement avant l’achat correspondant. Vérifiez l’état final, le chiffre d’affaires calculé et les déclenchements déjà émis. Distinguez la date de l’événement de sa réception. Un achat ancien reçu aujourd’hui ne doit pas automatiquement déclencher une campagne destinée aux achats récents ; la règle dépend de l’usage et doit être écrite.

Testez également une modification de schéma et un arrêt de destination. Qui voit le rejet ? Pendant combien de temps peut-on reprendre les données ? Le rejeu conserve-t-il les identifiants et respecte-t-il les préférences actuelles ? Précisez si la reprise doit seulement reconstruire les profils ou autoriser des actions. Rétablir un calcul et renvoyer des messages commerciaux sont deux opérations différentes.

Mesurer la latence jusqu’à l’application réelle dans la destination

Remplacez l’expression temps réel par des points de mesure. Horodatez la confirmation métier dans la source, l’acceptation par la CDP, le recalcul du profil, la transmission à la destination et l’application du changement dans cette destination. Un accusé de réception technique ne prouve pas qu’une exclusion est déjà effective. Si le dernier point n’est pas observable, signalez cette limite.

Le cadre SRE de Google distingue l’indicateur mesuré, l’objectif de service et l’accord qui prévoit les conséquences d’un écart. Il recommande aussi de regarder la distribution des délais. Dans le cahier des charges, définissez par exemple un p95 : le délai sous lequel se situent 95 % des observations du périmètre mesuré. Ajoutez taux d’erreur, observations manquantes et taille de l’échantillon.

Mesurez pendant les pointes, avec plusieurs audiences actives et après une indisponibilité. Fixez la période d’observation, la synchronisation des horloges et les exclusions autorisées. Une moyenne sur dix événements ne qualifie pas un pic quotidien. Répartissez enfin les responsabilités : une limite de l’API destinataire ne disparaît pas parce que la CDP traite rapidement les données.

Distinguer audience calculée, personnes autorisées et activation effective

Une audience de 100 000 profils n’équivaut pas à 100 000 personnes joignables. Suivez les étapes : profils répondant à la règle métier, profils autorisés pour l’usage concerné, identifiants exploitables, destinataires acceptés par la plateforme puis action effectivement réalisée. Les exclusions, rejets et limites de canal expliquent les écarts. Le volume exporté ne prouve ni la réception d’un message ni son effet commercial.

La CNIL rappelle que la prospection électronique auprès des particuliers repose en principe sur un consentement préalable, avec des exceptions encadrées, et que le contexte professionnel suit des règles spécifiques. Un indicateur global de consentement ne suffit donc pas à décrire tous les usages. Faites valider la politique applicable, puis représentez finalité, canal, organisation concernée, provenance, date et évolution du choix.

Testez un retrait après création de l’audience mais avant son activation. Testez aussi le rejeu d’un ancien événement favorable après un refus plus récent : il ne doit pas rétablir une autorisation obsolète. Définissez le comportement en cas d’information inconnue ou contradictoire, la propagation aux destinations et la preuve disponible. La démonstration vérifie l’application de votre politique ; elle ne remplace pas sa qualification juridique.

Laisser concourir plusieurs architectures sur le même résultat

N’imposez pas une plateforme intégrée si une architecture composée peut satisfaire les exigences. Une solution peut porter collecte, identité, segmentation et activation ; une autre peut associer entrepôt, modèles de données et synchronisation vers les outils métiers. Le reverse ETL décrit précisément ce dernier mouvement de données préparées vers des applications opérationnelles, comme l’explique dbt.

Comparez le parcours complet : où résident les identités, qui calcule les audiences, où sont vérifiées les préférences, qui supervise les flux ? Faites nommer le responsable de chaque incident et de chaque changement. Une architecture composée peut réutiliser des capacités existantes, mais demande une coordination explicite. Une plateforme intégrée conserve aussi des dépendances aux sources, aux destinations et aux compétences internes.

Demandez les preuves de séparation des environnements, de gestion des droits et de traçabilité. Vérifiez la localisation effective, les sous-traitants et les procédures d’incident avec les responsables compétents. La CNIL recommande d’évaluer les garanties offertes et de contractualiser les obligations de sous-traitance. Une certification constitue un élément du dossier ; son périmètre doit correspondre à la prestation achetée.

Organiser une preuve de fonctionnement que vos équipes peuvent rejouer

La démonstration commerciale sert à comprendre le produit. La preuve de fonctionnement sert à vérifier votre scénario. Fournissez aux finalistes le même dossier, les mêmes données de test et les mêmes critères, avec des données synthétiques lorsque possible. Fixez une enveloppe de préparation comparable et faites déclarer les composants, modules payants et interventions humaines mobilisés.

Déroulez un chemin complet : ingestion, rapprochement, règle d’audience, filtrage des préférences, activation et contrôle en destination. Introduisez ensuite une erreur connue, une panne et une modification métier. Faites réaliser une partie du parcours par les futurs utilisateurs. Le temps nécessaire pour diagnostiquer un profil absent ou corriger une règle renseigne davantage sur l’autonomie qu’une présentation de l’interface.

Conservez les résultats attendus et observés, journaux, versions de configuration, durées et réserves. Séparez les défauts du produit, de configuration et des sources. Attribuez chaque correction et rejouez les cas affectés. Un prototype valide un périmètre précis : il ne prouve pas à lui seul la tenue à la charge annuelle ni une création de valeur commerciale.

Noter les preuves sans laisser une moyenne masquer un blocage

Validez les critères éliminatoires avant notation : usage indispensable non couvert, exigence de sécurité non satisfaite, impossibilité de respecter une exclusion critique ou absence de solution de sortie acceptable. Chaque élimination doit correspondre à un besoin explicite, avec sa preuve. Une interface agréable ne compense pas un risque incompatible avec l’activité.

Sur les offres admissibles, utilisez une échelle commune : 0 pour absent, 1 pour déclaré sans preuve, 2 pour partiellement démontré, 3 pour le seuil atteint sur le scénario, 4 pour un résultat robuste incluant les cas difficiles, 5 pour une capacité supplémentaire utile et démontrée. Calibrez ces niveaux critère par critère avant les essais. Une promesse de développement conserve une réserve distincte.

La note sur 100 est la somme des poids multipliés par la note divisée par 5. Avec un poids de 20 %, une note de 4 contribue pour 16 points. Faites noter métier, data, IT et achats sur les mêmes preuves, puis arbitrez les divergences. Testez aussi si une légère variation des poids change le gagnant : un classement instable appelle une décision explicitement argumentée.

Comparer le coût complet avec les mêmes volumes et le même service

Le TCO, ou coût total de possession, inclut abonnement, modules, mise en œuvre, calcul et stockage, exploitation, changements et sortie. Faites préciser chaque unité facturée : profils connus ou anonymes, événements, destinations, appels ou consommation. Demandez comment les doublons, suppressions, rejeux et dépassements influencent la facture. Comparez une trajectoire basse, centrale et haute fondée sur vos volumes.

L’exemple ci-dessous est entièrement fictif, sur trois ans, en euros hors taxes constants, sans actualisation. Les montants ne représentent aucun tarif fournisseur. L’exploitation valorise du temps interne chargé ; le coût initial exclut ces opérations récurrentes pour éviter un double comptage. Les bénéfices commerciaux sont évalués séparément : ils ne réduisent pas artificiellement le coût présenté.

• Si le seul poste infrastructure augmente de 30 %, le supplément est de 16 200 € et le total atteint 427 200 €. Cela suppose les autres postes inchangés.
• Une hausse des volumes peut aussi changer l’abonnement, les besoins humains et les délais : demandez les règles de calcul, pas uniquement une remise initiale.
• Chiffrez les modifications prévisibles : nouvelle source, nouvelle marque, changement de règle d’identité et montée de version d’un connecteur.

Tester la sortie avant l’entrée : exporter ne suffit pas

Un fichier de profils ne suffit pas à reconstruire le service. Listez les identifiants sources et persistants, correspondances, historique utile, règles d’identité, transformations, définitions d’audiences, préférences et exclusions nécessaires. Déterminez ce qui est exportable, documentable ou à reconstruire. Une configuration propriétaire n’est pas forcément portable : évaluez son remplacement plutôt que de supposer une équivalence automatique.

Sur un périmètre figé, exportez les éléments puis reconstruisez une audience dans un environnement indépendant. Comparez les membres, les attributs décisifs et les exclusions ; expliquez chaque écart. Testez volumes, formats, fréquence d’export, limites d’API et coûts. Incluez le transfert des connaissances et les dépendances aux identifiants générés par le fournisseur.

Contractualisez l’assistance, la période de transition et les conditions de restitution et de suppression. Ces dernières font partie des points de sous-traitance identifiés par la CNIL. Précisez également le sort des copies et les preuves attendues selon les obligations applicables. Ne confondez pas possibilité technique d’exporter et autorisation de conserver toutes les données indéfiniment.

Transformer la sélection en engagements de mise en œuvre

Le dossier final doit relier chaque usage prioritaire à une architecture, un coût, un responsable et un test accepté. Conservez les écarts résiduels avec leur traitement : correction avant démarrage, contournement temporaire ou retrait de périmètre. Distinguez les résultats constatés pendant l’essai, les objectifs de production et les engagements contractuels. Ce sont trois niveaux de preuve différents.

Réutilisez les scénarios du cahier des charges pour la recette. Définissez les conditions de démarrage, l’arrêt d’une activation risquée et le retour à l’état précédent. Faites nommer les propriétaires des règles et l’équipe qui traitera les incidents après le projet. Une première livraison doit être assez limitée pour être maîtrisée, mais assez complète pour éprouver le fonctionnement quotidien.

Le choix est solide lorsque l’organisation peut expliquer pourquoi la solution couvre ses usages, quelles limites subsistent et comment elle les gérera. La qualité du cahier des charges se mesure alors à la réduction des surprises pendant la mise en œuvre, puis à la capacité des équipes à maintenir un service utile.

Questions fréquentes