Les Rôles Clés qui Définissent le Rythme du Projet
Dans un projet Salesforce, il est possible de recruter un excellent architecte, une équipe de développement expérimentée et un chef de projet organisé, et malgré tout, de prendre du retard. La raison la plus courante n'est pas le rythme de construction mais le rythme de décision. Le développement attend une décision, la décision attend une réunion, et la réunion attend une plage horaire disponible.
Ainsi, la répartition des rôles la plus efficace ne se fait pas selon "qui fait quoi", mais plutôt selon qui prend quelle décision et avec quel temps de réaction. Un aperçu des étapes où chaque rôle est requis est disponible dans le guide d'implémentation Salesforce.
Les Neuf Rôles et le Mandat de Chacun
Executive Sponsor — Arbitre les conflits inter-départementaux, approuve les dérogations au Scope et défend la priorité du projet face aux pressions concurrentes. S'il n'a pas d'autorité budgétaire, il n'est pas un Sponsor mais un représentant.
Propriétaire de Processus — Définit comment le travail sera réellement effectué après le changement et valide que le processus construit correspond à la réalité. Un par processus métier essentiel, non un comité.
Product Owner / Responsable CRM — Gère les priorités du backlog, arbitre les demandes concurrentes et maintient le lien entre les exigences et la valeur métier.
Chef de Projet — Calendrier, dépendances, risques, coordination des fournisseurs et rapports.
Architecte de Solution — Décide du modèle de données, des autorisations, des limites système et de la méthode d'implémentation ; est responsable de la documentation des alternatives considérées.
Salesforce Admin — Configuration, environnements, gestion des utilisateurs et maintenance quotidienne après le déploiement.
Développeur — Logique personnalisée, intégrations, tests automatisés.
Propriétaire des Données — Détermine la source de vérité, ce qui constitue un enregistrement valide et qui autorise le chargement des données.
Responsable de l'Adoption et de la Formation — Communication, formation par rôle, gestion de la résistance au changement et mesure de l'utilisation.
Dans un petit projet, une personne peut cumuler deux rôles, mais il y a deux paires qu'il est préférable de ne pas unifier : l'architecte et le chef de projet (conflit entre exhaustivité et rapidité), ainsi que le propriétaire de processus et le responsable des tests (qui testerait ses propres créations).
Qui Doit Être Interne
| Rôle | Peut être externe | Explication |
|---|---|---|
| Executive Sponsor | Non | Nécessite une autorité organisationnelle |
| Propriétaire de Processus | Non | Nécessite la propriété du travail réel |
| Propriétaire des Données | Non | Nécessite une responsabilité réglementaire et commerciale |
| Product Owner | Partiel | Un accompagnement est possible, pas un remplacement |
| Chef de Projet | Oui | Courant et acceptable |
| Architecte de Solution | Oui | Souhaitable avec un accompagnement interne pour la connaissance |
| Admin | Oui, temporairement | Préférable de le transférer à un interne avant le Go Live |
| Développeur | Oui | Standard |
| Responsable de l'Adoption | Partiel | La communication interne doit émaner de l'organisation |
Matrice RACI pour les Points de Décision Clés
| Décision | Responsable (Accountable) | Consulté (Consulted) | Temps de réponse requis |
|---|---|---|---|
| Structure du modèle de données | Architecte | Propriétaire de Processus, Propriétaire des Données | Jusqu'à une semaine |
| Modification du Scope | Sponsor | Product Owner, Chef de Projet | Jusqu'à une semaine |
| Ordre de priorité du backlog | Product Owner | Propriétaires de Processus | Jusqu'à deux jours |
| Définition d'un champ obligatoire | Propriétaire de Processus | Admin | Jusqu'à deux jours |
| Approbation du chargement de données | Propriétaire des Données | Architecte | Jusqu'à trois jours |
| Approbation du passage en production | Sponsor | Chef de Projet, Propriétaire de Processus | Selon une porte définie |
| Résolution d'un défaut bloquant | Chef de Projet | Architecte, Admin | Le jour même |
La colonne "Temps de réponse requis" est la partie la plus intéressante de la matrice. Un RACI sans SLA pour la décision est une belle description qui ne change pas le rythme.
Disponibilité Réaliste — L'Erreur Récurrente dans la Planification
| Rôle | Description | Construction | Tests | Go Live et les semaines suivantes |
|---|---|---|---|---|
| Sponsor | Faible, constante | Faible | Moyenne | Moyenne |
| Propriétaire de Processus | Élevée | Moyenne | Très élevée | Élevée |
| Product Owner | Élevée | Élevée | Élevée | Moyenne |
| Admin | Moyenne | Élevée | Élevée | Très élevée |
| Propriétaire des Données | Moyenne | Faible | Élevée | Moyenne |
| Responsable de l'Adoption | Faible | Moyenne | Moyenne | Très élevée |
La planification la plus fréquemment défaillante consiste à supposer que la charge de travail du propriétaire de processus diminue après la phase de description. En réalité, elle augmente à nouveau pendant la phase de tests, précisément lorsque l'employé retourne à son travail quotidien.
Exemple Concret : Une Institution Académique
Ce scénario est hypothétique et à titre d'exemple. Une institution a implémenté un système de gestion des candidatures. L'équipe a été définie correctement sur le papier, mais le "Propriétaire de Processus" était le responsable du service des admissions, qui disposait de deux heures par semaine pour le projet. Chaque question concernant le statut d'une candidature attendait jusqu'au mardi matin.
Après deux mois, il a été mesuré que le retard accumulé en attente de décisions dépassait toutes les autres causes combinées. La solution n'a pas été de recruter davantage de développeurs. L'institution a nommé un adjoint qui a reçu un mandat explicite pour prendre des décisions quotidiennes jusqu'à un niveau d'impact défini, ne laissant au responsable du service que les décisions qui modifient la politique. Le rythme de développement a augmenté sans modification de la taille de l'équipe du fournisseur.
Le Modèle de Collaboration avec le Fournisseur
Trois mécanismes suffisent pour la plupart des projets :
- Journal de Décisions Partagé — Chaque décision avec sa date, la personne qui la prend, la justification et les alternatives rejetées. C'est aussi la seule documentation qui reste utile deux ans plus tard.
- Point de Contact Unique des Deux Côtés — Les demandes directes de multiples participants aux développeurs sont le moyen le plus sûr de perdre la traçabilité.
- Cycle de Démonstration à Rythme Constant — Le propriétaire de processus voit un produit fonctionnel, pas une présentation. Un écart entre les attentes et la réalisation est découvert en deux semaines au lieu de deux mois.
Dans les grandes organisations, une couche de gouvernance supplémentaire entre les unités commerciales est nécessaire, comme décrit dans le guide d'implémentation Salesforce en entreprise.
Points de Jonction avec les Autres Étapes
La composition de l'équipe dépend directement de deux éléments : les livrables requis lors de la phase de description, détaillés dans le guide de découverte CRM, et l'étendue de la première vague, déterminée selon les règles du guide de définition du MVP Salesforce. Une première vague restreinte nécessite moins de propriétaires de processus simultanément, ce qui est une raison indépendante de réduire l'ampleur.
Vérification Rapide avant le Démarrage du Projet
Répondez à quatre questions avec des noms et prénoms, et non des noms de départements : qui décide lorsque le commercial et l'opérationnel ne sont pas d'accord ; qui valide que le processus construit correspond à la réalité ; qui déclare quelles données sont fiables ; et qui maintiendra le système dans un an. L'absence de réponse à l'une de ces questions représente le plus grand risque du projet, et c'est aussi le seul qui ne se résout pas avec de l'argent.