J’ai accompagné des dizaines de projets Salesforce. Et j’ai observé le même pattern se répéter à chaque fois que la mise en production vire à la catastrophe : la phase de recette a été mal conçue, broclée, ou les deux.
Ce n’est pas un problème technique. C’est un problème d’organisation et d’anticipation. Et il se fabrique toujours bien avant que la recette commence.
Les 5 erreurs qui font rater la recette Salesforce
1. La recette est planifiée trop tard et trop courte
Le schéma classique : le projet prend du retard en développement, le planning global ne bouge pas, et la phase de recette est comprimée pour tenir la date de go-live. On passe de 3 semaines prévues à 5 jours réels.
Résultat : les testeurs n’ont pas le temps de couvrir tous les scénarios. Les anomalies non critiques sont mise “en backlog” — et se retrouvent en production. La dette qualité s’accumule dès le premier jour.
La recette ne se comprime pas. Si le développement prend du retard, c’est le go-live qui doit étre reporté — pas la recette qui doit être écrasée.
2. Les mauvaises personnes font les tests
C’est l’erreur la plus fréquente. La recette est confiée aux développeurs, à l’équipe IT, ou à un chef de projet qui connaît le système mieux que n’importe quel utilisateur. Ces profils testent ce qu’ils ont conçu, avec des données propres, des scénarios prévisibles.
Ce qu’il faut à la place : les utilisateurs finaux. Les commerciaux qui vont saisir des opportunités à la suite d’un appel téléphonique. Le service client qui va gérer un ticket complexe avec des données réelles. Ce sont eux qui trouvent les vrais problèmes.
3. Il n’y a pas de critères d’acceptation définis
Une anomalie est-elle bloquante ou non ? Cette question, posée pendant la recette sans réponse pré-établie, génère des conflits interminables entre l’équipe projet et le client. Chacun a sa définition de “acceptable”.
La solution : définir les critères d’acceptation avant de commencer le développement, pas pendant la recette. Qu’est-ce qui est bloquant pour le go-live ? Qu’est-ce qui peut attendre le premier patch ? Ce cadrage doit exister par écrit.
4. Les données de test ne ressemblent pas à la production
La recette se passe avec 10 comptes propres, des champs bien renseignés, des scénarios linéaires. La production, c’est 50 000 comptes avec des données manquantes, des caractères spéciaux dans les noms, des cas limites que personne n’avait anticipés.
Tester avec des données qui ne ressemblent pas à la réalité, c’est se donner bonne conscience sans réduire le risque réel.
Ideal : utiliser un jeu de données anonymisé extrait de la production (ou du système source). Si ce n’est pas possible, construire manuellement des cas limites : champs vides, valeurs extrêmes, données dupliquées.
5. Il n’y a pas de pilote de recette
La recette est organisée, les testeurs sont désignés, les anomalies sont logées dans un tableur. Mais personne n’a la responsabilité de piloter l’avancement, de prioriser les corrections, de décider ce qui est bloquant et ce qui ne l’est pas.
Sans pilote clairement désigné, la recette dérive. Les anomalies s’accumulent sans être traitées. Les décisions ne sont pas prises. Et le go-live approche.
Comment organiser une recette Salesforce qui fonctionne
01
Définir les critères d’acceptation avant le développement
Bloquer, non bloquant, cosmétique — chaque catégorie a une définition écrite validée par le client et l’équipe projet.
02
Impliquer les utilisateurs finaux dès la conception des scénarios
Ce sont eux qui connaissent les cas limites réels. Leur participation à la phase de rédaction des scripts de test est aussi précieuse que leur présence en recette.
03
Préparer un jeu de données représentatif
Données manquantes, valeurs extrêmes, données dupliquées — les mêmes problèmes qui existent en production doivent exister en recette.
04
Désigner un pilote de recette avec pouvoirs de décision
Une personne qui peut prioriser les corrections, statuer sur le caractère bloquant d’une anomalie, et décider du go-live.
05
Protéger la durée de la recette
Si le développement prend du retard, le go-live se décale — pas la recette. C’est une règle non négociable.
Le signe que la recette va bien se passer
Les projets dont la recette se passe bien ont tous un point commun : les utilisateurs finaux ont été impliqués tôt. Pas seulement en recette — dès les ateliers de conception. Ils ont contribué à définir les scénarios, ils ont validé les maquettes, et quand la recette commence, ils savent ce qu’ils vont tester et pourquoi.
La recette n’est pas une étape en fin de projet. C’est l’aboutissement d’un processus de validation qui commence dès le premier atelier.
I have accompanied dozens of Salesforce projects. Production go-lives turn into disasters in one out of three cases. And each time, the problem doesn't come from the development — it comes from the testing phase.
This is not a technical problem. It's an organisational and anticipation problem. And it's always manufactured well before testing begins.
The 5 mistakes that derail Salesforce testing
1. The testing phase is too short
The classic pattern: development runs late, the overall schedule doesn't move, and the testing phase gets compressed to meet the go-live date. Three planned weeks become five real days.
Result: testers don't have time to cover all scenarios. Non-critical bugs are "backlogged" — and end up in production. Quality debt accumulates from day one.
Testing cannot be compressed. If development runs late, the go-live must be delayed — not the testing phase crushed.
2. The wrong people are doing the testing
This is the most frequent mistake. Testing is handed to developers, the IT team, or a project manager who knows the system better than any user. These profiles test what they designed, with clean data, predictable scenarios. What's needed instead: end users. The sales reps who will enter opportunities after a phone call. The customer service team that will handle a complex ticket with real data. These are the ones who find the real bugs.
3. No acceptance criteria are defined
Is an anomaly blocking or not? This question, asked during testing without a pre-established answer, generates endless conflicts between the project team and the client. Everyone has their own definition of "acceptable". The solution: define acceptance criteria before development starts, not during testing. What's blocking for go-live? What can wait for the first patch? This framing must exist in writing.
4. Test data doesn't resemble production
Testing happens with 10 clean accounts, well-filled fields, linear scenarios. Production has 50,000 accounts with missing data, special characters in names, edge cases nobody anticipated. Testing with data that doesn't resemble reality gives a clear conscience without reducing real risk.
Ideal: use an anonymised dataset extracted from production. If not possible, manually build edge cases: empty fields, extreme values, duplicate data.
5. There is no testing lead
Testing is organised, testers are assigned, anomalies are logged in a spreadsheet. But nobody has responsibility for tracking progress, prioritising fixes, deciding what's blocking and what isn't. Without a clearly designated lead, testing drifts. Anomalies accumulate without being addressed. Go-live approaches.
How to organise a Salesforce testing phase that works
01
Define acceptance criteria before development
Blocking, non-blocking, cosmetic — each category has a written definition validated by both the client and project team.
02
Involve end users from the test script design phase
They know the real edge cases. Their participation in writing test scripts is as valuable as their presence during testing itself.
03
Prepare a representative dataset
Missing data, extreme values, duplicates — the same problems that exist in production must exist in the testing environment.
04
Designate a testing lead with decision-making authority
One person who can prioritise fixes, rule on whether an anomaly is blocking, and decide on go-live.
05
Protect the testing duration
If development runs late, go-live shifts — not testing. This is a non-negotiable rule.
The sign that testing will go well
Projects whose testing phases go well all have one thing in common: end users were involved early. Not just in testing — from the design workshops. They contributed to defining scenarios, validated mockups, and when testing begins, they know what they're testing and why. Testing is not a step at the end of a project. It's the culmination of a validation process that begins at the first workshop.