Systèmes de gestion de la recharge des véhicules électriques : cloud ou sur site

Choisir entre un système de gestion de la recharge des véhicules électriques dans le cloud et un système sur site ne se résume pas à une simple décision d'hébergement informatique. Ce choix détermine qui exploite l'infrastructure, où sont stockées les données de recharge et de paiement, la capacité d'extension du réseau, les modalités de déploiement des mises à jour et quelle équipe est responsable de la sécurité, des sauvegardes, de la surveillance et de la reprise après sinistre.

La réponse appropriée dépend de votre réseau de bornes de recharge, des pays cibles, des flux d'utilisateurs et de paiements, de votre modèle de risque, de vos intégrations, de vos capacités informatiques internes et de votre plan de croissance sur cinq ans. Si vous devez d'abord définir l'ensemble de votre infrastructure technique, consultez le rapport de TrendPower. guide d'architecture du système de gestion de la recharge des véhicules électriques.

Que signifient réellement les termes Cloud, Cloud privé, Sur site et Hybride ?

Les documents d'approvisionnement utilisent souvent ces termes de manière imprécise. Avant de comparer les propositions, demandez à chaque fournisseur de présenter l'architecture proposée et d'attribuer les responsabilités pour chaque couche d'infrastructure et de logiciel.

Le Définition du cloud computing selon le NIST Le cloud est décrit comme un accès à la demande à un ensemble partagé de ressources configurables, pouvant être provisionnées et libérées rapidement. Cette flexibilité est précieuse, mais votre contrat doit néanmoins définir les modalités d'utilisation, les régions, les sauvegardes, la disponibilité et les droits de sortie.

Comparaison rapide des systèmes de gestion de la recharge des véhicules électriques : cloud vs sur site

Comment le modèle de déploiement modifie-t-il l'architecture CPMS ?

La chaîne fonctionnelle reste globalement similaire : les chargeurs communiquent avec le CPMS via OCPP ; les interfaces opérateur et conducteur utilisent des API ; la plateforme gère les utilisateurs, les sessions, les tarifs et les transactions ; et les services externes assurent la connexion des paiements, de l’itinérance, des cartes, des systèmes énergétiques, des ERP ou des systèmes de gestion de flotte. Le modèle de déploiement varie en fonction de l’emplacement d’exécution de ces composants et des personnes qui les exploitent.

Dans un déploiement cloud, les chargeurs se connectent généralement à un point de terminaison géré via des réseaux étendus sécurisés. Dans un déploiement sur site, le point de terminaison peut se trouver derrière un routage privé, un VPN, un pare-feu ou des contrôles réseau dédiés. Toutefois, la plateforme peut toujours nécessiter des connexions entrantes ou sortantes pour les prestataires de paiement, les applications mobiles, les SMS et les e-mails, les cartes, les boutiques d'applications, l'itinérance, les mises à jour logicielles et le support technique.

Cela signifie qu'une plateforme de recharge « sans connexion internet » constitue une architecture particulière, et non un simple synonyme d'infrastructure sur site. Elle peut limiter les services en temps réel destinés aux chauffeurs et les intégrations externes. Il est donc essentiel de définir précisément le modèle de connectivité avant de supposer que l'hébergement local élimine la dépendance à internet.

10 facteurs à comparer avant de choisir un CPMS cloud ou sur site

1. Rapidité de déploiement et approbation interne

Le déploiement dans le cloud permet de réduire les travaux d'infrastructure nécessaires avant la configuration et les tests de charge. C'est particulièrement utile pour les opérateurs qui doivent lancer un projet pilote, étendre leur réseau à un nouveau pays ou connecter rapidement de nouveaux sites. Les projets sur site impliquent généralement le dimensionnement des serveurs, leur acquisition, l'architecture réseau, l'audit de sécurité, la conformité aux normes du système d'exploitation, la configuration de la base de données, la sauvegarde et la surveillance avant la validation du CPMS.

Demandez des échéanciers distincts pour la préparation de l'environnement, le déploiement de l'application, les intégrations, la mise en service des chargeurs, les tests de sécurité, la validation par les utilisateurs et la mise en production. Une estimation sommaire de l'installation logicielle ne constitue pas un plan de lancement complet.

2. Évolutivité et performances

Les plateformes de recharge traitent les données de recharge (signalement, changements d'état, relevés de compteurs, commandes, sessions, tarifs, transactions, alertes et rapports). La croissance ne se mesure pas uniquement au nombre de bornes. Un réseau peut présenter un parc matériel modéré, mais une fréquence de télémétrie, un trafic API, un nombre de sessions simultanées ou une charge de travail analytique élevés.

Les environnements cloud facilitent l'extension de capacité, mais la mise à l'échelle n'est pas automatique, sauf si l'application, la base de données, les files d'attente et les intégrations sont conçues à cet effet. Les systèmes sur site peuvent également évoluer, mais l'acheteur doit prévoir la capacité, le délai d'approvisionnement, la redondance et les tests de performance.

Demandez des hypothèses concernant les chargeurs, les connecteurs, la fréquence des messages, les sessions simultanées, les utilisateurs actifs, les appels d'API, la croissance du stockage et les fenêtres de reporting. Définissez ensuite des critères d'acceptation des performances en fonction de vos prévisions, et non d'une valeur maximale générique fournie par le fournisseur.

3. Coût total de possession sur cinq ans

Les logiciels en nuage peuvent réduire les dépenses d'investissement en infrastructure, mais le prix de l'abonnement ne représente qu'une partie du coût. Les solutions sur site peuvent sembler avantageuses avec une licence perpétuelle, mais les coûts liés à la main-d'œuvre interne, au renouvellement du matériel, aux licences de bases de données, aux sauvegardes, aux outils de sécurité et à la reprise après sinistre peuvent impacter significativement le résultat.

Utilisez cette structure de coût total de possession (TCO) : Mise en œuvre + licences + infrastructure + consommation cloud + intégrations + main-d'œuvre opérationnelle + surveillance + sécurité et conformité + sauvegarde et reprise après sinistre + mises à niveau + support + migration et sortie.

Modélisez au moins trois scénarios de croissance. Intégrez les fonctionnalités de paiement, de messagerie, de cartographie, d'itinérance, de transfert et de stockage de données, le cas échéant. Distinguez les frais fixes, par chargeur, par connecteur, par session, par utilisateur et les frais basés sur la consommation.

4. Responsabilité en matière de sécurité

Les services cloud suivent un modèle de responsabilité partagée. Par exemple, AWS fait la distinction entre la sécurité « du » cloud et la sécurité « dans » le cloud.Le fournisseur exploite l'infrastructure sous-jacente, tandis que les clients conservent des responsabilités qui varient selon le service, notamment en matière de données, d'identités, d'applications et de configuration.

Avec un déploiement sur site, davantage de couches sont généralement transférées au client : accès physique, hyperviseurs, systèmes d’exploitation, bases de données, règles de pare-feu, certificats, correctifs, protection des terminaux, journaux, sauvegarde et restauration. Cela ne peut améliorer le contrôle direct que si l’organisation dispose des ressources humaines, des outils et de la discipline nécessaires pour appliquer ces contrôles de manière cohérente.

5. Souveraineté, confidentialité et propriété des données

La souveraineté des données ne se résume pas à la simple question de l'emplacement du serveur. Elle englobe la télémétrie des chargeurs, les données de compte, les jetons de paiement, les factures, les tickets d'assistance, les sauvegardes, les journaux, les analyses, les notifications push mobiles et les sous-traitants. Une plateforme cloud peut souvent utiliser une région spécifique, tandis qu'une plateforme sur site peut toujours envoyer des données à des services externes de paiement, de notification ou de cartographie.

Définir les rôles du responsable du traitement et du sous-traitant, les catégories de données, leur lieu de résidence, leur durée de conservation, leur suppression, les emplacements de sauvegarde, les transferts transfrontaliers et l'assistance aux personnes concernées. Confirmer contractuellement la propriété des données relatives aux chargeurs, aux sessions, aux clients, aux prix, aux transactions, aux pannes, à la maintenance et aux données analytiques dérivées. système de gestion des bornes de recharge pour véhicules électriques Cette page décrit les questions relatives au déploiement et aux données opérationnelles que les acheteurs devraient soulever lors de la phase de cadrage.

6. Disponibilité, sauvegarde et reprise après sinistre

L'infrastructure cloud fournit les éléments de base pour la redondance, mais l'architecture et le niveau de service déterminent le résultat concret. Une infrastructure sur site peut également être très résiliente, mais elle nécessite un financement et une exploitation pour un second site, des bases de données répliquées, une connectivité redondante, une capacité de réserve et des tests de reprise après sinistre.

Demandez un schéma de service et confirmez :

• la définition et le point de mesure de la disponibilité ;
• conception monozone, multizone ou multirégionale ;
• Tests de fréquence de sauvegarde, de conservation, d'immuabilité et de restauration ;
• objectif de temps de récupération (RTO) et objectif de point de récupération (RPO) ;
• Comportement du chargeur lorsque le serveur ou le réseau est indisponible ;
• paiement, autorisation et rapprochement des transactions après reconnexion.

7. Mises à jour, évolution d'OCPP et cycle de vie du logiciel

Les plateformes cloud managées permettent de centraliser la coordination des mises à jour applicatives, aidant ainsi les opérateurs à bénéficier de correctifs et d'améliorations sans avoir à reconstruire leur infrastructure. Cet avantage repose sur une gouvernance des déploiements : notifications, fenêtres de maintenance, rétrocompatibilité, tests de régression et restauration.

Les clients utilisant des solutions sur site souhaitent souvent un contrôle plus strict des modifications, mais les mises à niveau tardives peuvent engendrer une fragmentation des versions et accroître l'exposition aux vulnérabilités connues. Il est donc important de définir les versions obligatoires, la durée de support des versions, les personnes chargées de tester les dépendances de la base de données et du système d'exploitation, ainsi que la procédure d'approbation des correctifs d'urgence.

Le Open Charge Alliance répertorie actuellement OCPP 1.6, 2.0.1 et 2.1Votre modèle de déploiement devrait prendre en charge une feuille de route réaliste pour les protocoles et les micrologiciels des chargeurs, plutôt que de figer le réseau dans sa configuration de lancement.

8. Intégrations et connectivité réseau

Les solutions CPMS en nuage s'intègrent généralement efficacement aux passerelles de paiement, applications, réseaux d'itinérance et API d'entreprise. Le déploiement sur site simplifie le contrôle d'accès aux systèmes ERP, d'identité, de gestion de flotte, de services publics ou de technologies opérationnelles internes, mais peut nécessiter des passerelles API, des proxys inverses, des VPN, des listes blanches et un audit de sécurité pour chaque connexion externe.

Documentez la direction des données, l'authentification, les certificats, les plages d'adresses IP, les ports, la latence, les limites de débit, les tentatives de reconnexion et le comportement en cas d'échec. Déterminez qui est responsable de la surveillance de chaque connexion et de la gestion des incidents à la frontière entre les systèmes.

9. Opérations, surveillance et assistance

Le choix de l'hébergement influe sur le fonctionnement du support. Dans un cloud managé, le fournisseur de CPMS peut généralement observer l'application et la plateforme plus directement. Dans une infrastructure contrôlée par le client, le support peut dépendre de l'approbation des accès à distance, des journaux fournis par le client, de l'état de l'environnement, des sessions planifiées et de la coordination entre plusieurs équipes.

Définissez la responsabilité du suivi de l'infrastructure, des services applicatifs, des bases de données, des intégrations, de l'expiration des certificats, des connexions OCPP et des flux de travail métier. TrendPower gestion des opérations intelligentes Les fonctionnalités montrent comment la surveillance des chargeurs, les diagnostics, la réparation à distance et les ordres de travail peuvent former un seul processus d'exploitation et de maintenance.

10. Portabilité, verrouillage et planification de la sortie

Chaque modèle peut engendrer une dépendance propriétaire. Dans le cloud, cette dépendance peut provenir de services gérés, d'API propriétaires, de conditions commerciales ou de données opérationnelles inaccessibles. Sur site, elle peut provenir d'une infrastructure personnalisée, de dépendances spécifiques, de versions non prises en charge ou d'un code source que l'acheteur ne peut pas maintenir.

Exiger l'exportation complète des données, la documentation des schémas, l'accès à l'API, la propriété des identifiants de chargement, les sauvegardes de configuration, la propriété de l'App Store et du domaine, les conditions du code source le cas échéant, et une période de transition définie. Inclure la migration des points de terminaison de chargement, les modifications de certificats, l'historique des transactions, le rapprochement des paiements et les preuves de suppression dans le plan de sortie.

Qui devrait choisir un système de gestion de la recharge des véhicules électriques basé sur le cloud ?

Le déploiement dans le cloud est généralement une solution parfaitement adaptée lorsque la plupart de ces affirmations sont vraies :

• Vous lancez ou étendez vos activités sur plusieurs sites, villes ou pays.
• Vous souhaitez réduire l'infrastructure que votre équipe interne doit gérer.
• Vous prévoyez que le nombre de bornes de recharge, le trafic ou les besoins en stockage vont sensiblement évoluer.
• Les applications pour chauffeurs, les passerelles de paiement, l'itinérance et les API externes sont au cœur du service.
• Vous préférez des mises en production coordonnées, une surveillance, des sauvegardes et une maintenance de la plateforme.
• Vos exigences en matière de résidence des données peuvent être satisfaites par une région cloud et un contrat convenus.

Les candidats types incluent les CPO régionaux, les fabricants de bornes de recharge pour véhicules électriques lançant un service sous leur propre marque, les réseaux immobiliers, les entreprises de recharge de destination, les réseaux de recharge publics et les flottes commerciales distribuées. Pour les interfaces client et opérateur sous marque, consultez TrendPower. logiciel de recharge pour véhicules électriques en marque blanche.

Qui devrait choisir un CPMS sur site ?

Le déploiement sur site mérite une évaluation sérieuse lorsque plusieurs de ces conditions sont réunies :

• Une politique ou un contrat contraignant exige que la plateforme ou les données définies restent dans une infrastructure contrôlée par le client.
• Le CPMS doit s'intégrer profondément aux réseaux OT privés, aux réseaux de services publics, aux réseaux de flottes ou aux réseaux d'entreprise.
• La connectivité Internet est limitée et la continuité opérationnelle locale est une exigence inhérente à la conception du projet.
• Votre organisation exploite déjà une infrastructure résiliente, des bases de données, des systèmes d'observabilité, de sauvegarde et de sécurité.
• Vous pouvez ainsi maintenir les effectifs et les budgets alloués aux correctifs, aux mises à niveau, aux certificats, aux tests de récupération et à la planification des capacités.
• Vous avez besoin d'une personnalisation au niveau de l'infrastructure qu'un environnement géré standard ne peut pas fournir.

Les candidats types peuvent inclure les services publics, les environnements du secteur public, les grandes flottes de dépôts, les opérateurs de transport, les projets d'infrastructures critiques ou les entreprises disposant de normes établies en matière de cloud privé. L'infrastructure sur site doit constituer un choix architectural judicieux, étayé par des capacités opérationnelles solides, et non une réponse par défaut à des préoccupations générales de sécurité.

Quand une architecture de recharge hybride pour véhicules électriques est-elle préférable ?

Le modèle hybride peut s'avérer utile lorsque les exigences varient réellement en fonction de la charge de travail. Par exemple :

• conserver sur site un contrôleur d'énergie au niveau du dépôt et une logique de recharge locale tout en centralisant l'analyse de la flotte dans le cloud ;
• conserver certaines données réglementées dans un environnement privé tout en utilisant des applications cloud et des services de recharge publics ;
• assurer la continuité locale du contrôle du chargeur tout en synchronisant les sessions et les rapports avec un CPMS central ;
• connecter un système d'entreprise sur site via une couche d'intégration contrôlée plutôt que de déplacer l'intégralité du CPMS en local.

L'architecture hybride introduit également davantage d'interfaces, d'états de synchronisation et de limites de prise en charge. Elle permet de définir la source de vérité, la durée d'indisponibilité, la résolution des conflits, les transactions différées, la synchronisation temporelle, la gestion des certificats et les responsabilités en cas de divergence entre les couches locales et cloud.

Un cadre pratique de décision de déploiement

Posez-vous ces questions avant de demander l'architecture finale et le prix :

1. Quelle exigence est non négociable ? Identifier les contraintes contraignantes en matière de résidence, d'isolement, de latence, d'intégration ou de propriété plutôt que les préférences.
2. Qu'est-ce qui doit continuer à fonctionner hors ligne ? Dissocier le comportement des chargeurs locaux des applications, des paiements, de l'itinérance, des rapports et des opérations à distance.
3. Qui peut faire fonctionner la pile ? Nommez l'équipe responsable de l'infrastructure, du système d'exploitation, de la base de données, du réseau, de la sécurité, de l'observabilité et de la récupération.
4. À quelle vitesse le réseau va-t-il se développer ? Chargeur, connecteur, utilisateur, session, télémétrie, API et volumes de stockage du modèle.
5. Où chaque type de données doit-il résider ? Incluez les journaux, les sauvegardes, les analyses, les notifications et les sous-processeurs, et pas seulement la base de données de production.
6. Quels systèmes doivent être intégrés ? Plateformes de paiement cartographique, ERP, CRM, SSO, flotte, énergie, itinérance, cartes, assistance et plateformes de données.
7. Quelle disponibilité est réellement requise ? Définir la durée de fonctionnement, le RTO, le RPO, les fenêtres de maintenance et le fonctionnement en mode dégradé.
8. Comment le système va-t-il évoluer ? Plan OCPP, micrologiciel du chargeur, paiement, API, sécurité et mises à jour de l'application.
9. Quel est le coût total de possession (TCO) sur cinq ans ? Inclure la main-d'œuvre et les risques internes, et pas seulement les factures des fournisseurs.
10. Comment partirez-vous ? Testez l'exportation, les identifiants, la configuration, la migration du chargeur et l'assistance à la transition avant de signer.

Convertissez les réponses en un document d'approvisionnement structuré en utilisant le Liste de contrôle de l'appel d'offres pour un système de gestion de la recharge des véhicules électriques. Demander des réponses distinctes concernant l'architecture, les responsabilités, la mise en œuvre et les coûts pour chaque modèle de déploiement proposé.

Comment TrendPower aborde le déploiement flexible des CPMS

TrendPower conçoit des logiciels de recharge pour véhicules électriques adaptés au matériel de l'opérateur, à ses marchés cibles, à ses processus commerciaux, à ses intégrations et à ses exigences de contrôle. Sa plateforme globale prend en charge les déploiements dans le cloud public, le cloud privé et des solutions sur site, ces dernières étant évaluées en fonction des besoins du client en matière de données, de sécurité et d'intégration.

La décision de déploiement ne remplace pas la validation fonctionnelle. Les acheteurs doivent toujours confirmer la compatibilité du modèle de chargeur et du micrologiciel, les fonctions OCPP, les fournisseurs de paiement, les rôles des utilisateurs, les tarifs, les rapports, les API, la surveillance, l'étendue du support et les responsabilités en matière de migration. 15 fonctionnalités essentielles d'un CPMS Ce guide propose un cadre d'évaluation des fonctionnalités.

Les projets nécessitant une intégration plus poussée des flux de travail ou de l'entreprise peuvent également être définis par le biais d'un solution logicielle personnalisée de recharge pour véhicules électriquesPour un exemple de plateforme de marque connectant chargeurs, télécommande, planification, autorisations, paiements et règlement par le propriétaire, consultez la documentation. Étude de cas d'une plateforme de recharge domestique pour véhicules électriques aux États-Unis.

FAQ sur les logiciels de recharge pour véhicules électriques : cloud ou sur site

Sources faisant autorité et lectures complémentaires

• NIST SP 800-145 — Définition du cloud computing selon le NIST
• Amazon Web Services — Modèle de responsabilité partagée
• Open Charge Alliance — Protocoles OCPP
• Cadre de cybersécurité du NIST

Révision de la pertinence technique et d'approvisionnement : 20 septembre 2026. Les exigences en matière d'hébergement, de confidentialité, de sécurité et de réglementation varient selon la juridiction et le projet. Validez l'architecture finale avec vos équipes techniques, juridiques et de conformité.