France's 0.055 euro per gigabyte data tax: does a sovereign cloud still protect you?

No, a French sovereign cloud does not protect you from this tax. Amendment I-1358 taxes the gigabytes a company sends to subscribers of French internet providers, whoever hosts the servers and wherever they sit. OVHcloud, Scaleway, AWS, Google Cloud and Azure traffic would all be counted the same way. At 0.055 euro per gigabyte, that is 55 euros per terabyte delivered, about 70% of Azure's egress list price from France Central and five and a half times Scaleway's Object Storage egress price. On OVHcloud, where outbound traffic is included, it would be a new cost on bytes that are free today.

One correction before anything else. Much of the early commentary calls this a tax on stored data. The text taxes flows. Your backups, archives and data lakes sitting at rest are outside the base. The bytes you push to French households and offices are inside it.

As of November 3, 2026. This is a live legislative text and it may change or disappear within weeks.

Key points:

• A sovereign cloud does not exempt you. The tax applies to « flux de données numériques émises par les fournisseurs de contenu » (data flows sent by content providers), measured by French ISPs on the traffic reaching their customers (Assemblée nationale, amendment I-1358). Provider nationality and server location play no part in it.
• It is not law. The Assemblée nationale adopted the amendment on October 30, 2026 by 11 votes to 10, against the advice of both the budget committee and the government (compte rendu). The revenue half of the 2027 budget bill has not been voted yet, and if it gets rejected, the Sénat starts again from the government's original text without this amendment (LCP).
• The arithmetic is linear: 55 euros per TB delivered, 5,500 euros per 100 TB and 55,000 euros per PB. The cap is 15% of French revenue or 2% of worldwide revenue.
• Legal incidence sits on the sender of the data. Economic incidence lands on customers. OVHcloud's founder already says his company would have to collect the tax « et donc répercuter sur nos clients » (and therefore pass it on to our customers) (Next.ink).
• The hedges that work are fewer bytes delivered and a platform you can move. Choosing a provider by nationality does nothing here. Qovery runs your apps inside your own cloud account on AWS, GCP, Azure, Scaleway or your existing Kubernetes cluster, so you can still change providers if pass-through terms end up differing.

What exactly did France's National Assembly vote on, and is it law yet?

On October 30, 2026, the Assemblée nationale adopted amendment I-1358 to the projet de loi de finances pour 2027. The amendment creates a "taxe sur les producteurs de données numériques" of 0.055 euro per gigabyte of data that content providers send to customers of French internet access providers. It is not law today. The amendment passed 11 to 10, with 35 deputies taking part in the vote (compte rendu).

The text was filed by Laurent Lhardit and the Socialistes et apparentés group. It would add articles 302 bis ZP to 302 bis ZS to the Code général des impôts (amendment I-1358). Here is what it actually says:

• Base: data flows sent by content providers to subscribers of French ISPs. ISPs measure the volumes, identify the sender, and report quarterly to the tax administration (DGFiP) under the supervision of the telecoms regulator Arcep.
• CDNs: when a sender uses a content delivery network, the taxable quantity equals the CDN's outgoing flows. Caching at the edge does not reduce the bill.
• Rate and cap: 0.055 euro per gigabyte, capped at 15% of the sender's French revenue or 2% of its worldwide revenue.
• Payment: groups with a French entity pay alongside corporate income tax. Others pay by March 30 of the following year.

The sponsors' exposé claims a 10 billion euro yield. It bases that on an Arcep estimate of 200 billion gigabytes a year delivered to French ISP subscribers, half of it from Google, Meta, Amazon, Netflix and Akamai. The stated goals are fiscal fairness between companies rooted in France and globalised digital players, plus an ecological benefit from better compression.

The text leaves a lot undefined. It sets no de minimis threshold and no exemption for small or non-profit senders. It does not say how traffic to hosting and data centre connections is treated, and it does not explain how a cloud host's traffic gets split among its customers. All of that is left to a décret.

Here is the path from here, for readers outside France:

1. The Assemblée must finish and vote the revenue part.
2. The Sénat reads the bill.
3. A commission mixte paritaire tries to reconcile the two versions.
4. The government may force adoption with article 49.3, keeping only the amendments it chooses.
5. The Conseil constitutionnel reviews the result.
6. The law is published in the Journal officiel.

LCP expects the revenue part to be rejected. In that case the Sénat would receive the government's original text without any of the adopted amendments (LCP). Bandwidth taxes have been proposed and dropped before, and Next.ink lists several earlier attempts (Next.ink). Check the amendment's status on assemblee-nationale.fr before you act on any of this.

Who actually pays the 0.055 euro per gigabyte, the provider or the customer?

Legally, the sender of the data pays the tax, and French ISPs only measure and report it. In practice, whoever sits upstream bills it to their customers: the exposé itself says transit providers and CDNs « leur refacturent ou non la taxe selon leurs conditions de ventes » (re-bill it to their clients or not, according to their terms of sale).

The open question for anyone running on a cloud is who counts as "the sender". The text has ISPs identify senders by their network registration, which in practice is the autonomous system announcing the traffic. If your SaaS runs on OVHcloud, AWS or Scaleway, the traffic leaves from your provider's network. That means your provider is the most likely entity to be assessed first, and you are the most likely to receive the invoice line after that.

Octave Klaba, OVHcloud's founder, put a number on it. OVHcloud sends about 324 Gbps on average to French ISPs, and he estimates the gross tax at 70 million euros a year, or 23 to 70 million euros after the cap, « que nous devrions collecter pour l'État, et donc répercuter sur nos clients » (which we would have to collect for the State, and therefore pass on to our customers) (Next.ink).

France has run this experiment before. The 3% taxe sur les services numériques, created by the law of July 24, 2019 (Légifrance), was meant for big platforms, and the platforms passed it on. Amazon raised its French marketplace referral fees by 3% from October 1, 2019, "pour refléter le coût de la Taxe sur les services numériques" (Amazon Seller Central, archived). Google added a 2% "France Regulatory Operating Cost" to Google Ads invoices from May 1, 2021, and it rises to 3% on January 1, 2027 (Google Ads Help).

That DST mostly hit advertising and marketplaces. I found no notice of a French DST surcharge on AWS cloud invoices (AWS Tax Help), so treat cloud pass-through as untested. The precedent still points one way: when a platform holds pricing power, the customer pays.

The workloads that get hit are the ones that deliver bytes to people in France: video and audio streaming, software, game and app updates, image-heavy e-commerce and media sites, SaaS front ends with heavy JavaScript bundles, and file sharing.

Backups, archives, data lakes, ML training sets, inter-region replication and database snapshots stay outside the base, because they never travel to an ISP subscriber.

This turns the usual storage-cost thinking around. Tiering data down to Glacier changes nothing, while every gigabyte served to a French browser costs money.

How much would the French data tax actually cost at 1 TB, 100 TB and 1 PB?

At 0.055 euro per gigabyte, the tax scales linearly with the volume delivered to French ISP subscribers: 55 euros per TB, 550 euros per 10 TB, 5,500 euros per 100 TB and 55,000 euros per PB, before any provider markup and below the 15% / 2% revenue cap.

The text applies a per-gigabyte rate to measured volume and reports quarterly, so the table below assumes monthly delivered volume, decimal units (1 TB = 1,000 GB), and no cap.

The comparison that matters is the price you already pay for those same bytes. Here is the tax next to current first-paid-tier internet egress list prices from French regions:

On Azure France Central, the tax would add the equivalent of 70% of an egress price that is already high, and AWS and Google Cloud land in the same range once you convert currencies. On OVHcloud and Scaleway, which built their pricing around cheap or included bandwidth, it adds a cost that did not exist before.

Storage at rest is untaxed. A gigabyte in S3 Glacier Deep Archive in Paris costs $0.0018 a month (AWS price list) and owes nothing. The same gigabyte downloaded once by a French household would owe 0.055 euro, about thirty times its monthly storage price.

For a concrete profile, take a mid-size B2C SaaS serving 40 TB a month to French users through a CDN. That works out to 2,200 euros a month, or 26,400 euros a year, as a new budget line. A B2B API company sending 2 TB a month would pay 110 euros a month and hardly notice.

Why is OVHcloud objecting if the tax hits American hyperscalers too?

OVHcloud objects because the tax is provider-neutral. A flat charge per gigabyte delivered hits hardest the providers whose business model includes bandwidth in the price, and those are mostly the European ones. Klaba wrote that the tax « crée une distorsion de concurrence au détriment des acteurs nationaux et déclasse les entreprises qui embauchent en France » (distorts competition against domestic players and penalises companies that hire in France) (Next.ink).

Xavier Niel, founder of iliad, the group that owns Scaleway, was blunter on X: « Ce sont des ignares incompétents » (They are ignorant incompetents) (Next.ink). I could not find on-record positions from Numeum, France Digitale, Cigref or France Datacenter at the time of writing.

The government's own minister backed OVHcloud's reading in the chamber. David Amiel said half of the tax, « soit tout de même 5 milliards d'euros » (still 5 billion euros), would fall not on big tech but « sur des fournisseurs de contenus de plus petite taille, notamment sur des fournisseurs français » (on smaller content providers, notably French ones) (compte rendu).

The asymmetry shows up clearly in the financials. OVHcloud reported 1,145.1 million euros of revenue and 77.8 million euros of EBIT, a 6.8% margin, for the fiscal year ended August 31, 2026 (OVHcloud FY2026 results). Klaba's 23 to 70 million euro estimate therefore equals roughly 30% to 90% of OVHcloud's annual operating profit. AWS posted $45.6 billion of operating income on $128.7 billion of sales in 2025, a 35% margin (Amazon Q4 2025 results). AWS can absorb a new line on that margin, and OVHcloud cannot.

This is the sovereignty paradox. A levy designed to make global platforms pay lands hardest on the French hosts that industrial policy is trying to grow.

The counter-argument deserves a fair hearing. The sponsors argue that taxing large platforms on self-declared profit has failed, and that bytes delivered on French soil make a base that cannot be moved offshore. They also argue that pricing volume pushes senders to compress harder. Lhardit told the chamber the design avoids the problems that sank similar attempts in Canada and South Korea (compte rendu). I understand the fairness goal. I think the base is wrong, because it taxes delivery itself rather than the platforms' profits.

I found no other EU member state with a per-gigabyte traffic or storage tax. If the text survives, France would likely be the first. I cannot confirm that against an authoritative EU-wide register, so treat it as my reading rather than a fact.

Will moving to OVHcloud or Scaleway let me avoid the French data tax?

No. Sovereignty is a legitimate reason to choose OVHcloud, Scaleway, Outscale or Clever Cloud, but it gives no protection against this tax, because the tax follows bytes delivered to French ISP subscribers rather than the nationality or location of the company sending them. Moving your servers to Frankfurt or Dublin does not help either. The exposé calls the base « non délocalisable » (impossible to move offshore) on purpose.

Teams buy sovereign cloud for three real reasons, and this tax touches none of them:

• exposure to the US CLOUD Act and other extraterritorial jurisdiction
• GDPR data residency
• public procurement and certification rules

The only things that change your bill are sending fewer bytes to French users, staying under the revenue cap, or a de minimis threshold if the final text adds one. Relocating would not just fail to reduce the bill. For health data under HDS, SecNumCloud-qualified workloads, and public sector or defence contracts, it would break the reason you chose a French provider in the first place.

Everyone serving French users inherits the same new line, so cut the bytes you deliver and keep your options open. Do not re-platform for tax reasons.

What should engineering teams do in 2026 to prepare for a per-gigabyte data tax?

Treat it as a FinOps and architecture problem, not a procurement one. Three moves cover it: measure the bytes each service delivers to French users, cut those bytes, and make sure you could move or split workloads without a six-month migration.

1. Measure first. Most teams cannot say how many gigabytes they send to French end users, broken down by service. Pull CDN logs and load balancer egress per hostname, and geolocate by ASN.
2. Cut bytes at the source. Use Brotli or zstd compression, AVIF or WebP images, and smaller JavaScript bundles. Tune video bitrate ladders, ship delta updates instead of full downloads, and set long Cache-Control lifetimes so browsers stop re-downloading. CDN edge caching does not reduce the taxable volume under this text, but browser caching does.
3. Read your contracts. Ask your cloud provider and your CDN in writing how they would pass the tax through, at what granularity, and whether they would absorb any of it. Their answers will differ.
4. Build portability now. Use infrastructure as code, Kubernetes-native workloads, S3-compatible APIs instead of proprietary storage calls on the hot path, and no hard dependency on one region.
5. Budget two scenarios for 2027. Plan for the text as voted and for the text dropped. Decide in advance which high-egress services you would re-architect under the first.

Cleaning up non-production environments and old snapshots is still good FinOps, but it barely touches this tax, because test environments deliver almost nothing to French ISP subscribers.

How does Qovery help when cloud tax and residency rules change under you?

Qovery runs your applications inside your own cloud account on AWS, GCP, Azure, Scaleway, or your existing Kubernetes cluster, so the provider and region underneath your platform become configuration choices instead of a rewrite. A moving tax regime calls for exactly that optionality, and you can build it before the text is final.

• BYOC: your account, your bill, your residency. The cloud contract, the invoice, committed-use discounts and data location stay in your name. If a provider adds a French data tax line, you see it on your own invoice and can compare it across providers.
• Cloud-agnostic and Kubernetes-native. The same git-push deployment flow works on a Paris region, another EU region, a French sovereign provider, or hardware you already run. Qovery supports AWS, GCP, Azure, Scaleway and your own Kubernetes cluster equally.
• Footprint hygiene. Ephemeral preview environments per pull request and auto-stop for non-production environments cut idle spend whether or not this tax passes.
• A small team can run it. Per-environment RBAC and managed cluster upgrades mean you do not need a dedicated DevOps hire to operate on two providers.

To be fair about the limits: Qovery does not remove the tax, is not a tax-avoidance tool, and does not reduce the bytes your users download. It removes the migration cost of reacting when providers pass the tax through on different terms. Data gravity is still real, and moving petabytes stays slow and expensive whatever tooling you use. That is why the byte-reduction work comes before the portability work.

How do I audit my environments with Qovery from Claude Code or Cursor?

Install the Qovery Agent Skills once and your coding agent can inspect environments, stop idle ones and set up self-cleaning preview environments, asking for explicit approval before it changes anything. Four commands cover installing for all agents, installing for one project, read-only access and write access.

Install globally for every compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI):

curl -fsSL https://skill.qovery.com/install.sh | bash

Scope the install to a single project instead:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the Qovery MCP Server to Claude Code with OAuth. It is read-only by default, so the agent can look without touching:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you want the agent to act. This also requires turning on write access in the Qovery Console:

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills split the work: qovery-onboard, qovery-deploy, qovery-optimize for cost and footprint, qovery-preview for ephemeral environments, qovery-troubleshoot, qovery-speedup and qovery-terraform. Skills deploy, and the MCP Server operates what already exists. Then ask in plain language, for example: "list every environment that has not been deployed in 30 days and stop the non-production ones". Setup details are in the AI agent quickstart and the Claude Code integration page.