Le 16 septembre 2026, au petit matin californien et en pleine conférence Dreamforce, la plateforme Salesforce a subi une panne mondiale : des clients dans plusieurs régions ont signalé des ralentissements sévères, des erreurs intermittentes et, pour certains, une impossibilité pure et simple d’accéder à leurs outils. Le point de départ documenté est précis : 0 h 50, heure du Pacifique, le 16 septembre, selon la page de statut officielle de l’éditeur, avec des instances touchées dans toutes les régions peu avant 2 heures du matin. Quand le système qui porte la relation client, les devis, les commandes et le support d’une entreprise s’arrête, ce n’est pas seulement cette entreprise qui est à l’arrêt : ses commerciaux ne peuvent plus répondre, ses clients ne sont plus servis, ses fournisseurs attendent des validations qui ne viennent pas et son intégrateur informatique se retrouve en première ligne des réclamations.
La réponse pratique tient en trois réflexes. D’abord, figer la preuve de l’interruption et de ses effets, car en droit français celui qui réclame l’exécution d’une obligation doit la prouver. Ensuite, relire le contrat : niveaux de service promis, crédits de service, clauses qui plafonnent la réparation et procédure de notification, car la jurisprudence récente valide ces plafonds tout en sanctionnant le fournisseur défaillant. Enfin, décider sans précipitation : attendre la fin de l’incident avant de parler de rupture, mesurer si l’inexécution est suffisamment grave pour justifier une résolution, et traiter à part la question des données personnelles si la panne s’accompagne d’un incident de sécurité.
Deux réserves s’imposent avant d’aller plus loin. Nous ne disposons pas du contrat conclu entre Salesforce et ses clientes françaises, ni de ses annexes de service : tout ce qui suit raisonne donc à partir du droit commun et de décisions rendues dans des litiges comparables, pas à partir des conditions particulières de cet éditeur. Ensuite, une interruption de quelques heures, même mondiale et spectaculaire, n’équivaut pas automatiquement à une faute engageant la responsabilité de l’éditeur envers chaque entreprise utilisatrice : tout dépend du contenu des engagements souscrits, de la durée réelle de l’indisponibilité pour chaque cliente et du préjudice démontrable. Cet article est la carte de ces conséquences et des décisions à prendre, pas l’annonce d’un droit automatique à indemnisation.
I. Une panne de plateforme et sa propagation dans la chaîne des entreprises
A. Ce que l’on sait de l’incident du 16 septembre 2026, et ce que l’on n’en sait pas
Le récit factuel repose sur deux sources complémentaires. D’un côté, la presse spécialisée : le site Salesforce Ben, média sectoriel de référence de l’écosystème, a publié le 16 septembre 2026 un article consacré à cette panne mondiale, qui décrit une perturbation étendue touchant des clients dans plusieurs régions, avec des retards sévères, des erreurs intermittentes et, pour certains utilisateurs, une impossibilité d’accéder à la plateforme. L’article situe le début de la perturbation à 0 h 50, heure du Pacifique, le 16 septembre, d’après les informations de Salesforce Trust, et précise que peu avant 2 heures du matin plusieurs instances étaient affectées dans toutes les régions, en plein déroulement de la conférence annuelle Dreamforce. De l’autre côté, la source primaire : la page d’incident officielle de Salesforce Trust (incident n° 20004433), qui constitue le canal par lequel l’éditeur documente l’état de ses services.
Ce double ancrage est une méthode autant qu’une prudence. La presse spécialisée donne la date, l’ampleur et le contexte ; la page de statut officielle donne la version de l’éditeur, instance par instance. Pour une entreprise cliente qui voudra ensuite démontrer qu’elle a bien été privée de son outil, ces deux couches de preuve se complètent : captures datées de la page de statut, journaux internes d’erreurs, tickets d’assistance ouverts auprès de l’éditeur ou de l’intégrateur. À l’inverse, ce que ces sources ne donnent pas, c’est la mesure individuelle du préjudice de chaque entreprise : une multinationale dont les équipes américaines dormaient à 0 h 50 du Pacifique n’a pas subi la même gêne qu’une PME française dont la force de vente attaquait sa journée à 9 h 30, heure de Paris, soit 0 h 30 du Pacifique. La concomitance est troublante pour les utilisatrices européennes : le créneau de la panne recouvre le début de la journée de travail en France. Mais chaque entreprise devra établir sa propre chronologie, car le juge n’indemnise jamais une gêne collective présumée : il indemnise un préjudice précis, prouvé, poste par poste.
Il faut aussi distinguer trois questions que l’actualité mélange souvent. La panne, d’abord : l’indisponibilité ou la dégradation du service. La cause, ensuite : à la date de rédaction de cet article, la cause technique exacte de l’incident n’est pas établie publiquement de façon détaillée, et il serait imprudent de l’affirmer. La responsabilité, enfin : elle ne découle ni de la panne ni de sa cause supposée, mais de la confrontation entre les engagements contractuels de l’éditeur et ce qui s’est réellement passé pour chaque cliente. Une panne brève, résorbée en quelques heures, avec communication de l’éditeur et crédits de service appliqués, ne se traite pas comme une indisponibilité de plusieurs jours sans information. Cette gradation commande toute la suite du raisonnement.
B. La carte des acteurs : cliente, intégrateur, clients et fournisseurs finaux
L’angle de cet article est l’effet domino, et il faut donc nommer les dominos. Le premier est l’éditeur de la plateforme, Salesforce, débiteur envers ses clientes d’une obligation de fourniture continue du service, dans les termes de chaque contrat d’abonnement. Le deuxième est l’entreprise cliente : celle qui paie l’abonnement, paramètre son CRM, y stocke ses contacts, ses opportunités, ses devis, parfois sa facturation et son support. Le troisième est l’intégrateur ou le prestataire informatique : la société de services qui a vendu, paramétré, connecté et maintenu la solution chez la cliente, souvent avec son propre contrat de services et sa propre astreinte. Le quatrième rang rassemble les partenaires de la cliente : ses propres clients, qui attendent un devis, une livraison ou une réponse du support ; ses fournisseurs, qui attendent une commande ou un règlement validé dans le système ; parfois sa banque, quand les flux de paiement transitent par des connecteurs applicatifs.
Chaque lien de cette chaîne est un contrat distinct, avec son débiteur, son créancier et ses propres clauses. C’est le principe de la force obligatoire des conventions : « Les contrats légalement formés tiennent lieu de loi à ceux qui les ont faits. » C’est le point que les entreprises sous-estiment le plus souvent dans la panique d’une panne : la cliente ne peut pas « se retourner » directement contre l’éditeur pour le préjudice subi par son propre client, et son client ne peut pas assigner l’éditeur avec lequel il n’a aucun contrat. Chacun n’agit que sur son maillon. La cliente agit contre l’éditeur sur le fondement de l’abonnement ; elle peut aussi agir contre son intégrateur si celui-ci a manqué à ses propres obligations, par exemple de conseil, de supervision ou de plan de continuité ; le client final agit contre la cliente sur le fondement de leur contrat commercial ; le fournisseur fait de même. Puis, par ricochet économique, la cliente répercute dans son propre préjudice les sommes qu’elle a dû verser à ses partenaires : avoirs commerciaux consentis, pénalités de retard payées, commandes perdues. Cette mécanique de répercussion est admise, à condition d’être prouvée facture par facture, et elle explique pourquoi une panne de quelques heures peut coûter beaucoup plus cher que le montant de l’abonnement mensuel.
Deux situations concrètes illustrent la propagation. Première situation : une société de distribution gère ses commandes fournisseurs dans Salesforce ; la panne bloque la validation des réassorts le matin du 16 septembre ; les camions partent en retard ; les magasins franchisés, eux-mêmes indépendants, subissent des ruptures en rayon et réclament des avoirs à la tête de réseau. La tête de réseau, cliente de Salesforce, concentre alors trois préjudices : ses coûts internes de gestion de crise, les avoirs versés aux franchisés et l’éventuelle perte de marge. Deuxième situation : un intégrateur a vendu à plusieurs clientes un connecteur entre Salesforce et leur comptabilité ; la panne casse la synchronisation ; les factures du mois partent en retard ; les clientes paient leurs propres fournisseurs en retard et encourent des pénalités. L’intégrateur reçoit autant d’appels furieux qu’il a de clientes, alors même qu’il n’est l’auteur d’aucune faute technique : il subit l’incident par réputation interposée et doit gérer la crise sans être le débiteur de l’obligation de disponibilité de la plateforme. Ces deux récits montrent que le premier besoin, pour chaque acteur, n’est pas d’assigner, mais de comprendre sur quel contrat il peut agir et ce qu’il doit prouver.
C’est ici que l’accompagnement d’avocats en droit des affaires à Paris prend son sens : non pas pour promettre une indemnisation, mais pour ordonner la chaîne des recours, qualifier chaque manquement sur son propre contrat et éviter qu’une mise en demeure mal dirigée ne fasse perdre des mois. La suite de l’article donne à chaque acteur les outils de cette discipline : la preuve d’abord, la décision ensuite.
II. Qui détient quelle preuve et quelle décision prendre
A. Prouver l’interruption, prouver le préjudice : la charge de chacun
Le principe est posé par le Code civil en des termes simples : « 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. » Autrement dit, l’entreprise cliente qui soutient que son CRM est resté inaccessible toute la matinée du 16 septembre doit le démontrer ; et l’éditeur qui soutiendrait que le service était disponible, ou que l’incident relevait d’un cas d’exonération, devrait justifier cette affirmation. En pratique, la preuve se construit dès les premières heures et avec des pièces très concrètes : captures d’écran datées des messages d’erreur, exports des journaux de connexion et des appels d’interface (API) en échec, tickets d’assistance horodatés, échanges avec l’intégrateur, relevés du nombre de collaborateurs affectés et des opérations bloquées, attestations internes des responsables commerciaux et comptables.
La jurisprudence récente des contrats informatiques montre à quel point les juges examinent ces pièces de près, dans un sens comme dans l’autre. Dans une affaire d’hébergement jugée par la cour d’appel de Versailles le 19 mai 2022, l’hébergeur Claranet avait été déclaré responsable d’un incident survenu le 28 juin 2017 affectant les données de l’association Amnesty International, par confirmation du jugement du tribunal de commerce de Nanterre du 24 juillet 2020 en ce qu’il avait retenu la responsabilité de l’hébergeur pour l’incident du 28 juin 2017 ayant affecté les données de l’association Amnesty International. La cour a ensuite condamné l’hébergeur à verser au prestataire 8 497,20 euros de dommages et intérêts, outre un avoir annulant la facture litigieuse, tout en validant le jeu des clauses plafonnant la réparation. L’enseignement pour nos lecteurs est double : un prestataire technique peut être déclaré responsable d’un incident d’exploitation, mais l’indemnisation reste enfermée dans le cadre contractuel convenu, et les sommes allouées correspondent à des postes démontrés, pas à une estimation globale du « préjudice commercial ».
Le même réalisme se retrouve dans l’arrêt de la cour d’appel de Toulouse du 6 janvier 2026 opposant l’éditeur Cegid à un cabinet d’expertise comptable : la cour y confirme que les dysfonctionnements informatiques persistants constatés dans le cabinet pendant l’année 2018 étaient imputables à l’éditeur, qui avait manqué à ses obligations contractuelles, puis juge que que les clauses des articles 14.4 et 14.5 des conditions générales, qui plafonnaient l’indemnisation, devaient s’appliquer au litige, déboutant le client de ses demandes au titre de la perte d’exploitation, de l’embauche d’un salarié, de la perte de temps du dirigeant et de la perte de clientèle, pour ne lui accorder que 10 000 euros au titre du remboursement des frais de location du progiciel défaillant et du préjudice moral. La leçon est sévère mais claire : même quand la faute du fournisseur est établie, les grands postes de préjudice économique sont rejetés s’ils ne sont pas prouvés avec précision ou s’ils sont exclus par les clauses du contrat. Pour les victimes de la panne du 16 septembre, cela signifie qu’il faut, dès maintenant, chiffrer chaque poste séparément : heures supplémentaires payées, avoirs consentis aux clients, pénalités versées aux fournisseurs, commandes annulées avec leur marge documentée, coût d’une solution de secours.
Un troisième jugement, rendu par le tribunal judiciaire de Versailles le 11 avril 2025 dans un litige opposant un cabinet d’avocats à son prestataire de logiciel, complète le tableau : le tribunal y le tribunal a condamné le prestataire à verser 16 000 euros de dommages et intérêts au cabinet, en rejetant le surplus des demandes, après avoir écarté l’essentiel des demandes fondées sur des tickets d’assistance et des difficultés d’usage non rattachés à une faute démontrée du prestataire. Là encore, le message est constant : l’existence d’incidents et de tickets ne suffit pas ; il faut établir le lien entre un manquement précis du fournisseur et un préjudice précis du client. Pour l’intégrateur pris entre l’éditeur et ses clientes, la discipline probatoire est symétrique : conserver les journaux montrant que ses propres prestations sont restées conformes, tracer les alertes transmises, et démontrer que l’origine de l’interruption se situe sur la plateforme et non dans son paramétrage.
Deux conseils pratiques découlent de cette exigence. D’abord, adresser à l’éditeur et, le cas échéant, à l’intégrateur une réclamation écrite rapide, décrivant les créneaux d’indisponibilité constatés, les opérations bloquées et les premiers coûts, avec mise en demeure de conserver les journaux techniques : cette lettre fige la chronologie et ouvre le délai contractuel de traitement. Ensuite, constituer un dossier de préjudice évolutif, mis à jour semaine après semaine, avec chaque pièce comptable : c’est ce dossier, et non l’émotion de la panne, qui fera l’issue d’une négociation ou d’un procès. Les entreprises qui se contentent d’un courrier général réclamant « réparation de l’ensemble des préjudices » sans chiffrage obtiennent, comme le montrent les décisions citées, des sommes limitées ou un rejet pur et simple des postes non documentés.
B. Décider : contrat, résolution, force majeure et données personnelles
Une fois la preuve en cours de constitution, vient le temps des décisions, et la première est souvent de ne pas décider trop vite. Le Code civil offre à la partie victime d’une inexécution un éventail gradué : « 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. Les sanctions qui ne sont pas incompatibles peuvent être cumulées ; des dommages et intérêts peuvent toujours s’y ajouter. » Pour une panne de quelques heures déjà résorbée, l’option proportionnée est la demande de réparation, le cas échéant via les crédits de service prévus au contrat, plutôt que la résolution, qui suppose une inexécution suffisamment grave. La résolution « résulte soit de l’application d’une clause résolutoire soit, en cas d’inexécution suffisamment grave, d’une notification du créancier au débiteur ou d’une décision de justice » : notifier la résolution d’un abonnement annuel pour quelques heures d’indisponibilité exposerait l’entreprise à voir sa propre rupture jugée abusive, avec le risque de devoir payer le solde de l’abonnement. La voie de la résiliation doit donc être réservée aux situations où l’incident révèle une défaillance structurelle et répétée du fournisseur, documentée sur la durée, et après mise en demeure restée sans effet.
La deuxième décision concerne les clauses qui encadrent la réparation. Les contrats SaaS comportent presque toujours trois étages : un engagement de disponibilité exprimé en pourcentage, des crédits de service automatiques en cas de dépassement, et un plafond global de responsabilité, souvent exprimé en mois d’abonnement. La jurisprudence citée plus haut valide ces plafonds : ni la cour de Versailles ni celle de Toulouse ne les ont écartés, même en retenant la faute du fournisseur. Il faut donc les lire avant de chiffrer une réclamation, vérifier s’ils excluent les préjudices indirects et la perte d’exploitation, et identifier les exceptions éventuelles, notamment en cas de faute lourde ou dolosive. Sur ce dernier point, le Code civil limite strictement l’extension : « 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. » Et même dans ce cas extrême, « Dans le cas même où l’inexécution du contrat résulte d’une faute lourde ou dolosive, les dommages et intérêts ne comprennent que ce qui est une suite immédiate et directe de l’inexécution. » Concrètement, la perte de marge d’une commande annulée parce que le devis n’a pas pu être validé pendant la panne peut constituer une suite directe ; la perte d’un client qui, mécontent, confie ensuite l’ensemble de ses achats à un concurrent, relève le plus souvent d’un préjudice indirect, difficilement indemnisable. Cette distinction doit guider la rédaction de la réclamation : mettre en avant les postes directs et documentés, plutôt qu’un chiffrage global incluant des pertes d’image invérifiables.
La troisième question est celle de la force majeure, que l’éditeur pourrait invoquer et que les clientes doivent savoir analyser. Le Code civil la définit strictement : « 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. » Lorsque la gêne n’est que passagère, « 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. » Si l’empêchement est définitif, le contrat est alors résolu de plein droit. Une panne interne à la plateforme de l’éditeur, sur ses propres instances, remplit rarement ces trois conditions cumulatives, en particulier celle de l’événement échappant au contrôle du débiteur et celle de l’imprévisibilité, car la continuité de service est précisément l’objet du contrat d’hébergement et de fourniture SaaS. En revanche, si l’incident provenait d’un événement extérieur avéré, comme une coupure électrique majeure affectant un centre de données malgré les redondances, ou une attaque d’ampleur inédite contre l’infrastructure, la discussion serait ouverte, et c’est à l’éditeur d’en rapporter la preuve. Le même article qui ouvre la réparation rappelle d’ailleurs la seule exonération admise : « 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. » Pour l’entreprise cliente, la position pratique est donc la suivante : ne pas accepter une fin de non-recevoir fondée sur la force majeure sans exiger la description précise de l’événement invoqué, sa datation et la démonstration que les mesures appropriées, notamment de redondance, avaient été prises ; et symétriquement, ne pas invoquer soi-même la force majeure envers ses propres clients et fournisseurs pour justifier ses retards, sauf si les trois conditions sont réellement réunies, car un manquement de son fournisseur n’exonère pas automatiquement ses propres engagements envers ses partenaires.
La quatrième décision concerne les données personnelles, dès lors que le CRM héberge des contacts, des prospects et parfois des données de salariés. Une simple indisponibilité, sans accès ni exfiltration, ne constitue pas en elle-même une violation de données au sens du règlement européen. Mais si l’incident s’accompagne d’accès anormaux, d’exports suspects ou d’une altération de données, le régime des violations s’applique, avec ses délais stricts : le règlement impose au responsable du traitement de notifier la violation à l’autorité de contrôle dans les meilleurs délais et, si possible, au plus tard 72 heures après en avoir pris connaissance, sauf absence de risque pour les droits et libertés des personnes, tout retard devant être motivé (voir le chapitre 4 du règlement sur le site de la CNIL) Dans la chaîne SaaS, les rôles doivent être distingués : l’entreprise cliente est le plus souvent responsable du traitement de ses contacts commerciaux, tandis que l’éditeur agit comme sous-traitant, et le sous-traitant doit pour sa part avertir le responsable du traitement dans les meilleurs délais après en avoir pris connaissance Si le risque pour les personnes est élevé, s’ajoute l’information des personnes concernées : quand la violation est susceptible d’engendrer un risque élevé pour les droits et libertés d’une personne, le responsable doit aussi en informer la personne concernée dans les meilleurs délais Pour les lecteurs de cet article, la consigne opérationnelle est simple : demander à l’éditeur et à l’intégrateur, par écrit et sans délai, s’ils ont constaté un accès ou une altération anormale de données pendant l’incident ; à défaut de réponse claire, documenter la demande ; et si un indice sérieux apparaît, traiter la notification comme une urgence de 72 heures, pas comme un point à examiner « quand la panne sera résorbée ».
Reste la décision stratégique, celle que chaque dirigeant doit prendre une fois la crise passée : conserver le fournisseur en renégociant les garanties, ou organiser une sortie maîtrisée avec réversibilité des données. Les décisions citées montrent que les juges sanctionnent les sorties précipitées autant que les fournisseurs défaillants : le client qui cesse de payer l’abonnement sans respecter la procédure contractuelle s’expose à une condamnation au paiement, et celui qui migre sans plan de réversibilité perd la maîtrise de ses propres données. La bonne séquence est donc : réclamation chiffrée, négociation des crédits et des garanties renforcées, mise en demeure si nécessaire, et seulement en cas d’échec, résolution notifiée dans les formes, avec un plan de migration qui préserve la continuité. L’intégrateur, de son côté, a intérêt à proposer à ses clientes un audit de dépendance : quelles applications critiques reposent sur une seule plateforme, quels sont les modes dégradés possibles, quels sont les délais de bascule. C’est souvent dans cette phase d’après-crise que se joue la vraie valeur d’un prestataire : non pas pendant les heures où tout le monde subit, mais dans les semaines où l’on reconstruit des garanties.
En définitive, la panne mondiale du 16 septembre 2026 rappelle une vérité que les contrats informatiques énoncent rarement en première page : dans l’économie des plateformes, l’indisponibilité d’un seul maillon se paie sur toute la chaîne, mais ne s’indemnise que maillon par maillon, preuve par preuve, clause par clause. Les entreprises qui traverseront le mieux ce type d’incident ne sont pas celles qui menacent le plus fort, mais celles qui documentent le mieux : chronologie horodatée, préjudices chiffrés poste par poste, réclamations dirigées vers le bon débiteur sur le bon contrat. Et si la négociation s’enlise, les décisions rendues à Versailles et à Toulouse balisent le chemin du juge : responsabilité possible du fournisseur, plafonds contractuels respectés, préjudices indirects écartés. Une carte, en somme, plutôt qu’une promesse.