Maintenance et support Salesforce : organiser le suivi et choisir son intégrateur

Répartition des décisions entre client et intégrateur Salesforce, de la demande à la recette
Priorités, périmètre et validation restent des décisions explicites.

Votre Salesforce fonctionne, mais les demandes s’accumulent : un rapport à ajuster, un utilisateur bloqué, une automatisation à faire évoluer. Le responsable CRM devient le point de passage de tous les sujets, parfois sans disposer du temps nécessaire pour les qualifier. Trouver un intégrateur aide à absorber ce travail, à condition de savoir comment les décisions seront prises.

Ce guide s’adresse aux responsables CRM et aux équipes métier qui veulent organiser la maintenance et le support Salesforce dans la durée. L’objectif : rendre les demandes compréhensibles, garder la main sur les priorités et le budget, puis vérifier que chaque intervention améliore réellement le travail des utilisateurs.

1. Distinguer incident, assistance et évolution

Une demande urgente n’est pas toujours un incident. Un incident correspond à un fonctionnement attendu qui ne se produit plus : une commande ne se transmet pas, un utilisateur ne peut plus enregistrer un dossier. L’assistance aide à utiliser une fonction existante. Une évolution modifie le comportement ou ajoute une possibilité. La maintenance préventive prépare, par exemple, un changement de version ou le remplacement d’un composant devenu difficile à maintenir.

Cette distinction évite de traiter toutes les sollicitations de la même façon. Une explication peut suffire pour retrouver un filtre. Un nouvel écran demande de préciser le résultat attendu. Une interruption de synchronisation nécessite d’abord un diagnostic et une vérification des opérations déjà effectuées.

À la réception d’une demande, notez l’action concernée, les utilisateurs touchés, l’impact sur leur activité et l’existence d’un contournement. Une échéance métier réelle aide davantage à prioriser qu’une mention « urgent ». Pour un blocage en cours, notre guide de diagnostic d’un problème Salesforce détaille les informations utiles à transmettre.

2. Construire une liste de demandes que le métier peut arbitrer

Le backlog est simplement la liste partagée des demandes à examiner et à réaliser. Il devient utile lorsque chaque ligne décrit un problème ou un résultat attendu, avec un responsable métier. « Améliorer Salesforce » est trop large. « Permettre à l’équipe service client de retrouver les demandes sans réponse depuis lundi » ouvre une discussion concrète.

Pour chaque demande, conservez une fiche courte :

  • le besoin et un exemple représentatif ;
  • l’impact, la fréquence et l’échéance éventuelle ;
  • la personne qui décide de la priorité ;
  • les dépendances connues avec d’autres outils ou équipes ;
  • la proposition de traitement et son estimation ;
  • le résultat qui permettra de valider la livraison.

Une revue régulière sert à décider ce qui commence, ce qui attend et ce qui n’est plus nécessaire. Sa fréquence dépend du volume des demandes. Un responsable doit pouvoir retirer une demande devenue inutile, même si elle figure dans la liste depuis plusieurs mois. L’intégrateur explique les conséquences techniques ; le client arbitre la valeur métier et les moyens engagés.

Exemple fictif : une équipe demande un nouveau tableau de bord. L’échange montre qu’un rapport existant contient déjà les données, mais que son filtre est mal compris. Une courte explication et un ajustement peuvent résoudre le besoin. La demande initiale reste traçable, avec la solution retenue et sa validation.

3. Estimer avant d’engager, expliquer avant de dépasser

Une estimation utile précise ce qu’elle comprend : analyse, configuration ou développement, vérifications, préparation de la mise en production et documentation. Elle expose aussi les hypothèses. Si une intégration inconnue peut être affectée, l’incertitude doit apparaître avant le démarrage.

Pour un sujet mal compris, une investigation limitée peut être décidée séparément. Son livrable est un diagnostic et une proposition de suite. Elle ne vaut pas accord implicite pour réaliser toute la correction. Le client connaît ainsi le point où une nouvelle décision sera nécessaire.

Le suivi budgétaire doit rapprocher les demandes autorisées, le travail réalisé et ce qui reste estimé. Lorsqu’un élément nouveau change le périmètre, l’intégrateur explique la découverte, ses conséquences et les options : réduire la demande, la reporter ou accepter un complément. Le responsable CRM doit pouvoir décider avant que la charge supplémentaire soit engagée, selon le cadre convenu.

Le choix commercial mérite une discussion distincte. Notre comparatif TMA Salesforce : abonnement, forfait ou régie présente les formats et les points contractuels à examiner. Ici, le principe de fonctionnement reste le même : une demande visible, un périmètre compris et une autorisation adaptée.

4. Définir la recette avant de réaliser la modification

La recette consiste à vérifier que le résultat répond au besoin exprimé. Elle se prépare dès le cadrage. Pour un changement d’affectation des demandes clients, indiquez quelques situations attendues : dossier complet, information manquante, utilisateur autorisé, cas qui doit rester inchangé. Précisez qui exécutera ces vérifications et qui donnera l’accord de mise en service.

Les contrôles techniques de l’intégrateur et la validation métier sont complémentaires. Un traitement peut s’exécuter sans erreur tout en envoyant le dossier à la mauvaise équipe. À l’inverse, un exemple réussi ne suffit pas à vérifier les conséquences sur les autres parcours.

Salesforce décrit la recette utilisateur et la formation comme des étapes du cycle de vie d’une application. Selon le changement et les environnements disponibles, les essais se déroulent dans une sandbox adaptée, avant le passage en production. L’environnement et les données de test doivent être choisis avec soin, notamment pour les intégrations qui peuvent déclencher des effets dans un autre outil.

La livraison comprend enfin les instructions utiles aux utilisateurs, les contrôles après déploiement et la conduite à tenir si le résultat est incorrect. Si des données doivent être reprises, cette opération est explicitement bornée et vérifiée. Fermer une demande signifie que son résultat a été accepté, ou que la réserve restante est clairement documentée.

5. Reprendre un existant sans promettre de tout refaire

Changer d’intégrateur ne nécessite pas automatiquement de reconstruire Salesforce. Le premier travail consiste à comprendre les processus importants, les accès, les automatisations, les intégrations et les incidents connus. Les éléments manquants sont recensés avec leurs conséquences sur la reprise.

Demandez une restitution lisible : ce qui permet déjà de travailler, ce qui demande une vérification et ce qui présente un risque pour une opération précise. Une documentation incomplète peut justifier une investigation ciblée ; elle ne prouve pas que toute la configuration est mauvaise. Les recommandations doivent être rattachées à des faits observables.

La reprise se concentre ensuite sur un périmètre convenu. Identifiez les interlocuteurs, les comptes d’intervention autorisés, les environnements disponibles et les modalités de transmission avec le prestataire précédent. Évitez qu’un accès personnel partagé devienne le seul moyen d’administrer la plateforme.

Si les mêmes difficultés reviennent, une analyse de la dette technique Salesforce peut aider à choisir les corrections de fond. Elle doit déboucher sur des priorités compréhensibles, pas sur une liste technique impossible à arbitrer.

6. Préparer les changements et développer l’autonomie

La maintenance comprend aussi le temps consacré à anticiper. Les nouvelles versions et les changements de vos applications connectées doivent être examinés au regard des usages réels. Il est rarement utile de tester chaque nouveauté : commencez par les parcours dont l’interruption empêcherait l’équipe de travailler.

Salesforce explique comment une sandbox de préversion permet d’évaluer les nouveautés dans sa propre configuration avant leur arrivée en production. Toutes les sandbox ne suivent pas le même calendrier. La préparation doit donc vérifier les environnements disponibles et les dates applicables, plutôt que supposer qu’un environnement de test est toujours prêt.

L’autonomie se construit à chaque demande résolue : expliquer un réglage, documenter une manipulation fréquente, former un référent ou préciser quand solliciter l’intégrateur. Certaines opérations restent confiées à un spécialiste ; d’autres peuvent être prises en charge en interne après transmission. Cette répartition évolue avec l’équipe et les compétences disponibles.

Un suivi durable conserve aussi la mémoire des décisions. Le départ d’un interlocuteur ne devrait pas obliger à reconstruire tout l’historique : demandes, choix de configuration, documents et accès doivent rester maîtrisés par l’entreprise.

7. Le retour public du Laboratoire Rivadis

Le Laboratoire Rivadis développe, fabrique et commercialise des produits d’hygiène et de soins pour les établissements médicaux et hospitaliers, les pharmacies et les familles. Son site présente notamment ses activités de recherche, de fabrication et de qualité.

Rivadis a fait appel à Cloud Girafe pour reprendre la maintenance de son Salesforce Service Cloud. Dans le témoignage déjà publié, Cécile Guerin, Responsable CRM Groupe, décrit l’accompagnement, la pédagogie de l’interlocuteur et les évolutions réalisées :

“Nous collaborons depuis près d’un an avec Cloud Girafe dans le cadre d’une TMA pour notre solution Salesforce Service Cloud.
Nous sommes très satisfaits de la qualité de l’accompagnement réalisé par Cloud Girafe. Au-delà de son expertise technique, notre interlocuteur dédié est très réactif, et pédagogue ; il a toujours été en capacité de nous proposer des solutions sur mesure répondant à nos problématiques.
Nous sommes très satisfaits des évolutions réalisées, elles ont permis de grandes avancées notamment dans l’appropriation de la solution par nos utilisateurs !”

Cécile Guerin, Responsable CRM Groupe, Laboratoire Rivadis

Ce témoignage met en avant deux critères à examiner lors du choix d’un partenaire : la compréhension des problèmes rencontrés et la capacité à expliquer les solutions. La durée citée correspond au témoignage d’origine.

8. Choisir un intégrateur sur sa façon de travailler

Lors d’un premier échange, prenez une demande représentative de votre quotidien et demandez au prestataire comment il la traiterait. Vous verrez plus facilement qui qualifie le besoin, à quel moment une estimation est produite et comment la validation sera recueillie.

Vérifiez également sa capacité à couvrir votre environnement réel : produits Salesforce utilisés, développements, flux avec les autres applications et accompagnement des utilisateurs. Une certification renseigne sur une compétence ; elle ne remplace pas l’examen d’expériences pertinentes et du fonctionnement proposé.

Abordez les sujets pratiques : interlocuteur principal et relais, canal des demandes, plages d’intervention convenues, suivi du budget, propriété des livrables et conditions de réversibilité. Distinguez le délai de prise en compte du délai de résolution. Les engagements doivent correspondre à votre criticité et au contrat retenu.

Pour préparer cette discussion, rassemblez vos demandes récentes, les parcours importants et les difficultés de pilotage rencontrées. Échangeons sur l’organisation de votre support Salesforce : ces éléments permettront de définir un périmètre utile et une manière de travailler adaptée à votre équipe.

Questions fréquentes sur la maintenance et le support Salesforce

Le support répond aux difficultés et aux questions d’utilisation. La tierce maintenance applicative peut couvrir corrections, évolutions, prévention et accompagnement selon le périmètre convenu. Le contrat doit préciser les activités incluses, les responsabilités et les modalités de validation.

Un responsable côté client arbitre les priorités métier. L’intégrateur apporte le diagnostic, l’estimation et les dépendances techniques. Un incident critique peut modifier l’ordre prévu selon les règles définies ensemble ; ce changement doit rester visible dans le suivi.

Définissez le périmètre avant réalisation, distinguez investigation et correction lorsque nécessaire, puis rapprochez régulièrement le réalisé et le reste estimé. Une découverte qui change la charge doit déclencher une explication et une décision, selon les modalités convenues.

La reprise reste envisageable, mais les zones inconnues doivent être identifiées. Commencez par les processus critiques, les accès et les intégrations. Demandez un diagnostic borné et une transmission progressive plutôt qu’un engagement immédiat sur un environnement encore mal connu.

Le niveau de validation dépend de l’impact et des délégations convenues. Une évolution métier nécessite une personne capable d’accepter le résultat. Une correction courante peut suivre un cadre préapprouvé, avec traçabilité et contrôles adaptés. La responsabilité de validation doit toujours être explicite.

Conservez la maîtrise des accès, des documents et des décisions. Prévoyez la transmission aux référents, un historique partagé et les conditions de réversibilité. La relation peut durer tout en laissant l’entreprise capable de reprendre ou de confier le suivi à une autre équipe.