Comment lire cette liste
Les dix erreurs ci-dessous ne sont pas classées par fréquence mais par ordre d'apparition dans le calendrier d'un projet. Pour chacune d'elles, trois éléments sont présentés : le signe d'alerte précoce à identifier en temps réel, l'action préventive et l'étape au-delà de laquelle la correction devient significativement plus coûteuse. L'idée est simple : presque toutes ces erreurs coûtent très peu si elles sont traitées dans les deux semaines appropriées.
1. Débuter par une liste de fonctionnalités plutôt que par un processus
Le signe : Le document d'exigences est structuré comme un tableau de capacités souhaitées, sans qu'aucune ligne ne décrive un résultat commercial.
Ce qui se passe en pratique : Le projet aboutit à un système qui répond à la liste de fonctionnalités mais ne modifie pas la méthode de travail. Un an plus tard, la direction demande ce qui a changé, et il n'y a pas de réponse mesurable.
Prévention : Associer à chaque exigence le processus qu'elle sert et l'indicateur qui doit évoluer. Une exigence sans réponse à ces deux questions est placée en liste d'attente. L'ensemble des livrables qui évite ce piège est détaillé dans le guide de découverte CRM.
2. Absence d'un propriétaire de processus unique
Le signe : Lors des réunions, quatre personnes du même département sont présentes, et aucune n'est habilitée à dire "c'est ainsi que cela se passera".
Ce qui se passe en pratique : Chaque décision est conclue par un compromis qui tente de satisfaire tout le monde, ce qui signifie la construction de deux parcours au lieu d'un seul. Le système devient deux fois plus complexe que nécessaire.
Prévention : Attribuer à chaque processus le nom d'une seule personne. La répartition des rôches recommandée est détaillée dans le guide des rôles d'équipe projet Salesforce.
3. Reporter les décisions architecturales à la fin
Le signe : L'équipe avance dans la construction des écrans tandis que la question "quelle est la source de vérité pour le client" reste ouverte.
Ce qui se passe en pratique : Lorsque la décision est enfin prise, elle contredit ce qui a été construit. Une partie du travail est rejetée, et l'estimation initiale du projet n'est plus pertinente.
Prévention : Identifier dès le départ les trois à cinq décisions coûteuses à modifier – modèle de données central, source de vérité, modèle d'autorisations – et leur attribuer une date d'échéance avant le début de la construction.
4. Importer la dette de l'ancien système
Le signe : Le cahier des charges de la migration contient tous les champs de l'ancien système, y compris ceux dont le nom se termine par "_old_2".
Ce qui se passe en pratique : La nouvelle plateforme est lancée avec deux cents champs que personne ne maintient, des rapports qui s'appuient sur des données peu fiables, et des utilisateurs qui en déduisent que le nouveau système n'est pas non plus sérieux.
Prévention : Chaque champ transféré doit avoir un propriétaire et une utilisation prouvée au cours de la dernière année. Le reste est transféré vers une archive lisible et non vers le système actif.
5. Mesurer la progression par le nombre de "stories" complétées
Le signe : Le rapport hebdomadaire présente des pourcentages d'achèvement élevés, mais personne n'a encore réussi à exécuter un processus complet de bout en bout.
Ce qui se passe en pratique : Le projet semble être un succès sur le graphique jusqu'à la semaine précédant le déploiement, puis il s'avère que toutes les pièces fonctionnent séparément et que personne n'a vérifié la connexion.
Prévention : Définir un jalon "premier processus de bout en bout en production" aussi tôt que possible, même s'il ne couvre qu'un seul scénario. Tant que ce jalon n'est pas atteint, les pourcentages d'achèvement ne constituent pas une information pertinente.
6. Champs obligatoires comme substituts à la discipline des données
Le signe : L'écran de création d'enregistrement comprend douze champs obligatoires, dont trois dont personne ne sait qui est censé connaître la valeur.
Ce qui se passe en pratique : Les utilisateurs sélectionnent la première valeur de la liste pour avancer. Les rapports reçoivent des données complètement complètes et aussi complètement erronées.
Prévention : L'obligation n'est imposée qu'aux champs nécessaires à une décision au moment où ils sont demandés. Les champs nécessaires plus tard dans le processus sont rendus obligatoires plus tard dans le processus.
7. Construire l'automatisation avant la stabilisation du processus
Le signe : Il existe trois mécanismes d'automatisation fonctionnant sur le même objet, et personne ne connaît l'ordre d'exécution entre eux.
Ce qui se passe en pratique : Effets secondaires imprévus, boucles de mise à jour, et surtout, incapacité de modifier un processus sans craindre de tout casser.
Prévention : Exécuter un processus manuel ou semi-manuel pendant plusieurs semaines avant de l'automatiser. L'automatisation fige une décision — il est préférable que cette décision soit la bonne.
8. UAT réalisé par celui qui a construit
Le signe : Les scripts de test ont été écrits par la même équipe de développement, et ils couvrent principalement le chemin nominal.
Ce qui se passe en pratique : Les incidents qui atteignent la production sont justement les cas d'exception – annulations, avoirs, client en double, utilisateur ayant quitté le processus en cours.
Prévention : Les tests sont effectués par les responsables de processus, sur des données similaires aux données réelles, et avec une responsabilité définie d'approbation ou de rejet.
9. La formation comme événement ponctuel
Le signe : Le plan de déploiement comprend deux ateliers la semaine précédant le lancement, et rien après.
Ce qui se passe en pratique : Les utilisateurs apprennent des écrans et non des processus, oublient en deux semaines et se tournent vers des collègues ou une feuille Excel. Le taux d'utilisation diminue progressivement sans que personne ne s'en aperçoive.
Prévention : Formation par rôle, aussi proche que possible du moment où l'employé effectuera réellement l'action, avec un point de support disponible les premières semaines.
10. Absence de propriété après le Go Live
Le signe : Le plan de projet ne contient aucune ligne décrivant qui gère le système au cours du troisième mois.
Ce qui se passe en pratique : Les demandes de changement s'accumulent sans réponse, les petits incidents deviennent une pratique de contournement, et le système vieillit rapidement.
Prévention : Définir la propriété opérationnelle, un mécanisme de réception des demandes et un rythme de diffusion régulier avant le déploiement et non après. Dans les grandes organisations, cela se fait généralement via un modèle de gouvernance structuré, comme décrit dans le Guide de mise en œuvre de Salesforce dans une entreprise.
Coût de la correction par étape
| Erreur | Correction à la phase de conception | Correction à la phase de construction | Correction après le Go Live |
|---|---|---|---|
| Modèle de données incorrect | Modification du schéma | Reconstruction de l'objet | Migration interne et reférencement complet |
| Absence de propriétaire de processus | Désignation | Arrêt et prises de décision répétées | Processus en double maintenu indéfiniment |
| Dette de l'ancien système | Filtrage de la liste des champs | Nettoyage avant le chargement | Nettoyage sur le système en production |
| Champs obligatoires inutiles | Décision lors de la conception de l'écran | Modification de la configuration | Nettoyage des données erronées accumulées |
| Absence de propriété opérationnelle | Définition dans le plan | Recrutement ou formation | Reconstitution de la confiance des utilisateurs |
Exemple illustratif : Compagnie d'assurance de taille moyenne
Ce scénario est hypothétique et à des fins d'illustration. Une compagnie d'assurance a lancé Salesforce pour gérer ses agents. Trois mois plus tard, il s'est avéré que le taux de mise à jour des enregistrements d'agents était faible. L'analyse n'a révélé aucune défaillance technique unique : trois des erreurs mentionnées ci-dessus ont été trouvées simultanément — champs obligatoires inutiles dans l'écran de création, absence de propriétaire pour le processus de recrutement d'agents et une formation donnée deux mois avant que les premiers nouveaux agents n'entrent dans le système.
La correction n'était pas technique. Six champs obligatoires ont été supprimés, un seul propriétaire de processus a été nommé au sein du département des opérations, et la formation a été divisée en courtes sessions envoyées la semaine où chaque groupe a commencé à travailler. Le seul changement architectural requis a été le report de l'obligation de deux champs à une étape ultérieure du processus.
Que faire de cette liste
Passez en revue les dix erreurs et indiquez pour chacune si l'alerte précoce est actuellement présente dans votre contexte. Trois signes ou plus dans un projet qui n'est pas encore en production sont une raison d'arrêter et de corriger brièvement, pas d'accélérer. Les mêmes trois signes dans un système déjà en production justifient un diagnostic ordonné avant d'ajouter de nouvelles capacités sur une base instable.