La principale conclusion tirée des incidents Salesforce de 2025 est qu'il n'y a pas eu d'incident majeur et unique ayant marqué l'année. Les clients ont plutôt subi plusieurs types de perturbations : une interruption de service généralisée en février, des problèmes d'authentification sur plusieurs clouds en juin, un incident majeur sur la plateforme Heroku suite à une mise à jour non intentionnelle du fournisseur, un incident réseau dans un centre de données d'Indianapolis, et des incidents ultérieurs limités à certaines instances ou fonctionnalités. Cette distinction est importante car la réponse appropriée dépend de la nature de la panne.
Si les utilisateurs ne parviennent pas à se connecter, un simple rafraîchissement du navigateur ne résoudra pas le problème. Si la page d'état publique est mise à jour avec un certain délai, un système de surveillance des pannes générique risque également d'être incomplet. Si Salesforce est disponible mais qu'une file d'attente d'intégration est bloquée, le CRM peut sembler fonctionner correctement alors que les processus métier sont toujours défaillants. La leçon pratique à tirer de 2025 est de combiner des notifications d'état spécifiques à chaque locataire, une surveillance indépendante, des procédures manuelles éprouvées et un contrôle de reprise pour les systèmes en aval.
Les incidents suivants sont utiles pour une analyse rétrospective car ils illustrent différents modes de défaillance. Ils ne prétendent pas que tous les événements d'état Salesforce de 2025 soient répertoriés ici.
| Date | Perturbation | Ce que le dossier révèle | Pourquoi c'est important |
|---|---|---|---|
| 7 février | Interruption de service | Le rapport officiel indique que la perturbation a pris fin à 11h21 UTC et a duré environ 2 heures et 20 minutes. | Un incident de service majeur peut affecter le fonctionnement normal de Salesforce même si sa cause première n'est pas rendue publique. |
| 10 juin | Échecs d'authentification inter-cloud | Salesforce a signalé un impact sur les services d'authentification pour Heroku, Commerce, Marketing Cloud et les services Salesforce. | Les dépendances en matière de connexion et d'identité peuvent provoquer une panne inter-produits sans que chaque produit présente la même défaillance technique. |
| 10 juin | Perturbation de la plateforme Heroku | Heroku a par la suite attribué l'incident à une mise à jour système non intentionnelle appliquée à l'infrastructure de production par un fournisseur. Le site d'état d'Heroku a également été affecté. | Le canal de communication peut devenir partie intégrante de l'incident, rendant indispensables des voies de notification indépendantes. |
| 18 juin | Perturbation du réseau du centre de données d'Indianapolis | Salesforce a signalé qu'une panne du système de refroidissement du centre de données d'Indianapolis a affecté les piles 1 et 6. | Les incidents affectant l'infrastructure physique peuvent être plus localisés qu'une panne globale, mais tout aussi graves pour les entités concernées. |
| 1er novembre | Interruption des services principaux au niveau de l'instance | Le rapport d'incident officiel identifie IND76 comme une instance impactée et indique que l'événement est résolu. | Les vérifications spécifiques à chaque instance sont plus utiles que de se fier uniquement aux rapports généraux du type « Salesforce est-il en panne ? ». |
| 31 décembre | Dégradation des performances de la messagerie WhatsApp | Salesforce a signalé un impact sur les performances de la fonctionnalité de messagerie WhatsApp à plusieurs reprises et a confirmé ultérieurement le rétablissement du service à 16h56 UTC. | Une fonctionnalité peut être altérée tandis que le reste du CRM demeure utilisable. |
Pour les incidents de février et de Salesforce Trust, les dates, la portée et les mises à jour de restauration proviennent des enregistrements d'incidents de Salesforce : l'interruption de service du 7 février , l'incident d'authentification inter-cloud du 10 juin , l'incident d'Indianapolis du 18 juin , l'incident d'instance du 1er novembre et l'incident WhatsApp du 31 décembre .
Le 10 juin est une date particulièrement importante car l'expression « panne Salesforce » peut désigner plusieurs événements. Le rapport de confiance de Salesforce faisait état de défaillances d'authentification multifacteurs affectant plusieurs clouds. Le rapport d'Heroku, publié ultérieurement, décrivait une interruption de service de la plateforme, survenue à 6 h 00 UTC et causée par une mise à jour système non intentionnelle appliquée à l'infrastructure de production par un fournisseur.
Heroku a également reconnu que son site d'état était affecté. Selon la mise à jour des mesures correctives d'Heroku , des défauts de conception de la page d'état et la latence de l'API ont entraîné des délais d'attente, et la page pouvait sembler n'afficher aucun incident actif. Heroku a indiqué avoir mis en place des mesures de contrôle, notamment l'arrêt définitif des mises à niveau automatiques des systèmes d'exploitation des fournisseurs, des audits d'images système, une surveillance accrue, la mise en cache du contenu d'état, une planification de communication indépendante et des procédures de réponse aux incidents renforcées.
Il est important de faire cette distinction pour les administrateurs. Une page d'état ne constitue pas le service lui-même ; les clients l'utilisent pour décider d'attendre, de basculer, d'ouvrir un ticket d'assistance ou de communiquer avec leurs utilisateurs. Si le canal d'état partage une trop grande partie de l'infrastructure avec la plateforme concernée, il risque de ne pas fournir une vue fiable au moment où elle est le plus nécessaire.
Une équipe peut disposer de données applicatives intactes et se retrouver dans l'incapacité de travailler en cas de défaillance de la connexion, de l'authentification multifacteurs ou du système d'authentification. Ce point est particulièrement critique pour les entreprises utilisant conjointement Salesforce, Heroku, Commerce et Marketing Cloud. Il est essentiel de documenter les utilisateurs ayant besoin d'accéder à chaque système, d'identifier les contacts d'urgence habilités à recevoir les mises à jour des fournisseurs et de définir les tâches pouvant être poursuivies en cas d'impossibilité de connexion.
Pour une petite équipe commerciale, cela peut se traduire par une liste d'appels manuelle temporaire et un journal d'incidents partagé. Pour un centre de contact ou un établissement de santé, cela peut nécessiter une procédure formelle de gestion des interruptions de service, des exportations en lecture seule approuvées et un arbre d'escalade testé. L'ampleur du plan de repli doit être à la hauteur des conséquences opérationnelles d'une interruption de service.
La documentation de Salesforce explique que l'état de confiance fournit des informations sur la disponibilité et les performances, tandis que les vues plus récentes de Mon Centre de confiance sont conçues autour des locataires et des produits pris en charge. Le principe opérationnel est simple : il est essentiel de connaître l'identifiant de votre instance ou de votre locataire avant qu'un incident ne survienne.
Salesforce fournit également des instructions pour s'abonner aux messages et notifications de My Trust Center . Configurez les notifications pour les personnes concernées, et pas seulement pour l'administrateur ayant créé l'organisation. Conservez un canal de communication indépendant, comme une page d'état interne ou un groupe de discussion autorisé, afin que votre entreprise puisse communiquer même si le site d'état du fournisseur est lent ou indisponible.
Même si Salesforce signale le rétablissement des services, l'incident peut avoir des répercussions sur l'activité. Une requête API retardée peut être relancée deux fois, un message en file d'attente peut arriver en retard, ou un déploiement ayant échoué peut désynchroniser des enregistrements. Après la récupération, vérifiez les flux de travail les plus critiques : authentification, appels API, tâches planifiées, files d'attente d'intégration, distribution des e-mails et messages, création d'enregistrements et mise à jour des rapports.
Prenons l'exemple d'une équipe de support de taille moyenne dont les agents utilisent les requêtes Salesforce, tandis qu'un système de commerce distinct envoie des mises à jour via une intégration. Si Salesforce redevient disponible à 10h00, mais que la file d'attente de l'intégration contient des messages d'erreur liés à l'indisponibilité du service, l'équipe ne doit pas clôturer l'incident simplement parce que le navigateur se charge. Le test pertinent consiste à vérifier que les mises à jour des requêtes, nouvelles et ayant déjà échoué, suivent bien le flux de travail complet sans duplication.
| Conditions commerciales | minimum pratique | Quand en ajouter davantage |
|---|---|---|
| Petite équipe ; une courte interruption est tolérable. | Abonnez-vous aux notifications pertinentes de Trust, notez l'identifiant de l'instance et tenez à jour une courte liste de contrôle des tâches manuelles. | Ajoutez des exportations et des tests de récupération si l'historique client ou les dossiers de conformité sont essentiels. |
| Les revenus, les centres de contact ou les opérations de service dépendent de Salesforce toute la journée. | Utilisez une surveillance indépendante, une procédure en cas d'indisponibilité, des contrôles de nouvelle tentative d'intégration et un responsable d'incident désigné. | Effectuez des tests de basculement ou de canaux d'admission alternatifs pendant les heures ouvrables avant une panne réelle. |
| Salesforce est couplé à Heroku ou à plusieurs clouds | Surveillez séparément la source d'état de chaque produit et les dépendances d'authentification des documents. | Mener des exercices de reprise conjoints qui testent simultanément la connexion, les API, les files d'attente et les communications avec les clients. |
| Données réglementées ou à forte valeur ajoutée | Utilisez une conception de sauvegarde et de conservation approuvée, des contrôles d'accès, des pistes d'audit et un manuel de procédure de récupération. | Faites examiner le manuel d'exploitation par les responsables de la sécurité, du service juridique, de la conformité et les dirigeants de l'entreprise. |
Commencez par un schéma des dépendances d'une page. Notez votre instance ou locataire Salesforce, votre fournisseur d'identité, les clouds connectés, les intégrations critiques, les abonnements de statut et le processus manuel mis en œuvre en cas de panne. Définissez ensuite un objectif de vérification de reprise pour chaque flux de travail important. « Salesforce est de nouveau opérationnel » est trop vague ; « les nouvelles requêtes, les messages sortants et les mises à jour de commandes sont traités sans doublons » est vérifiable.
Enfin, examinez les modifications susceptibles d'affecter la disponibilité : mises à jour des fournisseurs, changements de système d'exploitation, nouvelles versions, modifications de configuration et migrations d'instances. L'incident Heroku de juin dernier a démontré pourquoi les modifications non supervisées nécessitent des contrôles rigoureux et pourquoi la communication d'état doit être elle-même résiliente. L'événement du 18 juin a montré pourquoi la capacité physique et les dépendances aux centres de données restent cruciales pour un service cloud. La dégradation des fonctionnalités en décembre a démontré pourquoi les équipes doivent surveiller les fonctions qu'elles utilisent réellement, et pas seulement la disponibilité globale de la plateforme.
La réponse la plus appropriée est donc conditionnelle. Une petite organisation peut se contenter de notifications et d'une liste de contrôle manuelle claire. Une entreprise qui ne peut interrompre ses ventes ou son support a besoin d'une surveillance indépendante, d'une reprise prenant en compte les files d'attente et d'une procédure d'indisponibilité éprouvée. Une organisation fortement réglementée a besoin d'une restauration testée, de preuves et d'une gouvernance. L'historique des pannes de Salesforce en 2025 confirme une conclusion constante : la résilience repose sur la chaîne de dépendances du client, et non sur un simple indicateur de disponibilité.
Cette rétrospective s'appuie sur les enregistrements d'incidents de Salesforce Trust et la documentation Salesforce ou Heroku disponibles au moment de la rédaction. Les pages d'incidents peuvent être mises à jour après résolution, et la couverture des produits Salesforce diffère entre Trust Status et My Trust Center. En l'absence d'analyse détaillée des causes profondes publiée par Salesforce, cet article n'en tire aucune conclusion.
Un guide pratique pour 2026 sur l'IA, les capteurs domotiques, la surveillance à distance, la sécurité contre les chutes, la protection de la vie privée et comment la technologie peut favoriser le maintien à domicile sans remplacer les soins.
Découvrez comment les villes peuvent transformer les données relatives à la mobilité, à l'aménagement du territoire, au climat et à la communauté en quartiers plus sûrs, plus verts et plus accessibles à pied, sans pour autant privilégier la technologie au détriment des personnes.
Comparez les principaux programmes d'ingénierie aérospatiale et de drones pour les drones, l'autonomie, les commandes, les opérations de systèmes aériens sans pilote et la recherche de troisième cycle, avec des mises à jour vérifiées jusqu'en 2026.
A practical guide to AI-powered surgical robotics: current capabilities, levels of autonomy, precision benefits, limits, regulation, and evaluation criteria.
Les investissements dans le captage, l'utilisation et le stockage du carbone (CCUS) sont en hausse, mais le captage du carbone peut-il inverser les émissions mondiales ? Découvrez où cela fonctionne, quelles sont les limites de son déploiement à grande échelle et quelles preuves sont pertinentes.
Comparez sept programmes mondiaux pour les chaînes d'approvisionnement numériques, la logistique, l'analyse de données, le commerce international et les opérations, avec des conseils pratiques pour choisir la solution la plus adaptée.
Découvrez comment les interfaces cerveau-ordinateur décodent les signaux neuronaux pour rétablir la communication et le mouvement, ce que les études récentes ont permis de réaliser et ce qui limite encore l'utilisation des interfaces cerveau-ordinateur.
Découvrez comment les drones commerciaux combinent capteurs, intelligence artificielle embarquée, batteries, communications et logiciels de contrôle de vol, et comment l'autonomie dépend encore de la mission et de la réglementation.
Comparez sept excellentes options de master en batteries et stockage d'énergie en fonction des matériaux, des systèmes, de la recherche, de l'exposition à l'industrie, de la flexibilité, de la langue et des compromis en matière de coûts.
Learn how payload mass, battery limits, weather, propulsion efficiency, and aircraft architecture shape industrial UAV endurance—and how to improve it.
