Le 9 juin 2026, des millions de clients du Crédit Agricole ont reçu une notification push « Test Cédric » sur leur application Ma Banque. 27 millions de destinataires, une application qui tombe sous la charge des connexions simultanées, et un sujet viral en quelques minutes. La banque a géré l’incident avec une réelle créativité en se rebaptisant « Cédric Agricole » sur ses réseaux sociaux, transformant le couac en moment de marque. Mais l’incident lui-même n’était pas inévitable.
Ce n’est pas la première fois. En 2022, Air France avait envoyé un email de test intitulé « Test de Julien » à des milliers de clients. Deux incidents, deux sociétés différentes, le même problème de fond : l’absence de garde-fous entre l’environnement de test et la production.
Un message envoyé par erreur à votre base de production n’est pas qu’un problème technique. C’est un problème de confiance client, de réputation d’expéditeur, et parfois un sujet RGPD si les données test incluent de vraies informations personnelles.
En CRM et marketing automation, la production c’est votre base client réelle. Un workflow mal configuré, une cible mal paramétrée, et vous êtes en train d’envoyer un email de test à 2 millions de contacts actifs, ou pire, de déclencher une mise en quarantaine en masse sur de vraies adresses.
Comme le souligne le guide QA de Mr Suricate (janvier 2026), la clé est d’avoir « des données de test stables et un environnement iso-prod pour éviter les faux positifs ». L’environnement de test doit ressembler à la production, en termes de configuration, de volume, de comportement, sans jamais être connecté aux vraies données clients.
Et comme le rappelle Invox dans son guide Marketing Automation : « avoir une donnée mal ordonnée est sans aucun doute l’une des pires choses qui puisse arriver à votre business. » La qualité des données commence par leur séparation correcte entre les environnements.
Sur Adobe Campaign Classic, plusieurs mécanismes natifs permettent de protéger la production :
J’ai détaillé l’importance de cette séparation dans mon article sur workflow technique vs workflow de campagne, un workflow mal paramétré peut déclencher des envois sans appliquer les typologies, et donc sans les garde-fous prévus.
Sur Salesforce, la gestion des environnements est structurée par les sandboxes :
J’ai détaillé les risques de déploiement Salesforce dans mon article sur Change Sets, SFDX et bonnes pratiques : la chaîne DEV → Full Sandbox → Production n’est pas optionnelle.
La QA en CRM ne se limite pas à vérifier que le workflow s’exécute sans erreur. Elle couvre :
Une règle simple que j’applique sur tous mes projets : la personne qui a créé la diffusion ne peut pas valider et envoyer elle-même. Une deuxième paire d’yeux, toujours. C’est cette règle que Cédric n’avait pas.
L’incident du Crédit Agricole n’est pas la faute d’un développeur distrait. C’est le symptôme d’un processus qui n’a pas prévu ce scénario. Dans une organisation de cette taille, avec 27 millions d’utilisateurs, envoyer une notification push devrait nécessiter plusieurs niveaux de validation. Si une seule personne peut déclencher un envoi à l’ensemble de la base depuis un environnement de test, le problème n’est pas technique, il est organisationnel.
Comme je l’ai décrit dans mon article sur les projets qui ratent leur recette : les incidents de production ne viennent presque jamais du code. Ils viennent de l’absence de processus autour du code.
La dette technique la plus chère n’est pas celle qu’on a accumulée. C’est celle qu’on n’avait pas prévu de mettre en prod.
La séparation test / production et les workflows d’approbation font partie des points que je vérifie systématiquement. Cadrage gratuit, sans engagement.
Contact →