Le mercredi 16 septembre 2026, en pleine conférence Dreamforce qui rassemble des dizaines de milliers de participants à San Francisco et plus de 200 000 inscrits en ligne, le premier éditeur mondial de CRM tombe en panne à l’échelle planétaire. Des centaines d’instances Salesforce, aux États-Unis, au Japon, en Inde, au Royaume-Uni, en France et en Allemagne, subissent pendant des heures des retards graves, des erreurs intermittentes et des impossibilités d’accès à certains services. La cause identifiée par l’éditeur lui-même est interne : les requêtes s’accumulent en attente de réponse d’un service de connexion interne, qui sature les ressources des serveurs. Même la création des tickets de support est affectée, et certains travaux planifiés ne s’exécutent pas comme prévu. Le correctif est déployé dans la journée et l’incident est déclaré résolu en début de soirée. Pour les entreprises dont la force de vente, le service client et les automatisations tournent sur cette plateforme, et pour les intégrateurs et éditeurs tiers branchés sur ses interfaces, la question n’est pas technique : qui détient la preuve de l’indisponibilité, qui supporte la perte d’usage, et quelle décision prendre dans les jours qui suivent.
La réponse tient en quatre gestes. D’abord, figer la preuve de l’indisponibilité pendant qu’elle existe : page de statut de l’éditeur, journaux internes, tickets, constats contemporains. Ensuite, chiffrer la perte d’usage poste par poste au lieu d’invoquer un préjudice global : commandes non saisies, support bloqué, tâches automatisées non exécutées. Ensuite, activer le contrat : crédits de service et pénalités prévus au SLA, mise en demeure si l’inexécution persiste, suspension ou résolution selon la gravité. Enfin, pour les partenaires qui revendent ou interconnectent leurs propres solutions, assumer leur propre maillon vis-à-vis de leurs clients avant de se retourner contre l’amont, car l’aval paie d’abord et se fait rembourser ensuite, à condition de prouver le lien entre la panne et chaque euro réclamé.
Deux réserves s’imposent avant d’aller plus loin. Au jour où ces lignes sont écrites, le 18 septembre 2026, l’incident est résolu et aucune perte de données n’a été rapportée : il s’agit d’une indisponibilité temporaire, pas d’une destruction d’informations, et tout ce qui suit raisonne sur cette hypothèse, pièces en main. Ensuite, les faits techniques rappelés ici sont ceux établis par l’éditeur sur sa page de statut et par la presse spécialisée, pas par le cabinet : le reste relève du droit des contrats et de la preuve, exposé pour aider chaque professionnel à décider, sans promettre aucun résultat.
I. Une panne mondiale brève mais structurante : ce que les sources établissent
A. La chronologie officielle du 16 septembre 2026
La première alerte est donnée vers 9 h 30, heure de Londres, soit 8 h 30 en temps universel, sur la page de statut de l’éditeur (incident n° 20004433, consultée le 18 septembre 2026). Le tableau est inhabituel par son ampleur : ce ne sont pas une ou deux instances isolées qui ralentissent, mais des centaines d’instances dans le monde entier, y compris en France. Les clients subissent des retards graves, des erreurs intermittentes et des impossibilités d’accéder à certains services. L’enquête interne de l’éditeur identifie rapidement le goulet : les requêtes restent bloquées en attente de réponse d’un service interne de connexion, qui consomme l’ensemble des ressources disponibles des serveurs. Autrement dit, la porte d’entrée elle-même est embouteillée, et c’est tout l’immeuble qui devient inaccessible.
À 10 h 10, heure de Londres, l’éditeur confirme ce diagnostic et annonce travailler au correctif. À 12 h 19, un premier correctif est validé et déployé, et le service recommence à revenir à la normale pour une partie des clients. Mais à 15 h, l’éditeur reconnaît que le correctif n’a pas tout rétabli : des travaux planifiés ne s’exécutent pas comme prévu pour certains clients pourtant reconnectés. La fin de journée est consacrée à des redémarrages ciblés et à des reprises manuelles sur un sous-ensemble d’instances, les environnements dits de première partie restant épargnés. L’incident est déclaré résolu vers 20 h 20, heure de Londres, après une phase de validation prolongée sur les environnements concernés. La liste des clients de l’éditeur — Amazon, Walmart, Coca-Cola, Toyota, IBM, pour ne citer que les noms rappelés par la presse — donne la mesure de l’onde de choc : quand l’outil qui porte la relation client s’arrête, ce sont des chaînes entières de vente et de support qui s’arrêtent avec lui, chacune devant ses propres clients.
Trois détails de cette chronologie méritent l’attention du juriste, car ils commanderont toute la suite. Premièrement, la panne affecte aussi la création des tickets de support : les clients ne peuvent pas toujours signaler l’incident par le canal contractuel prévu, ce qui complique la preuve des réclamations faites à chaud. Deuxièmement, des travaux automatisés — relances, synchronisations, traitements différés — ne s’exécutent pas, parfois sans erreur visible : le dommage est silencieux et ne se révèle que plus tard, dans les chiffres de la semaine. Troisièmement, tout est documenté publiquement, heure par heure, par l’éditeur lui-même sur sa page de statut : cette transparence, précieuse pour établir les faits, n’équivaut ni à une reconnaissance de responsabilité ni à une promesse d’indemnisation, et il faudra articuler ces publications avec le contrat réellement signé.
B. Qui détient quelle preuve, et que faut-il figer maintenant
En matière d’indisponibilité logicielle, la preuve ne se reconstitue pas après coup : elle se fige pendant l’incident ou dans les jours qui suivent, car les journaux tournent, les pages de statut sont archivées et les souvenirs des équipes s’effacent. Le premier réflexe de tout professionnel exposé consiste à inventorier ce qu’il détient déjà et à sécuriser ce qui peut disparaître.
L’entreprise cliente détient d’abord la preuve interne de l’arrêt : journaux de connexion et codes d’erreur relevés par ses équipes, captures datées des écrans d’erreur, tickets internes du support informatique, attestations des commerciaux et des agents du service client sur les plages d’indisponibilité, relevés des commandes non saisies et des appels non traités. Elle détient ensuite la preuve externe fournie par l’éditeur : les publications horodatées de la page de statut, qu’il faut sauvegarder avec leur adresse et leur date de consultation, car elles constituent l’aveu technique de l’incident — début, périmètre, cause interne, étapes du rétablissement. Elle détient enfin la preuve de ses propres diligences : messages d’information à ses clients, bascule sur les procédures dégradées, mobilisation des équipes. Car chacun répond de son propre maillon : le client final qui n’a pas été livré ou rappelé se retournera contre son fournisseur direct, et ce fournisseur devra démontrer qu’il a tout fait pour limiter la casse.
Le partenaire — intégrateur, éditeur tiers, prestataire dont la solution s’appuie sur la plateforme — détient une couche supplémentaire : journaux d’appels aux interfaces de programmation, taux d’échec des requêtes, files d’attente des synchronisations, rapports de supervision de ses propres sondes. C’est cette couche qui permettra, le cas échéant, de démontrer que sa propre solution n’est pas en cause et que l’origine de l’interruption se situe bien chez l’éditeur de la plateforme. À défaut, le partenaire reste seul face à ses clients, sans recours praticable contre l’amont.
Sur la méthode probatoire, deux décisions récentes de la cour d’appel de Paris, pôle 5, chambre 11, spécialisée dans les contrats informatiques, tracent une ligne claire que tout professionnel devrait méditer avant de commander un constat. Dans l’affaire qui oppose la société BD Multi-Média à son prestataire Arkeup, jugée le 21 mars 2025, la cour écarte des constats d’huissier pourtant nombreux : « Ce procès-verbal de constat réalisé environ deux semaines après celui dressé à la demande de la société Arkeup aboutit à des conclusions opposées ce qui rend l’analyse comparée de ces deux pièces non probantes. » Et la cour ajoute qu’un constat dressé plusieurs mois après l’arrêt des prestations correctives et le refus de mettre en place la maintenance « ne permet pas de démontrer l’existence de dysfonctionnements bloquants ou semi-bloquants imputables à la société Arkeup ». La leçon vaut pour une panne de plateforme : un constat tardif, non contradictoire, établi longtemps après le rétablissement, ne prouvera rien contre l’éditeur. Ce qui prouve, c’est le faisceau contemporain — page de statut horodatée, journaux internes du jour même, échanges écrits avec le support pendant l’incident — complété, si l’enjeu le justifie, par un constat dressé à chaud, dans des conditions que l’adversaire ne pourra pas discuter.
Le code civil fixe au demeurant la règle du jeu : « 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. » Appliquée à la panne, cette règle se dédouble. Le client qui réclame des crédits de service ou des dommages-intérêts doit prouver l’inexécution — l’indisponibilité, sa durée, son périmètre — et son préjudice. L’éditeur qui prétend échapper à toute indemnisation doit justifier le fait libératoire qu’il invoque : force majeure, fait du client, ou application d’une clause limitative. Les contrats étant la loi des parties, tout commence par leur relecture : « Les contrats légalement formés tiennent lieu de loi à ceux qui les ont faits », rappelle l’article 1103 du code civil. Niveaux de service garantis, crédits contractuels, exclusions, plafonds de responsabilité, procédure de réclamation : c’est ce document, et lui seul, qui dira ce que la panne du 16 septembre ouvre comme droits.
II. La carte des décisions pour la chaîne : clients, partenaires et recours
A. Côté entreprises clientes : activer le contrat sans se mettre en faute
La première décision est souvent la plus rentable et la moins contentieuse : activer les crédits de service et les pénalités déjà stipulés au contrat. Les contrats de plateforme comportent presque toujours une annexe de niveaux de service qui associe à chaque taux de disponibilité un crédit — généralement un pourcentage de l’abonnement — et une procédure de réclamation avec un délai court, parfois trente jours. Le client qui laisse passer ce délai perd le bénéfice automatique, même si la panne est avérée. Le dossier doit donc partir vite : référence du contrat, plage d’indisponibilité établie par la page de statut et les journaux internes, calcul du crédit selon le barème contractuel, demande écrite au canal prévu. Lorsque le contrat stipule une pénalité, le code civil s’applique : « Lorsque le contrat stipule que celui qui manquera de l’exécuter paiera une certaine somme à titre de dommages et intérêts, il ne peut être alloué à l’autre partie une somme plus forte ni moindre. » Le juge peut modérer une pénalité manifestement excessive ou l’augmenter si elle est dérisoire, et « Sauf inexécution définitive, la pénalité n’est encourue que lorsque le débiteur est mis en demeure ». D’où l’importance, même pour une simple demande de crédit, d’écrire et de dater : la mise en demeure n’est pas une formalité de principe, c’est le point de départ des droits.
La deuxième décision concerne la pression à exercer si l’éditeur minimise l’incident ou si les conséquences s’aggravent — travaux planifiés perdus, données désynchronisées, clôtures mensuelles manquées. Le code civil offre une palette graduée à la partie victime d’une inexécution : « 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. » Suspendre le paiement de l’abonnement pour une panne de quelques heures serait disproportionné et dangereux ; en revanche, exiger un plan de reprise, la réexécution des travaux planifiés manqués et la correction des désynchronisations relève de l’exécution forcée en nature, parfaitement légitime. Et si l’inexécution est suffisamment grave — par exemple si la panne révèle une fragilité structurelle du service de connexion et se répète — la résolution entre en jeu : « 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 », dispose l’article 1224 du code civil.
La jurisprudence informatique montre comment les juges arbitrent ces sorties de contrat, dans un sens comme dans l’autre, et chaque camp devrait la lire avant d’écrire. Dans l’affaire Castelis, jugée par la cour d’appel de Paris le 27 janvier 2023, une association avait commandé pour 450 000 euros toutes taxes comprises une solution de gestion complète, avec mise en production promise pour septembre 2015. Après des reports successifs — septembre 2016, fin 2016, janvier 2017 — puis l’aveu écrit du prestataire sur ses propres manquements, l’association l’avait mis en demeure le 26 mai 2017 de tenir ses engagements sous huit jours, sous condition de résiliation, avant de dénoncer le marché le 27 juin 2017 en réclamant près de 98 000 euros de pénalités de retard. La cour infirme le jugement qui avait débouté l’association, et son dispositif est net : « Prononce la résiliation du marché aux torts de la société Castelis », avec « 67.500 euros au titre des pénalités de retard, » « 50.000 euros au titre du préjudice immatériel, » et « 5.000 euros au titre de l’atteinte à l’image ». La méthode qui fait gagner est donc documentée : mises en demeure écrites et graduées, délai raisonnable laissé au prestataire, résiliation motivée par des manquements graves établis, pénalités liquidées au contrat. Transposée à une panne de plateforme, la leçon est que la résolution unilatérale suppose une inexécution suffisamment grave et prouvée — une indisponibilité de quelques heures, réparée dans la journée, n’y suffira quasiment jamais à elle seule.
Reste l’argument que l’éditeur brandira presque sûrement : la force majeure. Il faut le prendre au sérieux et le démonter avec le texte. Aux termes de l’article 1218 du code civil, « 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. » Or la cause communiquée par l’éditeur lui-même — des requêtes bloquées sur son propre service interne de connexion, qui saturent ses propres serveurs — est par définition interne à son système et donc sous son contrôle. Un incident d’architecture chez le prestataire, prévisible dans son principe pour un opérateur professionnel et surmontable par redondance et capacité, remplit mal les trois critères cumulatifs. Et quand bien même l’empêchement serait admis, « 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 » : une suspension de quelques heures n’éteint ni l’abonnement ni les droits du client, elle les reporte. En pratique, la force majeure ne doit donc ni paralyser le client ni exonérer automatiquement l’éditeur : elle se discute critère par critère, texte en main.
Enfin, le client avisé prépare déjà la prochaine panne. Continuité et réversibilité ne sont pas des options techniques, ce sont des stipulations contractuelles à renégocier : exports réguliers des données dans un format exploitable, procédures dégradées écrites et testées, engagements de reprise avec délais mesurables, droit d’audit des incidents majeurs. La panne du 16 septembre, brève et documentée, est le meilleur moment pour les obtenir — quand le souvenir est frais des deux côtés de la table et avant que l’urgence ne retombe.
B. Côté partenaires et intégrateurs : assumer son maillon avant de se retourner
Le second étage de la chaîne est souvent le plus exposé et le moins préparé. L’intégrateur qui a vendu une solution adossée à la plateforme, l’éditeur tiers dont les connecteurs interrogent ses interfaces, le prestataire qui s’est engagé sur des délais de traitement : tous ont promis à leurs propres clients un résultat qui dépendait, ce jour-là, d’un service tiers en panne. Leurs clients ne connaissent qu’eux et les assigneront eux, pas l’éditeur américain. La règle d’or est donc d’assumer d’abord son propre maillon — informer, basculer en mode dégradé, réexécuter les traitements manqués, indemniser quand le contrat le prévoit — puis de se retourner contre l’amont, plutôt que d’opposer à son client une panne tiers qu’il n’a pas à subir.
Ce retournement obéit à trois conditions cumulatives que la jurisprudence rappelle sans indulgence. Premièrement, le lien de causalité entre la panne amont et chaque préjudice réclamé doit être démontré poste par poste. L’arrêt Arkeup du 21 mars 2025 est à cet égard une mise en garde : la société BD Multi-Média réclamait plus de 100 000 euros de coûts de redéveloppement et 365 200 euros pour l’effondrement de son chiffre d’affaires, mais la cour constate que ces sommes, faute d’éléments détaillés sur les prestations réalisées, n’apparaissent pas liées aux interventions du prestataire, et la déboute ; de la même façon, la baisse du chiffre d’affaires n’est étayée par aucun élément reliant l’absence de livraison de certains documents à la perte alléguée, et l’atteinte à l’image n’est ni étayée ni reliée aux manquements reprochés. Transposé à la panne du 16 septembre, cela signifie qu’un partenaire qui réclamerait à l’éditeur la marge perdue sur ses propres contrats devra produire, pour chaque client et chaque facture, la chaîne complète : indisponibilité constatée à heure dite, impossibilité technique d’exécuter, perte chiffrée et directement rattachée. Un préjudice global invoqué sans pièces sera rejeté, même si la panne est certaine.
Deuxièmement, les renonciations contractuelles se paient comptant. Dans cette même affaire, la cour relève que la société cliente avait renoncé aux pénalités de retard initialement prévues, en contrepartie de la mise en production et sous conditions, par un avenant — et la déboute en conséquence de sa demande de près de 39 000 euros de pénalités. Pour les partenaires Salesforce, le message est direct : tout avenant signé dans l’urgence de l’incident — prolongation gracieuse, geste commercial accepté, nouveau calendrier contre abandon des pénalités — peut éteindre définitivement les droits nés de la panne. On ne signe rien à chaud sans mesurer ce que l’on abandonne, et tout accord transactionnel partiel doit réserver expressément les droits non soldés.
Troisièmement, il faut distinguer l’incident de la violation. Certains partenaires découvriront à l’occasion de la panne des failles de sécurité ou des expositions de données chez eux ou chez leurs clients, et seront tentés d’en faire un grief supplémentaire. L’arrêt Arkeup douche cette tentation : confrontée à une fuite alléguée de données personnelles de 20 000 utilisateurs, la cour retient qu’« Il n’est cependant pas démontré que la faille, corrigée par Arkeup, ait été exploitée et que des tiers aient eu accès à la base de données », et conclut que « La violation du RGPD n’est donc pas caractérisée ». Une vulnérabilité corrigée et non exploitée n’est pas une violation constituée, et une panne sans perte de données n’est pas une atteinte aux données. Pour la panne du 16 septembre, où aucune compromission n’a été rapportée, les partenaires éviteront donc d’ajouter un volet protection des données artificiel à leur réclamation : il affaiblirait l’ensemble au lieu de le renforcer.
Reste la question que tout partenaire doit trancher avec son conseil : faut-il assigner l’éditeur ou négocier ? L’article 1231-1 du code civil dispose que « 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. » Mais les contrats de plateforme plafonnent presque toujours la responsabilité à quelques mois d’abonnement et excluent les préjudices indirects — précisément la marge perdue avec les clients finaux. Avant tout contentieux dont le coût dépasserait l’enjeu plafonné, le partenaire rationnel chiffre son préjudice recouvrable au contrat, compare avec le plafond, puis négocie : crédits étendus, prolongation sans frais, engagements de continuité renforcés pour l’avenir. L’assignation reste l’arme des cas graves — pannes répétées, inexécution durable, refus de tout geste — et elle se prépare comme l’ont montré les affaires citées : preuves contemporaines, mise en demeure, chiffrage poste par poste. Pour structurer cette stratégie de contrats imbriqués et de recours en chaîne, l’appui d’un accompagnement en droit des affaires des entreprises à Paris permet de calibrer chaque étage — client, partenaire, éditeur — sans engager un contentieux perdu d’avance contre un plafond contractuel.
Conclusion : une panne réparée, des décisions à prendre maintenant
La panne mondiale Salesforce du 16 septembre 2026 n’a duré que quelques heures et n’a détruit aucune donnée : à ce titre, elle est l’incident le moins grave qu’une chaîne professionnelle puisse subir. Elle n’en est pas moins un révélateur sans fard. Elle a montré aux entreprises clientes que leur outil vital peut s’arrêter en plein milieu d’une journée de vente, sans qu’elles disposent d’aucun levier direct sur le rétablissement. Elle a montré aux partenaires que leurs engagements envers leurs propres clients reposent sur un maillon qu’ils ne maîtrisent pas et dont ils répondent pourtant. Et elle a laissé, sur une page de statut publique, l’aveu horodaté de sa cause interne — une pièce que beaucoup de litiges informatiques n’ont jamais.
Les décisions utiles se prennent dans les jours qui viennent, pas dans six mois. Sauvegarder les preuves contemporaines avant que les journaux ne tournent. Réclamer les crédits contractuels dans les délais du SLA. Chiffrer la perte d’usage poste par poste, avec le lien causal pour chaque euro. Mettre en demeure quand l’inexécution laisse des séquelles, sans résoudre à la légère un contrat dont la rupture coûterait plus cher que la panne. Renégocier la continuité — exports, procédures dégradées, engagements de reprise — pendant que le souvenir est frais. Et pour les partenaires, assumer leur maillon face à leurs clients avant de se retourner contre l’amont, sans signer à chaud l’avenant qui éteindrait leurs droits. Une panne réparée n’est pas une panne sans conséquences : c’est une répétition générale offerte aux professionnels, à condition d’en tirer les décisions pendant qu’il est encore temps de prouver.
Besoin d’un avis rapide sur votre dossier
Votre CRM est tombé en panne en pleine journée de vente, vos connecteurs sont restés sans réponse, vos clients vous demandent des comptes pour un incident né chez votre éditeur : chaque situation appelle un avis rapide sur les crédits à réclamer, la mise en demeure à adresser et les preuves à figer. Maître Reda KOHEN, avocat au Barreau de Paris, reçoit en consultation téléphonique au 06 46 60 58 22 et répond aux demandes écrites via la page contact du cabinet.