Un centre de données peut-il accepter de réduire sa consommation d'énergie ?
On March 19, 2026, Google announced an unusual kind of energy resource.
It was not a new power station, transmission line, or battery. It was 1 GW of electricity demand that Google had agreed could be limited or shifted under contracts with several U.S. utilities.
A gigawatt is a large number. In this case, the more interesting fact is what the number does not mean.
Google did not promise to switch off an entire gigawatt of data centers whenever the grid asked. Nor did the announcement represent a gigawatt-hour of energy saved. It referred to demand-response capacity incorporated into long-term utility agreements, using selected machine-learning workloads that Google says can be reduced or moved during certain periods.
The company presents those agreements as one way to connect new data centers before every planned generation and grid investment has been completed. Google’s announcement also acknowledges that flexibility has limits and will be available only at certain locations.
This is the bargain now attracting utilities, regulators, and data-center operators.
The grid gains a defined right to ask for less demand when capacity is scarce or the system is under pressure. The data center may gain something in return, such as an earlier connection, a different tariff, direct compensation, or access to capacity that would otherwise remain unavailable.
But data centers sell availability.
Demand response asks which part of that promise is negotiable.
The grid is buying a change in behavior
Demand response is sometimes described as energy efficiency.
The two are related, but they do different jobs.
Energy efficiency reduces the electricity needed to provide the same service. A more efficient server, cooling system, or power supply can lower demand whenever it operates.
Demand response changes when or how much electricity a consumer uses because the grid, market, or price sends a signal.
Lawrence Berkeley National Laboratory divides demand flexibility into three broad actions: shedding, where demand falls for a period; shifting, where consumption moves to another time; and modulating, where demand changes repeatedly or more gradually in response to system needs. Its demand-flexibility program applies those ideas across buildings, transport, industry, and data centers.
For a data center, the difference might look like this.
A more efficient GPU completes the same work with less electricity. That is efficiency.
A batch job waits until later in the night, when the grid has more capacity. That is load shifting.
A group of processors temporarily operates below its normal power limit. That is load reduction or modulation.
A battery supplies part of the facility for an hour, reducing what the site draws from the grid. The computing demand may remain unchanged, but the grid sees a smaller load.
These mechanisms can be combined. They should not be treated as equivalent.
A job moved to 3 a.m. still has to run. The energy was shifted, not necessarily eliminated.
A power cap may lower demand while making the job take longer.
A battery can reduce grid demand immediately, but it eventually has to be recharged and may also be needed for resilience.
The grid is not buying a vague promise that the data center will be helpful.
It is buying a measurable change in electricity use under defined conditions.
A data center contains several kinds of flexibility
From outside the fence, a data center can look like one large electrical load.
Inside, it contains workloads with different deadlines, hardware with different operating limits, cooling and power systems, batteries, storage, networking, and equipment kept ready for failures or sudden demand.
Each layer offers a different kind of flexibility.
The most valuable layer may be the computing work itself.
Some workloads have little room to move. Search, payments, communications, medical services, live inference, and other customer-facing systems may need to respond immediately. Moving or slowing them can break latency targets, service agreements, or essential operations.
Other work has slack.
A video-processing task may need to finish by morning but not begin at a particular minute. A model evaluation can sometimes wait. Rendering, data preparation, simulations, backups, and parts of machine-learning development may tolerate a delayed start or slower execution.
The useful resource is the time between when the job could run and when it must finish.
Google began using that margin in 2020, shifting non-urgent tasks toward hours when lower-carbon electricity was more available. It later extended the approach geographically, moving suitable media-processing work between data centers where data, privacy, capacity, and operational conditions allowed. The company’s examples included processing for YouTube, Photos, and Drive rather than the real-time services users expect continuously.
The hardware creates another option.
Processor power can be capped. Clock speeds can be reduced. A training job can run more slowly or, where its software supports it, pause at a checkpoint and continue later.
These actions do not come free.
Stretching a job may delay the next one. Pausing a large distributed training run can leave expensive hardware idle and may require a coordinated restart across many machines. Lowering processor power can reduce peak demand while increasing the time needed to complete the work.
A third layer sits in the facility itself.
Cooling systems, batteries, and on-site power equipment can change what the grid sees even when the workload does not move. Berkeley Lab identifies four main routes for data-center flexibility: computational load management, adjustments to facility infrastructure, energy storage, and on-site generation. Its 2026 review of AI data centers and the power grid treats them as complementary mechanisms rather than one universal solution.
Cooling has only limited room for improvisation. Temperatures can sometimes be managed across a short event using thermal inertia, control changes, or stored cooling, but the system must keep equipment within safe operating conditions. Reducing fan, pump, or compressor demand is not useful if the servers overheat five minutes later.
Our article on how data-center cooling systems work follows that physical constraint from the processor to the final heat-rejection equipment.
Batteries can respond much faster than most workloads. But a battery installed to carry critical systems through an outage may not have its full capacity available for regular grid services. Using it for demand response changes its state of charge, cycling, degradation, and readiness for the event it was originally installed to handle.
The flexible resource is therefore not “the data center.”
It is a carefully selected combination of workload slack, hardware control, thermal margin, stored energy, and operating permission.
The service promise sets the limit
A job scheduled to finish by 6 a.m. has flexibility only while that deadline remains safe.
Suppose it needs four hours of computation.
If it enters the queue at 8 p.m., the operator can delay it for two hours without changing the result delivered to the customer. A demand-response request arriving at 9 p.m. can use some of that margin.
A second request at 1 a.m. creates a different problem. The spare time may already be gone.
This is why a data center cannot offer the grid a fixed percentage of flexibility without understanding the work scheduled inside it.
The same facility may have substantial flexibility one day and almost none the next.
A training cluster nearing a deadline behaves differently from one beginning a non-urgent experiment. An inference service during a quiet period behaves differently from the same service during a traffic spike. A backup job can move until delaying it starts to threaten the recovery objective it exists to support.
Geographical movement introduces another set of limits.
A workload can run elsewhere only if another site has suitable hardware, available capacity, network access, the required data, compatible software, and permission to process the information there.
Moving a small, stateless task is one thing. Moving a large job whose working data spans petabytes is another.
Data location and jurisdiction may prevent movement even when the technical system allows it. Network transfer can also consume time, energy, and money. A destination that looks flexible at the grid level may fail the workload’s latency or security requirements.
This is where an electrical problem becomes a distributed-systems problem. Hivenet’s guide to distributed cloud architecture explains why workload placement depends on state, data, networking, failure handling, capacity, and operating responsibility rather than available hardware alone.
The question is never simply whether compute can move.
It is what must move with it.
A fast demonstration does not establish lasting flexibility
In 2026, EPRI Europe reported the results of a UK demonstration involving National Grid, Emerald AI, Nebius, NVIDIA, and EPRI.
According to EPRI, the pilot reduced the power demand of a high-performance AI data center by as much as 30% to 40% within seconds without disrupting critical workloads. The demonstration matters because it shows that substantial, rapid response is technically possible in at least one real operating arrangement.
It does not mean every AI data center can shed 40% on demand.
A pilot can establish response speed and technical feasibility under its test conditions. A commercial flexibility service needs more.
How long can the reduction last?
How often can it happen?
What was the facility doing before the event?
Which workloads were protected?
What happens to the delayed computation afterward?
Can the same response be delivered during peak customer demand?
How much advance notice is required?
Does the data center retain the same capability after its hardware, workload mix, or occupancy changes?
Google’s 1 GW announcement has a similar boundary.
One gigawatt of contracted demand-response capacity is evidence that utilities and a major operator are willing to build flexibility into long-term agreements. It is not evidence that the full gigawatt has already been dispatched simultaneously, how often it will be available, or how much energy the arrangements will shift over a year.
Those answers require operational records.
ENTSO-E now describes data centers as systemically relevant electricity users and is studying how their flexibility might support grid operation and market participation. Its May 2026 report presents flexibility as a potential role that requires new connection practices and operational coordination, not as a capability the sector can already take for granted.
The distinction matters because electricity systems need resources they can rely on, not flexibility that appears only when convenient.
A grid operator planning around 50 MW of response needs confidence that the load will move when called.
A data-center operator needs confidence that answering the call will not break the service being sold to customers.
The contract sits between those two forms of reliability.
Most of the product is in the fine print
A serious data-center demand-response agreement has to define more than the number of megawatts.
It needs a baseline. The parties must agree what the facility would have consumed without the event. Otherwise, there is no stable way to calculate how much demand was actually reduced.
It needs a response time. A day-ahead instruction, a 15-minute warning, and an automated signal requiring action within seconds describe different technical services.
It needs a duration. A battery may cover a short event. A delayed workload may move for several hours. Neither necessarily supports a prolonged shortage.
It needs a frequency limit. A data center may tolerate a few events each year and reject a contract that allows daily interruption.
It needs to address the rebound. Work delayed during an event may return later, creating a new peak if every job restarts at once.
It needs measurement and verification. The utility must see what changed, while the operator must preserve appropriate security and confidentiality around facility and workload data.
It needs priority rules. Safety, cooling, storage integrity, essential services, and customer commitments may be excluded from reduction.
And it needs an agreed allocation of cost and risk.
Who pays if the data center cannot deliver the promised reduction?
Who carries the cost of idle accelerators, delayed jobs, additional battery cycling, or migrating work to another site?
What does the data center receive for accepting a less-firm connection or offering capacity to a market?
Could frequent events reduce hardware life or undermine the economics of the facility?
EPRI’s DCFlex program has reviewed 159 flexible-load tariffs from 71 U.S. utilities, covering interruptible service, demand response, standby power, and related arrangements. The variety is evidence that “data-center flexibility” has not settled into one standard commercial product. Utilities are still deciding what they need, what they will pay for, and how to verify delivery.
European rules are evolving too. ACER submitted a proposed EU-wide network code on demand response in March 2025, intended to improve access to electricity markets for flexible consumers, storage, and distributed resources. ACER still identifies inconsistent national rules, market barriers, and weak price signals as obstacles to participation.
The technology is only part of the work.
Flexibility becomes useful when it can be bought, dispatched, measured, and trusted.
An earlier grid connection comes with a different right to power
The commercial attraction becomes clearest where connection capacity is scarce.
A traditional firm connection is intended to give the customer access to its contracted electrical capacity under the agreed service conditions. Building enough network infrastructure to support that right can take years.
A flexible or non-firm arrangement changes the bargain.
The customer may connect earlier or avoid waiting for every reinforcement to be completed, while accepting that its demand can be limited under specified network conditions.
The International Energy Agency now recommends that system operators explore non-firm grid connections and incentives for data-center demand response as tools for accelerating connections and using existing infrastructure more effectively. It presents them as bridges while slower generation and grid investments proceed, not replacements for those investments.
That distinction protects both sides from a misleading story.
Demand response does not create electrical capacity from nothing.
It changes the reliability right attached to part of the load.
A data center that signs a flexible connection is agreeing that some of its maximum demand does not have the same claim on the grid at every moment.
Whether that is commercially sensible depends on the workload and contract.
A facility serving delay-tolerant batch work may find the exchange attractive. A site dominated by services with strict latency and availability guarantees may have much less to offer. A mixed facility may divide its electrical envelope, keeping one portion firm while allowing another to respond.
This is why the headline power rating of a data center does not reveal its operational relationship with the grid.
Two facilities may each have a 100 MW connection.
One expects firm access to almost all of it.
The other has agreed that 20 MW can be limited during defined periods.
The nameplate number is identical.
The right to consume it is not.
The work comes back
Demand response is often illustrated as a clean dip in a load curve.
Demand falls. The grid event ends. The line returns to normal.
Computing makes the second half more complicated.
If a workload was canceled permanently, its energy may disappear.
If it was made more efficient, less energy may be needed to complete it.
If it was delayed, the work remains in the queue.
The operator then has to decide how quickly to catch up. Restart everything immediately and the delayed demand can create a rebound peak. Restart gradually and customer deadlines may come under pressure.
Geographical shifting can move the rebound elsewhere rather than remove it from the wider system.
A data center that reduces load during a constrained evening may perform the work overnight, when electricity is cheaper or more plentiful. That is useful even if total energy remains similar, because grid costs and reliability often depend heavily on the highest-demand hours.
The same logic connects demand response with renewable energy curtailment. Moving suitable work toward hours of strong wind or solar output can help align demand with generation.
But timing has to match.
A demand-response event called during a network emergency is not automatically a renewable-energy strategy. A job shifted away from one peak may run during another carbon-intensive period. A facility responding to local congestion may produce little change in total system emissions.
The purpose of the event needs to remain clear.
Reliability, connection capacity, energy price, renewable integration, and emissions are related goals.
They are not interchangeable outcomes.
Flexibility cannot be bolted onto the container
For Policloud, the useful principle is straightforward.
Physical modular infrastructure can be evaluated at an energy, industrial, municipal, or other defined site. The available power, grid connection, workload, networking, cooling, storage, ownership, regulation, and operating model shape whether that deployment fits.
That does not make a Policloud unit flexible demand by default.
Flexibility would have to be designed into the actual deployment.
The electrical agreement would need to define which part of the connection is firm and which may be limited.
The workload owner would need to identify which services can slow, stop, or move.
The operating team would need control systems and telemetry capable of delivering and verifying the response.
Any battery or on-site energy system would need rules protecting its primary operational role.
Commercial agreements would have to allocate the cost of interruption, delay, migration, idle hardware, and non-delivery.
And the software layer would have to enforce those decisions without confusing physical capacity with permission to use a workload elsewhere.
A modular deployment may make the conversation easier to bound. Capacity can be considered in increments, and each increment can be assessed against the power rights and operating constraints available at the site.
Whether that produces useful grid flexibility remains a site-level question.
Policloud’s current energy-producer guidance explicitly prevents proximity to generation or the presence of suitable infrastructure from being treated as proof of demand response, avoided curtailment, grid support, or environmental benefit. Those outcomes require a defined mechanism, operating evidence, and owner approval.
The commercial proposition is therefore narrower than “the data center becomes a battery.”
It is also more credible.
A deployment can be designed so that electricity availability and workload behavior are considered together before the operating promises are fixed.
That is where real flexibility begins.
The grid is buying the margin around the workload
A data center does not become flexible because someone installs a switch beside the meter.
The useful resource is the margin inside its operations.
The minutes between when a job could start and when it must start.
The distance between normal processor power and the lowest level that preserves the deadline.
The battery capacity available after resilience requirements have been protected.
The computing capacity available at another site after data, latency, jurisdiction, and customer commitments have been considered.
The difference between the maximum connection and the part that needs an uninterrupted right to power.
That margin changes from hour to hour.
Cela a également un prix.
Le réseau ne demande pas au centre de données de renoncer à sa fiabilité. Il demande à l'opérateur de définir quelle partie de sa demande peut faire l'objet d'un engagement de fiabilité différent.
Pour le centre de données, la décision est tout aussi concrète.
Quelle flexibilité peut être vendue sans vendre la même capacité deux fois ?
À quelle fréquence la charge de travail peut-elle être déplacée avant que les performances, la rentabilité du matériel ou la confiance des clients n'en pâtissent ?
À quoi est-on prêt à renoncer en échange d'un accès prioritaire à l'énergie ?
Et qui décide lorsque la demande entre en conflit avec la charge de travail ?
Un centre de données flexible n'est pas un centre que l'on peut simplement éteindre.
C'est un centre qui sait, avant même que le réseau ne le sollicite, exactement ce qui peut être déplacé, pour combien de temps, sous quelle autorité et à quel coût.
