Les obligations de grid-forming transforment les spécifications d’onduleurs en clauses de risque financier

« Grid-forming mandatory » peut passer pour une note technique en bas de page. Ce n’est pas le cas. C’est un transfert de responsabilité.

Quand un régulateur impose des onduleurs grid-forming pour le stockage à grande échelle, comme le fait aujourd’hui le Portugal en lançant un appel d’offres de 1 GW et en s’appuyant sur des BESS pour renforcer la fiabilité, l’onduleur cesse d’être une boîte qui “suit” le réseau. Il devient un élément de la stabilité du réseau lui-même (Portugal makes grid-forming mandatory for large-scale BESS and launches 1GW tender).

Cette seule phrase change quatre sujets en même temps :

• Ce que vous devez spécifier (pas seulement la performance, mais le comportement sous contrainte).
• Ce que vous devez démontrer (pas uniquement au FAT/SAT, mais via une chaîne de preuves qui résiste aux audits et aux réclamations).
• Ce que « conforme au grid code » veut réellement dire dans un langage d’achats.
• Qui supporte l’impact économique quand le réseau demande de la stabilité plutôt que des revenus.

Si vous traitez ces points comme des chantiers séparés, vous livrerez une centrale conforme… mais commercialement fragile. Vous « passerez » et vous perdrez quand même de l’argent.

1) Le changement concret : d’un produit de capacité à un produit de comportement

La plupart des projets achètent encore un onduleur comme une machine de capacité : MW entrants, MW sortants, quelques points de facteur de puissance, une courbe de réponse, on signe, et on passe au sujet suivant.

Une obligation de grid-forming impose un autre modèle mental. Le réseau dit, en substance : « Votre BESS fait désormais partie de mes équipements de stabilisation. » C’est un contrat de comportement.

La spec ne peut donc pas s’arrêter aux puissances nominales. Elle doit décrire le comportement de l’installation quand le système se dégrade :

• Formation de tension et de fréquence : pas seulement les réglages de droop, mais la façon dont le droop transitionne, sature et revient à l’équilibre.
• Fault ride-through avec intention : rester connecté ne suffit pas si le mode de contrôle devient instable en conditions de réseau faible.
• Gestion des modes : comment et quand le contrôleur bascule entre grid-forming et grid-following (et qui a le droit de le modifier).
• Limites d’oscillation et d’interaction : les boucles de contrôle de votre centrale vont rencontrer celles d’autres convertisseurs. « Ça marche au labo » n’est pas une spécification.
• Attentes sur le black start et l’ilotage (si applicable) : pas comme des arguments marketing, mais comme des séquences testables avec des critères de succès mesurables.

La raison est simple. Dès que l’onduleur devient un outil de stabilité, un « petit » choix de contrôle se transforme en responsabilité majeure. Un ajustement de tuning qui augmente l’amortissement peut aussi réduire le throughput d’énergie ou augmenter les pertes. Vous avez alors un arbitrage commercial caché derrière un paramètre de contrôle.

2) Ce qui doit changer dans vos specs : les écrire comme des outils d’incident

La plupart des spécifications techniques ressemblent à un achat sur catalogue. En grid-forming, vos specs doivent être écrites comme si vous vous prépariez à un litige.

Je m’appuie sur le même principe que dans la livraison logicielle : le document n’est pas là pour avoir l’air intelligent, il est là pour réduire le temps de rétablissement quand quelque chose se passe mal. Si la spec ne vous aide pas à diagnostiquer un événement réseau six mois après la COD, elle est incomplète.

Voici la checklist “terrain” que j’appliquerais avant de publier les employer’s requirements ou la spec fonctionnelle de l’onduleur.

Checklist spec : le minimum qui change avec le grid-forming

• Définir l’enveloppe de robustesse du réseau dans laquelle vous prévoyez d’opérer (conditions de réseau faible, hypothèses de SCR, hypothèses sur le bruit harmonique). Si vous ne la posez pas, vous hériterez du « typical » du fournisseur.
• Exiger une performance sous contraintes : temps de réponse, temps d’établissement, limites de dépassement, comportement de reprise, pas seulement des courbes de droop en régime permanent.
• Imposer un modèle de gouvernance des paramètres de contrôle : qui peut changer les réglages, ce qui doit être revalidé, et ce qui constitue un « changement significatif ».
• Spécifier les points de mesure et l’échantillonnage : quels signaux sont enregistrés, à quelle fréquence, avec quelle synchronisation temporelle, et pendant combien de temps les données sont conservées.
• Inclure les attentes d’interaction : comportement lorsque plusieurs actifs grid-forming opèrent en parallèle, y compris anti-islanding, partage de puissance et marges de stabilité.
• Définir la logique de derating : que se passe-t-il aux limites de température, de SOC ou de courant convertisseur. Le soutien à la stabilité entre souvent en concurrence avec la marge thermique.
• Mettre les seuils pass/fail dans le document, pas dans un slide deck. « Démontrer un fonctionnement stable » n’est pas un critère.

Si cela vous paraît lourd, tant mieux. L’obligation est lourde. Elle vous fait passer de « vendre de l’énergie et de la capacité » à « vendre un comportement correct sous contrainte ».

3) FAT et SAT : arrêter de les traiter comme des cérémonies

Factory acceptance et site acceptance sont des moments où les projets se mettent à s’enliser : trop tard pour changer le design, trop tôt pour observer le comportement réel du réseau, et beaucoup de formulations de réception ambiguës.

Le grid-forming rend le FAT/SAT plus critiques, mais aussi plus risqués, car tout le monde sera tenté de cocher des cases qui ne correspondent pas à la réalité du système.

Le changement n’est donc pas « ajouter plus de tests ». Le changement, c’est de construire une chaîne de preuves qui relie trois niveaux.

• Preuves par modèle : des simulations qui couvrent l’enveloppe d’exploitation spécifiée, avec perturbations et sensibilités aux paramètres.
• Preuves par contrôleur : HIL ou équivalent, démontrant que le logiciel de contrôle fait ce que le modèle affirme.
• Preuves par centrale : un SAT qui prouve que l’installation telle que construite correspond aux signaux, latences et limites supposés.

C’est là que beaucoup d’équipes se font exposer. Elles ont un modèle impeccable et un SAT “passable”, mais le lien entre les deux manque. Quand l’opérateur réseau questionne ensuite la performance, vous ne pouvez pas démontrer l’équivalence entre ce que vous avez vendu et ce que vous avez construit.

Checklist FAT : ce que je rajouterais ou renforcerais

• Jeu de perturbations : pas de fréquence, pas de tension, sauts de phase, émulation de réseau faible et séquences de retour. Pas un seul « happy path ».
• Balayage de paramètres : démontrer la stabilité sur une plage autorisée de droop et d’inertie virtuelle, pas uniquement sur un point réglé.
• Preuves de latence et de timing : timing des boucles de contrôle, des communications et des déclenchements. Le grid-forming est sensible au timing.
• Répétition de la capture de données : prouver que la centrale produit les logs dont vous aurez besoin ensuite, avec des timestamps corrélables aux événements réseau.

Checklist SAT : ce qui doit être non négociable

• Validation “as-built” des hypothèses : polarité CT/VT, scaling, alignement des comptages, synchronisation temporelle, coordination des protections. De petites erreurs de câblage ou d’échelle ressemblent à de « l’instabilité de contrôle ».
• Préparation à l’analyse d’événements : démontrer que les event logs survivent à un déclenchement, un reboot et une coupure de communication. Les preuves doivent tenir même quand ça casse.
• Tests de perturbation contrôlée quand c’est autorisé : suffisamment pour valider la dynamique, pas seulement l’export/import en régime permanent.
• Complétude du package de handover : baselines de réglages, checksum ou versioning, et un processus clair de delta pour les futurs ajustements.

Un enseignement vécu : j’ai déjà vu une équipe cross-functional perdre des semaines parce que personne ne pouvait répondre, après un incident terrain, à une question basique : « Quelle version de contrôle tourne réellement sur site ? » Pas la version approuvée. Pas la version envoyée par e-mail. Celle qui tourne. C’est dans ce vide que naissent les réclamations.

4) La conformité au grid code devient un problème de « droit à prouver »

Avant, conformité voulait dire : passer un test, obtenir un certificat, l’archiver. Le grid-forming vous pousse vers une preuve continue.

Puisque le réseau s’appuie sur votre comportement pour gérer la stabilité, vous devez partir du principe que les preuves seront questionnées. Pas par malveillance. Les opérateurs système et les prêteurs ne supportent pas l’ambiguïté quand la fiabilité est en jeu.

Votre dossier de conformité doit être construit comme un raisonnement défendable :

• Traçabilité : chaque clause de grid code que vous revendiquez doit pointer vers un test, un résultat et une configuration “as-built”.
• Maîtrise de configuration : si les réglages changent, votre statut de conformité est soit maintenu par règle, soit explicitement revalidé.
• Capacité d’analyse post-incident : vous pouvez reconstruire ce que la centrale a fait pendant une perturbation, avec des logs fiables.

C’est le même réflexe que « prouver son innocence » dans les supply chains logicielles modernes. Si vous ne pouvez pas prouver ce que vous avez exécuté et ce que cela a produit, vous négociez en position de faiblesse. Si ce sujet vous parle, le même schéma apparaît ailleurs : your right to prove innocence est un avantage concurrentiel, pas de la bureaucratie.

5) Le déplacement contractuel : le soutien à la stabilité crée de nouveaux impacts négatifs

C’est la partie que l’on évite, parce qu’elle est inconfortable. Une obligation de grid-forming déplace les risques. Si vous ne les nommez pas explicitement, ils atterriront chez la partie la moins capable de les piloter — souvent le propriétaire du projet.

Trois catégories de risque apparaissent immédiatement :

• Risque de performance : la centrale n’arrive pas à délivrer le comportement dynamique requis dans toutes les conditions, même si elle respecte les ratings en régime permanent.
• Risque de curtailment ou de dispatch : l’opérateur système limite le throughput d’énergie pour préserver la stabilité ou gérer la congestion. Les revenus bougent.
• Risque de changement : l’interprétation du grid code évolue, des mises à jour firmware interviennent, les réglages sont retunés, et l’installation « telle que mise en service » n’est plus celle « telle que financée ».

Qui doit porter quoi ?

Ma position : attribuez chaque impact négatif à la partie qui peut en réduire la probabilité et le coût. Si le fournisseur contrôle le firmware et la méthode de tuning, il ne doit pas partir à la COD en haussant les épaules. Si le propriétaire pilote la stratégie d’enchères marché, c’est son sujet. Si l’opérateur système change les règles de dispatch, vous avez besoin d’événements de relief explicites.

Checklist contrat : clauses que je rouvrirais systématiquement

• Définir la « conformité grid-forming » comme des livrables mesurables, pas comme une promesse de « respecter le grid code ». Alignez-la sur les mêmes critères de test que dans la spec.
• Critères de réception liés aux preuves : ce qui déclenche la réception finale, et quelles données doivent être remises pour l’étayer.
• Liquidated damages qui reflètent le comportement dynamique : pas seulement la disponibilité, mais l’incapacité à fournir la réponse requise dans des conditions définies.
• Change control sur les réglages et le firmware : qui autorise, qui teste, qui paie, et ce qui arrive aux garanties après changement.
• Événements de relief sur curtailment et dispatch : règles claires indiquant quand une opération contrainte compte comme indisponibilité (en général, elle ne devrait pas) et quand elle déclenche une compensation dans les termes d’offtake.
• Responsabilité des interactions : si l’instabilité vient d’interactions avec d’autres actifs réseau, définir comment on établit la cause racine et comment on finance les actions correctives.

La plupart des litiges ne portent pas sur la physique. Ils viennent de frontières mal écrites. Si vous voulez aller plus loin sur le moment du handover, cela se rattache directement à who owns performance risk after the battery is commissioned?

Ce que je ferais ce trimestre si le grid-forming devenait obligatoire

Je ne commencerais pas par acheter un autre onduleur. Je commencerais par resserrer la chaîne entre intention, preuve et argent.

1. Réécrire les employer’s requirements autour du comportement : définir l’enveloppe, les perturbations et des attentes de reprise mesurables.
2. Concevoir le dossier de preuves avant l’achat : matrice de traçabilité, exigences de logging, règles de contrôle de version, et livrables de données pour la réception.
3. Faire du FAT/SAT une séquence de preuve connectée : du modèle au contrôleur, puis à la centrale, avec des vérifications d’équivalence explicites.
4. Rééquilibrer le contrat : attribuer les impacts de performance, de changement et de curtailment aux parties capables de les atténuer.

Les obligations de grid-forming sont une bonne nouvelle pour la fiabilité. Elles sont aussi un piège pour ceux qui continuent de traiter la conformité au grid code comme une case à cocher. L’onduleur fait désormais partie de la stabilité du réseau. Votre documentation et votre allocation de risques doivent intégrer cette réalité — ou le réseau s’en chargera plus tard, sous forme de revenus perdus et de réclamations douloureuses.