L’intelligence artificielle promet des gains majeurs dans le secteur de la mobilit\u00e9 \u00e9lectrique. Maintenance pr\u00e9dictive des bornes de recharge, optimisation intelligente de la charge (smart charging), r\u00e9duction des co\u00fbts \u00e9nerg\u00e9tiques, meilleure anticipation des besoins de renouvellement de flotte. Pourtant, une large majorit\u00e9 des projets IA \u00e9chouent avant m\u00eame de produire des r\u00e9sultats.<\/p>\n\n\n\n
Et la raison est rarement l’algorithme lui-m\u00eame. Elle se trouve presque toujours dans la qualit\u00e9, la coh\u00e9rence et l’accessibilit\u00e9 des donn\u00e9es qui l’alimentent.<\/p>\n\n\n\n
Si vos donn\u00e9es sont incompl\u00e8tes, dispers\u00e9es entre plusieurs syst\u00e8mes ou entach\u00e9es d’erreurs, aucun mod\u00e8le de machine learning, aussi sophistiqu\u00e9 soit-il, ne pourra les transformer en d\u00e9cisions fiables. Ce n’est pas une limitation technique, c’est un principe fondamental : l’IA n’invente pas la donn\u00e9e. Elle l’exploite.<\/p>\n\n\n\n
La bonne nouvelle existe et elle passe par la mise en place d’une base data solide et d’une approche progressive o\u00f9 la Business Intelligence pr\u00e9pare le terrain pour l’IA. C’est cette fondation dont nous parlerons dans cet article.<\/p>\n\n\n\n
\u00c0 retenir<\/strong><\/p>\n\n\n\n Le premier obstacle que rencontrent les entreprises du secteur n’est jamais \u00ab notre algorithme n’est pas assez bon \u00bb. C’est \u00ab nos donn\u00e9es ne sont pas pr\u00eates \u00bb. Et cette diff\u00e9rence est cruciale.<\/p>\n\n\n\n Un mod\u00e8le d’apprentissage automatique fonctionne selon un principe simple mais implacable : il apprend ce qu’on lui enseigne. Fournir des donn\u00e9es sales, incoh\u00e9rentes ou mal \u00e9tiquet\u00e9es revient \u00e0 lui demander d’apprendre \u00e0 reproduire ou amplifier ces d\u00e9fauts. Les statisticiens et data scientists appellent cela le principe Garbage In, Garbage Out. Pas d’entr\u00e9e de qualit\u00e9, pas de sortie de qualit\u00e9.<\/p>\n\n\n\n Dans la mobilit\u00e9 \u00e9lectrique, les d\u00e9rives algorithmiques peuvent prendre plusieurs formes :<\/p>\n\n\n\n Comprendre la diff\u00e9rence entre une hallucination et une d\u00e9rive algorithmique importe beaucoup. Les hallucinations sont le ph\u00e9nom\u00e8ne des mod\u00e8les de langage qui inventent des faits plausibles. Elles sont \u00e9videntes quand on les lit. Les d\u00e9rives algorithmiques, elles, r\u00e9sultent d’un apprentissage sur du bruit ou des donn\u00e9es biais\u00e9es. Elles restent invisibles op\u00e9rationnellement jusqu’au moment o\u00f9 elles causent des dommages.<\/p>\n\n\n\n Ce qui rend la mobilit\u00e9 \u00e9lectrique particuli\u00e8rement exigeante en mati\u00e8re de qualit\u00e9 data, c’est que le secteur cumule des difficult\u00e9s rarement rencontr\u00e9es ailleurs. Ce ne sont pas des obstacles th\u00e9oriques. Ce sont des r\u00e9alit\u00e9s quotidiennes pour les \u00e9quipes d’exploitation.<\/p>\n\n\n\n L’h\u00e9t\u00e9rog\u00e9n\u00e9it\u00e9 du parc repr\u00e9sente le premier d\u00e9fi. Les bornes proviennent de constructeurs diff\u00e9rents. Certaines communiquent en OCPP 1.6, d’autres en OCPP 2.0.1. Elles remontent la m\u00eame information (puissance, temp\u00e9rature, codes d’erreur) mais le format varie. Les codes d’erreur sont propri\u00e9taires, la fr\u00e9quence d’envoi des mesures change d’une borne \u00e0 l’autre, les identifiants de connecteurs ne suivent pas la m\u00eame logique d’un fabricant \u00e0 l’autre.<\/p>\n\n\n\n \u00c0 cela s’ajoutent les probl\u00e8mes temporels. Les fuseaux horaires, les horloges de bornes d\u00e9synchronis\u00e9es, les sessions qui s’interrompent ou se dupliquent. Une m\u00eame session de recharge peut \u00eatre enregistr\u00e9e deux fois si la borne perd la connexion au serveur puis la r\u00e9tablit. Ou elle peut \u00eatre fragment\u00e9e en deux sessions alors qu’elle n’en \u00e9tait qu’une. Tout cela fausse directement les mod\u00e8les de pr\u00e9vision de demande.<\/p>\n\n\n\n Il existe enfin une contrainte r\u00e9glementaire majeure qu’impose le r\u00e8glement europ\u00e9en AFIR<\/a> (Alternative Fuels Infrastructure Regulation). Les op\u00e9rateurs de bornes doivent publier les donn\u00e9es statiques (localisation, caract\u00e9ristiques techniques) et dynamiques (disponibilit\u00e9, prix) de leurs stations sur des points d’acc\u00e8s nationaux comme data.gouv.fr selon un sch\u00e9ma extr\u00eamement strict. Une simple erreur de formatage suffit pour que les donn\u00e9es de l’op\u00e9rateur soient rejet\u00e9es et exclues de la base nationale consolid\u00e9e. Cette exclusion est tr\u00e8s p\u00e9nalisante commercialement, car la base publique cumule 261 800 t\u00e9l\u00e9chargements et 170 150 vues.<\/p>\n\n\n\n La multiplicit\u00e9 des sources t\u00e9l\u00e9matiques cr\u00e9e un probl\u00e8me diff\u00e9rent mais tout aussi complexe. Chaque constructeur automobile expose une API distincte, avec ses propres unit\u00e9s, ses propres fr\u00e9quences de remont\u00e9e de donn\u00e9es, ses propres niveaux de d\u00e9tail. Pour une flotte mixte (Renault, Peugeot, Nissan, Hyundai), il faut int\u00e9grer autant d’APIs constructeurs. La t\u00e9l\u00e9matique d’un v\u00e9hicule Renault remonte l’\u00e9tat de charge (SoC) toutes les 5 minutes et la sant\u00e9 de la batterie (SoH) une fois par jour. Un v\u00e9hicule Hyundai remonte l’une et l’autre \u00e0 des fr\u00e9quences diff\u00e9rentes et dans des unit\u00e9s diff\u00e9rentes.<\/p>\n\n\n\n \u00c0 cela s’ajoutent les donn\u00e9es des bornes de recharge, les cartes carburant historiques (pour les flottes mixtes thermique\/\u00e9lectrique), les syst\u00e8mes de maintenance distincts, les ELD (enregistreurs \u00e9lectroniques de conduite), les donn\u00e9es d’assurance. Chaque syst\u00e8me stocke une version de la v\u00e9rit\u00e9 l\u00e9g\u00e8rement diff\u00e9rente.<\/p>\n\n\n\n Les processus restent largement manuels. Des exports CSV \u00e0 partir de plusieurs plateformes, des r\u00e9conciliations \u00e0 la main dans Excel, des v\u00e9rifications r\u00e9p\u00e9t\u00e9es pour s’assurer qu’on compare bien les m\u00eames p\u00e9riodes et les m\u00eames v\u00e9hicules. Une responsable de flotte globale constate que r\u00e9soudre les r\u00e9clamations de conducteurs et maintenir l’exactitude des informations de base demande un travail chronophage qui devrait \u00eatre automatis\u00e9.<\/p>\n\n\n\n Qu’on soit op\u00e9rateur de bornes ou gestionnaire de flotte, le probl\u00e8me central reste le m\u00eame. Il faut relier les donn\u00e9es entre elles de fa\u00e7on stable et incontest\u00e9e :<\/p>\n\n\n\n Sans ces liens, le calcul d’un co\u00fbt r\u00e9el par v\u00e9hicule devient impossible. La refacturation s’en ressent. Les mod\u00e8les pr\u00e9dictifs de maintenance ne savent pas attribuer une panne \u00e0 son vrai contexte. Et surtout, les \u00e9quipes op\u00e9rationnelles n’ont jamais une vue unifi\u00e9e du syst\u00e8me.<\/p>\n\n\n\n Avant de d\u00e9ployer un mod\u00e8le pr\u00e9dictif, il faut r\u00e9pondre \u00e0 une question simple : \u00eates-vous capable de d\u00e9crire de fa\u00e7on fiable ce qui s’est r\u00e9ellement pass\u00e9 le mois dernier ? Si vous ne pouvez pas produire un taux de disponibilit\u00e9 des bornes incontestable ou un co\u00fbt de recharge fiable par v\u00e9hicule, vous ne pouvez pas pr\u00e9dire l’avenir de fa\u00e7on fiable.<\/p>\n\n\n\n C’est ici que la Business Intelligence intervient. Non pas comme un exercice de reporting cosm\u00e9tique, mais comme l’\u00e9tape de validation qui pr\u00e9pare le terrain \u00e0 l’IA.<\/p>\n\n\n\n Le mod\u00e8le Gartner<\/a>, popularis\u00e9 depuis une quinzaine d’ann\u00e9es, structure cette progression en quatre \u00e9tapes. Le descriptif d’abord : que s’est-il pass\u00e9 ? Combien de sessions de recharge r\u00e9ussies, combien \u00e9chou\u00e9es, quelle \u00e9nergie totale d\u00e9livr\u00e9e, quel taux de disponibilit\u00e9 des bornes par constructeur, quelle consommation moyenne par v\u00e9hicule.<\/p>\n\n\n\n Le diagnostic vient ensuite, c’est l\u00e0 que la BI montre sa v\u00e9ritable valeur. En croisant les donn\u00e9es, on peut r\u00e9pondre \u00e0 des questions utiles : quelles bornes tombent en panne le plus souvent, sur quels sites, avec quel firmware ? Quels v\u00e9hicules consomment anormalement, \u00e0 quelle heure de la journ\u00e9e, dans quelles conditions m\u00e9t\u00e9orologiques ?<\/p>\n\n\n\n Le troisi\u00e8me niveau reste le pr\u00e9dictif, c’est le domaine de l’IA. Pr\u00e9vision de pannes borne avant qu’elles n’impactent les utilisateurs finaux, pr\u00e9vision de la demande \u00e9nerg\u00e9tique pour optimiser les contrats de fourniture, pr\u00e9vision de la d\u00e9gradation des batteries pour anticiper les remplacements.<\/p>\n\n\n\n Le quatri\u00e8me s’appelle prescriptif et ici l’IA recommande ou d\u00e9cide automatiquement. Planification automatique de la recharge pour chaque v\u00e9hicule de flotte selon son emploi du temps et l’\u00e9tat de ses batteries, pilotage dynamique de la puissance d\u00e9livr\u00e9e par chaque borne pour \u00e9viter les d\u00e9passements de contrat et profiter des heures creuses.<\/p>\n\n\n\n La cl\u00e9 reste simple : on ne peut pas sauter les deux premiers niveaux. Aucune entreprise ne peut passer directement du chaos des donn\u00e9es \u00e0 la pr\u00e9diction. Et c’est pr\u00e9cis\u00e9ment ce que tentent de faire ceux qui \u00e9chouent.<\/p>\n\n\n\n D\u00e8s qu’on commence \u00e0 visualiser les donn\u00e9es dans des tableaux de bord, les anomalies sautent aux yeux avec une clart\u00e9 embarrassante. Des trous dans les s\u00e9ries temporelles (une borne qui ne remonte rien pendant 8 heures, puis qui reprend). Des sessions de dur\u00e9e aberrante (0 seconde ou 47 heures). Des consommations incoh\u00e9rentes (un petit v\u00e9hicule \u00e9lectrique qui consomme 1 000 kWh en 10 minutes). Des bornes qui ne remontent plus rien depuis trois semaines : sont-elles en panne, d\u00e9connect\u00e9es, ou simplement mises hors service ?<\/p>\n\n\n\n Un tableau de bord d\u00e9di\u00e9 \u00e0 la qualit\u00e9 des donn\u00e9es, mesurant la compl\u00e9tude (quel pourcentage de sessions ont tous leurs champs remplis ?), la fra\u00eecheur (la derni\u00e8re donn\u00e9e remonte d’il y a combien de temps ?), la coh\u00e9rence (les sessions ont-elles des timestamps logiques ?), devient un outil op\u00e9rationnel de pilotage de la base data elle-m\u00eame. Les \u00e9quipes peuvent enfin r\u00e9agir aux probl\u00e8mes avant qu’ils ne contaminent les analyses et les mod\u00e8les.<\/p>\n\n\n\n Un exemple concret : un taux de disponibilit\u00e9 calcul\u00e9 \u00e0 partir de logs OCPP incomplets sera faux. Si une borne cesse d’\u00e9mettre, est-elle vraiment en panne ou simplement d\u00e9connect\u00e9e du r\u00e9seau ? Sans r\u00e8gles de gestion explicites, deux \u00e9quipes diff\u00e9rentes pourront calculer deux chiffres radicalement diff\u00e9rents. Un co\u00fbt de recharge par v\u00e9hicule devient impossible \u00e0 calculer si les sessions ne sont pas solidement reli\u00e9es aux v\u00e9hicules via un r\u00e9f\u00e9rentiel stable.<\/p>\n\n\n\n La BI cr\u00e9e une couche s\u00e9mantique partag\u00e9e. Au lieu de laisser chaque syst\u00e8me interpr\u00e9ter les donn\u00e9es \u00e0 sa fa\u00e7on, la BI d\u00e9finit pr\u00e9cis\u00e9ment les notions m\u00e9tier. Qu’est-ce qu’une session r\u00e9ussie ? Est-ce une session qui a livr\u00e9 de l’\u00e9nergie sans erreur, ou une session qui a livr\u00e9 au moins 0,1 kWh ? Qu’est-ce qu’une panne ? Est-ce un code d’erreur OCPP, ou une p\u00e9riode d’inactivit\u00e9 anormale d’une certaine dur\u00e9e ? Qu’est-ce que la disponibilit\u00e9 ?<\/p>\n\n\n\n Ces d\u00e9finitions, une fois formalis\u00e9es, deviennent des tables nettoy\u00e9es et coh\u00e9rentes qui servent directement de mati\u00e8re premi\u00e8re aux mod\u00e8les IA. Les variables qu’un mod\u00e8le de maintenance pr\u00e9dictive utilisera (nombre d’erreurs sur 7 jours, taux d’occupation, \u00e2ge de la borne, temp\u00e9rature moyenne) sont souvent des indicateurs d\u00e9j\u00e0 calcul\u00e9s pour la BI. Il n’y a pas de duplication de travail, il y a une cha\u00eene logique.<\/p>\n\n\n\n La BI constitue aussi l’historique dont l’IA a d\u00e9sesp\u00e9r\u00e9ment besoin. Un mod\u00e8le de machine learning doit s’entra\u00eener sur des mois ou des ann\u00e9es de donn\u00e9es propres et coh\u00e9rentes. En historisant syst\u00e9matiquement les indicateurs d\u00e8s la mise en place de la BI, on accumule progressivement le jeu d’entra\u00eenement des futurs mod\u00e8les. Commencer la BI t\u00f4t revient \u00e0 gagner des mois sur le calendrier du projet IA.<\/p>\n\n\n\n Dans votre secteur, qu’il s’agisse de bornes ou de flottes, certains KPI structurent le pilotage et ouvrent naturellement la porte \u00e0 l’IA.<\/p>\n\n\n\n Chez les op\u00e9rateurs de bornes<\/strong><\/p>\n\n\n\n\n
Comprendre pourquoi l’IA d\u00e9pend de la qualit\u00e9 des donn\u00e9es<\/h2>\n\n\n\n
\n
Les probl\u00e8mes de donn\u00e9es sp\u00e9cifiques au secteur<\/h2>\n\n\n\n
Chez les op\u00e9rateurs de bornes<\/h3>\n\n\n\n
Chez les gestionnaires de flottes<\/h3>\n\n\n\n
Le probl\u00e8me transversal : la r\u00e9conciliation<\/h3>\n\n\n\n
\n
La BI comme fondation de l’IA et de la prise de d\u00e9cision<\/h2>\n\n\n\n
La progression en quatre niveaux d’analyse<\/h3>\n\n\n\n
Ce que r\u00e9v\u00e8le la BI sur la qualit\u00e9 r\u00e9elle des donn\u00e9es<\/h3>\n\n\n\n
Comment la BI pr\u00e9pare le terrain \u00e0 l’IA<\/h3>\n\n\n\n
Les indicateurs cl\u00e9s qui deviennent les variables de l’IA<\/h3>\n\n\n\n