Un problème Salesforce ? Les vérifications utiles avant de corriger

Un commercial ne peut plus enregistrer son opportunité. Des demandes clients restent sans affectation. La synchronisation avec la facturation ne remonte plus rien depuis ce matin. Dans ces situations, « Salesforce ne fonctionne pas » décrit le ressenti de l’équipe, mais ne suffit pas à choisir la bonne intervention.

Le premier objectif est concret : comprendre ce qui bloque le travail et transmettre assez d’informations pour agir sans tâtonner. Ce guide s’adresse aux responsables métier et aux administrateurs qui doivent qualifier un incident Salesforce, même lorsqu’ils ne connaissent pas encore sa cause. Il propose une méthode de triage, une fiche de signalement et les points à vérifier avant de considérer le problème comme résolu.

1. Partir de l’action bloquée et de son impact

Commencez par une phrase qui décrit le résultat attendu : « Les commerciaux doivent pouvoir enregistrer une opportunité après avoir renseigné le montant. » Ajoutez ce qui se passe réellement : message affiché, bouton sans effet, donnée absente ou traitement qui reste en attente. Cette description évite de partir trop vite sur une explication technique.

Précisez ensuite le périmètre. Une seule personne est-elle touchée ? Une équipe entière ? Tous les utilisateurs d’une même application ? Le blocage concerne-t-il tous les enregistrements ou seulement certains dossiers ? Notez l’heure du premier constat et celle du dernier fonctionnement connu. Une indication comme « depuis hier » devient beaucoup plus utile lorsqu’elle est rapprochée d’une opération précise.

L’impact métier détermine l’ordre de traitement. Une création de commande impossible et une colonne manquante dans un rapport n’ont généralement pas les mêmes conséquences. Pour chaque incident, indiquez l’activité empêchée, l’échéance réelle et l’existence d’un contournement acceptable. Le nombre de personnes concernées aide à prioriser, mais un utilisateur isolé peut porter une opération critique.

Notre recommandation : nommer une personne qui centralise les informations et une personne métier capable de confirmer le retour à la normale. Si plusieurs intervenants changent simultanément des réglages, le diagnostic devient plus difficile et personne ne sait quelle action a réellement corrigé le comportement.

2. Vérifier si le problème concerne la plateforme ou votre environnement

Le site officiel Salesforce Trust permet de consulter les incidents et la disponibilité des services. Recherchez le domaine ou l’instance de votre organisation, puis le service et la période concernés. Un incident sur une autre instance n’explique pas automatiquement votre situation. À l’inverse, l’absence d’incident affiché ne démontre pas que votre configuration fonctionne correctement.

Si l’équipe peut se connecter, mais qu’une opération précise échoue, décrivez cette opération avant de parler de panne générale. Si la connexion elle-même est impossible, vérifiez avec l’administrateur le chemin utilisé : connexion habituelle, authentification de l’entreprise, application mobile ou compte d’intégration. Ces chemins peuvent dépendre de composants différents.

L’administrateur dispose notamment de l’historique des connexions pour examiner les tentatives réussies ou échouées. Salesforce distingue cet historique du suivi des modifications de configuration et du suivi des données. Cette distinction aide à choisir les bonnes traces, sans demander à chaque utilisateur de multiplier les essais. Documentation Salesforce sur les fonctions d’audit.

Pour un problème d’affichage isolé, une comparaison avec un autre navigateur autorisé ou une session propre peut être utile. Préservez d’abord le travail non enregistré. Si l’erreur apparaît au moment de sauvegarder un dossier, vider le cache ne remplace pas l’examen des données saisies et du traitement exécuté.

3. Orienter le diagnostic selon le symptôme

L’enregistrement d’un dossier échoue

Relevez le texte exact du message, l’action effectuée et un exemple de dossier concerné. Distinguez une information manquante signalée clairement d’une erreur plus générale. L’administrateur pourra examiner les règles de validation, les autorisations, les automatisations et les développements qui interviennent lors de cette action.

Ne recréez pas immédiatement le dossier pour contourner l’erreur. Une partie du traitement a pu avoir lieu ailleurs, notamment si une intégration est impliquée. Vérifier ce qui existe déjà évite de transformer une erreur visible en doublon plus difficile à retrouver.

Une personne ne voit plus une donnée ou une fonction

Comparez deux situations précises : un utilisateur concerné et un utilisateur autorisé chez qui l’action fonctionne. Il faut examiner les droits applicables, l’accès au dossier et le contexte d’utilisation. Donner des droits administrateur à titre d’essai élargit inutilement les accès et peut masquer le défaut initial.

Une correction de droits doit correspondre au besoin métier : quelle information la personne doit-elle consulter, quelles opérations doit-elle effectuer et dans quel périmètre ? « Faire comme son collègue » n’est pas une description suffisante si les deux personnes ont des responsabilités différentes.

Un Flow affiche une erreur

Un Flow est une automatisation Salesforce. L’écran utilisateur peut montrer un message générique, alors que l’email d’erreur contient des détails utiles pour le diagnostic. L’administrateur doit vérifier qui reçoit ces notifications et conserver celle qui correspond à l’incident. Salesforce précise que ces emails peuvent contenir des données saisies par les utilisateurs : ils doivent circuler dans le canal de support approprié, après retrait des informations inutiles. Gestion des destinataires des erreurs Flow.

Le fait de connaître le nom du Flow ne suffit pas encore pour le désactiver. Il faut comprendre les autres opérations qu’il réalise, les dossiers qu’il touche et les conséquences de son arrêt. La correction doit porter sur la cause identifiée et être vérifiée sur des cas représentatifs.

Une intégration ne transmet plus les données

Prenez un exemple attendu, puis suivez-le de bout en bout : existe-t-il dans le système source ? A-t-il été envoyé ? Le système destinataire l’a-t-il accepté ? Est-il visible au bon endroit ? Cette succession de questions aide à distinguer une interruption d’envoi, un rejet et un simple problème de consultation.

Avant de relancer un lot, vérifiez le nombre d’éléments déjà traités et la façon dont le connecteur reconnaît un enregistrement existant. Une reprise complète peut créer des doublons ou déclencher à nouveau des actions métier. Le responsable de l’intégration doit préciser ce qui sera rejoué, ce qui sera conservé et comment contrôler le résultat.

L’application devient lente

Décrivez une action mesurable plutôt qu’une impression générale : ouverture d’un dossier, affichage d’une liste, sauvegarde ou exécution d’un rapport. Relevez les utilisateurs, les heures et les volumes concernés. Une lenteur permanente sur un écran et une lenteur occasionnelle lors d’un traitement important appellent des investigations différentes.

L’équipe technique choisira les observations adaptées. Notre article sur Salesforce Inspector Advanced présente des outils d’exploration pour les administrateurs ; leur utilisation doit rester liée à une question précise, avec les droits et précautions nécessaires.

4. Rechercher ce qui a changé avant l’incident

Un déploiement, une nouvelle version de Flow, une modification de droits, un import ou un changement dans une application connectée peuvent fournir une piste. La proximité dans le temps constitue un indice, pas une conclusion. Notez les changements connus et vérifiez leur lien avec l’action qui échoue.

Le journal Setup Audit Trail recense des modifications de configuration, avec leur date et leur auteur. Il aide notamment lorsque plusieurs administrateurs interviennent sur la même organisation. Il ne constitue pas un historique complet de toutes les valeurs métier ni un enregistrement de chaque clic utilisateur. Documentation officielle de Setup Audit Trail.

Si ces éléments ne suffisent pas, les journaux de débogage peuvent aider à suivre l’exécution d’une automatisation ou d’un développement. Leur collecte doit viser l’utilisateur, l’opération et la période utiles. Salesforce décrit cette démarche dans sa procédure de collecte et de lecture des Debug Logs.

Évitez les répétitions qui modifient de vraies commandes ou déclenchent des communications. Le scénario de reproduction doit être convenu avec le responsable métier et réalisé dans un environnement de test lorsqu’il est adapté au problème. Si l’incident dépend de la production, définissez à l’avance les données et les effets acceptables de l’observation.

5. Préparer une demande de support exploitable

Un bon signalement peut tenir dans un message court. Il n’a pas besoin de proposer une solution. Il doit permettre à l’intervenant de retrouver le même comportement et de comprendre pourquoi il faut agir.

Vous pouvez reprendre cette trame :

• Action attendue : ce que la personne cherche à terminer.
• Comportement constaté : message exact ou résultat obtenu.
• Périmètre : utilisateurs concernés, application et type de dossiers.
• Chronologie : premier échec connu et dernier fonctionnement confirmé.
• Exemple : référence d’un dossier et capture anonymisée si elle apporte quelque chose.
• Impact : activité bloquée, échéance et contournement disponible.
• Changement récent : déploiement, import ou modification connu, sans l’affirmer comme cause.
• Validation : personne qui pourra vérifier le retour au fonctionnement attendu.

Exemple fictif : « Depuis ce matin, deux membres de l’équipe commerciale ne peuvent plus enregistrer le passage d’une opportunité à l’étape suivante. La consultation fonctionne. Le message apparaît après la saisie du montant ; une capture et la référence d’un dossier sont disponibles. La préparation des propositions de cet après-midi est bloquée. Aucun contournement n’est validé. »

Ne joignez pas un export complet de la base pour illustrer un seul cas. Un exemple réduit, transmis par le bon canal, est souvent plus facile à exploiter. Les mots de passe, jetons et secrets de connexion ne doivent pas figurer dans le signalement.

6. Vérifier la correction du point de vue de l’équipe

La disparition du message d’erreur n’est qu’un premier contrôle. Rejouez l’action attendue avec un utilisateur représentatif, vérifiez les données produites et observez les traitements qui suivent. Si une commande doit ensuite être transmise à un autre outil, sa sauvegarde dans Salesforce ne prouve pas à elle seule que le parcours est rétabli.

Convenez avant la mise en production des cas à vérifier, de la personne qui les valide et de la marche à suivre si la correction ne donne pas le résultat attendu. Il faut aussi traiter les opérations restées en attente pendant l’incident : dossiers à reprendre, synchronisations à rejouer ou utilisateurs à prévenir. Leur reprise fait partie du retour à la normale.

Conservez une trace courte de la cause identifiée, de la correction réalisée et des contrôles effectués. Si la cause reste incertaine mais qu’un contournement permet de travailler, indiquez-le explicitement et fixez la prochaine vérification. Cela évite de refermer un sujet qui réapparaîtra à la prochaine opération similaire.

7. Choisir entre une correction ponctuelle et un suivi régulier

Un incident isolé peut se traiter par une intervention limitée. Il devient utile d’organiser un suivi lorsque les mêmes difficultés reviennent, que les demandes s’accumulent ou que l’équipe ne sait plus qui décide des priorités. La tierce maintenance applicative, ou TMA, peut alors associer corrections, petites évolutions et accompagnement des utilisateurs.

La démarche peut rester simple : une liste de demandes compréhensibles, un ordre de priorité décidé avec le métier et un périmètre validé avant réalisation. Certaines demandes se résolvent par une explication ou un réglage ; d’autres nécessitent une investigation, une estimation et des tests plus étendus. Le niveau de traitement doit suivre le besoin réel.

Si les incidents révèlent des automatismes difficiles à maintenir, des droits peu lisibles ou des modifications dont les effets sont mal connus, nos indicateurs de dette technique Salesforce aident à préparer une analyse plus large. Cette démarche se décide après le triage : chaque problème n’impose pas une refonte.

Pour un blocage en cours, décrivez votre problème Salesforce. Nous examinons le contexte avec vous, puis convenons du périmètre, de la disponibilité et du budget éventuel avant intervention. Pour organiser un suivi régulier, vous pouvez aussi échanger avec Cloud Girafe.