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.
Pourquoi la séparation test / production est critique en CRM
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.
Les trois environnements à maintenir
DEV
Environnement de développement
Base anonymisée ou fictive, aucun vrai destinataire. Le développeur teste ses workflows, ses scripts de personnalisation, ses requêtes. Aucune communication ne peut partir vers l’extérieur.
QA
Environnement de recette / staging
Base whitelistée (adresses internes uniquement). L’équipe métier valide les scénarios, les visuels, les liens. Aucun envoi possible vers une adresse externe. C’est ici que la QA se fait vraiment.
PROD
Production
Base client réelle. Aucun accès direct sans workflow d’approbation. Toute modification doit passer par DEV → QA avant d’arriver ici.
Les bonnes pratiques sur Adobe Campaign
Sur Adobe Campaign Classic, plusieurs mécanismes natifs permettent de protéger la production :
- Typologies de contrôle — une règle de typ peut bloquer tout envoi vers des adresses hors whitelist sur les instances de test. Simple à configurer, efficace à 100%.
- Adresses de test vs adresses de substitution — les adresses de test permettent de recevoir une copie sans figurer dans la cible réelle. Les adresses de substitution simulent le rendu pour un profil donné. Les deux ne doivent jamais être confondues.
- Workflow d’approbation — configurer une approbation de contenu et/ou de cible avant chaque diffusion à fort volume. Un dexième regard humain avant l’envoi.
- Environnements séparés — dév, recette et production sur des instances distinctes. Un changement fait en recette ne doit jamais être appliqué directement en production sans passer par le processus de déploiement.
J’ai détaillé l’importance de cette séparation dans mon article sur workflow technique vs workflow de campagne — un workflow mal catalisé peut déclencher des envois sans appliquer les typologies, et donc sans les garde-fous prévus.
Les bonnes pratiques sur Salesforce
Sur Salesforce, la gestion des environnements est structurée par les sandboxes :
- Developer Sandbox — pour le développement. Pas de données réelles, pas d’envoi email possible vers des contacts réels.
- Full Sandbox — copie complète de la production, données comprises. Idéal pour la recette finale. Attention : les emails peuvent partir si les profils d’utilisateur ne sont pas correctement configurés.
- Configuration des Email Relay — en sandbox, Salesforce propose de bloquer tous les emails sortants ou de les rediriger vers une adresse de test. Ce paramètre est critiqu — ne jamais l’ignorer.
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 marketing automation : ce que l’équipe technique oublie souvent
La QA en CRM ne se limite pas à vérifier que le workflow s’exécute sans erreur. Elle couvre :
- La cible est-elle correcte ? (segment, exclusions, typologies appliquées)
- Le contenu est-il bien celui attendu ? (version, langue, personnalisation)
- Les liens fonctionnent-ils ? (tracking, redirections, landing pages)
- Le rendu est-il correct sur les principaux clients email ? (Gmail, Outlook, mobile)
- L’heure d’envoi est-elle confirmée ? (fuseau horaire, heure de pointe, événement concurrent)
- L’approbation a-t-elle été donnée par la bonne personne ?
- La désinscription fonctionne-t-elle correctement ?
Une règle simple que j’applique sur tous mes projets : personne qui a créé la diffusion ne peut valider et envoyer lui-même. Une deuxième paire d’yeux, toujours. C’est cette règle que Cédric n’avait pas.
Ce que l’incident « Test Cédric » nous enseigne vraiment
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.
On 9 June 2026, millions of Crédit Agricole customers received a push notification on their Ma Banque app: "Test Cédric". Two words, no context, a link that led nowhere. An internal notification sent by mistake to all 27 million users. The flood of simultaneous connections from curious users crashed the app — over 7,700 reports on Downdetector around 4:30pm.
This wasn't the first time. In 2022, Air France sent a test email titled "Test de Julien" to thousands of customers. Two incidents, two different companies, the same underlying problem: the absence of safeguards between the test environment and production.
A message accidentally sent to your production database isn't just a technical problem. It's a customer trust issue, a sender reputation issue, and sometimes a GDPR concern if test data includes real personal information.
Why test/production separation is critical in CRM
In CRM and marketing automation, production is your real customer database. A misconfigured workflow, a misconfigured target, and you're sending a test email to 2 million active contacts, or worse, triggering a mass quarantine on real addresses.
As highlighted in Mr Suricate's QA guide (January 2026), the key is having "stable test data and an iso-prod environment to avoid false positives". The test environment must resemble production — in terms of configuration, volume, behaviour — without ever being connected to real customer data.
The three environments to maintain
DEV
Development environment
Anonymised or fictitious database, no real recipients. Developers test workflows, personalisation scripts, queries. No communication can go out externally.
QA
Testing / staging environment
Whitelisted database (internal addresses only). The business team validates scenarios, visuals, links. No sending possible to external addresses. This is where real QA happens.
PROD
Production
Real customer database. No direct access without an approval workflow. Every change must pass through DEV → QA before arriving here.
Best practices on Adobe Campaign
Adobe Campaign Classic offers several native mechanisms to protect production:
- Control typologies — a typology rule can block any send to addresses outside a whitelist on test instances. Simple to configure, 100% effective.
- Test addresses vs substitution addresses — test addresses receive a copy without appearing in the real target. Substitution addresses simulate rendering for a given profile. The two must never be confused.
- Approval workflow — configure content and/or target approval before each high-volume delivery. A second human look before sending.
- Separate environments — dev, staging and production on distinct instances. A change made in staging must never be applied directly to production without going through the deployment process.
I detailed the importance of this separation in my article on technical workflows vs campaign workflows — a miscategorised workflow can trigger sends without applying typologies, and therefore without the intended safeguards.
Best practices on Salesforce
On Salesforce, environment management is structured through sandboxes:
- Developer Sandbox — for development. No real data, no email sending possible to real contacts.
- Full Sandbox — complete copy of production, including data. Ideal for final testing. Note: emails can go out if user profiles aren't correctly configured.
- Email Relay configuration — in sandbox, Salesforce offers to block all outbound emails or redirect them to a test address. This setting is critical — never ignore it.
QA in marketing automation: what the technical team often forgets
QA in CRM is not limited to verifying that the workflow runs without error. It covers:
- Is the target correct? (segment, exclusions, typologies applied)
- Is the content the expected one? (version, language, personalisation)
- Do the links work? (tracking, redirects, landing pages)
- Is the rendering correct on major email clients? (Gmail, Outlook, mobile)
- Is the send time confirmed? (timezone, peak hours, competing events)
- Has approval been given by the right person?
- Does unsubscription work correctly?
A simple rule I apply on all my projects: whoever created the delivery cannot validate and send it themselves. A second pair of eyes, always. This is the rule Cédric didn't have.
What the "Test Cédric" incident really teaches us
The Crédit Agricole incident is not the fault of a distracted developer. It's the symptom of a process that didn't account for this scenario. In an organisation of this size, with 27 million users, sending a push notification should require multiple validation levels. If a single person can trigger a send to the entire database from a test environment, the problem isn't technical — it's organisational.
As I described in my article on projects that fail their testing phase: production incidents almost never come from the code. They come from the absence of process around the code.
The most expensive technical debt isn't what you've accumulated. It's what you didn't plan to put into production.