Subscribe & get the latest news in your email
By
Joachim Lohse
September 15, 2026
La borne indique Disponible. Le conducteur branche le véhicule. Rien ne se passe. Ou bien la session dure deux heures et s'interrompt à 4 % de l'objectif, alors que le tableau de bord affiche le port comme étant en ligne tout du long.
Chaque opérateur est confronté à ce problème chaque semaine. Pourtant, presque personne ne publie l'arbre de décision associé.
Ce guide constitue cet arbre. Il divise les échecs de session de recharge en trois branches, basées sur le seul élément visible à 6h du matin sur un site — le comportement de la borne — puis fournit le signal de diagnostic pour chacune : le statut OCPP et le code d'erreur attendus, l'emplacement de la preuve (journal de la borne ou du backend), et la méthode pour distinguer une défaillance côté véhicule, côté borne ou côté réseau. La dernière section traite du volet opérationnel : quelles pannes se résolvent d'elles-mêmes, lesquelles nécessitent une réinitialisation à distance ou une intervention sur site, et comment gérer chaque cas sans submerger votre équipe d'alertes.
L'ordre a son importance. La première branche signifie que la borne ne fonctionnera pas, quoi que fasse le conducteur. Les branches deux et trois méritent l'attention du conducteur.
À quoi cela ressemble. Le voyant d'état est rouge. L'écran affiche « indisponible », « en défaut », « hors service » ou un message équivalent. C'est visible avant même tout branchement.
Ce que le conducteur doit faire. Rien. Il est important de le préciser clairement, car les conducteurs perdent du temps ici. Une borne dans cet état ne lancera jamais le processus d'authentification : brancher le câble et présenter une carte ne déclenchera aucune session, peu importe le nombre de tentatives. S'il existe une autre borne, utilisez-la. Si c'est la seule option, contactez le gestionnaire du site ou le support technique pour qu'ils interviennent.
Ce que cela signifie en coulisses. En OCPP 1.6, il s'agit d'un StatusNotification avec le statut Faulted ou Indisponible, ainsi que le errorCode correspondant, constituent la charge utile de diagnostic. Voici les plus courants et ce qu'ils indiquent :
Trois causes distinctes peuvent mener à cette situation, avec des probabilités différentes :
ChangeAvailability vers Inoperative dans le backend, et non d'une panne. Cela ne devrait jamais surprendre votre équipe, mais c'est régulièrement le cas pour les conducteurs.Ce que ce n'est généralement pas : un problème de connectivité. C'est un diagnostic erroné fréquent. Les chargeurs sont conçus pour continuer à fonctionner pendant un certain temps sans connexion au backend, en utilisant des listes d'autorisation mises en cache. Un chargeur ayant perdu sa connexion réseau continuera généralement à charger ; il ne passera pas en état Faulted. Si vos sites subissent de réelles périodes hors ligne, c'est un cas pour connectivité avec redondance et basculement et prise en charge de la recharge hors ligne — mais ne cherchez pas une explication liée au réseau si vous voyez un voyant rouge.
À quoi cela ressemble. Le voyant de la borne est vert. Le conducteur branche le câble et s'authentifie — via l'application mobile, une carte de recharge ou l'authentification automatique du véhicule. La borne semble réagir : l'écran change, elle semble se préparer. Puis elle repasse en mode disponible ou en état de défaut. Débranchez le câble et elle redevient verte.
C'est la situation la plus déroutante pour les conducteurs, car tout semble indiquer que cela devrait fonctionner.
Séquence de relance par le conducteur — dans cet ordre :
Ce qui se passe en coulisses. La borne passe de Disponible → En préparation au moment où un câble ou une carte est présenté. Cette transition est normale et indique que le chargeur fonctionne correctement. C'est ce qui se passe ensuite qui pose problème, et il existe deux types de pannes distinctes qui semblent identiques depuis l'extérieur du véhicule.
Famille A — autorisation et backend. Le chargeur envoie une requête Authorize (ou l' idTag dans StartTransaction) au backend. Le backend répond avec un statut idTagInfo :
Invalid — carte ou compte inconnu du systèmeBlocked — connu, mais désactivéExpired — période de validité dépasséeConcurrentTx — ce jeton a déjà une session ouverte ailleursAccepted — autorisé à chargerTouteAccepté réponse met fin à la tentative et la borne revient à l'état Disponible. C'est déterministe : l'échec sera identique à chaque nouvelle tentative, ce qui est révélateur. La preuve se trouve dans le journal du backend, pas dans la borne. La borne sait seulement qu'elle a été refusée ; le backend en connaît la raison.
Il existe une troisième possibilité dans cette catégorie : le backend n'a jamais répondu, en raison d'un délai d'attente dépassé ou d'une surcharge. C'est moins courant, mais cela produit le même comportement visible — et contrairement à une carte rejetée, une nouvelle tentative peut réellement aboutir. C'est le seul cas où « réessayez » est un conseil valable plutôt qu'une tactique dilatoire.
Famille B — la borne ne parvient pas à communiquer avec le véhicule. La borne et le véhicule échangent des données via le fil pilote du câble : état de préparation, courant disponible, codes d'erreur. Si le véhicule est stationné depuis un certain temps, son contrôleur de communication peut être passé en mode veille et ne pas se réveiller pour répondre.
Dans le protocole OCPP 1.6, cela apparaît sous la forme errorCode: EVCommunicationError, ou comme une session qui atteint l'état SuspendedEV et y reste — la borne est prête et propose de l'énergie, mais le véhicule ne la prend pas. Cette distinction est l'indicateur le plus utile de tout ce guide : SuspendedEVSE signifie que la borne ou le site restreint l'alimentation ; SuspendedEV signifie que le véhicule est en attente. L'un est à votre charge, l'autre relève de la flotte.
Le cycle arrêt/marche/arrêt de la séquence de nouvelle tentative sert spécifiquement à réveiller le contrôleur du véhicule. Cela fonctionne assez souvent pour être tenté avant toute escalade.
Comment distinguer rapidement les familles : si l'échec est identique à chaque fois avec un retour propre vers Disponible, suspectez un problème d'autorisation — vérifiez le backend. Si le comportement varie d'une tentative à l'autre, ou si la session reste bloquée dans un état suspendu, suspectez un problème de communication avec le véhicule. Alertes OCPP en temps réel et état du chargeur et du connecteur vous permettent d'obtenir cette distinction sans avoir à lire les journaux bruts sur le terrain.
À quoi cela ressemble. La session a été initiée correctement. Le véhicule a consommé de l'énergie — plusieurs kWh, parfois pendant des heures. Puis, il s'est arrêté, alors que le véhicule n'était pas encore chargé à bloc.
Actions du conducteur : démarrez une nouvelle session. Si cela ne fonctionne pas, éteignez et rallumez le véhicule, puis réessayez. Si le problème persiste, essayez une autre carte ou un autre compte.
Ce que cela signifie en coulisses. Étant donné qu'une session a fonctionné, une défaillance matérielle est l'explication la moins probable. Privilégiez d'abord les causes liées aux règles d'utilisation.
Cause la plus fréquente : une limite d'état de charge (SoC) intentionnelle. De nombreux dépôts et sites publics limitent les sessions à un état de charge cible. C'est une mesure délibérée pour deux bonnes raisons. Premièrement, la vitesse de charge de la plupart des véhicules chute brutalement au-delà de 80 % de SoC environ ; le dernier cinquième prend donc un temps disproportionné et bloque la borne pour le véhicule suivant. Deuxièmement, charger systématiquement à 100 % chaque jour réduit sensiblement la durée de vie de la batterie. Si votre flotte procède ainsi, assurez-vous que les conducteurs en sont informés : un arrêt prévu mais non documenté génère autant d'appels au support qu'une panne réelle.
Deuxième cause : un plafond d'autorisation. Sur les sites publics, les cartes de carburant et les cartes bancaires sont soumises à des limites de pré-autorisation. Lorsque le coût de la session atteint ce plafond, de nombreux opérateurs interrompent la session plutôt que de prendre un risque financier. Une nouvelle session réinitialise ce plafond, ce qui explique pourquoi un redémarrage fonctionne.
Troisième cause : un arrêt effectif. OCPP StopTransaction comporte un champ reason , et c'est le moyen le plus rapide de résoudre ce problème :
Un arrêt Remote sur un site de dépôt est très souvent dû à votre propre gestion de la charge, qui exécute exactement ce pour quoi elle a été configurée. Vérifiez ce point avant d'envoyer une équipe sur place.
Ces deux journaux répondent à des questions différentes, et consulter le mauvais dès le départ fait perdre les vingt premières minutes de toute investigation.
InternalError ou AutreErreur.La règle pratique : si la défaillance était déterministe et propre, il s'agit d'un problème de backend. Si elle était désordonnée, intermittente ou physique, il s'agit d'un problème de borne.
Accéder au journal de la borne nécessitait autrefois un déplacement sur site. Cela ne devrait plus être le cas. Diagnostics matériels et journalisation et audit des bornes permettent de gérer cela depuis un bureau, ce qui est crucial car la différence entre un diagnostic à distance et sur site représente une journée de travail pour un technicien.
Le diagnostic représente la moitié du travail. L'autre moitié consiste à acheminer les informations — décider quelles défaillances méritent réellement l'attention d'un humain.
Auto-réparation — enregistrez-la, ne créez pas d'alerte. Réduction de puissance thermique qui se résorbe. Événements SuspendedEV isolés sur des véhicules qui finissent par charger normalement. Brèves pertes de signal qui se rétablissent dans la fenêtre de nouvelle tentative. Créer des alertes pour ces cas habitue votre équipe à ignorer les notifications, ce qui est pire que de les manquer.
Réinitialisation à distance — tentez-la automatiquement, n'alertez qu'en cas d'échec. ConnectorLockFailure, ReaderFailure, et de nombreux InternalError se règlent par une réinitialisation logicielle. Essayez cette solution et ne faites appel à un technicien que si la réinitialisation ne suffit pas ou si le défaut persiste. Contrôle à distance du chargeur et mises à jour automatiques du micrologiciel permettent de gérer la plupart de ces cas ; les défauts récurrents liés au micrologiciel, en particulier, doivent être résolus par le déploiement d'une nouvelle version plutôt que par des réinitialisations répétées.
Intervention sur site : alertez immédiatement en fournissant le contexte. GroundFailure, PowerSwitchFailure, PowerMeterFailure, dommages physiques au connecteur et tout problème persistant après deux réinitialisations. Un chargeur réellement défectueux nécessite une inspection ou une réparation d'urgence, ce qui peut prendre de quelques heures à plusieurs jours. L'alerte doit être transmise avec le code d'erreur, l'extrait du journal et l'historique des réinitialisations déjà joints, afin que le technicien dépêché sur place sache exactement à quoi s'attendre. Notifications multicanaux, le centre d'alertes, et la collaboration d'équipe sur les alertes sont ce qui empêche cela de devenir un simple standard téléphonique.
Ce n'est pas à vous de le réparer ? Transférez-le. Les pannes liées au véhicule relèvent de la flotte ou du constructeur. Les problèmes de paiement et d'itinérance incombent à l'eMSP. Les problèmes d'approvisionnement concernent le fournisseur d'énergie. Le coût ici n'est pas la réparation, mais l'heure passée à établir que la faute ne vous incombait pas dès le départ. Le service d'assistance de niveau 1 et le support de niveau 2 existent pour absorber ce triage avant qu'il n'atteigne vos ingénieurs.
Le principe fondamental : chaque alerte doit correspondre à une action qu'une personne peut entreprendre. Tout le reste n'est que bruit, et c'est à cause de ce bruit que les vraies pannes passent inaperçues. Associer cela à la maintenance préventive des bornes de recharge permet d'éliminer une part significative de ces défaillances de la file d'attente réactive.
Pourquoi ma borne indique-t-elle « Disponible » mais refuse-t-elle de lancer une session ?La borne est prête ; le problème survient à l'étape suivante. Il s'agit le plus souvent d'un refus d'autorisation de la part du backend, d'un délai d'attente dépassé, ou d'un défaut de communication du véhicule via le câble. Éteindre et rallumer le véhicule, puis réessayer dans les 20 secondes, permet généralement de résoudre les cas liés au véhicule.
Pourquoi ma session de recharge s'est-elle arrêtée avant que la batterie ne soit pleine ?C'est généralement intentionnel. De nombreux dépôts et sites publics limitent les sessions à un état de charge cible pour libérer le connecteur et préserver la durée de vie de la batterie. L'autre cause fréquente est une limite de pré-autorisation sur une carte de carburant ou de crédit. Démarrer une nouvelle session permet normalement de poursuivre la charge.
Comment savoir si le problème vient de la borne ou du véhicule ?Vérifiez quel côté a suspendu la session. Dans le protocole OCPP, SuspendedEVSE signifie que la borne ou le site interrompt l'alimentation ; SuspendedEV signifie que le véhicule n'accepte plus la charge. EVCommunicationError indique un problème de liaison de données par câble avec le véhicule.
Une borne cesse-t-elle de fonctionner en cas de coupure internet ?En général, non. Les bornes continuent de fonctionner pendant un certain temps sans connexion au backend grâce à l'autorisation en cache. Une borne affichant un voyant rouge ou une erreur est bien plus souvent confrontée à un problème matériel ou de configuration qu'à un souci réseau.
Quelles pannes de recharge nécessitent une intervention sur site ?Les défauts de mise à la terre, les pannes de contacteur ou de compteur, les dommages physiques et toute erreur persistant après deux réinitialisations à distance. La plupart des autres types de pannes — échecs de verrouillage, problèmes de lecteur, événements thermiques et nombreuses erreurs internes — se résolvent à distance.
Réduisez les déplacements inutiles. Ampcontrol fournit aux opérateurs des alertes OCPP en temps réel, des diagnostics et un contrôle à distance pour toutes les marques de bornes — la base pour surveiller et entretenir vos bornes et pour utiliser l'OCPP pour vos opérations de recharge à grande échelle. Réservez une démo pour voir comment cela s'applique à vos propres sites.
Ampcontrol est un logiciel basé sur le cloud qui se connecte de manière transparente aux réseaux de recharge, aux véhicules, aux systèmes de flotte et à d'autres systèmes logiciels. Aucun matériel n'est nécessaire, il suffit d'une intégration unique.
