👤 SAP Customer Data Cloud (Gigya) – CIAM, Consent & Profiles

Éléments de base

Vision “Customer 360”

L’idée : centraliser tout ce qui touche à l’identité et au consentement, puis exposer :

• Un profil unique par individu, partagé entre marques/canaux.
• Des API standard pour lecture / écriture de ces données.
• Des flux sortants pour alimenter le marketing, l’analytics, etc.

• Portail B2C / B2B2C unifié pour plusieurs marques.
• Programme de fidélité avec profil global client.
• Centre de préférences marketing (opt-in / opt-out, canaux, thèmes).
• Self-service privacy (export / suppression des données).

Exemple : groupe multi-marques

• Un compte Gigya pour un individu.
• Plusieurs “identities” / liens avec les plateformes internes.
• Consentement consolidé sur tous les sites du groupe.

Vue DevOps / intégration SI

• Exposition de REST API pour les backend (Django, Java, Node…).
• Connecteurs / Jobs pour SAP (Marketing Cloud, Commerce, etc.).
• Webhooks pour réagir aux évènements (registration, profile update…).

Rôles & responsabilités

• Équipe digital : UX des formulaires & parcours.
• Équipe IAM / sécurité : policies d’accès, tokens, scopes.
• Équipe data/CRM : mapping & sync vers DWH/CRM.

Sites & marques

• Un site = configuration spécifique (domaines, policies, forms…).
• On peut avoir un site par marque, par pays, par canal…
• Les identités peuvent être partagées entre sites d’une même account CDC.

Régions & data centers

• Instances EU / US / autres, selon contraintes de localisation.
• Important pour RGPD / contrats (hébergement des données).
• DevOps : aligner les apps (DNS, latence) sur les régions CDC.

Flux “front → CDC → SI”

Client (web / mobile)
        │  (JS SDK, OIDC, screenset)
        ▼
SAP CDC (Gigya)
        │  (events / webhooks / ETL)
        ▼
Backends internes (Django, SAP, CRM, DWH...)
                        

Flux “back → CDC”

Les systèmes back peuvent aussi créer / mettre à jour des profils :

• Import batch (fichiers, jobs ETL).
• API server-to-server (REST) pour faire du “upsert” d’identités.
• Process de merge / dédoublonnage alignés avec CDC.

Social login

• Connecteurs intégrés pour les principaux réseaux.
• Récupération des données de profil dans le compte CDC.
• Possibilité de linker plusieurs identities sociales à un même compte.

Aspects DevOps

• Gestion des clés OAuth dans SAP CDC (et non dans les apps).
• Simplification de la config sur les frontends.
• Monitoring du taux de succès social vs classique.

Progressive profiling

On ne demande pas tout à l’inscription : on enrichit le profil dans le temps.

• Phase 1 : email + consent obligatoire.
• Phase 2 : centres d’intérêt, téléphone, adresse, etc.
• Phase 3 : données plus sensibles / business.

Implémentation

• Configs d’UI qui affichent certains champs selon le contexte.
• Rules / workflows déclenchés après login (prompts à afficher).
• Stockage centralisé des réponses dans les champs custom CDC.

REST API

POST https://accounts.<region>.gigya.com/accounts.getAccountInfo
Content-Type: application/json

{
  "UID": "123456789",
  "include": "profile,data,subscriptions",
  "apiKey": "...",
  "secret": "..."
}
                        

Utilisation typique

• Backends qui ont besoin des infos profil / consent.
• Jobs de synchronisation vers CRM/DWH.
• Process métiers (fusion de comptes, corrections...).

Pattern Django (exemple pseudo-code)

def sync_gigya_user(uid: str):
    payload = {"UID": uid, "include": "profile,data,consents"}
    res = requests.post(GIGYA_ENDPOINT, json=payload, timeout=5)
    res.raise_for_status()
    gd = res.json()
    # Mapper sur ton modèle interne
    user, _ = Customer.objects.update_or_create(
        external_uid=uid,
        defaults={
            "email": gd["profile"]["email"],
            "first_name": gd["profile"]["firstName"],
            "last_name": gd["profile"]["lastName"],
            "segment": gd["data"].get("segment"),
        }
    )
    return user
                        

Points d’attention

• Timeouts & retries (API CDC).
• Résilience côté jobs (files d’attente, retry DLQ).
• Audit de ce qui est écrit localement vs dans CDC.