# Intercom depuis une extension : ouvrir le chat avec le contexte du compte

> Redemander son plan et son ancienneté à un client qui ouvre le chat, c'est le meilleur moyen de l'énerver. Le contexte doit partir avec lui, automatiquement.

- Auteur : WordPress Développement
- Publié le : 2023-07-14
- Mis à jour le : 2023-07-14
- Catégorie : Extensions
- URL : https://www.wpmoderne.fr/extensions/intercom-extension-ouvrir-chat-contexte-compte/

## L’essentiel

- L'identity verification empêche l'usurpation de compte via le widget
- Les attributs personnalisés Intercom se poussent à la connexion, pas à l'ouverture du chat
- Un attribut obsolète non rafraîchi vaut pire qu'aucun attribut

Un abonné du plan « Entreprise » ouvre le chat de support et se voit poser la question : « quel est votre plan actuellement ? » Cette situation, fréquente sur une intégration Intercom mal branchée, ruine l'intérêt même de l'outil : offrir un support contextualisé sans ressaisie. Ce tutoriel construit le pont entre les données de compte gérées par WordPress (ou WooCommerce) et le widget Intercom affiché au visiteur connecté, sans traiter Zendesk, non concerné par ce cas précis.

Le principe général tient en une phrase : chaque fois qu'un utilisateur se connecte, l'extension pousse à Intercom un instantané à jour de ses attributs de compte, de sorte que l'équipe support voit, dès l'ouverture de la conversation, le plan souscrit, la date d'inscription et le statut d'abonnement, sans qu'aucune de ces informations ne soit redemandée au client.

## L'identity verification, étape non négociable

Intercom propose un mode « identity verification » qui empêche un visiteur malveillant de se faire passer pour un autre utilisateur en falsifiant simplement son identifiant côté navigateur. Ce mode repose sur un hash HMAC calculé côté serveur, jamais côté client :

```
function wpm_intercom_hash_utilisateur( int $user_id ) : string {
    return hash_hmac( 'sha256', (string) $user_id, WPM_INTERCOM_SECRET_CLE );
}
```

Sans cette vérification, activer Intercom reviendrait à afficher les données de n'importe quel compte à quiconque connaît ou devine son identifiant, ce qui est inacceptable dès qu'un attribut sensible (montant de facturation, plan tarifaire) est exposé dans le widget.

## Pousser les attributs à la connexion

Le hook `wp_login` est le point d'entrée naturel pour synchroniser les attributs de compte, plutôt que d'attendre une ouverture du widget qui pourrait survenir bien après la connexion, avec des données entre-temps modifiées :

> L'essentiel à retenir : L'identity verification empêche l'usurpation de compte via le widget ; Les attributs personnalisés Intercom se poussent à la connexion, pas à l'ouverture du chat ; Un attribut obsolète non rafraîchi vaut pire qu'aucun attribut

```
add_action( 'wp_login', function ( string $user_login, WP_User $user ) {
    $abonnement = wpm_recuperer_abonnement( $user->ID );

    $attributs = array(
        'user_id'          => (string) $user->ID,
        'email'            => $user->user_email,
        'name'             => $user->display_name,
        'created_at'       => strtotime( $user->user_registered ),
        'plan'             => $abonnement['plan'] ?? 'gratuit',
        'anciennete_jours' => (int) floor( ( time() - strtotime( $user->user_registered ) ) / DAY_IN_SECONDS ),
    );

    set_transient( 'wpm_intercom_attributs_' . $user->ID, $attributs, DAY_IN_SECONDS );
}, 10, 2 );
```

## Initialiser le widget avec ce contexte

Côté front, le script d'initialisation Intercom lit les attributs préparés côté serveur et les injecte dans l'appel `Intercom('boot', ...)`, en incluant le hash de vérification calculé précédemment :

```
window.intercomSettings = {
    app_id: "<?php echo esc_js( WPM_INTERCOM_APP_ID ); ?>",
    user_id: "<?php echo esc_js( $attributs['user_id'] ); ?>",
    user_hash: "<?php echo esc_js( $hash_verification ); ?>",
    email: "<?php echo esc_js( $attributs['email'] ); ?>",
    name: "<?php echo esc_js( $attributs['name'] ); ?>",
    plan: "<?php echo esc_js( $attributs['plan'] ); ?>",
    anciennete_jours: <?php echo (int) $attributs['anciennete_jours']; ?>
};
```

## Éviter l'attribut obsolète

Un attribut de plan resté figé après un changement d'abonnement est pire qu'une absence d'attribut : l'agent support fait confiance à une donnée fausse et propose une réponse inadaptée. Deux événements doivent donc déclencher une resynchronisation immédiate, en plus de la connexion :

- Le changement de plan d'abonnement, via le hook métier déclenché par la passerelle de paiement (par exemple `woocommerce_subscription_status_changed`).
- Une tâche planifiée quotidienne qui resynchronise les attributs de tous les comptes actifs, en filet de sécurité pour les événements manqués.

> La règle appliquée sur ce type d'intégration : un attribut affiché dans Intercom ne doit jamais avoir plus de vingt-quatre heures de retard sur la réalité du compte. Au-delà, mieux vaut ne pas l'afficher que d'afficher une valeur potentiellement fausse.

## Pour aller plus loin

Cette intégration peut s'enrichir d'événements personnalisés (`Intercom('trackEvent', ...)`) pour signaler une action précise, comme l'abandon d'un tunnel de paiement, ce qui permet de déclencher une intervention proactive de l'équipe support plutôt que d'attendre que le client ouvre lui-même le chat. Mais la base reste la même : identité vérifiée, attributs poussés au bon moment, et jamais de donnée affichée sans garantie de fraîcheur.