Remplacer une intégration CRM par une autre n’est jamais qu’un changement de clé d’API : c’est une bascule qui peut casser silencieusement un scénario d’automatisation construit sur des champs précis, des déclencheurs précis et des conditions de segmentation précises. Sur ce projet client, la migration d’un connecteur CRM propriétaire vers Brevo a servi de terrain pour construire une checklist de tests réutilisable, indépendante de la migration des données historiques elle-même, traitée séparément.
L’objectif de cette checklist n’est pas de vérifier que la connexion à l’API fonctionne — cela se voit en quelques secondes — mais que le comportement métier attendu par les équipes marketing survit intact au changement d’outil, en particulier les scénarios déclenchés automatiquement sans intervention humaine.
1. Cartographier chaque champ avant de coder
Avant d’écrire le moindre test, la correspondance entre les champs de l’ancien CRM et ceux de Brevo doit être documentée exhaustivement, y compris les champs qui semblent équivalents mais ne le sont pas totalement, comme un champ de statut d’abonnement dont les valeurs possibles diffèrent d’un système à l’autre.
- Lister les quatorze champs personnalisés utilisés par les scénarios d’automatisation existants
- Vérifier le type de donnée attendu par Brevo pour chacun (texte, nombre, date, catégorie)
- Repérer les champs dont les valeurs possibles ne correspondent pas terme à terme
2. Écrire un test de correspondance par champ
Chaque champ cartographié à l’étape précédente doit faire l’objet d’un test qui vérifie que la valeur envoyée par le connecteur arrive intacte côté Brevo, via l’API de contacts en environnement de test :
public function test_champ_date_adhesion_correctement_transmis(): void
{
$contact = $this->creer_contact_de_test(['date_adhesion' => '2026-03-15']);
$reponse = $this->connecteur_brevo->synchroniser($contact);
$contact_brevo = $this->client_brevo->getContact($contact->get_email());
$this->assertSame('2026-03-15', $contact_brevo->getAttributes()['DATE_ADHESION']);
}
Ce test unitaire par champ paraît répétitif, mais c’est justement sa simplicité qui le rend fiable : un échec pointe immédiatement vers le champ fautif, sans avoir à déchiffrer un scénario d’automatisation complet pour localiser le problème.
Attention particulière aux champs de segmentation
Les champs utilisés comme critères de segmentation méritent une vérification renforcée, car une valeur mal transmise ne provoque aucune erreur visible : le contact est simplement absent de la liste attendue, silencieusement, sans qu’aucun message n’alerte l’équipe marketing.
3. Rejouer chaque scénario d’automatisation en environnement de test
Une fois les champs validés isolément, chaque scénario d’automatisation existant doit être reconstruit dans l’espace de test Brevo et déclenché avec un contact fictif, pour vérifier que la séquence complète s’exécute comme prévu :
- Créer un contact de test correspondant exactement au déclencheur du scénario (par exemple, une inscription à une newsletter)
- Vérifier que le scénario se déclenche dans le délai attendu, sans intervention manuelle
- Vérifier que chaque étape conditionnelle du scénario emprunte la bonne branche selon les champs du contact
- Vérifier que le contact atteint bien l’état final attendu (ajout à une liste, retrait d’une autre, envoi d’un email)
4. Vérifier les cas de rejet et de doublon
Un scénario souvent négligé : que se passe-t-il quand un contact existe déjà côté Brevo au moment de la synchronisation ? La checklist doit couvrir explicitement la mise à jour d’un contact existant, sans création de doublon, et la gestion d’une adresse email invalide qui doit être rejetée proprement plutôt que silencieusement ignorée.
public function test_synchronisation_ne_cree_pas_de_doublon(): void
{
$contact = $this->creer_contact_de_test();
$this->connecteur_brevo->synchroniser($contact);
$this->connecteur_brevo->synchroniser($contact); // deuxième appel volontaire
$resultats = $this->client_brevo->getContactsByEmail($contact->get_email());
$this->assertCount(1, $resultats);
}
5. Garder l’ancien connecteur actif en parallèle
La dernière ligne de la checklist, souvent la plus rassurante pour un client : ne pas couper l’ancien connecteur CRM le jour de la bascule, mais le laisser tourner en parallèle sur un sous-ensemble de contacts pendant une à deux semaines, en comparant les résultats produits par les deux outils sur les mêmes déclencheurs.
Un connecteur qui fonctionne en test isolé peut encore révéler un écart de comportement une fois confronté au volume et à la variété réelle des contacts en production ; la période de double fonctionnement sert exactement à capter cet écart avant qu’il ne coûte cher.
Pour aller plus loin
Cette checklist reste volontairement centrée sur le comportement fonctionnel du connecteur et des scénarios d’automatisation. Elle ne couvre pas la migration des données historiques déjà présentes dans l’ancien CRM, qui relève d’un projet distinct avec ses propres exigences de qualité de données et son propre calendrier de validation.
