La disponibilité technique nationale des bornes de recharge, telle qu’elle est mesurée par les flux de données remontés en temps réel par les superviseurs, plafonne autour de 93 %. La disponibilité technique nationale des bornes de recharge plafonne autour de 93 %. Le règlement AFIR (Alternative Fuels Infrastructure Regulation) en impose 95 % sur les corridors TEN-T (Trans-European Transport Network). Un écart de deux points qui peut sembler marginal, mais qui représente, à l’échelle d’un parc de plusieurs centaines de bornes, des dizaines de milliers de sessions perdues, des pénalités contractuelles et une réputation dégradée auprès des collectivités et des automobilistes.
Pourtant, les opérateurs disposent de plus de données que jamais. Les plateformes de supervision comme Monta ou Freshmile génèrent en continu des flux de sessions, d’états de connecteurs, d’alertes et de consommation énergétique. Alors pourquoi cet écart persiste-t-il ?
La réponse n’est pas dans le volume de données. Elle est dans ce qu’on en fait. Elle est dans ce qu’on en fait : des exports manuels traités une fois par mois, des alertes sans contexte historique, des tableaux de bord figés qui mesurent l’état mais jamais la trajectoire. La plupart des opérateurs pensent être au palier 2 de maturité analytique. En pratique, ils sont encore au palier 1. Et le passage au palier 3, voire au palier 4, est rarement un problème technique.
Cet article propose un diagnostic en quatre paliers, construit spécifiquement pour les opérateurs IRVE, avec ce que chaque niveau implique concrètement en termes de stack, de données et de décisions.
À retenir
- La majorité des opérateurs IRVE est encore au palier 1 de maturité analytique, même ceux qui disposent d’une plateforme de supervision.
- Le palier 3 se divise en deux sous-axes distincts en IRVE : la prédiction de panne et la prédiction de demande. Cette dualité n’existe pas dans d’autres secteurs industriels.
- Le vrai obstacle entre palier 3 et palier 4 n’est pas algorithmique : c’est la responsabilité contractuelle dans un écosystème multi-acteurs.
- Viser le palier 4 partout serait un contresens économique. Le bon niveau de maturité dépend du segment de marché.
- L’analytique prédictive a une deuxième audience souvent ignorée : les investisseurs. L’état de santé d’un parc nourrit la valorisation financière autant que l’exploitation.
Pourquoi la donnée IRVE est structurellement plus difficile à maîtriser qu’ailleurs
Avant de poser le diagnostic, il faut comprendre pourquoi la donnée d’un opérateur de bornes est plus complexe à fiabiliser que dans la plupart des secteurs industriels.
Une batterie est un système fermé. Ses données sont générées par un composant physique unique, régi par des lois électrochimiques prévisibles. L’ensemble de la télémétrie appartient au même acteur, du capteur à l’algorithme.
Une borne de recharge est un système ouvert. Elle fait interagir un véhicule, un conducteur, une infrastructure physique, une plateforme de supervision tierce et parfois le réseau électrique national. Et dans le cas de l’itinérance, une part significative des sessions est initiée par un usager d’un autre fournisseur de mobilité, via des plateformes comme Gireve ou Hubject, à l’échelle européenne, sur des protocoles ouverts de type OCPI. Conséquence directe : une partie des données comportementales échappe structurellement au CPO. L’identité et le contexte de l’usager ne sont pas toujours visibles par l’opérateur qui gère physiquement la borne.
À cela s’ajoute l’hétérogénéité du parc. Un opérateur gère rarement des bornes d’une seule marque. Alfen, Keba, ABB, Wallbox, EVBox, chaque fabricant a son propre firmware, ses propres conventions de données, ses propres formats d’export. Ce que le monde de la batterie appelle « transfer learning entre chimies » devient ici un « transfer learning entre marques et versions de firmware » : un modèle entraîné sur un parc Alfen ne se transpose pas directement sur un parc Keba.
Enfin, l’opérateur IRVE est un intégrateur, pas un propriétaire de bout en bout. Le hardware vient d’un fabricant. Le software de supervision vient souvent d’une plateforme SaaS tierce. L’énergie vient d’un fournisseur. La capacité à monter en maturité analytique ne dépend donc pas seulement des compétences internes : elle dépend aussi de l’ouverture API des tiers. C’est un point structurel presque toujours oublié lors des discussions internes sur la maturité data.
Les quatre paliers de maturité : où en êtes-vous réellement ?
Palier 1 : les seuils fixes
C’est le point de départ de la quasi-totalité des opérateurs aujourd’hui. La logique est simple et volontairement déterministe : si la borne perd son heartbeat OCPP, si une session se termine en erreur via un StatusNotification, si la température d’un connecteur sort de sa plage nominale ou si une surintensité est détectée, une alerte est déclenchée. Les superviseurs du marché classent ces événements par sévérité, du P1 (intervention immédiate) au P4 (signalement non critique), en cohérence avec les SLA contractuels qui imposent généralement entre 97 et 99 % de disponibilité et un délai d’intervention maximal de 24 à 48 heures ouvrées.
Ce niveau de maturité est volontairement simple, et c’est justifié. Une couche de sécurité doit rester déterministe, auditable et facilement certifiable. Mais il a une limite fondamentale : il détecte la panne, il ne l’anticipe pas. L’alerte arrive quand le problème existe déjà. Aucun contexte sur l’usure réelle du connecteur, aucune corrélation avec l’historique de la borne.
Le signe que vous êtes encore là : vos alertes arrivent au moment où la borne est déjà hors service, et votre taux de faux positifs a fini par installer une forme de fatigue des alarmes dans les équipes terrain.
Palier 2 : la dérive statistique
Le premier vrai saut qualitatif consiste à arrêter de regarder des valeurs instantanées pour regarder des trajectoires. Ce n’est plus « la borne est en panne » mais « cette borne dérive depuis trois semaines ».
Les candidats concrets pour un opérateur IRVE :
- La dérive de la puissance réellement délivrée par rapport à la puissance nominale (signe précoce d’usure d’un contacteur ou d’un câble avant la panne franche)
- La tendance du taux d’échec de session par borne sur un glissement de quatre semaines
- La corrélation entre la température ambiante et la fréquence des incidents sur certains modèles de bornes
Ces indicateurs ne nécessitent pas de machine learning. Ils reposent sur des techniques statistiques classiques : cartes de contrôle SPC, détection d’anomalies par écart-type dynamique, séries temporelles simples.
Ce palier exige en revanche une condition préalable que beaucoup sous-estiment : des données propres, continues et bien structurées. Un export Monta de 400 000 lignes traité manuellement une fois par mois ne permet pas de construire des tendances fiables. C’est l’enjeu technique réel à ce niveau, avant même de parler de modèles.
Le signe que vous y êtes : vous avez des tableaux de bord de tendance, pas seulement des tableaux d’état. Vous anticipez l’intervention, vous ne la subissez plus.
Palier 3 : le Machine Learning prédictif, deux sous-axes à distinguer
C’est là que l’IRVE se différencie structurellement d’autres secteurs industriels. Contrairement au cas de la batterie, où le palier 3 se concentre uniquement sur la dégradation physique d’un actif, un opérateur de bornes doit piloter deux familles de prédiction distinctes.
3a. La prédiction de panne
L’objectif est de prédire quel composant (connecteur, contacteur, câble, ventilateur de refroidissement sur les bornes DC rapides) va lâcher avant la panne franche. L’obstacle principal n’est pas la rareté des données de fin de vie, comme dans le cas batterie. C’est l’hétérogénéité du parc. Un modèle entraîné sur l’historique d’un parc Alfen ne généralise pas directement à un parc composé d’équipements Keba ou EVBox. Chaque migration de firmware est susceptible de modifier les patterns de données et d’invalider partiellement les modèles existants.
Un argument business concret justifie l’investissement dans un modèle imparfait : les délais d’approvisionnement en pièces détachées dépassent souvent trois semaines pour une carte électronique. Anticiper une panne trois semaines à l’avance n’a pas la même valeur qu’anticiper une panne trois jours à l’avance. Même un modèle dont la précision reste perfectible génère un retour mesurable, à condition que la fenêtre de prédiction soit suffisamment large.
Ce que peu de DSI anticipent à ce stade : l’état de santé prédictif du parc n’intéresse pas uniquement les équipes d’exploitation. Un fond d’infrastructure qui valorise un actif physique raisonne en durée de vie résiduelle, en risque de dépréciation et en coût de maintenance future. Le DSI qui monte au palier 3a crée de la valeur financière, pas seulement opérationnelle. Dans un secteur où les levées de fonds s’accélèrent, cette donnée nourrit directement la data room et les due diligences.
3b. La prédiction de demande
Ce sous-axe n’a pas d’équivalent dans le cas de la batterie. Il s’agit de prévoir l’occupation d’une borne par créneau horaire, la charge d’un site à J+7, les pics de demande sur un corridor autoroutier en période de grands départs. Ces prédictions alimentent directement le palier 4 : elles rendent possible la tarification dynamique et le pilotage de puissance en anticipation, plutôt qu’en réaction.
Un point de vigilance spécifique à l’IRVE : la non-stationnarité des données. Le marché du véhicule électrique évolue rapidement. Les patterns d’usage d’il y a dix-huit mois ne généralisent pas forcément dans un marché où le taux d’équipement des ménages progresse de façon non linéaire. Un modèle entraîné sur des données de 2022 peut produire des prédictions biaisées en 2026, contrairement à un modèle de dégradation physique d’une cellule, dont les lois sous-jacentes ne changent pas.
Palier 4 : le prescriptif
Le modèle ne dit plus « dégradation prévue dans six semaines ». Il recommande une action : redistribuer la puissance disponible entre les points de charge d’un même site pour ne pas dépasser la puissance souscrite, moduler le prix de la session pour lisser la demande aux heures de pointe, déclencher une intervention préventive sur un site précis avant un week-end de fort trafic, arbitrer sur les achats d’électricité en fonction des prix spot.
Dans un récit de maintenance prédictive industrielle, le palier 4 sert principalement à éviter un coût : la panne, le remplacement prématuré de l’actif. Pour un opérateur IRVE qui achète l’électricité en gros et la revend à l’utilisateur final, le palier 4 devient un levier de marge directe. Décaler la recharge vers les heures où l’électricité est moins chère, lisser la pointe pour éviter les pénalités de dépassement de puissance souscrite, capter des revenus de flexibilité : la donnée ne protège plus seulement une valeur, elle en crée une nouvelle.
Où vous situez-vous ?
| Palier | Signal caractéristique | Ce qui manque |
| Palier 1 | Vos alertes arrivent quand la borne est déjà hors service | Anticipation, contexte historique |
| Palier 2 | Vous suivez des tendances, pas seulement des états | Des données propres et continues en entrée |
| Palier 3 | Vous prédisez des pannes ou des pics de demande | Un parc homogène et des modèles maintenus dans le temps |
| Palier 4 | Vos modèles recommandent des actions et génèrent de la marge | Une architecture de décision en temps réel et une gouvernance multi-acteurs |
La plupart des opérateurs mid-market se situent entre le palier 1 et le palier 2. Ce n’est pas un retard : c’est le point de départ réaliste d’une trajectoire data qui se construit par étapes, à condition de poser les bonnes fondations dès maintenant.

Tous les segments n’ont pas le même plafond rationnel
Un article sur la maturité analytique qui laisserait entendre que le palier 4 est un horizon universel souhaitable pour tout le monde rendrait un mauvais service à ses lecteurs. En IRVE, le bon niveau de maturité dépend directement du segment de marché.
| Segment | Palier rationnel | Logique |
| Résidentiel | 1-2 au niveau du site | Faible volume de sessions par site ; le palier 3 ne se justifie qu’à l’échelle d’un portefeuille agrégé de milliers d’adresses |
| Tertiaire / flottes | 3-4 | Usage prévisible, décideur unique, contrainte dure de puissance souscrite : terrain le plus favorable à la décision automatisée |
| Urbain / voirie | 1-2 pour le SLA ; 4 politiquement délicat | Aucune collectivité ne veut qu’un algorithme coupe seul une borne sur la voie publique |
| Grande itinérance | 3-4 | Poussé par l’obligation AFIR (95 % de disponibilité sur les corridors TEN-T) et le volume de sessions |
| Collectivités / DSP | Variable, souvent imposé | Le palier est parfois défini dans le cahier des charges de la délégation de service public, pas choisi |
Le message clé : viser le palier 4 partout serait un contresens économique, pas un signe de maturité. L’effort d’architecture data doit être dimensionné au regard du retour attendu, segment par segment.
Ce qui rend le prescriptif particulièrement complexe en IRVE
Deux obstacles spécifiques ralentissent la montée vers le palier 4 en IRVE, indépendamment de la qualité des modèles.
Le premier est la dépendance à l’ouverture API des tiers. L’opérateur orchestre des briques qu’il ne contrôle pas entièrement. Si la plateforme de supervision limite l’accès à certaines données ou impose des délais de mise à disposition, la couche analytique en dépend directement. La vraie question du build vs buy à ce niveau n’est pas « développer ou acheter un modèle Machine Learning » : c’est « est-ce que mon architecture data est assez solide et indépendante pour alimenter un modèle avec des données fiables et continues ?«
Le second est réglementaire, mais dans le sens inverse de ce qu’on imagine. Il existe un plancher de collecte de données imposé de l’extérieur. Le programme ADVENIR exige la remontée systématique des données de session pour toute borne télé-opérée bénéficiant du dispositif. Un opérateur resté au palier 1 par choix stratégique est malgré tout contraint à un minimum d’instrumentation. C’est un plancher qui peut paradoxalement accélérer la montée en maturité, en forçant la mise en place d’une infrastructure de collecte qui deviendra ensuite la base des paliers suivants.
Le vrai mur n’est pas l’algorithme
Entre le palier 3 et le palier 4, l’obstacle est presque toujours le même : ce n’est pas la qualité du modèle, c’est la confiance des équipes métier à laisser un modèle recommander une action qui a des conséquences contractuelles.
En IRVE, ce mur est plus haut qu’ailleurs. La chaîne multi-acteurs (CPO Chief Product Officer, EMSP e-Mobility Service Provider, gestionnaire de réseau, collectivité) démultiplie la question de la responsabilité. Laisser un algorithme décider seul de réduire la puissance disponible sur un site pour optimiser la marge énergétique pose immédiatement une question que personne n’a envie d’esquiver : qui répond si cette décision automatisée casse un engagement de disponibilité vis-à-vis d’un EMSP partenaire ou pénalise une session facturable ?
La réponse pragmatique n’est pas de renoncer au palier 4. C’est de commencer sur le segment où ce mur est le plus bas : les flottes tertiaires. Usage prévisible, décideur unique, risque commercial limité. C’est là que la confiance se construit le plus facilement, et que le premier cas pilote devient un argument convaincant en interne pour étendre l’approche.
La pression réglementaire va probablement forcer la main avant que cette confiance ne se construise naturellement. Le décret AFIR, les obligations de disponibilité sur les corridors TEN-T et les exigences croissantes de reporting des collectivités poussent les opérateurs vers une supervision de plus en plus automatisée. Ce n’est plus seulement un choix de compétitivité : c’est une nécessité opérationnelle.
Dans un marché qui attire des capitaux mais qui se consolide rapidement, la qualité de l’infrastructure data sera l’un des critères de différenciation. Pas seulement pour optimiser l’exploitation au quotidien : pour produire les métriques qu’un fonds d’infrastructure attend avant d’investir, les indicateurs qu’un auditeur vérifiera lors d’une due diligence, et la traçabilité qu’un partenaire financier exige sur la durée. La donnée prédictive ne sert pas qu’à anticiper une panne. Elle sert à valoriser un actif.
La vraie question n’est pas « faut-il investir dans la maturité analytique ?« . C’est « à quel palier votre architecture data vous permet-elle d’opérer aujourd’hui, et quel est le prochain saut que votre stack peut réellement absorber ?«
Progresser d’un palier à l’autre ne dépend pas d’une refonte complète de votre système d’information. Cela dépend d’abord de votre capacité à centraliser vos sources opérationnelles en un pipeline fiable et automatisé, sans lourde mobilisation de la ressource IT. ClicData connecte vos sources de données hétérogènes et automatise les flux entre vos outils métier et vos environnements analytiques. Vous construisez ensuite des alertes contextuelles et des dashboards adaptés à chaque niveau de lecture, de l’équipe terrain au comité de direction. C’est cette architecture, posée dès le palier 2, qui rend possible le passage au prédictif sans tout reconstruire. Et dans un secteur où la donnée nourrit autant vos décisions opérationnelles que vos discussions avec des investisseurs, la qualité de votre infrastructure analytique est rarement un sujet qu’on peut remettre à plus tard.
FAQ
Faut-il un data engineer pour passer au palier 2 ?
Pas nécessairement. Le palier 2 repose sur des techniques statistiques classiques : cartes de contrôle SPC, détection d’anomalies par écart-type dynamique, séries temporelles simples. Le vrai prérequis n’est pas humain, il est structurel : disposer de données propres, continues et bien structurées. Un export traité manuellement une fois par mois ne permet pas de construire des tendances fiables. C’est cet enjeu-là qu’il faut résoudre en premier.
À partir de combien de bornes un modèle prédictif devient-il pertinent ?
Ce n’est pas une question de volume, c’est une question de segment. Un parc résidentiel dispersé ne justifie le palier 3 qu’à l’échelle d’un portefeuille agrégé de milliers d’adresses. En revanche, un parc tertiaire ou de grande itinérance peut y accéder bien plus tôt : l’usage est prévisible, le décideur est unique, et la contrainte de puissance souscrite est une incitation directe à la prédiction.
Notre parc est hétérogène (Alfen, Keba, EVBox). Est-ce un obstacle au prédictif ?
C’est l’obstacle principal du palier 3a. Un modèle entraîné sur l’historique d’un parc Alfen ne se transpose pas directement sur un parc Keba ou EVBox. Chaque migration de firmware peut en plus modifier les patterns de données et invalider partiellement les modèles existants. Cela ne rend pas le prédictif impossible, mais cela implique de maintenir les modèles dans le temps et d’investir dans une architecture data suffisamment indépendante des spécificités de chaque fabricant.



Comment justifier un investissement data auprès d’un board ou d’un investisseur ?
Comment justifier un investissement data auprès d’un board ou d’un investisseur ?
Un fonds qui investit dans un parc de bornes raisonne comme il raisonnerait sur n’importe quel actif physique à long terme : durée de vie résiduelle, risque de défaillance, coût de maintenance futur. L’état de santé prédictif d’un parc répond directement à ces questions. Dans un secteur où les levées de fonds s’accélèrent, ces données nourrissent la data room et les due diligences au même titre que les métriques opérationnelles. Le DSI qui monte au palier 3 crée de la valeur financière, pas seulement opérationnelle.