Choisir et intégrer une borne de recharge VE en bâtiment (résidentiel & hôtel) : puissance, délestage, OCPP, mode dégradé

Illustration générée par IA — visuel conceptuel.

Pourquoi la “borne VE” est un sujet bâtiment (pas seulement un achat)

Dans une villa haut de gamme comme dans un hôtel, une borne de recharge ne se limite pas à une prise plus puissante. Elle introduit une charge électrique importante, des enjeux d’exploitation (qui a le droit de charger, comment tracer, comment dépanner) et, très souvent, une dépendance au réseau (supervision, accès distant, mises à jour).

La bonne approche consiste à concevoir une architecture de recharge : puissance disponible, priorités, comptage, délestage, interfaces (OCPP/Modbus) et mode dégradé. Cela évite deux dérives fréquentes : surdimensionner sans raison, ou installer “comme à la maison” un système qui devient ingérable en exploitation.

1) Clarifier le cas d’usage : villa, hôtel… ou parking mixte

Villa : confort, cohérence énergétique, simplicité d’usage

En résidentiel, la recharge VE s’intègre souvent à une logique plus large : confort, gestion d’énergie, et parfois production photovoltaïque ou batterie. L’objectif est généralement une recharge “sans y penser”, avec une limitation automatique quand d’autres usages montent en puissance. Si votre projet comporte déjà PV/batterie, l’article KNX, photovoltaïque, batteries et recharge de véhicule électrique : comment optimiser les flux ? permet de recadrer “qui décide quoi” entre onduleur/EMS, batterie et bâtiment.

Hôtel : service client, pilotage multi-usagers, traçabilité

En hôtellerie, une borne est un service : elle doit être administrable, traçable, et compatible avec des usages variés (clients, navettes, personnel, prestataires). Le projet doit aussi décider si la recharge est :

• Un service inclus (ex. avantage commercial),
• Un service piloté (accès contrôlé + journalisation),
• Un service facturable (si l’établissement choisit de refacturer tout ou partie).

Ce choix influence le niveau d’intégration attendu (identification, comptage, reporting), et surtout le comportement en mode dégradé (si la supervision tombe, que fait-on ?).

2) Puissance disponible : partir de la contrainte amont, pas de la borne

Avant de comparer des bornes, il faut cadrer la puissance réellement disponible au point d’alimentation de la zone (parking, sous-sol, extérieur) et comprendre les autres charges qui peuvent monter en même temps.

En pratique, une architecture robuste clarifie :

• Le périmètre électrique : quelle armoire alimente la zone, quelles protections, quels départs “non délestables”.
• Les usages concurrents : cuisines, CVC, pompes, laverie, événements (hôtel), ou gros consommateurs ponctuels (villa).
• La stratégie de contrainte : limitation, délestage, ou répartition dynamique entre bornes.

Pour la méthode de conception “délestage”, voir aussi Délestage intelligent : comment piloter les charges électriques d’un bâtiment ?.

3) Délestage et priorités : éviter le ON/OFF brutal

Un bon délestage de recharge ne se résume pas à “couper la borne”. On cherche plutôt à moduler (réduire, répartir, prioriser) de manière compréhensible et stable. Deux logiques complémentaires coexistent souvent :

• Limiter la puissance totale appelée par la recharge (priorité au bâtiment).
• Partager la puissance entre plusieurs points (priorité à l’équité ou à certains usages).

Prioriser les charges : bâtiment d’abord, confort ensuite, recharge en dernier (souvent)

Dans beaucoup de projets, la recharge VE est une charge très flexible. Cela ne veut pas dire “à sacrifier” : cela veut dire qu’elle peut être pilotée pour éviter les dépassements et préserver les usages critiques.

Recommandation de projet : formaliser une matrice de priorités (charges non délestables, délestables, modulables) et une stratégie de rétablissement (comment on remonte progressivement sans faire osciller le site). Cette logique se conçoit avec le BET électricité et, si la GTB/KNX intervient, avec l’intégrateur.

Ne pas confondre délestage et “smart charging”

Le “smart charging” peut désigner des choses différentes selon les acteurs : répartition entre bornes, consignes venant d’un serveur, optimisation PV, ou contraintes électriques instantanées. Le cahier des charges doit donc préciser : qui calcule la limite (borne, contrôleur local, GTB/KNX, supervision OCPP), et quelles informations sont nécessaires (mesure, états, priorités).

4) Comptage, sous-comptage et “facturation éventuelle” : cadrer le niveau de preuve

Que l’on refacture ou non, la recharge devient rapidement un sujet de mesure : énergie consommée, sessions, période, utilisateur, borne. Le bâtiment gagne à séparer :

• Le pilotage électrique (éviter les dépassements, délester),
• La mesure énergétique (comprendre et suivre),
• La valorisation (refacturer, ou suivre par centre de coût).

Pour structurer la mesure sans multiplier les compteurs inutiles, voir Sous-comptage énergétique : savoir précisément où part l’énergie d’un bâtiment.

Facturer n’est pas juste “lire un kWh”

Si l’hôtel souhaite facturer la recharge, il faut cadrer dès l’étude :

• Quelle donnée fait foi (compteur interne de la borne, compteur externe dédié, mesure d’armoire, données OCPP, etc.).
• Le niveau de traçabilité attendu (session, utilisateur, véhicule, chambre, facture interne… selon l’exploitation visée).
• Les limites acceptables : selon les bornes, les mesures existent mais ne sont pas toujours conçues comme un “outil de facturation” au sens strict. Cela se vérifie sur la documentation du fabricant et en recette.

Au Maroc, les exigences exactes (si vous cherchez une refacturation formelle avec un certain niveau de preuve) doivent être confirmées au cas par cas avec vos conseils et fournisseurs. L’article vise ici à structurer le besoin et les tests, sans imposer un cadre réglementaire qui dépend du contexte.

Hôtel : relier la recharge au “parcours client” (sans surcompliquer)

En exploitation, le sujet n’est pas seulement “combien d’énergie a été consommée”, mais comment le service est opéré :

• Qui autorise une session : réception, application, badge, QR code, ou règles automatiques par type d’utilisateur.
• Comment on rattache une session : à une chambre, à un client, à un véhicule de navette, à un centre de coût interne, etc.
• Ce que l’on fait des exceptions : session interrompue, badge perdu, borne hors service, litige, etc.

Recommandation de projet : exiger une procédure exploitation (qui fait quoi, avec quels accès) et une recette “front desk” (tests côté réception) au même titre que les tests techniques. Cette logique se rapproche de la démarche livrables/exploitation décrite dans DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?.

5) Interfaces : OCPP pour l’exploitation, Modbus pour l’intégration bâtiment (souvent)

Le point clé : “compatible” ne suffit pas. Un protocole définit un langage, mais pas forcément le périmètre réellement supporté par la borne, ni le comportement en cas de panne. Il faut donc concevoir par fonctions (pilotage, comptage, droits, supervision) puis vérifier les interfaces disponibles.

OCPP : utile pour superviser, administrer et tracer

OCPP est un standard ouvert pour la communication entre une borne (Charging Station) et un système de supervision/gestion (CSMS). En conception, cela devient le bon candidat pour :

• Remonter des états et événements (disponibilité, sessions, alertes selon produit).
• Administrer des droits d’accès selon l’architecture retenue (badges, listes locales, règles).
• Appliquer des politiques de charge, lorsque la borne et le CSMS supportent réellement les fonctions attendues.

Point de vigilance : OCPP existe en versions. En pratique, votre cahier des charges doit exiger la version et les profils réellement supportés, pas seulement “OCPP”. Pour une référence de définition et de versions côté Open Charge Alliance, voir OCPP protocols (Open Charge Alliance).

OCPP et “smart charging” : optionnel selon profils

Dans OCPP, toutes les fonctions ne font pas partie d’un socle unique : certains périmètres (comme le Smart Charging) dépendent de profils et de mises en œuvre. Conséquence projet : une borne OCPP peut être parfaitement supervisable sans offrir le pilotage fin attendu pour un délestage dynamique. Il faut donc vérifier la prise en charge réelle, côté borne et côté CSMS.

Pour ancrer ce point (sans le surinterpréter), notez que dans le programme de certification OCPP 2.0.1, le profil Core est obligatoire, tandis que Smart Charging et Advanced Security sont listés comme optionnels : cela rappelle qu’un libellé “OCPP” ne suffit pas à décrire le périmètre. Référence : Certification OCPP 2.0.1 (Open Charge Alliance).

Sécurité OCPP : ne pas confondre “certifié OCPP” et “architecture sécurisée”

Une borne connectée est un équipement réseau. Or, le fait d’être “compatible OCPP” ne décrit pas à lui seul la posture de sécurité réelle : selon les produits et le couple “borne + CSMS”, le périmètre de sécurité mis en œuvre (chiffrement, authentification, gouvernance des identités, durcissement réseau, mise à jour) peut varier.

Conséquence projet (pragmatique) : traitez la sécurité comme une exigence de conception et d’exploitation — et pas comme un slogan. En cahier des charges, cela se traduit généralement par :

• un chiffrement des communications et une authentification adaptés à l’architecture retenue (à confirmer selon les capacités de la borne et du CSMS) ;
• une gouvernance des comptes (droits, traçabilité, suppression des accès) ;
• une gestion de cycle de vie (mises à jour, certificats/identités si utilisés, sauvegardes et procédures de renouvellement) ;
• des tests de mode dégradé : une sécurité trop “rigide” peut bloquer l’exploitation si elle est mal opérée ; une sécurité trop “laxe” peut exposer le réseau.

Pour une lecture plus opérationnelle (process, journalisation, gestion des certificats, recommandations), vous pouvez aussi vous appuyer sur le guide OCA : OCPP Security Operations Guide (Open Charge Alliance).

Modbus : utile pour interfacer une logique locale (mais registres variables)

Modbus est un protocole ouvert, très utilisé en bâtiment pour la mesure et certaines commandes. Pour la recharge VE, Modbus peut devenir pertinent lorsque vous visez une logique locale : délestage immédiat, intégration GTB, échange avec un contrôleur local, ou lecture de compteurs.

Mais Modbus n’est pas “plug and play” : le mapping des registres (ce que la borne expose, ce que l’on peut écrire, à quelle unité, à quelle granularité) est spécifique au fabricant. Autrement dit : dire “Modbus” ne garantit pas qu’on puisse imposer une consigne de courant, ni remonter une mesure utile au même niveau de détail que votre besoin. C’est un point à valider sur la documentation de la borne candidate.

6) KNX / GTB : comment intégrer la recharge sans fragiliser l’exploitation

Dans une villa, KNX sert souvent de socle pour coordonner énergie, CVC, éclairage, et scénarios. Dans un hôtel, on est plus proche d’une logique immotique/GTB, où la cohérence des responsabilités est essentielle. Pour le cadre général, voir KNX : le standard ouvert de la domotique et de l’immotique et Qu’est-ce que l’immotique ?.

KNX et recharge : passerelles et périmètre

Dans beaucoup de projets, KNX ne parle pas “nativement” à une borne. L’intégration passe donc par une couche d’interface (par exemple Modbus, API, ou supervision). Le projet doit décider si KNX :

• Lit des informations (état, puissance, énergie) pour un tableau de bord ou une logique énergétique.
• Écrit des consignes (limites) vers une passerelle/contrôleur, lorsque la borne et l’interface l’autorisent réellement.

Pour la stabilité, il est généralement préférable de concevoir une logique où les fonctions essentielles (sécurité électrique, protections, contraintes critiques) ne dépendent pas d’une supervision “confort”. La philosophie est similaire à celle décrite dans nos guides de conception : prévoir une architecture qui reste compréhensible, maintenable et testable.

Tableau, réseaux et documentation : la recharge touche au “socle”

Si KNX (ou une GTB) intervient, cela implique souvent des passerelles IP, des interfaces Modbus, et une intégration réseau. Il faut donc traiter très tôt :

• La place et l’organisation au tableau (voir Tableau électrique KNX : comment le dimensionner et l’organiser ?).
• Le DOE et les sauvegardes, pour ne pas dépendre d’un prestataire unique (voir DOE domotique : quels documents et sauvegardes le client doit-il recevoir ?).

7) Réseau (hôtel et sites multi-usages) : VLAN, accès et isolation

La recharge connectée (bornes, supervision, passerelles) devient un lot IP. En hôtel, cela doit s’inscrire dans l’architecture réseau globale, au même titre que Wi-Fi, vidéosurveillance, VoIP ou GRMS. Deux lectures complémentaires :

• Architecture réseau IP d’un hôtel : comment faire cohabiter Wi-Fi, IPTV, VoIP, CCTV et GRMS ?
• VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ?

Recommandation d’architecture : isoler la recharge comme un réseau technique

Sans sur-spécifier, un principe robuste consiste à isoler :

• Le réseau “technique” (bornes, passerelles, supervision),
• Le réseau “administration” (interfaces de gestion),
• Le réseau “invités” (qui ne doit pas atteindre les systèmes techniques).

Ce n’est pas une obligation “protocole” : c’est un choix de sécurité et de maintenabilité. L’objectif : limiter les flux, simplifier le diagnostic, et éviter qu’un équipement exposé ne devienne une porte d’entrée vers le reste du bâtiment.

Pour une référence “bonnes pratiques” (OT/IT) sur la segmentation logique, NIST décrit notamment l’usage des VLAN comme un moyen de séparation logique lorsque la séparation physique n’est pas possible : NIST SP 800-82r3 — Guide to Operational Technology (OT) Security.

À cadrer au CCTP : dépendances réseau “minimales” de la recharge

Une borne pilotée via OCPP, une passerelle Modbus et un CSMS (cloud ou local) introduisent des dépendances IT qu’il vaut mieux déclarer plutôt que découvrir en fin de chantier. Recommandation de projet : demander au fournisseur (borne et CSMS) une fiche d’interfaces listant au minimum :

• les flux nécessaires au fonctionnement (supervision, temps, résolution DNS, mises à jour si utilisées) ;
• les ports/protocoles requis (à valider sur documentation fabricant, car cela varie) ;
• les adresses/IP ou FQDN attendus (utile pour filtrage sortant) ;
• le comportement si ces dépendances tombent (supervision indisponible, DNS indisponible, etc.).

Ce cadrage facilite ensuite une politique réseau propre : pas d’exposition entrante inutile, flux sortants limités, et diagnostics plus rapides en cas d’incident.

8) Mode dégradé : le critère qui révèle la qualité de conception

La recharge est souvent perçue comme non critique… jusqu’au jour où elle fait partie de l’expérience client (hôtel) ou du quotidien (villa). Le mode dégradé doit donc être défini, puis testé.

Offline OCPP : ce que la supervision ne doit pas vous faire oublier

Les documents OCPP décrivent un comportement “offline” typique : une session en cours continue, les messages peuvent être mis en mémoire tampon puis transmis au retour de connexion ; en revanche, l’autorisation de nouvelles sessions dépend des mécanismes locaux (listes locales, règles, choix d’exploitation). Cela signifie concrètement : le projet doit décider à l’avance ce qui est accepté lorsque le lien vers la supervision n’est plus disponible.

Pour une référence explicite sur ce comportement (buffering, autorisations offline et variables associées), voir le whitepaper OCA : Improving Uptime Monitoring with OCPP (Open Charge Alliance).

Point d’attention : autoriser des sessions “offline” pour des identifiants inconnus peut introduire un risque d’exploitation (notamment si une logique de facturation ou d’autorisation dépend de la supervision). C’est donc une décision métier autant que technique.

Ce qu’il faut exiger : une recette “pannes” et pas seulement des tests de charge

Un cahier des charges sérieux prévoit des essais :

• Perte Internet / perte supervision.
• Redémarrage de borne et reprise.
• Conflit de charges (scénario de pointe) et stabilité du délestage.
• Comportement des droits d’accès en mode offline (selon stratégie retenue).

Dans un hôtel, cette logique s’inscrit dans la démarche de readiness et de passation vers l’exploitation, au même titre que les autres systèmes connectés (voir DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?).

9) Checklists de conception (pratiques) : villa vs hôtel

Checklist villa (projet haut de gamme)

• Puissance disponible : contraintes au tableau et usages concurrents.
• Objectif : recharge “simple” ou optimisation énergie (PV/batterie) ? (voir KNX, photovoltaïque, batteries et recharge VE)
• Délestage : quels circuits sont prioritaires ? (voir Délestage intelligent)
• Interface : OCPP utile ou pas ? Modbus exploitable ou uniquement mesure ?
• Intégration KNX : lecture seule vs consigne, et DOE (voir DOE domotique).
• Mode dégradé : que se passe-t-il si Internet tombe ?

Checklist hôtel (parking clients et exploitation)

• Politique de service : inclus, contrôlé, ou facturable (et comment).
• Gestion des droits : clients vs personnel vs prestataires.
• Comptage : sous-comptage et reporting (voir Sous-comptage énergétique).
• Architecture réseau : VLAN, filtrage, supervision (voir VLAN et architecture IP hôtel).
• Mode dégradé : sessions en cours, autorisation offline, procédures de contournement.
• DOE + passation exploitation : accès, sauvegardes, comptes, runbook (voir DOE & maintenance d’un hôtel connecté).

Conclusion : une borne VE réussie est une architecture testée

Choisir une borne, ce n’est pas seulement choisir une puissance ou un design : c’est définir une architecture capable de tenir la charge (électrique), la réalité d’exploitation (droits, traçabilité), et les pannes (mode dégradé). OCPP, Modbus et KNX/GTB sont des briques utiles, mais leurs fonctions réelles varient selon les modèles et les versions : le projet doit donc exiger des preuves (documentation, profils, essais) et une recette adaptée au site.

Pour cadrer votre projet (villa ou hôtel) et éviter les zones grises entre lots (électricité, réseau, GTB, exploitation), vous pouvez vous appuyer sur un cahier des charges structuré — par exemple en vous inspirant de la méthode décrite dans Cahier des charges KNX pour une villa : que faut-il spécifier avant de consulter un intégrateur ? et en l’adaptant à la recharge.

Si vous souhaitez valider une architecture de recharge (puissance, délestage, interfaces, réseau et exploitation) sur plans avant consultation des fournisseurs, Domocasa peut vous aider à cadrer le périmètre et les tests de recette.