Un retard COD BESS compte parmi les surprises les plus coûteuses du développement de stockage, et les dates de mise en exploitation commerciale manquées sont bien plus fréquentes que ce que supposent les plannings de mise en service.
Et pourtant, chaque projet BESS que j’ai examiné repose sur un planning de mise en service qui suppose qu’il sera achevé dans les temps.
Le secteur sait que les retards sont courants. Les développeurs le savent. Les EPC aussi. Et pourtant, chaque projet part du principe qu’il battra les statistiques, puis ne le fait pas.
Il ne s’agit pas d’incompétence. La mise en service d’un BESS est réellement plus exigeante que celle d’une centrale solaire seule, avec davantage de régimes d’essais, davantage de dépendances séquentielles et davantage d’interlocuteurs réglementaires. Mais plus exigeant ne signifie pas imprévisible. Les cinq causes racines expliquent la grande majorité des échecs de COD des BESS, elles sont identifiables des semaines à l’avance et elles peuvent être maîtrisées.
Motif 1 : versions de firmware BMS non concordantes
C’est la défaillance de mise en service la plus courante propre aux BESS, et elle est presque toujours découverte trop tard.
La mise en service du système de gestion de batterie (BMS) exige de valider la logique de contrôle du BMS au niveau des cellules. Pour un BESS à l’échelle d’un parc avec des dizaines de milliers de cellules, cette étape prend beaucoup de temps. Lorsque le firmware des modules livrés ne correspond pas à la version des contrôleurs BMS du site, chaque module concerné doit être mis à jour et réessayé.
Une non-concordance de firmware détectée lors de la mise en service sur site plutôt qu’à la réception des équipements peut générer entre 7 et 14 jours de reprise. Sur un projet ayant déjà consommé 60 jours de marge de planning à cause de retards en amont, 14 jours signifient un échec de COD.
La solution consiste en une vérification du firmware avant mise en service, lancée dès que les bons de livraison des équipements sont confirmés. L’agent de renseignement sur les risques de mise en service compare les versions de firmware BMS déclarées aux spécifications de configuration des contrôleurs du site. Dès qu’un écart apparaît dans les bons de livraison, l’alerte est émise immédiatement, avant l’installation des équipements et non après. L’agent fonctionne sur la plateforme d’IA agentique pour le solaire et le stockage de ClearSpot, aux côtés des agents O&M.
Motif 2 : erreurs de séquence des relais de protection
Le raccordement au réseau exige la mise en service séquentielle des relais de protection. Les fonctions de protection à maximum de courant, différentielle, de défaut à la terre et spécifiques au stockage doivent être réglées, testées et acceptées par le gestionnaire de réseau dans un ordre défini.
Le mode de défaillance tient à des réglages de relais corrects isolément mais incompatibles avec la configuration de réseau propre au gestionnaire. Les gestionnaires de réseau actualisent leurs spécifications de mise en service, parfois chaque année. Les projets conçus selon la spécification de l’année précédente se heurtent à ce mur lors de l’essai de réception.
Le point est d’autant plus délicat que l’incompatibilité n’est pas toujours visible dans les réglages eux-mêmes. Elle se trouve dans l’exigence de séquence. Un ingénieur qui a correctement configuré des relais sur 15 projets précédents les configurera correctement sur celui-ci, selon la spécification qu’il connaît, qui n’est peut-être pas la version en vigueur.
Comment l’agent le prévoit : il croise les exigences de spécification des relais figurant dans l’offre de raccordement avec les réglages des relais de protection consignés dans les registres de mise en service.
Lorsque des écarts existent, il crée une action corrective et en assure le suivi jusqu’à sa résolution, avant que l’essai de réception du gestionnaire de réseau ne soit programmé.
Non pas comme un point de liste de contrôle qu’un humain coche, mais comme un recoupement automatique qui tourne en continu à mesure que les registres de mise en service sont mis à jour.
Motif 3 : retards dans la certification du système d’extinction incendie
Les installations BESS nécessitent la certification du système d’extinction incendie avant l’autorisation d’exploiter, l’acceptation du raccordement au réseau et la plupart des polices d’assurance. Cela suppose une inspection par un tiers, réalisée par un ingénieur sécurité incendie accrédité.
Le problème structurel est que, dans de nombreuses juridictions européennes, les inspecteurs accrédités en sécurité incendie pour BESS ont des délais de réservation de 4 à 8 semaines. Un projet qui programme l’inspection incendie en semaine 40, alors que le premier inspecteur accrédité disponible est en semaine 46, accumule un retard structurel de COD de 6 semaines, visible dès la semaine 20, mais seulement si quelqu’un suit la disponibilité des inspecteurs.
Personne ne suit systématiquement la disponibilité des inspecteurs. C’est une contrainte de ressources qui ressemble à un retard technique.
L’agent de renseignement sur les risques de mise en service traite la certification du système d’extinction incendie comme une piste de risque distincte, avec un modèle de délais fondé sur les données régionales de disponibilité des inspecteurs. Lorsque le planning de mise en service fait apparaître la certification en semaine 40, l’agent vérifie la disponibilité et signale si le modèle de délais indique que la date réaliste est la semaine 46. Il le fait en semaine 24, et non en semaine 39.
Motif 4 : lacunes dans les essais de conformité au code de réseau
La conformité au code de réseau pour les BESS se complexifie. La réponse en fréquence, la capacité de puissance réactive, le contrôle de rampe, la capacité de réalimentation à froid (black start) pour certains contrats et la capacité de formation de réseau (grid-forming) pour les BESS de grande taille les plus récents exigent des essais formels selon les spécifications du gestionnaire de réseau.
Le mode de défaillance est simple : un essai de conformité échoue, typiquement la capacité de puissance réactive ou la précision de la réponse en fréquence, et toute la séquence repart à zéro. Le gestionnaire de réseau reprogramme l’ensemble de la batterie d’essais de conformité, et pas seulement l’élément défaillant. Cela ajoute 3 à 6 semaines, quelle que soit la rapidité de résolution du problème technique.
La piste des essais de conformité réseau requiert sa propre gestion des risques, distincte de la piste de mise en service physique. Sur la plupart des projets, c’est le même ingénieur de mise en service qui gère tout le reste. Sur un projet où la levée des réserves, le paramétrage des relais de protection et la certification incendie sont simultanément en difficulté, les essais de conformité réseau ne reçoivent pas l’attention ciblée dont ils ont besoin tant que quelque chose ne cède pas.
Pour le contexte réglementaire et de conformité réseau plus large en Europe, SolarPower Europe et les lignes directrices O&M de l’IEA PVPS sont deux références faisant autorité sur la manière dont l’évolution des exigences des codes de réseau transforme la complexité de la mise en service des projets à grande échelle.
Motif 5 : documentation incomplète au stade du dossier de raccordement
C’est la défaillance des mille petites coupures. Aucun élément n’est catastrophique pris isolément. Ensemble, ils repoussent la date de l’essai de réception de 2 à 3 semaines.
Le dossier de documentation préalable à la mise en service exigé par le gestionnaire de réseau comprend des schémas unifilaires as-built à la révision en vigueur, des fiches de réglage des relais de protection avec gestion de version, des certificats de performance du BESS, la certification incendie, les fiches techniques du système de gestion de l’énergie et les plans d’essais de conformité réseau. Chaque élément a une spécification de format. Tout élément au mauvais format, à la mauvaise révision ou sans une signature requise est rejeté, et le dossier doit être resoumis.
De nombreux projets à grande échelle soumettent ce dossier plus d’une fois avant acceptation, et chaque nouvelle soumission est un retard qui aurait pu être évité.
L’agent de renseignement sur les risques de mise en service contrôle en continu l’exhaustivité de la documentation au regard des exigences du dossier du gestionnaire de réseau, non pas au moment de la soumission seulement, mais tout au long de la phase de mise en service. Il signale les problèmes de format et les éléments manquants alors qu’il est encore possible de les corriger sans retarder la fenêtre de soumission.
Le fil conducteur
Les cinq modes de défaillance sont tous prévisibles. Aucun n’exige du recul pour être identifié. Ils exigent un système qui suive simultanément les cinq dimensions de risque de la mise en service, en continu, et qui alerte assez tôt pour que l’on puisse agir.
Le maillage de ClearSpot associe des agents d’IA autonomes pour l’O&M et la mise en service à des drones autonomes. Pour les BESS, la validation thermique par drone de l’état de pré-mise en service, au niveau des racks et du système, détecte les anomalies thermiques qui provoqueraient des échecs de mise sous tension avant le début de la séquence d’énergisation. La même approche a ensuite détecté un point chaud opérationnel sur un BESS en avance, et après la COD la référence de mise en service alimente directement le logiciel de supervision des BESS.
Le guide des bonnes pratiques O&M photovoltaïques du NREL renforce le même principe que celui qui s’applique à la mise en service : une supervision structurée et continue du risque à l’échelle du système est le seul moyen fiable d’éviter des événements de défaillance techniquement visibles avant de devenir financièrement lourds.
Les pénalités de retard (liquidated damages) sur les projets BESS à grande échelle s’accumulent généralement pour chaque jour de retard. Un seul glissement de COD évité rembourse donc souvent plusieurs fois la supervision continue de la mise en service.
Les probabilités ne sont pas difficiles à calculer.
Réflexion finale
Lequel de ces cinq modes de défaillance avez-vous le plus souvent rencontré sur les projets BESS auxquels vous avez participé, et qu’est-ce qui a fini par le révéler ?
Questions fréquentes
C’est un décalage de la date de mise en exploitation commerciale (COD) d’un projet de stockage par batteries, généralement causé par des problèmes de mise en service, de certification, de conformité réseau ou de documentation découverts tardivement.
Les non-concordances de version de firmware BMS comptent parmi les causes les plus courantes de retard de mise en service d’un BESS.
Ils exigent davantage d’essais séquentiels, davantage d’interdépendances et davantage d’étapes de conformité réseau.
Oui. Les non-concordances de firmware, les lacunes de séquence des relais, les délais de certification incendie, le risque sur les essais de conformité réseau et les lacunes de documentation sont visibles des semaines à l’avance lorsque les registres de mise en service sont suivis en continu.
Les agents d’IA de ClearSpot recoupent les registres de mise en service avec les spécifications, suivent le risque lié à la certification et à la documentation, et déclenchent la validation thermique par drone avant l’énergisation.