Pas de projet IA sans une base data solide

L’intelligence artificielle promet des gains majeurs dans le secteur de la mobilité électrique. Maintenance prédictive des bornes de recharge, optimisation intelligente de la charge (smart charging), réduction des coûts énergétiques, meilleure anticipation des besoins de renouvellement de flotte. Pourtant, une large majorité des projets IA échouent avant même de produire des résultats.

Et la raison est rarement l’algorithme lui-même. Elle se trouve presque toujours dans la qualité, la cohérence et l’accessibilité des données qui l’alimentent.

Si vos données sont incomplètes, dispersées entre plusieurs systèmes ou entachées d’erreurs, aucun modèle de machine learning, aussi sophistiqué soit-il, ne pourra les transformer en décisions fiables. Ce n’est pas une limitation technique, c’est un principe fondamental : l’IA n’invente pas la donnée. Elle l’exploite.

La bonne nouvelle existe et elle passe par la mise en place d’une base data solide et d’une approche progressive où la Business Intelligence prépare le terrain pour l’IA. C’est cette fondation dont nous parlerons dans cet article.

À retenir

• L’IA n’invente pas la donnée, elle l’exploite. Un modèle prédictif entraîné sur des données incomplètes ou incohérentes produira des résultats faux, voire dangereux pour les opérations.
• Le secteur cumule les difficultés data. Multiplicité des protocoles (OCPP, télématique constructeur), silos entre acteurs, données dispersées entre systèmes qui ne communiquent pas.
• La BI est l’étape de validation obligatoire. Avant de prédire ce qui va se passer, il faut être capable de décrire ce qui s’est passé de façon fiable.
• Six piliers structurent une base data exploitable. Référentiels unifiés, modèle de données commun, qualité mesurée en continu, architecture adaptée (temps réel + historique), gouvernance claire, conformité réglementaire.
• Le ROI de la donnée propre est mesurable avant même le premier modèle IA. Réduction des pannes, baisse des coûts énergétiques, automatisation des processus manuels.

Comprendre pourquoi l’IA dépend de la qualité des données

Le premier obstacle que rencontrent les entreprises du secteur n’est jamais « notre algorithme n’est pas assez bon ». C’est « nos données ne sont pas prêtes ». Et cette différence est cruciale.

Un modèle d’apprentissage automatique fonctionne selon un principe simple mais implacable : il apprend ce qu’on lui enseigne. Fournir des données sales, incohérentes ou mal étiquetées revient à lui demander d’apprendre à reproduire ou amplifier ces défauts. Les statisticiens et data scientists appellent cela le principe Garbage In, Garbage Out. Pas d’entrée de qualité, pas de sortie de qualité.

Dans la mobilité électrique, les dérives algorithmiques peuvent prendre plusieurs formes :

• Le surapprentissage sur du bruit (Overfitting) : si un capteur de température d’une borne enregistre régulièrement des pics irréalistes qui ne correspondent à rien d’opérationnel, le modèle de maintenance prédictive va apprendre ces anomalies comme la norme et déclencher des fausses alertes. Les techniciens sont mobilisés pour rien, leur confiance dans le système s’effondre.
• La dérive de distribution (Data Drift) : un modèle entraîné sur les sessions de recharge d’été, avec des températures extérieures clémentes et des batteries bien chargées, va appliquer des courbes de décharge irréalistes dès les premières gelées. Si la variable température n’a pas été correctement prise en compte à l’entraînement, le modèle échouera silencieusement.
• Les arbitrages absurdes : imaginez un algorithme de smart charging entraîné à réduire les pics de puissance. Si l’état de charge (SoC) remonte avec 30 minutes de latence ou si les prix spot de l’électricité contiennent des erreurs, l’algorithme peut prendre des décisions contre-productives. Il coupe la recharge d’utilitaires prioritaires pour économiser quelques centimes, bloquant ainsi les tournées prévues le lendemain. Le coût caché de cette « optimisation » dépasse largement le gain énergétique.

Comprendre la différence entre une hallucination et une dérive algorithmique importe beaucoup. Les hallucinations sont le phénomène des modèles de langage qui inventent des faits plausibles. Elles sont évidentes quand on les lit. Les dérives algorithmiques, elles, résultent d’un apprentissage sur du bruit ou des données biaisées. Elles restent invisibles opérationnellement jusqu’au moment où elles causent des dommages.

Les problèmes de données spécifiques au secteur

Ce qui rend la mobilité électrique particulièrement exigeante en matière de qualité data, c’est que le secteur cumule des difficultés rarement rencontrées ailleurs. Ce ne sont pas des obstacles théoriques. Ce sont des réalités quotidiennes pour les équipes d’exploitation.

Chez les opérateurs de bornes

L’hétérogénéité du parc représente le premier défi. Les bornes proviennent de constructeurs différents. Certaines communiquent en OCPP 1.6, d’autres en OCPP 2.0.1. Elles remontent la même information (puissance, température, codes d’erreur) mais le format varie. Les codes d’erreur sont propriétaires, la fréquence d’envoi des mesures change d’une borne à l’autre, les identifiants de connecteurs ne suivent pas la même logique d’un fabricant à l’autre.

À cela s’ajoutent les problèmes temporels. Les fuseaux horaires, les horloges de bornes désynchronisées, les sessions qui s’interrompent ou se dupliquent. Une même session de recharge peut être enregistrée deux fois si la borne perd la connexion au serveur puis la rétablit. Ou elle peut être fragmentée en deux sessions alors qu’elle n’en était qu’une. Tout cela fausse directement les modèles de prévision de demande.

Il existe enfin une contrainte réglementaire majeure qu’impose le règlement européen AFIR (Alternative Fuels Infrastructure Regulation). Les opérateurs de bornes doivent publier les données statiques (localisation, caractéristiques techniques) et dynamiques (disponibilité, prix) de leurs stations sur des points d’accès nationaux comme data.gouv.fr selon un schéma extrêmement strict. Une simple erreur de formatage suffit pour que les données de l’opérateur soient rejetées et exclues de la base nationale consolidée. Cette exclusion est très pénalisante commercialement, car la base publique cumule 261 800 téléchargements et 170 150 vues.

Chez les gestionnaires de flottes

La multiplicité des sources télématiques crée un problème différent mais tout aussi complexe. Chaque constructeur automobile expose une API distincte, avec ses propres unités, ses propres fréquences de remontée de données, ses propres niveaux de détail. Pour une flotte mixte (Renault, Peugeot, Nissan, Hyundai), il faut intégrer autant d’APIs constructeurs. La télématique d’un véhicule Renault remonte l’état de charge (SoC) toutes les 5 minutes et la santé de la batterie (SoH) une fois par jour. Un véhicule Hyundai remonte l’une et l’autre à des fréquences différentes et dans des unités différentes.

À cela s’ajoutent les données des bornes de recharge, les cartes carburant historiques (pour les flottes mixtes thermique/électrique), les systèmes de maintenance distincts, les ELD (enregistreurs électroniques de conduite), les données d’assurance. Chaque système stocke une version de la vérité légèrement différente.

Les processus restent largement manuels. Des exports CSV à partir de plusieurs plateformes, des réconciliations à la main dans Excel, des vérifications répétées pour s’assurer qu’on compare bien les mêmes périodes et les mêmes véhicules. Une responsable de flotte globale constate que résoudre les réclamations de conducteurs et maintenir l’exactitude des informations de base demande un travail chronophage qui devrait être automatisé.

Le problème transversal : la réconciliation

Qu’on soit opérateur de bornes ou gestionnaire de flotte, le problème central reste le même. Il faut relier les données entre elles de façon stable et incontestée :

• Relier une session de recharge à un badge, puis à un véhicule, puis à un conducteur, puis à un centre de coûts
• Relier les codes d’erreur OCPP d’une borne aux interventions de maintenance enregistrées dans un système de ticketing
• Relier la consommation énergétique remontée par une borne à celle calculée par la télématique du véhicule

Sans ces liens, le calcul d’un coût réel par véhicule devient impossible. La refacturation s’en ressent. Les modèles prédictifs de maintenance ne savent pas attribuer une panne à son vrai contexte. Et surtout, les équipes opérationnelles n’ont jamais une vue unifiée du système.

La BI comme fondation de l’IA et de la prise de décision

Avant de déployer un modèle prédictif, il faut répondre à une question simple : êtes-vous capable de décrire de façon fiable ce qui s’est réellement passé le mois dernier ? Si vous ne pouvez pas produire un taux de disponibilité des bornes incontestable ou un coût de recharge fiable par véhicule, vous ne pouvez pas prédire l’avenir de façon fiable.

C’est ici que la Business Intelligence intervient. Non pas comme un exercice de reporting cosmétique, mais comme l’étape de validation qui prépare le terrain à l’IA.

La progression en quatre niveaux d’analyse

Le modèle Gartner, popularisé depuis une quinzaine d’années, structure cette progression en quatre étapes. Le descriptif d’abord : que s’est-il passé ? Combien de sessions de recharge réussies, combien échouées, quelle énergie totale délivrée, quel taux de disponibilité des bornes par constructeur, quelle consommation moyenne par véhicule.

Le diagnostic vient ensuite, c’est là que la BI montre sa véritable valeur. En croisant les données, on peut répondre à des questions utiles : quelles bornes tombent en panne le plus souvent, sur quels sites, avec quel firmware ? Quels véhicules consomment anormalement, à quelle heure de la journée, dans quelles conditions météorologiques ?

Le troisième niveau reste le prédictif, c’est le domaine de l’IA. Prévision de pannes borne avant qu’elles n’impactent les utilisateurs finaux, prévision de la demande énergétique pour optimiser les contrats de fourniture, prévision de la dégradation des batteries pour anticiper les remplacements.

Le quatrième s’appelle prescriptif et ici l’IA recommande ou décide automatiquement. Planification automatique de la recharge pour chaque véhicule de flotte selon son emploi du temps et l’état de ses batteries, pilotage dynamique de la puissance délivrée par chaque borne pour éviter les dépassements de contrat et profiter des heures creuses.

La clé reste simple : on ne peut pas sauter les deux premiers niveaux. Aucune entreprise ne peut passer directement du chaos des données à la prédiction. Et c’est précisément ce que tentent de faire ceux qui échouent.

Ce que révèle la BI sur la qualité réelle des données

Dès qu’on commence à visualiser les données dans des tableaux de bord, les anomalies sautent aux yeux avec une clarté embarrassante. Des trous dans les séries temporelles (une borne qui ne remonte rien pendant 8 heures, puis qui reprend). Des sessions de durée aberrante (0 seconde ou 47 heures). Des consommations incohérentes (un petit véhicule électrique qui consomme 1 000 kWh en 10 minutes). Des bornes qui ne remontent plus rien depuis trois semaines : sont-elles en panne, déconnectées, ou simplement mises hors service ?

Un tableau de bord dédié à la qualité des données, mesurant la complétude (quel pourcentage de sessions ont tous leurs champs remplis ?), la fraîcheur (la dernière donnée remonte d’il y a combien de temps ?), la cohérence (les sessions ont-elles des timestamps logiques ?), devient un outil opérationnel de pilotage de la base data elle-même. Les équipes peuvent enfin réagir aux problèmes avant qu’ils ne contaminent les analyses et les modèles.

Un exemple concret : un taux de disponibilité calculé à partir de logs OCPP incomplets sera faux. Si une borne cesse d’émettre, est-elle vraiment en panne ou simplement déconnectée du réseau ? Sans règles de gestion explicites, deux équipes différentes pourront calculer deux chiffres radicalement différents. Un coût de recharge par véhicule devient impossible à calculer si les sessions ne sont pas solidement reliées aux véhicules via un référentiel stable.

Comment la BI prépare le terrain à l’IA

La BI crée une couche sémantique partagée. Au lieu de laisser chaque système interpréter les données à sa façon, la BI définit précisément les notions métier. Qu’est-ce qu’une session réussie ? Est-ce une session qui a livré de l’énergie sans erreur, ou une session qui a livré au moins 0,1 kWh ? Qu’est-ce qu’une panne ? Est-ce un code d’erreur OCPP, ou une période d’inactivité anormale d’une certaine durée ? Qu’est-ce que la disponibilité ?

Ces définitions, une fois formalisées, deviennent des tables nettoyées et cohérentes qui servent directement de matière première aux modèles IA. Les variables qu’un modèle de maintenance prédictive utilisera (nombre d’erreurs sur 7 jours, taux d’occupation, âge de la borne, température moyenne) sont souvent des indicateurs déjà calculés pour la BI. Il n’y a pas de duplication de travail, il y a une chaîne logique.

La BI constitue aussi l’historique dont l’IA a désespérément besoin. Un modèle de machine learning doit s’entraîner sur des mois ou des années de données propres et cohérentes. En historisant systématiquement les indicateurs dès la mise en place de la BI, on accumule progressivement le jeu d’entraînement des futurs modèles. Commencer la BI tôt revient à gagner des mois sur le calendrier du projet IA.

Les indicateurs clés qui deviennent les variables de l’IA

Dans votre secteur, qu’il s’agisse de bornes ou de flottes, certains KPI structurent le pilotage et ouvrent naturellement la porte à l’IA.

Chez les opérateurs de bornes

KPI	Utilisation
Taux de disponibilité (par borne, site, constructeur)	Mesurer la continuité de service et identifier les équipements problématiques
Sessions réussies vs échouées	Révéler des schémas de défaillance récurrents
Énergie délivrée par période	Planifier l’expansion du réseau et dimensionner les contrats de fourniture
Temps moyen entre deux pannes (MTBF)	Alimenter les modèles de maintenance prédictive
Température des connecteurs	Détecter les signaux précurseurs de défaillance matérielle
Taux d’occupation des connecteurs	Déterminer où installer de nouvelles bornes

Chez les gestionnaires de flottes

KPI	Utilisation
Coût total de possession (TCO) par véhicule	Agréger tous les coûts (acquisition, assurance, entretien, énergie) pour arbitrer les décisions
Consommation réelle vs théorique (WLTP)	Révéler les écarts entre le terrain et les promesses constructeur
Taux d’utilisation des véhicules	Optimiser la taille de la flotte et identifier les véhicules sous-utilisés
Coût par kilomètre	Guider les décisions de renouvellement
Émissions CO2 (bilan GES)	Assurer la conformité LOM et ZFE, piloter la stratégie RSE
Historique des codes de défaut croisé avec les fiches de maintenance	Prédire les pannes futures et planifier les interventions

Ces indicateurs ne sont pas des fins en elles-mêmes. Ce sont les variables d’entrée des modèles prédictifs de demain. Un modèle de maintenance prédictive utilisera le MTBF, le nombre d’erreurs sur 7 jours, l’âge de la borne. Un modèle d’optimisation de flotte utilisera le TCO, le taux d’utilisation, la consommation réelle. La BI qui les a produits fournit aussi la mesure « avant » permettant de prouver que le modèle IA améliore vraiment les performances une fois déployé.

Les six piliers d’une base data solide

Une base data exploitable et résiliente s’appuie sur une structure logique. Les six piliers suivants doivent être présents simultanément. L’absence d’un seul crée une faille par laquelle toute la valeur peut s’échapper.

Pilier 1 : les référentiels (master data)

Un registre unique des actifs. Sites, bornes, connecteurs, véhicules, badges, conducteurs. Chaque entité dispose d’un identifiant stable, unique et inchangé au fil du temps. C’est la base de toute réconciliation fiable. Sans référentiels centralisés, relier une session de recharge à un véhicule devient un cauchemar manuel qui dégénère en erreurs systématiques.

Pilier 2 : un modèle de données commun

Les codes d’erreur propriétaires des constructeurs doivent être traduits vers une nomenclature unique. Les unités doivent être harmonisées (les kWh toujours en kWh, pas alternant entre MJ et Wh selon la source). Les définitions doivent être partagées : une « session », une « panne », une « disponibilité » doivent avoir le même sens pour tout le monde, indépendamment de la source de données.

Pilier 3 : la qualité mesurée en continu

Il ne s’agit pas de nettoyer les données une fois par an. Les indicateurs de complétude, exactitude, fraîcheur et cohérence doivent être suivis en continu avec des alertes automatiques. C’est le rôle du tableau de bord qualité mentionné plus tôt. C’est le contrôle de qualité qui ne s’arrête jamais.

Pilier 4 : une architecture adaptée au flux et à l’historique

L’ingestion en flux permet le temps réel : pilotage dynamique de la charge, alertes immédiates si une borne tombe en panne. Le stockage historisé de type lakehouse préserve les données pour l’entraînement des modèles. L’historique des données brutes doit être conservé, pas écrasé ou agrégé à chaque rafraîchissement. Cette architecture double coûte plus cher en infrastructure, mais c’est l’investissement qui sépare une BI tactique d’une vraie plateforme data capable de supporter l’IA.

Pilier 5 : la gouvernance des données

Chaque domaine de données doit avoir un responsable identifié. Des règles d’accès claires selon les rôles. Un cadre contractuel pour les données partagées entre partenaires (opérateurs de bornes, gestionnaires de flotte, fournisseurs d’énergie). Ces questions ne sont pas administratives. Elles déterminent qui peut faire confiance aux données et qui en assume la responsabilité en cas d’erreur.

Pilier 6 : la conformité réglementaire

La géolocalisation des véhicules de salariés reste une donnée personnelle au sens du RGPD. La CNIL a publié des recommandations spécifiques : finalités limitées, pas de suivi permanent hors temps de travail, information des salariés. Le règlement européen AFIR impose aux opérateurs de bornes de mettre à disposition certaines données statiques et dynamiques selon des formats normalisés pour la transparence du marché. Une donnée bien structurée devient alors une obligation réglementaire, et plus seulement un atout stratégique.

Comment réussir : bâtir la base data progressivement

Comprendre les six piliers est une chose. Les mettre en place en est une autre. Il existe une voie pragmatique pour avancer sans être paralysé par la taille du projet.

Le premier réflexe doit être d’investir en amont plutôt qu’en urgence. Une large part du temps d’un projet IA, entre 60 et 80%, est consacrée à la préparation et au nettoyage des données, pas à l’entraînement des modèles. Cette statistique apparaît dans pratiquement chaque étude sectorielle des data scientists. Investir dans la qualité data d’abord ne coûte donc pas plus cher. Cela réduit fortement le coût et la durée des projets IA suivants. C’est un gain multiplicateur.

Le deuxième réflexe doit être de commencer par la BI, pas par l’IA. Les entreprises qui tentent de lancer directement un projet prédictif sans avoir d’abord construit une BI fiable se heurtent toujours au même mur : les données ne sont pas prêtes. La BI reste l’étape de validation obligatoire. Elle crée la visibilité, elle impose les définitions, elle trace les dépendances. Dès que la BI fonctionne, le passage à l’IA devient un ajout naturel, pas une révolution.

Prenons l’exemple de WAAT, un opérateur français de recharge pour véhicules électriques. Avant de même penser à l’IA, WAAT gérait sa facturation de façon largement manuelle. Conversion des devis en factures à l’aide de vérifications successives, mises à jour de champs, contrôles fonctionnels. Chaque dossier demandait au minimum 5 minutes de traitement manuel, mobilisant plusieurs membres de l’équipe sur des tâches sans valeur ajoutée.

Le processus était chronophage parce qu’il exigeait de croiser des données issues de plusieurs outils : l’ERP Sellsy, la plateforme de financement Advenir, les systèmes de supervision des bornes. Les règles métiers étaient strictes et complexes à appliquer manuellement. La visibilité sur le traité et le non-traité n’existait pas.

En structurant d’abord le flux de données et en automatisant le pipeline, WAAT a transformé son opération. Les 10 étapes manuelles ont été remplacées par 30 tâches automatisées robustes. L’extraction des devis, l’application des règles métiers, la création des factures et la distribution des rapports aux équipes s’exécutent désormais chaque jour sans intervention humaine. En trois mois, c’était 83 heures libérées. Les équipes métier peuvent se concentrer sur des enjeux à plus forte valeur ajoutée. Et surtout, la fondation data est maintenant fiable.

Le troisième réflexe doit être de mesurer le ROI data indépendamment de l’IA. Les gains arrivent avec la BI seule, avant le premier modèle prédictif. Chaque point de disponibilité des bornes gagné grâce à une meilleure identification des pannes représente du chiffre d’affaires et de la satisfaction client. Un smart charging fiable qui commence avec une visibilité correcte sur l’état des batteries réduit les dépassements de puissance souscrite et la facture énergétique. Une meilleure visibilité sur l’état de santé des batteries améliore les décisions de renouvellement de flotte. Ces gains justifient l’investissement data.

Comment ClicData accompagne cette transition

La vision est claire. Mais comment la concrétiser sans mobiliser une équipe de data engineers ?

Centraliser les sources hétérogènes sans déployer une usine à gaz

ClicData propose des connecteurs vers les plateformes métier du secteur. Monta pour la supervision des bornes, Sellsy pour l’ERP et la facturation, les APIs des constructeurs automobiles, les Data Warehouses Snowflake. Ces connecteurs permettent de ramener toutes les données à un endroit unique, de les enrichir mutuellement, de les transformer selon le modèle de données commun qu’on a défini.

WAAT utilise précisément cette approche. Les données des devis, de la plateforme Advenir et des systèmes de supervision des bornes convergent dans un seul pipeline de données centralisé. Au lieu d’exports manuels à partir de trois systèmes différents, il y a une source unique de vérité.

Automatiser les workflows sans coder

Plutôt que des exports CSV manuels et des réconciliations à la main, ClicData permet de définir des Data Flows. Des pipelines automatisés qui extraient, transforment, nettoient et réconcillient les données selon des règles précises que vous définissez visuellement, sans code.

Pour WAAT, l’impact a été immédiat. Ce qui prenait des heures de traitement manuel devient un flux automatique qui s’exécute chaque jour. C’est un levier majeur pour libérer du temps et fiabiliser les processus en supprimant la variabilité humaine.

Rendre la qualité visible et actionnable

Un tableau de bord dédié à la qualité des données vous permet de suivre la complétude, la fraîcheur, la cohérence des données en temps réel. Les anomalies sont détectées automatiquement et remontent sous forme d’alertes. Ce n’est plus un audit ponctuel une fois par trimestre. C’est un contrôle continu qui vous permet de réagir avant que les problèmes ne se propagent.

Tableaux de bord – Pilotage du réseau de bornes

Activer le temps réel sans complexité technique

Les webhooks permettent d’être alerté immédiatement si une borne tombe en panne, si une anomalie critique est détectée, si les prix de l’électricité dépassent un seuil défini. Le temps réel n’est plus une vision futuriste. C’est une réalité opérationnelle à portée de main.

Construire des tableaux de bord lisibles pour tous

Les KPI sont visualisés de façon claire et immédiatement compréhensible. Les équipes d’exploitation voient la disponibilité des bornes et les pannes prioritaires. Les gestionnaires de flotte voient le TCO et les consommations anormales. Les équipes financières voient les coûts et les marges. Les investisseurs voient les projections de croissance et les tendances clés. Un même socle data, des vues différentes selon le besoin de chacun.

Tableaux de bord – Flotte – Performance & Sécurité

Rendre la donnée accessible sans IT dédié

WAAT n’avait pas d’équipe IT dédiée. Pas de développeurs en staff pour construire des pipelines data complexes. Pourtant, avec ClicData, ils ont bâti une infrastructure data end-to-end. L’interface est conçue pour que les équipes métier puissent contribuer, créer des rapports, définir des alertes sans avoir à coder. La donnée devient un levier pour tous, pas seulement pour les spécialistes.

Préparer le terrain pour l’IA de demain

En structurant les données, en les rendant visibles et en prouvant leur fiabilité via la BI, ClicData crée la fondation sur laquelle vos cas d’usage prédictifs pourront vraiment fonctionner. Les modèles IA trouveront des données exploitables, historisées et bien documentées. Les équipes auront compris les métriques et seront prêtes à interpréter et actionner les prédictions.

Conclusion

La BI n’est pas une étape optionnelle avant l’IA. C’est la fondation qui rend l’IA possible. En structurant les données, en les rendant visibles et en prouvant leur fiabilité, elle prépare le terrain pour les cas d’usage prédictifs et prescriptifs qui transformeront le secteur de la mobilité électrique.

Le ROI commence dès la BI, pas au premier modèle prédictif. Automatisation des processus manuels, visibilité opérationnelle améliorée, décisions mieux informées. Et c’est en construisant une base data solide dès aujourd’hui que les projets IA de demain réussiront.

La question ne devrait donc pas être : quand allons-nous déployer l’IA ? Elle devrait plutôt être : comment allons-nous structurer nos données pour en extraire de la valeur immédiatement et préparer l’IA pour demain ?

FAQ