Le 16 septembre 2026 au matin, les entreprises qui pilotent leurs ventes et leur support dans Salesforce se sont heurtées à un mur : connexions impossibles, interfaces inaccessibles, appels d’API en échec. Les premiers signalements sont apparus vers 7 h 50 UTC, l’éditeur a reconnu un incident touchant de multiples instances dans toutes les régions à 8 h 32 UTC, et le correctif n’a été déployé sur l’ensemble du parc qu’en fin de matinée, autour de 11 h 27 UTC. La panne est survenue le jour même de l’ouverture de Dreamforce, la conférence annuelle de l’éditeur à San Francisco. Pour les directions commerciales, les intégrateurs et les partenaires, la question n’est pas technique mais contractuelle et urgente : qui prouve l’indisponibilité, qui supporte les retards qu’elle a causés en cascade, et quelles décisions prendre dans les jours qui suivent.
La réponse tient en trois réflexes : figer immédiatement les preuves de l’interruption et de ses effets sur l’activité, relire son propre contrat pour identifier les engagements de disponibilité et les plafonds d’indemnisation, puis agir par écrit — mise en demeure, information des clients en aval, activation des secours — avant que les traces ne se dispersent. Réserve importante : cet article décrit le droit applicable à partir des documents publics disponibles au 20 septembre 2026 ; les éléments factuels de la panne sont rapportés d’après le récit horodaté publié le jour même, qui cite la page de statut officielle de l’éditeur et les relevés publics d’incidents, recoupés avec les pages officielles consultées le 20 septembre. Chaque contrat SaaS a ses clauses propres, et le périmètre exact de l’incident se vérifie instance par instance : ce qui suit ne remplace pas l’examen individuel d’un dossier.
I. Une matinée sans CRM : la panne du 16 septembre et ses dominos
A. Ce qui s’est passé, heure par heure, et ce qui reste à vérifier
La chronologie publiée le jour même est précise. Les premiers rapports d’utilisateurs sont remontés sur les plateformes publiques de signalement des incidents (Downdetector) vers 7 h 50 UTC, avec un pic peu après 9 h 00 heure britannique. À 8 h 32 UTC, Salesforce a confirmé le dysfonctionnement sur plusieurs instances dans toutes les régions du monde, puis a actualisé sa page de statut toutes les demi-heures. À 9 h 10, les ingénieurs ont repéré des requêtes bloquées en attente d’une réponse d’un service de connexion interne ; à 9 h 57, une dépendance externe a été identifiée comme étant à l’origine de la défaillance de l’ancien serveur de connexion ; à 10 h 20, la cause a été attribuée à la surcharge d’un composant central, avec un correctif déjà en test. Le correctif a été validé sur une instance de test à 10 h 56, déployé sur l’ensemble du parc à 11 h 27, et la plupart des instances se sont rétablies en début d’après-midi, certaines nécessitant un redémarrage manuel. Pendant l’incident, le message affiché sur la page de statut de l’éditeur, tel que rapporté dans le récit horodaté publié le jour même, prévenait les clients que de graves ralentissements, des erreurs intermittentes et des impossibilités d’accéder à certains services pouvaient survenir, en ajoutant que la panne empêchait même la création de nouveaux dossiers de support depuis le portail. Autrement dit, les entreprises bloquées ne pouvaient pas toujours ouvrir une demande d’aide par le canal normal.
Le périmètre géographique décrit est mondial : des centaines d’instances touchées, avec des signalements aux États-Unis, au Japon, en Inde, au Royaume-Uni, en France et en Allemagne, ainsi qu’en Australie, au Brésil, au Canada, en Suisse, en Indonésie, en Italie, en Corée du Sud, à Singapour et en Suède. La répartition des signalements citée attribue 69 % des remontées à l’accès au site, 16 % à l’application et 15 % à la connexion. Seul l’environnement GovCloud, dédié à l’administration publique américaine, serait resté opérationnel pendant toute la durée de l’incident. La cause technique mise en avant est un vieux serveur d’authentification : une dépendance externe aurait cessé de répondre et fait planter ce composant d’un autre âge, toujours présent sur le chemin d’accès, les requêtes restant en attente au lieu d’échouer rapidement.
Ces éléments appellent deux vérifications que chaque entreprise doit mener pour son propre compte. D’abord, l’appartenance de son instance au périmètre : le fait qu’une panne soit mondiale ne prouve pas que telle instance, tel connecteur ou telle intégration a été indisponible à telle heure, et c’est cette preuve individualisée qui comptera devant un juge ou dans une négociation. Ensuite, la nature exacte des services touchés : l’accès au site, la connexion, les API et les intégrations ne relèvent pas forcément des mêmes engagements contractuels, et la page Marketing Cloud citée dans le récit n’intéressera que les entreprises qui utilisent ce module. Les pages officielles consultées le 20 septembre 2026 — la page de statut de l’éditeur et la page publique de suivi des incidents — ne montrent plus aucun incident en cours, ce qui est normal quatre jours après : elles servent désormais de preuve du retour à la normale, pas du détail de l’incident. Les captures de la page de statut pendant l’incident, les journaux horodatés et les échanges avec le support constituent donc des pièces à réunir sans attendre, avant leur rotation ou leur archivage.
B. Trois cercles de professionnels touchés, trois jeux de preuves
Le premier cercle est celui des entreprises clientes qui ont fait de Salesforce leur système nerveux commercial. Quand la connexion centrale cesse de répondre, tout s’arrête : les commerciaux ne saisissent plus les opportunités, le support ne traite plus les tickets, les directions ne suivent plus les commandes, et les automatisations qui relient le CRM à la facturation, à la logistique ou au service après-vente s’interrompent. Le préjudice n’est pas seulement l’abonnement payé pour une matinée perdue : ce sont les devis non envoyés, les délais contractuels manqués vis-à-vis de leurs propres clients, les pénalités de retard encourues en aval et la désorganisation des équipes. Ces entreprises détiennent les preuves les plus directes de l’effet domino : les journaux applicatifs montrant les échecs de connexion, les exports d’activité attestant l’arrêt des traitements, les messages d’erreur conservés avec leur horodatage, les relevés d’appels au support, les attestations internes datées et, pour les faits les plus coûteux, le constat d’un commissaire de justice dressé sur les postes de travail pendant ou juste après l’incident.
Le deuxième cercle est celui des intégrateurs, prestataires de tierce maintenance applicative et éditeurs de connecteurs qui vivent de l’écosystème de la plateforme. Eux subissent la panne deux fois : ils ne peuvent ni superviser ni maintenir les environnements de leurs clients, et leurs propres engagements de temps de rétablissement continuent de courir pendant que l’infrastructure sur laquelle ils reposent est à l’arrêt. Un intégrateur qui a promis contractuellement une reprise en quelques heures se retrouve en inexécution apparente sans avoir commis la moindre faute, tandis que ses clients lui imputent des retards dont la cause réelle se situe un étage plus haut. Les preuves de ce cercle sont d’une autre nature : les sondes de supervision et leurs courbes d’indisponibilité, les tickets ouverts chez l’éditeur avec leurs numéros d’incident, les échanges avec les clients avertissant du blocage, les journaux des tentatives de contournement et les plannings d’intervention bouleversés. C’est aussi le cercle où la documentation contractuelle est la plus stratifiée, entre le contrat-cadre de l’éditeur, les contrats de mise en œuvre et les contrats de maintenance : chaque étage a ses exclusions, ses plafonds et ses procédures de réclamation, et c’est de leur articulation que dépendra qui supporte finalement le coût de la matinée perdue.
Le troisième cercle est celui des clients en aval et des partenaires commerciaux des entreprises utilisatrices : le distributeur qui n’a pas reçu sa confirmation de commande, le client final dont la livraison a glissé, le partenaire dont le flux de données ne s’est pas synchronisé. Ces professionnels ne sont pas cocontractants de l’éditeur et n’ont souvent même pas connaissance de la panne d’origine : ils constatent un retard, appliquent une pénalité ou résilient une commande. Leurs preuves sont les bons de commande, les confirmations non reçues, les pénalités facturées et les correspondances commerciales. L’enjeu pour l’entreprise utilisatrice est double : elle doit à la fois justifier son retard envers eux et préserver ses propres recours contre l’éditeur ou l’intégrateur, sans reconnaître par écrit une faute qui n’est pas la sienne. Toute la gestion de crise consiste à tenir ces deux fronts ensemble, avec des messages distincts et des pièces cloisonnées : informer l’aval sans s’incriminer, réclamer en amont sans attendre.
II. Qui prouve quoi, qui paie quoi : les décisions par acteur
A. Face à l’éditeur : contrat, plafonds et faute lourde
Le point de départ est le contrat, et d’abord la question de savoir qui est juridiquement l’éditeur face à l’entreprise française : la société américaine, sa filiale européenne, ou un revendeur local qui a facturé l’abonnement. Les sanctions de l’inexécution prévues par le code civil s’appliquent au cocontractant identifié : « La partie envers laquelle l’engagement n’a pas été exécuté, ou l’a été imparfaitement, peut : – refuser d’exécuter ou suspendre l’exécution de sa propre obligation ; – poursuivre l’exécution forcée en nature de l’obligation ; – obtenir une réduction du prix ; – provoquer la résolution du contrat ; – demander réparation des conséquences de l’inexécution. » (article 1217 du code civil). Et le même article précise l’articulation des sanctions : « Les sanctions qui ne sont pas incompatibles peuvent être cumulées ; des dommages et intérêts peuvent toujours s’y ajouter. » (article 1217 du code civil). Concrètement, l’entreprise cliente peut donc cumuler la demande de crédits de service ou de réduction de prix avec une demande de dommages-intérêts pour le préjudice qui dépasse ces crédits, à condition de prouver chaque poste.
La deuxième question est celle des plafonds contractuels. Les contrats SaaS encadrent presque toujours la responsabilité de l’éditeur : crédits de service en cas de disponibilité dégradée, exclusion des préjudices indirects, plafond exprimé en mois d’abonnement. Ces clauses ne sont pas automatiquement efficaces. Le tribunal des activités économiques de Nanterre l’a rappelé le 3 septembre 2026 dans un litige opposant une société de services informatiques à un opérateur de réseau : après une interruption de 59 jours sans solution palliative, malgré une garantie contractuelle de reprise en 24 heures, le tribunal a jugé que « Orange a manqué au respect de ses obligations contractuelles, qui sont des obligations de résultat. » (tribunal des activités économiques de Nanterre, 3e chambre, 3 septembre 2026, RG 2026F00452, décision). Il a ajouté que « L’ampleur du préjudice causé et l’inobservation délibérée d’une obligation essentielle permettent de caractériser la faute lourde. » (même décision), écartant en conséquence les limitations de responsabilité au visa de l’article 1231-3 du code civil. Le tribunal a finalement condamné l’opérateur à payer 40 000 euros de dommages-intérêts, en retenant exactement que le tribunal « Condamne la SA Orange à payer à la SARL S.E.R.I.A. Société d’Études et de Réalisations Informatiques en Agroalimentaire la somme de 40 000 euros » (même décision). La leçon pour les entreprises clientes de Salesforce est directe : une indisponibilité durable, combinée à l’absence de solution de contournement et au non-respect des engagements de rétablissement, peut faire échec aux plafonds, mais encore faut-il démontrer la durée exacte, l’absence de palliatif et le manquement aux engagements chiffrés du contrat.
Le texte qui fonde ce raisonnement mérite d’être lu avant toute réclamation : « Le débiteur n’est tenu que des dommages et intérêts qui ont été prévus ou qui pouvaient être prévus lors de la conclusion du contrat, sauf lorsque l’inexécution est due à une faute lourde ou dolosive. » (article 1231-3 du code civil). Autrement dit, le préjudice prévisible à la signature — l’arrêt des ventes, le retard des livraisons, la désorganisation du support — est indemnisable dans la limite des clauses, tandis que le dépassement des plafonds exige la démonstration d’une faute lourde ou dolosive. Le pendant de ce texte est le fondement de toute demande : « Le débiteur est condamné, s’il y a lieu, au paiement de dommages et intérêts soit à raison de l’inexécution de l’obligation, soit à raison du retard dans l’exécution, s’il ne justifie pas que l’exécution a été empêchée par la force majeure. » (article 1231-1 du code civil). C’est donc à l’éditeur, si une action est engagée, de justifier d’une force majeure — et une défaillance interne de son propre serveur d’authentification, composant qu’il exploite et maintient, ne présente ni l’extériorité ni l’imprévisibilité requises.
La troisième question est symétrique : que deviennent les clauses limitatives si le client, excédé, fait résoudre le contrat ? La Cour de cassation a tranché le 13 novembre 2025 dans un litige informatique opposant un éditeur à son client : « Il résulte de ces textes qu’en cas de résolution d’un contrat pour inexécution, les clauses limitatives de réparation des conséquences de cette inexécution demeurent applicables. » (Cour de cassation, chambre commerciale, financière et économique, 13 novembre 2025, pourvoi n° 22-22.225, décision). Résoudre le contrat ne fait donc pas sauter les plafonds : c’est une décision à peser froidement, en comparant le coût d’une migration vers un autre CRM — extraction des données, reconfiguration, formation, double licence pendant la transition — avec le rendement probable d’une action en responsabilité encadrée par ces mêmes plafonds. Dans la plupart des cas, la voie efficace n’est pas la rupture mais la réclamation chiffrée et documentée, adossée à une mise en demeure qui fige les positions.
Reste l’argument que l’éditeur opposera presque sûrement : ses engagements de disponibilité seraient des objectifs de moyens, assortis de crédits de service exclusifs de tout autre recours. Trois réponses s’articulent. D’abord, la qualification se discute clause par clause : un engagement chiffré de disponibilité, assorti d’une garantie de temps de rétablissement, s’analyse plus volontiers en obligation de résultat, comme l’a retenu le tribunal de Nanterre pour des services d’accès. Ensuite, l’exclusivité des crédits de service ne résiste pas à la faute lourde, ainsi qu’on l’a vu. Enfin, les clauses qui organiseraient une irresponsabilité quasi totale de l’éditeur pour l’indisponibilité de son propre service s’exposent à la censure du déséquilibre significatif : « Engage la responsabilité de son auteur et l’oblige à réparer le préjudice causé le fait, dans le cadre de la négociation commerciale, de la conclusion ou de l’exécution d’un contrat, par toute personne exerçant des activités de production, de distribution ou de services : » (article L. 442-1 du code de commerce), notamment le fait « De soumettre ou de tenter de soumettre l’autre partie à des obligations créant un déséquilibre significatif dans les droits et obligations des parties » (article L. 442-1 du code de commerce). Cet argument, manié avec prudence et au cas par cas, pèse surtout dans la négociation : un éditeur mondial préfère souvent consentir un geste commercial substantiel plutôt que de voir ses clauses types contestées devant un tribunal français.
La quatrième décision à prendre face à l’éditeur est procédurale : écrire vite, écrire juste, écrire au bon destinataire. La mise en demeure doit décrire l’interruption constatée instance par instance, viser les clauses invoquées, chiffrer provisoirement le préjudice et impartir un délai pour obtenir les crédits de service et engager la discussion sur le surplus. Elle s’adresse au cocontractant désigné par le contrat, avec copie à l’interlocuteur commercial, par un canal qui prouve la réception. Suspendre le paiement des abonnements en représailles est en revanche déconseillé sans analyse : l’exception d’inexécution suppose une inexécution suffisamment grave et expose à une résiliation pour impayé qui inverserait les torts. De même, la menace de résolution doit rester une arme de négociation maniée par écrit et à bon escient, pas un réflexe : une fois le contrat résolu, les plafonds demeurent, comme l’a jugé la Cour de cassation, et l’entreprise devra reconstruire son système d’information en position de demanderesse.
B. Dans la chaîne : intégrateurs, sous-traitants et clients en aval
L’intégrateur ou le mainteneur se trouve en sandwich : responsable envers ses clients de la disponibilité promise, dépendant envers l’éditeur d’une plateforme qu’il ne contrôle pas. Sa première décision est probatoire et défensive : démontrer que l’inexécution apparente de ses propres engagements a pour cause exclusive l’indisponibilité de l’étage supérieur. Les courbes de supervision, les numéros d’incidents ouverts chez l’éditeur, les messages d’alerte envoyés aux clients pendant la panne et les journaux des tentatives de contournement forment le dossier qui lui permettra d’opposer la force majeure à ses propres clients — ou du moins de caractériser une cause étrangère. Le texte applicable est strict : « Il y a force majeure en matière contractuelle lorsqu’un événement échappant au contrôle du débiteur, qui ne pouvait être raisonnablement prévu lors de la conclusion du contrat et dont les effets ne peuvent être évités par des mesures appropriées, empêche l’exécution de son obligation par le débiteur. » (article 1218 du code civil). L’intégrateur devra donc aussi prouver qu’il avait prévu des mesures appropriées : redondance, bascule, mode dégradé documenté. Et si l’empêchement n’est que temporaire, la règle est la suspension, pas l’effacement : « Si l’empêchement est temporaire, l’exécution de l’obligation est suspendue à moins que le retard qui en résulterait ne justifie la résolution du contrat. » (article 1218 du code civil). Autrement dit, les obligations de l’intégrateur reprennent à la fin de la panne, et les retards accumulés doivent être résorbés selon un plan annoncé par écrit.
Sa deuxième décision concerne ses flux financiers. Quand le client final suspend ses paiements en invoquant l’interruption, quand l’éditeur continue de facturer l’abonnement, et quand ses propres sous-traitants de rang 2 réclament leur dû, l’intégrateur doit éviter l’engrenage des compensations sauvages. La Cour de cassation vient d’illustrer le 9 septembre 2026 les pièges d’une chaîne informatique en cascade : dans un litige opposant une banque cessionnaire de créances à un donneur d’ordre informatique et au liquidateur de son sous-traitant, la cour d’appel avait retenu « l’existence d’une chaîne de contrats d’entreprise de sous-traitance concourant à la réalisation d’une même opération », et le pourvoi contre cette analyse a été rejeté (Cour de cassation, chambre commerciale, financière et économique, 9 septembre 2026, pourvoi n° U 25-12.146, décision). Dans cette affaire, le donneur d’ordre avait payé directement des prestataires de rang 2 impayés par son sous-traitant, s’était fait saisir par l’un d’eux, puis avait suspendu tout paiement — avant que le sous-traitant ne soit liquidé et que la banque cessionnaire ne vienne réclamer les factures. La morale opérationnelle pour l’intégrateur bloqué par la panne du 16 septembre est claire : payer directement ses sous-traitants sans quittance subrogative en règle, suspendre des paiements sans notification motivée, ou céder des créances sans vérifier les protections légales des maillons inférieurs, ce sont trois manières de transformer une matinée d’indisponibilité en contentieux de plusieurs années. Chaque paiement dérogatoire doit être tracé, chaque suspension notifiée, chaque cession relue au regard de la loi du 31 décembre 1975 sur la sous-traitance.
La troisième décision de la chaîne est celle des données. Une indisponibilité du CRM n’est pas en soi une violation de données, mais elle impose un examen documenté : les données sont-elles restées confidentielles et intègres pendant l’incident, l’accès a-t-il été rétabli dans des délais appropriés, et les traitements ont-ils repris sans altération ? Le règlement européen impose aux responsables et aux sous-traitants des mesures incluant « des moyens permettant de garantir la confidentialité, l’intégrité, la disponibilité et la résilience constantes des systèmes et des services de traitement » (règlement (UE) 2016/679, article 32, paragraphe 1, point b)), ainsi que « des moyens permettant de rétablir la disponibilité des données à caractère personnel et l’accès à celles-ci dans des délais appropriés en cas d’incident physique ou technique » (règlement (UE) 2016/679, article 32, paragraphe 1, point c)). Si l’analyse révèle une violation — accès non autorisé, exfiltration, altération —, le sous-traitant doit alerter sans délai : « Le sous-traitant notifie au responsable du traitement toute violation de données à caractère personnel dans les meilleurs délais après en avoir pris connaissance. » (règlement (UE) 2016/679, article 33, paragraphe 2). Et le responsable de traitement notifie à l’autorité : « En cas de violation de données à caractère personnel, le responsable du traitement en notifie la violation en question à l’autorité de contrôle compétente conformément à l’article 55, dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, à moins que la violation en question ne soit pas susceptible d’engendrer un risque pour les droits et libertés des personnes physiques. » (règlement (UE) 2016/679, article 33, paragraphe 1). En pratique, l’entreprise cliente documente son examen même quand il conclut à l’absence de violation : ce registre d’incident est la pièce qui protégera le délégué à la protection des données en cas de contrôle ultérieur, et l’intégrateur exige de l’éditeur le rapport d’incident correspondant par écrit.
La quatrième décision est celle de l’aval : que dire aux clients qui ont subi les retards, et comment limiter la casse commerciale sans créer de reconnaissance de faute. La règle probatoire pèse sur celui qui réclame : « Celui qui réclame l’exécution d’une obligation doit la prouver. Réciproquement, celui qui se prétend libéré doit justifier le paiement ou le fait qui a produit l’extinction de son obligation. » (article 1353 du code civil). L’entreprise utilisatrice qui invoque la panne pour justifier un retard doit donc prouver la panne et son lien avec le retard — d’où l’importance du dossier constitué en première heure. Ses messages à l’aval doivent être factuels et datés : nature de l’incident subi, plage d’indisponibilité constatée sur ses propres systèmes, mesures de reprise engagées, nouveau calendrier proposé. Ils ne doivent ni promettre une indemnisation avant chiffrage, ni désigner un responsable avant analyse, ni invoquer la force majeure à la légère, car ces écrits seront relus en cas de litige. Et parce que ces écrits sont électroniques, leur conservation doit garantir leur valeur : « L’écrit électronique a la même force probante que l’écrit sur support papier, sous réserve que puisse être dûment identifiée la personne dont il émane et qu’il soit établi et conservé dans des conditions de nature à en garantir l’intégrité. » (article 1366 du code civil). L’export des journaux, des échanges et des constats dans un archivage intègre et horodaté n’est pas un luxe d’informaticien : c’est la condition pour que le dossier tienne devant le tribunal.
La cinquième décision, enfin, est stratégique : faut-il renégocier, changer d’architecture ou changer de prestataire ? La panne du 16 septembre est un révélateur de dépendance : mono-CRM sans mode dégradé, intégrateur unique sans réversibilité documentée, sauvegardes inexploitables sans la plateforme. La renégociation peut porter sur les engagements de disponibilité chiffrés, les crédits de service automatiques, les délais de communication d’incident, la fourniture d’un rapport d’incident écrit et la clause de réversibilité avec format d’export. Lorsque le préjudice se chiffre en dizaines de milliers d’euros et que la discussion devient contentieuse, les entreprises concernées gagnent à faire relire l’ensemble de la chaîne contractuelle par l’expertise en droit des affaires du cabinet à Paris avant d’assigner ou de signer un protocole : c’est à ce stade que se jouent l’identification du bon défendeur, le choix entre action individuelle et action groupée des clients lésés, et l’articulation entre la réclamation contre l’éditeur et la gestion des litiges en aval. L’assurance pertes d’exploitation sans dommage matériel mérite aussi d’être activée sans tarder, car ses délais de déclaration sont souvent de quelques jours.
La panne mondiale du 16 septembre 2026 n’a duré qu’une matinée, mais elle a rappelé une vérité que les directions juridiques connaissent bien : dans une économie où le CRM est le système nerveux de l’entreprise, l’indisponibilité d’une plateforme centrale se propage instantanément aux intégrateurs, aux partenaires et aux clients, avec des factures à chaque étage. Les entreprises qui traverseront le mieux cet épisode ne sont ni celles qui minimisent ni celles qui menacent : ce sont celles qui, dès le premier message d’erreur, ont conservé les preuves, relu leurs contrats et écrit à bon escient — à l’éditeur pour réclamer, à l’intégrateur pour exiger le plan de reprise, à l’aval pour informer sans s’incriminer. Les enseignements jurisprudentiels sont convergents : les engagements de résultat se paient quand ils sont inexécutés, les plafonds tombent devant la faute lourde mais survivent à la résolution, et les chaînes de sous-traitance mal documentées transforment chaque incident en contentieux durable. La matinée du 16 septembre est derrière ; les décisions qu’elle impose, elles, sont devant.
Besoin d’un avis rapide sur votre dossier
Maître Reda KOHEN, avocat au Barreau de Paris, reçoit en consultation téléphonique les entreprises clientes, intégrateurs et partenaires confrontés à l’indisponibilité d’une plateforme ou d’un logiciel central : contrats SaaS, preuves de la panne, préjudices en chaîne et recours. Téléphone : 06 46 60 58 22. Contact : https://kohenavocats.fr/formulaire-de-contact/.