Accueil
» Technologie
»
Erreurs de Salesforce Workbench : Dépannage des outils API pendant une interruption de service
Erreurs de Salesforce Workbench : Dépannage des outils API pendant une interruption de service
Vérifié le 16 septembre 2026. Les erreurs Workbench sont faciles à mal interpréter lors d'un incident Salesforce. Un échec de connexion peut provenir d'une session expirée, d'un environnement incorrect, d'une route Workbench défectueuse ou d'une panne de l'API Salesforce. Une requête renvoyant une erreur 503 Service Unavailableindique une explication différente de celle d'une 401 Invalid Sessionerreur de connexion, même si les deux peuvent survenir lorsqu'un développeur travaille rapidement.
L'objectif du dépannage n'est pas de forcer le traitement d'une requête. Il s'agit d'identifier la couche défaillante, de protéger les données pendant l'instabilité du système et de savoir quand les preuves sont suffisamment solides pour attendre, changer d'outil ou contacter le service d'assistance approprié.
Diagnostic rapide : que signifie très probablement cette erreur ?
Ce que vous voyez
Couche la plus probable
Meilleure prochaine étape
La page de l'atelier ne se charge pas.
Site de l'espace de travail, navigateur, DNS ou chemin réseau
Ouvrez l'état de confiance de Salesforce et testez le site depuis un réseau alternatif autorisé.
L'interface de travail se charge, mais la connexion échoue avec une erreur 401.
Session, OAuth, nom d'utilisateur, mot de passe ou flux de connexion
Créez une nouvelle session autorisée et confirmez l'environnement sélectionné.
La requête API renvoie une erreur 403
Autorisations, politique relative aux applications connectées ou limite d'API
Vérifiez les limites de l'utilisateur, de l'application connectée et des requêtes ; ne considérez pas cela comme une preuve d'indisponibilité.
Plusieurs appels API renvoient les codes 500, 502 ou 503.
Plateforme Salesforce, routage périphérique, maintenance ou surcharge
Comparez le délai d'erreur avec l'état de votre instance et de votre produit sur Trust.
Une seule requête ou un seul objet échoue.
Problème de syntaxe de requête, d'accès aux objets, de partage d'enregistrements ou de données
Réduisez la requête à une lecture inoffensive et fiable, et examinez le corps de la réponse.
Ce tableau constitue un point de départ, et non un diagnostic. Un même code HTTP peut avoir différentes causes selon le point de terminaison, la méthode d'authentification et la politique de l'organisation.
Tout d'abord, comprenez les limites de support de Workbench.
Workbench est une suite logicielle basée sur navigateur permettant d'interagir avec les organisations Salesforce via plusieurs API, notamment REST, SOAP, Bulk, Streaming, Metadata et des outils liés à Apex. Cependant, le site de Workbench précise qu'il ne s'agit pas d'un produit officiel Salesforce et que Salesforce n'offre aucun support pour Workbench. Sa page « À propos » avertit également les utilisateurs de ne pas utiliser l'application avec des données de production.
Cet avertissement modifie votre comportement en cas d'indisponibilité du service. Le support Salesforce peut examiner un problème lié à un service, une instance ou une API Salesforce, mais ne peut pas nécessairement résoudre tous les problèmes de l'interface Workbench. Inversement, un problème signalé uniquement par Workbench peut provenir de Workbench ou du chemin d'accès du navigateur plutôt que de la plateforme Salesforce.
Dans la mesure du possible, limitez le contenu des captures d'écran aux informations de dépannage en lecture seule. Ne collez pas de mots de passe, de clés secrètes OAuth, d'identifiants de session, de jetons d'accès, de données client ni d'en-têtes de requête non masqués dans les captures d'écran, les messages de chat ou les rapports de problèmes publics.
Commencez par identifier le chemin de connexion à Workbench et l'environnement sélectionné. L'interface affichée est une maquette illustrative ; il ne s'agit pas d'un écran de connexion réel ni d'une image invitant à saisir des identifiants.
Étape 1 : Vérifiez le statut de confiance Salesforce avant de modifier les paramètres de Workbench
Ouvrez la page « État de confiance Salesforce » dans un nouvel onglet. La documentation d'aide de Salesforce renvoie les clients vers cette page en cas de panne de produit ou de dégradation de service. Le site « État de confiance » peut également afficher des informations sur les produits et les incidents spécifiques.
Vérifier deux points de vue :
Vue d'ensemble du produit : recherchez un incident, une dégradation de service, une interruption ou un événement de maintenance affectant le service Salesforce que vous utilisez.
Vue de votre instance : recherchez votre instance ou Mon domaine et ouvrez le résultat correspondant.
L'indication « Disponible » ne garantit pas le bon fonctionnement de toutes les opérations API. Cela signifie que l'instance et ses services sont disponibles selon la définition d'état de Salesforce. « Performances dégradées » indique un accès potentiellement limité ou partiellement fonctionnel ; « Interruption de service » signifie que l'instance est indisponible ; « Maintenance » signale une opération de maintenance susceptible d'affecter ou non l'accès.
Étape 1 — Comparez les informations générales sur l’état de confiance avec l’instance de l’organisation concernée. La capture d’écran présentée est un guide illustratif du processus de recherche documenté et ne constitue pas la preuve d’un incident réel.
Étape 2 : Confirmez l’environnement et l’organisation avant de réessayer.
Workbench peut se connecter à différents environnements Salesforce. Avant de conclure à une panne d'API, vérifiez si la requête en échec cible l'environnement de production, un environnement de test ou un autre environnement autorisé. Un test réussi dans un environnement ne permet pas d'identifier l'environnement réellement défaillant.
Utilisez l'identifiant de domaine ou d'instance de l'organisation concernée. Salesforce indique que le préfixe « Mon domaine » peut être utilisé dans l'état de confiance, tandis qu'un administrateur peut trouver l'instance dans la configuration, sous Informations sur l'entreprise . Notez l'instance, l'environnement, la version de l'API, l'heure approximative de la défaillance et le point de terminaison. Cet enregistrement permet d'éviter une erreur fréquente : comparer une erreur de production avec un état de fonctionnement normal dans un environnement de test.
Si la page de connexion Workbench affiche une méthode de connexion non prise en charge ou vous redirige vers l'écran de connexion, considérez cela comme un problème d'authentification ou un problème lié à Workbench distinct, jusqu'à ce que l'état de confiance et une connexion directe à Salesforce indiquent le contraire. En cas de panne suspectée, évitez de saisir vos identifiants à répétition ; des tentatives excessives peuvent entraîner des blocages ou perturber l'enquête.
Étape 3 : Classer la réponse de l’API au lieu de deviner
La documentation de l'API REST de Salesforce explique que l'en-tête de réponse contient un code d'état HTTP et que le corps contient généralement un message et, le cas échéant, le champ ou l'objet associé à l'erreur. Conservez ces deux éléments.
Code
L'indice documenté de Salesforce
Comment l'interpréter pendant une interruption de service
400
La requête n'a pas pu être comprise, souvent parce que le corps JSON ou XML est invalide.
Il est généralement préférable de résoudre le problème avant de le considérer comme une panne.
401
L'identifiant de session ou le jeton OAuth a expiré ou n'est pas valide.
Réauthentifiez-vous via une procédure approuvée ; une erreur 401 seule ne constitue pas une preuve de panne de la plateforme.
403
La requête a été refusée, souvent en raison de problèmes d'autorisation ou d'une limite de l'API.
Vérifiez les accès et les limites avant de signaler un incident de disponibilité.
500
Une erreur s'est produite au sein de la plateforme Lightning.
Réessayez uniquement après avoir enregistré la réponse ; comparez les échecs répétés avec l’état de confiance.
502
Salesforce Edge n'a pas pu communiquer avec succès avec l'instance.
Un problème de routage ou de plateforme est possible, notamment lors de requêtes multiples.
503
Le serveur est indisponible ; il est peut-être en cours de maintenance ou surchargé.
Vérifiez s'il y a un incident ou une opération de maintenance et évitez les tentatives de réutilisation destructives.
Étape 3 — Notez le code HTTP et sa signification avant de modifier les informations d’identification ou les requêtes. Cet exemple ne contient ni jeton, ni données client, ni identifiant d’incident réel.
Étape 4 : Effectuer un test de comparaison sécurisé
Une fois l'état et l'environnement connus, utilisez le test en lecture seule le plus simple autorisé. Une bonne comparaison présente trois caractéristiques : elle cible l'organisation concernée, elle ne modifie pas les données et elle est suffisamment simple pour qu'une erreur de format de requête soit improbable.
Répétez la même requête inoffensive une fois après avoir enregistré la première réponse.
Si la requête renvoie une erreur 401, lancez un nouveau flux d'authentification autorisé plutôt que de réutiliser une ancienne session.
Si elle renvoie 400, 403 ou 404, examinez le point de terminaison, la version de l'API, le nom de l'objet, les autorisations et le corps de la requête.
Si la réponse est 500, 502 ou 503 de manière répétée, comparez l'heure et l'instance avec l'état de confiance.
Si l'interface utilisateur du navigateur fonctionne mais que Workbench échoue, testez le même chemin d'API autorisé avec un client interne approuvé ou un diagnostic d'intégration.
N’utilisez pas une requête d’écriture, de suppression, de mise à jour en masse, de déploiement de métadonnées ou de migration comme contrôle d’intégrité. Lors d’un incident, une écriture peut générer des résultats partiels, des doublons ou donner l’illusion d’une récupération réussie.
Quand faut-il modifier son approche de dépannage ?
Changer d'approche lorsque le statut de confiance indique un incident
Cessez de modifier la requête, sauf si vous disposez de preuves indépendantes indiquant qu'elle est mal formée. Enregistrez le numéro d'incident, le service concerné, l'instance, l'heure de début et la dernière mise à jour. Suivez les instructions de récupération de Salesforce et protégez les tâches en file d'attente contre les tentatives de réexécution en double.
Changer d'approche lorsque l'état de confiance est disponible mais que Workbench seul échoue
Concentrez-vous sur Workbench, votre navigateur, votre réseau, l'authentification ou votre stratégie locale. Essayez une fenêtre de navigation privée, un autre navigateur compatible et effectuez une comparaison des réseaux autorisés. Le site Workbench renvoie vers les ressources de sa communauté open source pour obtenir de l'aide spécifique à Workbench, tandis que l'assistance Salesforce reste la source d'information pour les produits et comptes Salesforce.
Changez d'approche si l'erreur est systématiquement 401 ou 403.
Passez à l'analyse d'identité et d'autorisation. Vérifiez l'utilisateur, la politique de l'application connectée, le périmètre OAuth, la durée de validité de la session, l'accès à l'API, le profil ou l'ensemble d'autorisations, ainsi que les limites de l'organisation. Actualiser la page du navigateur à plusieurs reprises ne résoudra pas le problème d'une autorisation manquante ou d'un jeton invalide.
Changez d'approche lorsqu'un point de terminaison échoue mais que les lectures simples fonctionnent.
Examinez le point de terminaison, l'objet, le champ, le partage d'enregistrements, la version de l'API, le corps de la requête et le corps de la réponse. Une erreur localisée ne suffit pas à conclure à une panne globale de Salesforce. Réduisez la taille de la requête jusqu'à identifier si le problème provient de la syntaxe, de l'accès, des données ou d'un service dépendant.
Étape 4 — Respectez les limites de support et de sécurité de Workbench. Utilisez le support Salesforce officiel pour les incidents liés à la plateforme et les ressources communautaires open source pour les comportements spécifiques à Workbench.
Quelles preuves devez-vous envoyer au service d'assistance ?
Identifiant de l'organisation, instance et environnement
Horodatage UTC et votre fuseau horaire local
Opération sur la page Workbench ou l'API impliquée
Code HTTP, code d'erreur et corps de réponse expurgé
Que ce soit l'interface utilisateur de Salesforce, un autre utilisateur ou un autre client autorisé qui échoue également
Numéro d'incident Trust Status ou une note indiquant qu'aucun événement correspondant n'a été trouvé.
Avant d'envoyer les journaux, supprimez les identifiants, les ID de session, les jetons d'accès, les noms de clients, les ID d'enregistrement et les données sensibles. Si le problème concerne uniquement Workbench, suivez la procédure d'assistance indiquée sur la page d'aide de Workbench ; Salesforce n'offre pas de support produit pour Workbench.
Comment vérifier la récupération
Un indicateur vert est encourageant, mais ce n'est pas la fin du parcours. Vérifiez la reprise par étapes :
Vérifiez que la page de l'incident affiche une résolution ou que l'instance est de nouveau disponible.
Connectez-vous via le flux Salesforce ou Workbench approuvé sans réutiliser une session obsolète.
Exécutez la même requête en lecture seule inoffensive qui a échoué précédemment.
Comparez le code HTTP, le temps de réponse et le corps de la réponse avec l'erreur enregistrée.
Vérifiez les intégrations, les tâches en file d'attente et les notifications en aval pour détecter les travaux retardés ou dupliqués.
Le résultat souhaité n'est pas simplement « la page s'est ouverte ». Vous souhaitez que l'opération autorisée initiale réussisse, avec la réponse attendue et sans effets secondaires imprévus.
Liste de vérification d'auto-évaluation
Portée : Avez-vous vérifié à la fois la page de confiance au niveau du produit et l’instance concernée ?
Environnement : Avez-vous confirmé l’opposition entre environnement de production et environnement de test, ainsi que le bon domaine ou la bonne instance ?
Preuve : Avez-vous enregistré le code HTTP exact, le code d'erreur, l'heure et la réponse expurgée ?
Sécurité : Avez-vous évité les requêtes d'écriture, de suppression, de traitement en masse, de déploiement et de migration pendant l'incident ?
Décision : Avez-vous fait la distinction entre le comportement propre à Workbench et une défaillance de l’API Salesforce ?
Récupération : Avez-vous testé à nouveau l'opération initiale et inspecté les travaux en aval retardés ?
En résumé
En cas d'erreur Salesforce Workbench pendant une interruption de service, commencez par vérifier l'état de confiance et l'instance concernée, puis classifiez la réponse HTTP avant de modifier les informations d'identification ou de réécrire les requêtes. Des erreurs 500, 502 ou 503 répétées lors de tests simples en lecture seule, associées à un incident de confiance correspondant, suggèrent un problème côté Salesforce. Une erreur 401, 403, 400 ou une défaillance spécifique à Workbench nécessite généralement un dépannage au niveau de l'authentification, des autorisations, des requêtes, du navigateur ou de Workbench. Workbench n'étant pas un produit pris en charge par Salesforce, veillez à ne pas y intégrer de données de production, à documenter clairement les limites de l'environnement et à consulter les dernières informations et recommandations du support technique en cas de changement de situation.