Le 1er septembre 2026, une partie de la région Google Cloud us-central1, dans l’Iowa, a cessé de répondre normalement pendant plus de quatre heures. De 07h44 à 11h52 heure du Pacifique, soit de 16h44 à 20h52 heure de Paris, une quinzaine de services managés — dont Compute Engine, Google Kubernetes Engine, Cloud SQL, BigQuery et Cloud Run — ont subi ce que l’éditeur appelle une dégradation réseau doublée d’une isolation d’instances dans la zone us-central1-b. Pour les entreprises européennes qui hébergent leurs applications critiques sur cette zone, pour les intégrateurs qui les y ont installées et pour les clients finaux qui attendaient une livraison, un paiement ou une disponibilité contractuelle ce soir-là, la question n’est pas technique mais juridique et urgente : qui prouve l’interruption, qui supporte les retards qu’elle a causés en cascade, et quelles décisions prendre par écrit avant que les traces ne se dispersent.
La réponse tient en trois réflexes. Figer immédiatement les preuves de l’indisponibilité et de ses effets sur l’activité, parce qu’un droit non documenté est un droit affaibli et que le rapport d’incident rédigé par le seul prestataire ne suffit jamais à lui seul. Relire son propre contrat pour identifier les engagements de disponibilité, les crédits de service qui constituent souvent la réparation exclusive, et les plafonds d’indemnisation qui bornent tout recours. Puis agir par écrit : réclamer le crédit dans le délai de soixante jours prévu au contrat, mettre en demeure, informer les clients en aval et activer le plan de reprise, avant que les délais ne courent contre vous.
Deux réserves s’imposent avant d’entrer dans le détail, car elles conditionnent tout le raisonnement. D’abord, les faits sont rapportés d’après la fiche d’incident officielle de Google, consultée pour ce dossier, et d’après une synthèse technique mise à jour le 15 septembre 2026 ; la cause matérielle évoquée — des câbles de fibre optique débranchés pendant une opération de maintenance — vient de cette synthèse, l’éditeur n’ayant pas publié à ce jour de rapport post-mortem détaillé. Ensuite, chaque contrat cloud a ses clauses propres : les extraits du contrat de service cités ici sont ceux de l’offre Compute Engine, et votre contrat, vos avenants et vos accords de niveau de service peuvent différer. Les règles exposées sont vérifiées sur les textes en vigueur et sur des décisions lues intégralement ; leur application suppose de relire vos propres écrits et de dater chaque démarche. Ce qui suit est la carte des décisions, pas une promesse d’issue.
I. Une zone qui tombe : la panne du 1er septembre et ses trois dominos
Comprendre ce qui s’est réellement passé, heure par heure, puis identifier les trois acteurs que l’interruption frappe différemment : c’est le préalable sans lequel toute réclamation se perd dans l’approximation. L’infrastructure tombée n’est pas un logiciel applicatif, et cette différence change tout le régime des preuves et des recours.
A. Ce qui s’est passé le 1er septembre, et ce qui reste à vérifier
La chronologie officielle est précise. Selon la fiche d’incident publiée sur le tableau de bord officiel de Google Cloud, la perturbation a démarré le 1er septembre 2026 à 07h44 heure du Pacifique et s’est achevée à 11h52, soit une durée de quatre heures et onze minutes que la synthèse technique arrondit à quatre heures et huit minutes. Les clients dont les ressources étaient hébergées dans la zone us-central1-b ont subi des erreurs et une dégradation jusqu’à 11h52 heure du Pacifique. L’éditeur a classé l’événement comme une dégradation de service réseau accompagnée d’une isolation d’instances plutôt que comme une coupure totale, une nuance de vocabulaire qui a son importance pour les clauses de disponibilité contractuelle : dans les faits, des machines virtuelles sont devenues inaccessibles, des bases de données n’ont plus répondu et des traitements analytiques se sont interrompus pendant toute une fin de journée ouvrée en Europe.
La liste des produits affectés couvre un spectre large de l’offre : Compute Engine avec l’impossibilité d’accéder aux machines virtuelles du périmètre touché, Google Kubernetes Engine, Cloud SQL et AlloyDB, Cloud Spanner, Bigtable, BigQuery, Cloud Run. Autrement dit, ce ne sont pas seulement des sites vitrines qui ont disparu quelques heures, mais des chaînes entières de traitement : calcul, orchestration de conteneurs, bases transactionnelles et analytiques. Pour une entreprise qui avait concentré son système d’information sur cette seule zone, sans réplication multi-zone ni site de secours actif, l’interruption a été totale même si, vue de l’éditeur, elle restait partielle à l’échelle de la région.
Reste la cause, et c’est là que la prudence s’impose. La synthèse technique mise à jour le 15 septembre 2026 rapporte qu’un technicien aurait débranché des câbles de fibre optique pendant une opération de maintenance matérielle, provoquant la partition réseau de la zone. Google n’a pas publié de rapport post-mortem détaillé équivalent à ceux qu’il produit parfois après ses incidents majeurs, et la fiche officielle décrit les effets sans désigner publiquement un responsable. Retenez donc la distinction : les effets et leur durée sont établis par une source officielle, la cause matérielle ne l’est que par une source technique secondaire. En contentieux, cette distinction compte, car c’est à celui qui invoque la faute du prestataire d’en rapporter la preuve, et une synthèse de presse ne vaut pas aveu de l’éditeur.
Cette panne d’infrastructure ne doit pas être confondue avec la panne applicative mondiale qui a frappé un éditeur de logiciels de relation client le 16 septembre 2026, traitée séparément sur ce site. Là, c’était une matinée sans outil commercial dans le monde entier ; ici, c’est une fin de journée sans infrastructure dans une zone américaine, avec des conséquences différentes : là où l’utilisateur d’un logiciel applicatif subit et documente, le client d’une infrastructure doit aussi répondre de ses propres choix d’architecture, à commencer par l’existence ou non d’un plan de reprise. C’est cette responsabilité partagée qui fait toute la spécificité du dossier.
B. Trois acteurs frappés différemment : le client hébergé, l’intégrateur et le destinataire final
Le premier domino, c’est l’entreprise cliente qui a confié ses charges critiques à la zone tombée. Pour elle, le préjudice ne se résume pas à quatre heures d’écran noir : commandes en ligne non abouties, traitements de paie ou de facturation bloqués, données de télémétrie perdues, équipes mobilisées toute la soirée pour redémarrer et vérifier l’intégrité des bases. Chacun de ces postes devra être chiffré séparément, car le juge n’indemnise que des préjudices prouvés et, en matière contractuelle, en principe prévisibles lors de la conclusion du contrat. L’entreprise doit aussi interroger sa propre architecture : avait-elle répliqué ses instances sur plusieurs zones comme l’éditeur le recommande et le tarifie, avait-elle un plan de reprise testé, ses sauvegardes étaient-elles exploitables ? Ces questions ne sont pas rhétoriques : elles détermineront si une part du dommage lui est imputable et si son recours contre l’éditeur survit aux clauses du contrat.
Le deuxième domino, c’est l’intégrateur, l’infogéreur ou l’éditeur intermédiaire qui a vendu à son propre client une solution hébergée sur cette infrastructure. Lui se trouve pris en étau : responsable envers son client final de l’indisponibilité qu’il s’était engagé à éviter, et créancier d’un recours contre l’hébergeur dont les conditions plafonnent la réparation à des crédits de service. La jurisprudence des contrats informatiques connaît bien cette configuration. Dans une affaire jugée par la cour d’appel de Versailles le 19 mai 2022, un intégrateur avait confié en sous-traitance à un hébergeur les données de son client, une association ; après un incident sur les serveurs ayant entraîné une interruption du service et la perte des données comptables, c’est l’intégrateur qui a dû répondre devant son client avant de se retourner contre l’hébergeur. La chaîne contractuelle ne protège pas l’intermédiaire : elle l’oblige deux fois, une fois envers l’aval, une fois à prouver la faute de l’amont.
Le troisième domino, ce sont les destinataires en aval : les clients de l’entreprise hébergée qui n’ont pas été livrés, les usagers d’un service en ligne resté muet, les partenaires dont les flux d’échanges ont été rompus. Eux n’ont aucun contrat avec l’hébergeur et ne peuvent agir que contre leur propre cocontractant, qui ne pourra pas leur opposer la panne de son prestataire comme une excuse automatique. C’est l’un des points les plus mal compris des défaillances en chaîne : la panne du fournisseur de votre fournisseur n’est pas, pour vous, un cas de force majeure qui effacerait vos propres engagements. Chacun répond de ses promesses envers son voisin contractuel, puis exerce son recours vers l’amont dans la limite de son propre contrat. D’où l’importance, pour l’entreprise hébergée, d’informer ses clients en aval par écrit et sans tarder : ce courrier d’information, daté et précis, servira à la fois à limiter l’aggravation du dommage et à prouver sa diligence.
II. Qui prouve quoi, qui paie quoi : le droit de la panne d’infrastructure
Une fois la carte des acteurs dressée, le raisonnement juridique suit un ordre impératif : d’abord les preuves, car sans elles aucun droit ne prospère ; ensuite la réparation, car le contrat cloud organise et borne les recours d’une manière que le droit commun des contrats éclaire mais ne remplace pas.
A. Figer les preuves : le statut officiel, vos journaux, et jamais le seul rapport du prestataire
Le principe est posé par l’article 1353 du code civil : « 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é à la panne du 1er septembre, ce texte se dédouble. C’est à l’entreprise cliente de prouver l’inexécution, c’est-à-dire l’indisponibilité du service pendant la plage litigieuse et le manquement aux engagements de disponibilité ; et c’est au prestataire qui invoque une cause d’exonération — fait du client, obsolescence, cas fortuit — d’en rapporter la preuve. Chacun doit donc constituer son dossier, et le plus tôt est le mieux, car les journaux techniques s’écrasent et les souvenirs du soir de la panne s’estompent.
Concrètement, le dossier de preuves comporte quatre pièces. La première, c’est la fiche d’incident officielle de l’éditeur, horodatée, qui établit la fenêtre d’indisponibilité et le périmètre des services touchés : capturez-la, datez la capture, conservez son adresse. La deuxième, ce sont vos propres journaux : fichiers de logs montrant les périodes d’indisponibilité avec leurs dates et heures, relevés de supervision, tickets d’incident ouverts auprès du support, échanges avec vos équipes. La troisième, c’est la mesure de vos effets : commandes perdues, pénalités versées à vos propres clients, heures de remédiation, constats ponctuels si l’enjeu le justifie. La quatrième, c’est votre architecture : cartographie des zones utilisées, preuve de la réplication ou de son absence, date du dernier test de votre plan de reprise.
L’avertissement majeur vient de la jurisprudence : le rapport rédigé par le seul prestataire ne suffit jamais à établir sa propre exonération. Dans l’affaire de l’hébergeur jugée à Versailles, l’hébergeur n’avait produit que le compte-rendu qu’il avait personnellement rédigé pour soutenir que l’indisponibilité venait des logiciels obsolètes du client ; la cour a relevé qu’il « ne produit en effet que le compte-rendu qu’elle a personnellement rédigé, alors même que nul ne peut se fournir de preuve à lui-même », et la cour en a déduit un manquement caractérisé à l’obligation contractuelle de garantie de rétablissement en quatre heures, confirmant le jugement sur la responsabilité de l’hébergeur pour l’incident du 28 juin 2017. Symétriquement, ne vous contentez pas de votre propre récit : corroborez chaque affirmation par une pièce extérieure, car le juge écarte les attestations unilatérales non étayées.
Deux diligences procédurales complètent le tableau. D’une part, le contrat de service impose en général de réclamer vite et avec les journaux : le contrat Compute Engine prévoit ainsi que le contrat de service Compute Engine de Google Cloud impose au client de notifier le support technique dans les soixante jours de l’ouverture du droit au crédit et que ce même contrat exige la production des journaux établissant les périodes d’indisponibilité avec leurs dates et heures, sous peine de perdre le droit au crédit. Manquer ce délai de soixante jours ou réclamer sans journaux, c’est perdre le crédit avant même tout débat. D’autre part, si l’inexécution persiste ou si vous envisagez de rompre, la mise en demeure préalable reste le passage obligé sauf urgence : l’article 1226 du code civil exige qu’elle mentionne expressément qu’à défaut d’exécution, le créancier sera en droit de résoudre le contrat, et c’est au créancier de prouver ensuite la gravité de l’inexécution. Écrivez donc tôt, écrivez précis, écrivez avec accusé de réception.
B. Obtenir réparation : crédits exclusifs, plafonds, résolution et part de responsabilité du client
L’arsenal du créancier d’une obligation inexécutée est large. L’article 1217 du code civil dispose que « 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 ». Mais dans le contrat cloud, cet arsenal se heurte à deux bornes contractuelles qu’il faut lire avant de chiffrer : le crédit de service comme réparation exclusive, et le plafond d’indemnisation.
Première borne : le crédit comme seule réparation de l’indisponibilité. Le contrat de service stipule que le contrat de service Compute Engine de Google Cloud fait du crédit financier la réparation exclusive de tout manquement aux objectifs de disponibilité. Tant que le manquement reste une simple indisponibilité couverte par l’accord de niveau de service, le client ne peut donc prétendre qu’aux crédits calculés sur la redevance, à l’exclusion de dommages et intérêts complémentaires. La leçon pratique est double : réclamez le crédit dans les formes et délais, car c’est un droit quasi automatique dès lors que la mesure est établie ; et ne confondez pas ce crédit avec la réparation de vos préjudices d’exploitation, qui suppose de sortir du champ du seul accord de disponibilité, par exemple en démontrant une faute distincte du prestataire ou un manquement à une autre obligation, comme le devoir de conseil ou la sécurité des données.
Deuxième borne : les plafonds et exclusions. Les contrats d’hébergement plafonnent couramment la responsabilité à quelques mois de redevances et excluent les préjudices indirects tels que pertes de revenus ou de clientèle. Ces clauses sont en principe valables entre professionnels, et les juges les appliquent lorsqu’elles ont été acceptées, même tacitement par référence expresse dans les conditions particulières signées. Dans l’affaire versaillaise, la cour a ainsi jugé qu’« il n’y a donc pas lieu de réputer non-écrite la clause limitative de responsabilité figurant dans les conditions générales, celle-ci devant produire son plein effet », au motif que l’obligation essentielle restait une disponibilité à 99,5 %, les incidents relevant des 0,5 % résiduels ayant été envisagés par les parties, et elle a ramené l’indemnisation de 64 629,60 euros demandés à 8 497,20 euros, soit trois mois de prestations. Le même arrêt ajoute une règle précieuse pour les dominos : les services interrompus et jamais repris ne se facturent pas, et le prestataire a été condamné à émettre un avoir annulant la facture postérieure à l’interruption. Vérifiez donc vos factures des mois de septembre et suivants : toute période sans service doit être créditée ou contestée.
Ces plafonds connaissent toutefois deux limites. D’une part, la prévisibilité : l’article 1231-1 du code civil ouvre les 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 », tandis que l’article 1231-3 cantonne en principe la réparation aux dommages prévus ou prévisibles, « sauf lorsque l’inexécution est due à une faute lourde ou dolosive ». La cour d’appel de Paris a fait application de cette réserve le 25 novembre 2022 en évaluant à 17 178,90 euros le préjudice subi du fait de la faute lourde d’un prestataire informatique, par compensation avec les sommes dues en sens inverse. Une défaillance grossière dans la gestion de l’incident — absence d’alerte, restauration négligée, manquement caractérisé au devoir de conseil — peut ainsi rouvrir ce que le plafond semblait fermer, à condition de prouver la faute lourde, ce qui suppose plus qu’une simple indisponibilité.
D’autre part, la résolution reste ouverte en cas d’inexécution suffisamment grave. L’article 1224 du code civil prévoit que « 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 ». La cour d’appel de Paris l’a illustré le 19 septembre 2025 dans un contrat de téléphonie et de services : la promesse de garantie de rétablissement sous quatre heures figurant dans l’offre détaillée, acceptée avec le bon de commande, faisait partie du périmètre contractuel, et ses violations répétées ont justifié de « CONSTATE la résolution du contrat liant la société Voxtel et la société Entretien Maintenance Services aux torts de la société Voxtel », avec restitution des sommes versées et prise en charge des frais de résiliation. Transposée au cloud, la méthode vaut mise en garde : une panne isolée de quatre heures, même fautive, justifie rarement à elle seule la rupture d’un contrat pluriannuel, sauf clause résolutoire expresse visant les seuils de disponibilité ; en revanche, des engagements de rétablissement bafoués de façon répétée et documentée peuvent fonder une résolution, judiciaire de préférence pour un enjeu de cette taille.
Reste la question que tout client en aval posera : la panne de mon prestataire m’exonère-t-elle envers mes propres clients ? La réponse est non, sauf à démontrer une force majeure dans votre propre contrat. L’article 1218 du code civil ne retient la force majeure que pour « 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 ». Or une interruption de quelques heures d’un fournisseur cloud, dont les accords de niveau de service annoncent eux-mêmes des taux de 99,9 % et non de 100 %, est prévisible dans son principe, et ses effets pouvaient être atténués par des mesures appropriées : réplication multi-zone, bascule automatisée, sauvegardes testées. Le client qui n’avait prévu aucune redondance aura donc les plus grandes difficultés à invoquer la force majeure contre ses propres clients, et il répondra des retards en cascade avant de se retourner vers l’amont. Symétriquement, une indisponibilité régionale de quatre heures ne constitue pas pour l’éditeur une force majeure l’exonérant de ses engagements de disponibilité : ses propres contrats l’obligent à des crédits, preuve que les parties avaient envisagé l’incident.
Cette part de responsabilité du client se double, pour les données personnelles, d’obligations réglementaires. Le règlement général sur la protection des données impose au responsable du traitement et au sous-traitant de mettre en œuvre des mesures garantissant notamment « 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 » 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 ». Il exige aussi de ne faire appel qu’à « des sous-traitants qui présentent des garanties suffisantes quant à la mise en œuvre de mesures techniques et organisationnelles appropriées », et encadre la sous-traitance en chaîne puisque « Le sous-traitant ne recrute pas un autre sous-traitant sans l’autorisation écrite préalable, spécifique ou générale, du responsable du traitement ». Pour l’intégrateur qui héberge des données personnelles de clients sur une zone unique sans reprise testée, la panne du 1er septembre n’est donc pas seulement un incident commercial : c’est le révélateur d’un écart de conformité qu’il devra documenter et corriger, registre des traitements et analyse d’impact à l’appui, sous peine de voir sa propre responsabilité recherchée en cas de contrôle ou de plainte.
Un dernier signal de jurisprudence, tout récent, confirme que les juges n’hésitent pas à condamner les grands prestataires lorsque le dossier est établi : le 3 septembre 2026, le tribunal des activités économiques de Nanterre a condamné un opérateur national à payer 40 000 euros à une société de services informatiques, avec 4 000 euros au titre des frais irrépétibles. La minute consultée ne détaille pas les motifs, et l’on ne peut donc en tirer aucune règle générale ; mais le montant rappelle qu’un contentieux prestataire bien documenté se chiffre en dizaines de milliers d’euros, et non en avoirs symboliques. Pour passer de cette carte générale à votre dossier particulier, avec ses journaux, ses clauses et ses montants, l’appui d’un conseil qui pratique ces contentieux fait gagner un temps que les délais de réclamation ne pardonnent pas, comme le propose l’accompagnement en droit des affaires à Paris du cabinet pour les entreprises confrontées à la défaillance d’un prestataire. Les soixante jours du crédit de service courent depuis le 1er septembre : vos droits se jouent dans les écrits que vous adressez dans les prochaines semaines.
Conclusion : une fenêtre, trois dossiers, une méthode
La panne de la zone us-central1-b entre dans sa phase contentieuse : les faits sont établis par la fiche officielle, la cause matérielle reste à consolider, et le délai de soixante jours pour réclamer les crédits de service court jusqu’au début du mois de novembre 2026. D’ici là, chaque acteur doit tenir son propre dossier. L’entreprise hébergée fige ses preuves, relit son accord de niveau de service, réclame le crédit avec ses journaux, met en demeure si l’inexécution persiste et informe ses clients en aval pour contenir la cascade. L’intégrateur répond à son client sans attendre l’issue de son propre recours, documente la faute de l’amont par des pièces extérieures et vérifie ses propres engagements de disponibilité et de sécurité des données. Le prestataire en aval, enfin, chiffre chaque poste de préjudice et distingue ce qui relève du crédit automatique de ce qui suppose une faute prouvée.
Cette méthode dépasse le seul cas de l’Iowa. Qu’il s’agisse d’une zone cloud, d’un logiciel applicatif mondial ou d’un hébergeur historique, la grammaire est la même : l’incident se prouve par des pièces extérieures et datées, le contrat borne la réparation par des crédits et des plafonds que seule une faute caractérisée permet de dépasser, et chacun répond envers son voisin avant de se retourner vers l’amont. La panne du 1er septembre a surtout révélé une vérité d’architecture : en 2026, confier ses charges critiques à une zone unique sans reprise testée, c’est accepter par avance quatre heures d’arrêt dont le coût restera très largement à votre charge.
Besoin d’un avis rapide sur votre dossier
Vous êtes entreprise cliente d’un prestataire cloud, intégrateur ou prestataire hébergé, et vous devez décider quoi réclamer et quoi écrire après l’interruption du 1er septembre 2026. Maître Reda KOHEN, avocat au Barreau de Paris, reçoit en consultation téléphonique pour un premier avis sur votre dossier. Joignez le cabinet au 06 46 60 58 22 ou écrivez via la page contact pour exposer votre situation et vos délais.