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.
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.
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.
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.
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.
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.
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.
Le cadrage est gratuit et sans engagement. 30 minutes pour définir le périmètre et valider la faisabilité.
Contact →