AIDE

Les trucs et astuces

Débloquer un compte utilisateur

Le décorateur AuthRateLimit :

@AuthRateLimit({ attempts: 5, duration: 3600 })

permet de bloquer l'accès à une fonctionnalité si trop de tentatives ont été effectué. L'implémentation est utilisée pour la connexion, dès lors qu'un utilisateur tente de se connecter 5 fois avec le mauvais mot de passe / email, ce dernier doit attendre 1 heure avant d'être débloqué.

Pour débloquer un utilisateur, il faut se connecter à la database de production, soit :

ssh firstName@DB-PROD

Une fois connecté, on se rend dans le répertoire We-Go :

cd /var/wego/

Puis on exécute la commande suivante, afin de se connecter à l'interface redis :

sudo docker exec -it wego-redis-1 redis-cli

On peut lire les différentes clés liées au blocage de connexion avec :

KEYS auth*

Les clés qui commencent par "auth:block" empêchent alors la connexion si la valeur est true. Tandis que les clés qui commencent par "auth:fail" stockent le nombre de tentatives effectuées.

Pour débloquer un utilisateur, il suffit de supprimer la clé "block" liée :

DEL "auth:block:ip:XXX:email:XXX"

Autorisations entre groupes

Introduction

Une nouvelle fonctionnalité apparaît sur We-Go, celle de l'autorisation entre groupes. Dorénavant, un groupe définit ceux qui peuvent se charger chez eux, autrement, l'autorisation sera définit par les emsps.

Fonctionnement

Par défaut, un groupe autorise uniquement les personnes de son propre groupe à pouvoir se charger chez eux. Si on souhaite que les utilisateurs puissent se recharger chez leurs groupes enfants, il faut alors le configurer. Autoriser un groupe à se charger chez soit n'assure pas la réciprocité.

Configuration

La configuration globale actuelle mise en place est la suivante :

Pour configurer une autorisation, vous devez vous rendre sur la page spécifique d'un groupe, dans l'onglet "Autorisations" tel que :

Depuis cet interface, vous pouvez voir les groupes autorisés à se charger, mais également, vous pouvez définir d'autres autorisations. Le bouton "Autoriser les utilisateurs issus des groupes enfants à venir se charger sur les bornes de ce groupe" permet que les groupes enfants de ce dernier puissent se charger chez lui et inversement. En cochant le bouton, on définit en l'occurence que le groupe "DR_EST" est autorisé à se charger chez "DR_EST" donc ça comprend le groupe et ses enfants.

Tandis que le second paramètre "Autoriser les utilisateurs de ce groupe à se charger sur les bornes de ce groupe" est activé par défaut, cela permet aux utilisateurs possédant un rôle sur DR_EST de pouvoir se charger sur les bornes des stations associées à ce groupe. Si on décoche ce paramètre, cela empêche les utilisateurs internes de ce groupe à pouvoir se charger directement, ils passeront alors via Fulli.

Pour créer une nouvelle autorisation, vous pouvez cliquer sur le bouton "Autoriser un groupe à se charger", ce qui affichera une boite de dialogue vous demandant le groupe à ajouter.

Une fois l'autorisation créée, vous aurez la possibilité de supprimer cette dernière ci-besoin grâce au bouton rouge adéquat.

Etablir Fulli pour l'ensemble d'un groupe

Nous allons analyser le cas DR_EST pour déterminer si les sessions de charges de ce groupe et ses sous-groupes sont liées à Fulli et comment mettre en place cette configuration.

Conditions

Pour la 2e règle, si Eiffage Energie Systèmes, qui est parent de DR_EST, autorise TEST ET ESSAIS ce n'est pas impactant car c'est un groupe externe. En revanche, si il autorise DR_EST directement par exemple, alors tous les sous groupes pourront se charger sans passer par Fulli.

Algorithme

Tout d'abord, un bref rappel de l'algorithme pour déterminer les autorisations entre groupes : Par défaut, on peut se charger dans son propre groupe (l'utilisateur doit posséder un rôle direct).

Dès lors qu'on est refusé, on bascule sur les emsps.

Vérifier les autorisations point de vue dev

Récupérons dans un premier temps les id des groupes grâce à :

WITH RECURSIVE GroupHierarchy AS (
      SELECT g.id, g.name, g.id_parent_group as idParentGroup FROM groups AS g WHERE g.id = ? AND g.deleted_at IS NULL
      UNION ALL
      SELECT g.id, g.name, g.id_parent_group as idParentGroup FROM groups AS g
      JOIN GroupHierarchy AS rgh ON g.id_parent_group = rgh.id
      WHERE g.id_parent_group IS NOT NULL AND g.deleted_at IS NULL
    )
    SELECT GROUP_CONCAT(id) AS group_ids
    FROM GroupHierarchy;

Avec ? étant l'id du groupe que l'on souhaite observer, ici 24 pour DR_EST. Il ne faut pas oublier également les groupes parents de DR_EST soit 23 Eiffage Energie Systèmes, 185 Eiffage et 1 Wego car ils ne doivent pas contenir de règles d'autorisations pouvant impacter les enfants, en l'occurence DR_EST.

On récupère donc les règles d'autorisations sur les parents :

SELECT * FROM group_access_authorizations where id_source_group IN (23, 185, 1) ADN deleted_at IS NULL;

Cela nous donne les autorisations accordées sur Eiffage Energie Systèmes, Eiffage et Wego. On voit ainsi qu'aucune règle n'a été établie. On reproduit l'étape cette fois ci pour DR_EST et ses sous groupes que l'on a récupéré ci-dessus.

+----+-----------------+-----------------+---------------------+---------------------+------------+
| id | id_source_group | id_target_group | created_at          | updated_at          | deleted_at |
+----+-----------------+-----------------+---------------------+---------------------+------------+
| 51 |              34 |             185 | 2026-01-07 13:56:01 | 2026-01-07 13:56:01 | NULL       |
| 52 |              64 |             185 | 2026-01-07 13:56:48 | 2026-01-07 13:56:48 | NULL       |
| 53 |             168 |             185 | 2026-01-07 13:57:08 | 2026-01-07 13:57:08 | NULL       |
| 54 |             197 |             185 | 2026-01-07 13:57:44 | 2026-01-07 13:57:44 | NULL       |
| 55 |             891 |             185 | 2026-01-07 13:58:15 | 2026-01-07 13:58:15 | NULL       |
| 56 |            1070 |             185 | 2026-01-07 13:58:34 | 2026-01-07 13:58:34 | NULL       |
+----+-----------------+-----------------+---------------------+---------------------+------------+

On observe alors différentes autorisations établies qui permettent à Eiffage de pouvoir se charger.

Enfin dernière étape, on vérifie les configurations_group pour déterminer si on a bien décoché la charge sur son propre groupe avec :

SELECT * FROM configurations_group where id_group IN () AND configuration LIKE "%authorizeChargeOwnUsers%" AND deleted_at IS NULL;

Avec cette requête on voit que seuls les groupes 39 et 445 ont désactivé la charge chez soit car si authorizeChargeOwnUsers: true ou n'est pas définis alors on considère true. Pour passer outre la configuration initiale de pouvoir se charger sur son propre groupe, il faut expliciter authorizeChargeOwnUsers: false.

Conclusion

Dans DR_EST et ses sous groupes :

Sur l'ensemble des groupes, les utilisateurs internes peuvent se charger directement sans passer par Fulli. Ce qu'il faut faire pour que tout passe par Fulli sur les sous groupes DR_EST :

Script SQL

Je met à disposition le script qui a déjà été injecté :

--Sous groupes de Eiffage Energie Systemes 24 sauf DR EST
-- CY_MULHOUSE
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (1, 67, 185, NOW(), NOW(), NULL);
-- DR Hauts de france
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (2, 50, 185, NOW(), NOW(), NULL);
-- DR I2S
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (3, 217, 185, NOW(), NOW(), NULL);
-- DR MEDITERRANEE
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (4, 488, 185, NOW(), NOW(), NULL);
-- DR Nouvelle Aquitaine
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (5, 165, 185, NOW(), NOW(), NULL);
-- DR Occitanie
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (6, 334, 185, NOW(), NOW(), NULL);
-- DR OUEST
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (7, 143, 185, NOW(), NOW(), NULL);
-- DR IDF ELEC
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (8, 882, 185, NOW(), NOW(), NULL);
-- EES Site Verquin
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (9, 490, 185, NOW(), NOW(), NULL);
-- EES ACCESS GROUP ANNECY BU 04604
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (10, 565, 185, NOW(), NOW(), NULL);
-- EES Centre Normandie
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (11, 179, 185, NOW(), NOW(), NULL);
-- EES NAT Allemagne
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (12, 1000, 185, NOW(), NOW(), NULL);
-- EES DR CENTRE EST
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (13, 223, 185, NOW(), NOW(), NULL);
-- EES NORD
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (14, 53, 185, NOW(), NOW(), NULL);
-- Eiffage Rail 2
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (15, 506, 185, NOW(), NOW(), NULL);
-- EMX
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (16, 941, 185, NOW(), NOW(), NULL);
-- Pole Sud Alsace
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (17, 280, 185, NOW(), NOW(), NULL);
-- Reseau Mobile
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (18, 354, 185, NOW(), NOW(), NULL);

--Sous groupes de Eiffage 185 sauf Eiffage Energie Systeme
-- 00860 Grand Sud Industries
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (19, 187, 185, NOW(), NOW(), NULL);
-- APRR AREA
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (20, 189, 185, NOW(), NOW(), NULL);
-- CONCESSION
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (21, 191, 185, NOW(), NOW(), NULL);
-- DG EIFFAGE
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (22, 118, 185, NOW(), NOW(), NULL);
-- Eiffage Construction
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (23, 553, 185, NOW(), NOW(), NULL);
-- Eiffage Deutschland
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (24, 1021, 185, NOW(), NOW(), NULL);
-- Eiffage Infrastructure
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (25, 186, 185, NOW(), NOW(), NULL);
-- Eiffage Services
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (26, 205, 185, NOW(), NOW(), NULL);
-- EIFFAGE VELIZY
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (27, 229, 185, NOW(), NOW(), NULL);
-- IMPORT VLZ
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (28, 780, 185, NOW(), NOW(), NULL);
-- Sous Traitant
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (29, 1079, 185, NOW(), NOW(), NULL);

--Sous groupes de Clients Externes
-- Arlanxeo pas d'enfants
-- Artois mobilites Lens pas d'enfants
-- ASVEL
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (30, 1148, 1148, NOW(), NOW(), NULL);
-- CAP Val de Saône
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (31, 267, 267, NOW(), NOW(), NULL);
-- CCAS FOUGERES pas d'enfants
-- Centrakor
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (32, 1001, 1001, NOW(), NOW(), NULL);
-- Centre hospitalier de cholet
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (33, 926, 926, NOW(), NOW(), NULL);
-- Charmes Automobiles
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (34, 169, 169, NOW(), NOW(), NULL);
-- Communaute de communes Pays du mont blanc
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (35, 554, 554, NOW(), NOW(), NULL);
-- Communaute de communes Thelloise pas d'enfants
-- CPA REIMS
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (36, 550, 550, NOW(), NOW(), NULL);
-- DAE 2025
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (37, 997, 997, NOW(), NOW(), NULL);
-- DG Des finances publiques DRFIP DIJON pas d'enfants
-- EHPAD
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (38, 953, 953, NOW(), NOW(), NULL);
-- Euroglas pas d'enfants
-- Formes et sculptures bléré pas d'enfants
-- GILL CORPORATION ANGLET pas d'enfants
-- Glas trosch pas d'enfants
-- GRDF
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (39, 733, 733, NOW(), NOW(), NULL);
-- JEL Production Chalets Coeur du lac Malbuisson
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (40, 439, 439, NOW(), NOW(), NULL);
-- John Deere
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (41, 1008, 1008, NOW(), NOW(), NULL);
-- Kelois Bus Besancon pas d'enfants
-- Mademoiselle desserts
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (42, 887, 887, NOW(), NOW(), NULL);
-- Mairie velentigney pas d'eanfnts
-- Marché aux affaires bourguignon pas d'enfants
-- Noremat Ludres pas d'enfants
-- Orange
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (43, 1106, 1106, NOW(), NOW(), NULL);
-- PAX Strasbourg evenements
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (44, 925, 925, NOW(), NOW(), NULL);
-- RTE
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (45, 597, 597, NOW(), NOW(), NULL);
-- SIA Habitat
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (46, 992, 992, NOW(), NOW(), NULL);
-- SKF Saint Cyr Sur Loire pas d'enfants
-- Terres de montaigu communauté d'agglomération
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (47, 511, 511, NOW(), NOW(), NULL);
-- Tun girève pas d'enfants
-- Ville de Mantes La Jolie
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (48, 863, 863, NOW(), NOW(), NULL);
-- Ville de senlis
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (49, 994, 994, NOW(), NOW(), NULL);
-- Ville soissons
INSERT INTO group_access_authorizations (id, id_source_group, id_target_group, created_at, updated_at, deleted_at) VALUES (50, 184, 184, NOW(), NOW(), NULL);
-- Viskase thaon les vosges pas d'enfants

Refonte de l'ACL [DOC Technique]

Contexte

L'actuellement implémentation présente des rôles trop permissifs par rapport à l'utilisation quotidienne qu'ont certains profils utilisateurs. Cela représente un risque de sécurité et également une difficulté à faire évoluer les droits. Il devient necéssaire d'ajouter un nouveau rôle Gestionnaire de parc pour leur restreindre certains droits. L'exploitation a également relevé que certains gestionnaires supprimaient des comptes de membres de l'exploitation car, étant visibles dans leur groupe, ceux-ci sont considérés comme des anomalies aux yeux des gestionnaires qui ne veulent pas les avoir dans leur groupe, ce qui résulte d'une suppression de compte.

But de la refonte des rôles

On aimerait alors une granularité plus fine des permissions. En accord avec l'analyse détaillée de Pierre sur le chantier UX - UI, celui-ci a obtenu nombre de témoignages qui vont en ce sens. Il faut alors créer un nouveau rôle dédié pour ce profil utilisateur.

Actions principales

Mise en place d'une hiérarchie des rôles

Cela permet plus particulièrement lors de suppression / modification d'utilisateur, de ne pouvoir intervenir que si le rôle de la personne modifiée est similiaire ou inférieur au notre. Ainsi, un gestionnaire ne pourra plus supprimer des membres de l'exploitation tel que la hiérarchie définit est la suivante :

MANAGER > TECHNICIAN > FLEET_MANAGER > VIEWER > USER

Refonte font-end de la gestion des droits

L'ACL front-end a été revue pour être plus fidèle à la matrice des droits. Cela assure plus de sécurité et permet une meilleure maintenabilité, évolutivité. Originellement découpé selon canRead et canWrite dans chaque components, on a voulu plutôt retranscrire exhaustivement les droits liés, permettant alors de désactiver directement des pages ou fonctionnalités selon le rôle. Cela facilite la fluidité du parcours utilisateur et on pourra également imaginer à l'avenir des interfaces dédiés plus poussés. Par exemple, concernant la situation écrite en préambule du document, on pourrait personnaliser la page utilisateurs pour afficher 2 boutons distincts, facile d'utilisation, qui expliciterait la suppression du compte ou la suppression du rôle dans le groupe.

Implémentation technique

Le front-end ne sécurise pas seul, c'est le back-end qui vérifie toujours, néanmoins il sert à l'UX.

Back-end

Dans src/acl/roles.enum.ts on retrouve les différents rôles associés aux utilisateurs. Chaque endpoint situé dans les controllers utilise l'ACL par l'intermédiaire de décorateurs. Les guards vérifient la connexion et assurent que le rôle utilisé existe :

@UseGuards(AuthenticationGuard, AuthorizationGuard)

On désigne ensuite quels sont les rôles à pouvoir accéder a l'endpoint :

@ROLES(Role.MANAGER, Role.TECHNICIAN, Role.VIEWER)

Front-end

Dans src/app/models/acl-rights.ts on établit un inventaire exhaustif des fonctionnalités. On les attribue aux rôles dans src/app/models.roles.ts

Ensuite, dans chaque components on vérifie les droits utilisés qu'on stocke dans la variable aclRights soit :

aclRights: AclRights = {};

constuctor(private aclService: AclService){}

this.aclRights[ACL_READ_LOCATIONS_MAP] = this.aclService.can(ACL_READ_LOCATIONS_MAP);

Matrice des droits

Disponible ci-joint.

Edit 05/05/2026 Je ne crois pas avoir les droits de modifier une pièce jointe, je met donc une capture d'écran en complément sur certaines fonctionnalités qui ont pu changer suite à une réunion le 28/04/2026

Accès API

Fonctionnement & exemple

Cette documentation permet de mieux comprendre le fonctionnement d'accès API en s'appuyant sur l'exemple de la consigne Dynamique/Manuel de smartCharging.

Structure

La table public_api_clients permet de générer une clé API relié à un rôle, elle contient alors :

Seul le rôle MANAGER peut gérer les clés des autres utilisateurs. Voici les routes principales :

Un Guard CombinedAuthGuard a été mis en place pour permettre d'utiliser une route soit via jwtToken (Supervision) ou par basic token (clé API). Le Guard ApiScopeGuard permet quant à lui d'assurer des droits autorisés pour la clé.

Exemple concret consigne smartCharging externe

Dans notre cas, on souhaite autoriser un client externe à pouvoir modifier la puissance d'une station. Pour se faire, on créé un utilisateur MANAGER ou TECHNICIAN sur le groupe désiré, afin qu'il ait les droits de modifier une station. Pour autant, on ne communiquera pas le mot de passe du compte puisque c'est la clé API générée qui sera utilisée uniquement. Ainsi, grâce à la mise en place de ApiScopeGuard et de features, on évite que le client puisse interférer sur d'autres routes.

  @UseGuards(CombinedAuthGuard, AuthorizationGuard, ApiScopeGuard)
  @ROLES(Role.MANAGER, Role.TECHNICIAN)
  @ApiScope("locations:update")
  @ApiParamIdOrSlug
  @Put(":idOrSlug")
async update(
    @ParseIdOrSlug() idOrSlug: LocationParamIdOrSlugDto,
    @Body() location: LocationUpdateDto,
    @SessionGroups() inGroups: number[],
    @Req() req: Record<string, unknown>,
  ): Promise<number> {}

L'utilisation de CombinedAuthGuard permet également aux utilisateurs connectés en supervision de pouvoir toujours utiliser la route via jwtToken.

Nouveau rôle : Gestionnaire

Contexte

Les utilisateurs gestionnaires étaient jusqu'alors affectés au rôle de Manager ce qui leur permettaient d'avoir accès à des fonctionnalités trop importantes par rappor tà leur status. Ce rôle permet alors d'assurer une matrice des droits plus fidèle à la réalité.

Changements

Désormais, les gestionnaires n'auront plus le droit de créer ou modifier des bornes (cela comprend également les points de charges et connecteurs), des stations, des groupes et des tarifs. Ils peuvent toutefois toujours gérer les badges et utilisateurs. Notons par ailleurs que lorsqu'ils supprimeront un utilisateur de leur groupe, cela va en réalité supprimer uniquement le rôle associé, empêchant ainsi la suppression d'un compte utilisateur que l'on pouvait observé auparavant.

Actions sur une borne

Concernant les actions possibles sur une borne, ils peuvent :

Mode d'emploi

L'entièreté des rôles anciennement Manager ont été basculé en Gestionnaire hors utilisateurs se situant au niveau du groupe racine Wego. Pour appliquer le rôle à de futurs utilisateurs, cela se trouve dans le formulaire de la page utilisateurs suivant :

📋 Guide EMAT — Comprendre et activer la synchronisation We-Go

À destination de : équipe hotline & clients
Sujet : Comment les données We-Go remontent automatiquement dans EMAT

🔍 Comment ça fonctionne ?

Chaque mois, le logiciel EMAT d'Eiffage vient récupérer automatiquement les données du mois précédent depuis la plateforme We-Go.

Il récupère 3 types d'informations :

⚠️ Important : We-Go ne "pousse" pas les données vers EMAT. C'est EMAT qui vient les chercher, généralement en début de mois pour le mois précédent.

✅ Checklist des prérequis

Pour qu'un conducteur ou une donnée apparaisse dans EMAT, toutes les conditions suivantes doivent être remplies côté We-Go. Utilisez cette checklist pour diagnostiquer un problème.

👤 Pour qu'un conducteur remonte dans EMAT

# À vérifier Pourquoi c'est important
☐ 1 Le conducteur est bien créé dans We-Go Sans compte, aucune donnée n'est générée
☐ 2 Le conducteur est rattaché à un groupe Eiffage dans We-Go Seuls les groupes Eiffage sont exportés vers EMAT
☐ 3 La plaque d'immatriculation du conducteur est renseignée 🚨 Sans plaque, le conducteur est invisible dans tous les exports
☐ 4 Le conducteur a un groupe de facturation (invoiced group) C'est ce groupe qui détermine son "Entité" dans EMAT
☐ 5 Le groupe de facturation contient un numéro BU à 5 chiffres dans son nom Ex : BU12345, 12345-Lyon. Sans les 5 chiffres, l'entité n'est pas reconnue par EMAT

🔌 Pour qu'une recharge remonte dans EMAT

# À vérifier Pourquoi c'est important
☐ 1 Toutes les conditions du conducteur (tableau ci-dessus) Prérequis de base
☐ 2 La recharge a bien une énergie consommée > 0 kWh Les sessions "à blanc" ou les connexions sans charge ne sont pas exportées
☐ 3 La recharge est terminée (pas en cours) Seules les sessions terminées dans le mois précédent sont incluses
☐ 4 La recharge a été faite sur une borne We-Go (pas en itinérance/roaming) Les recharges sur des réseaux tiers (via roaming) ne sont pas exportées

📏 Pour qu'un relevé kilométrique remonte dans EMAT

# À vérifier Pourquoi c'est important
☐ 1 Toutes les conditions du conducteur (tableau ci-dessus) Prérequis de base
☐ 2 Le conducteur a saisi son kilométrage dans l'application We-Go ce mois-là Les relevés ne sont pas automatiques sauf si un système de télématique est connecté
☐ 3 Le relevé a été saisi durant le mois précédent Seuls les relevés du mois M-1 sont exportés
☐ 4 La plaque du véhicule au moment du relevé correspond à la plaque actuelle du conducteur Si le conducteur a changé de véhicule, les anciens relevés ne remontent pas

💡 Astuce : Si un conducteur oublie de saisir son kilométrage, il peut le faire rétroactivement dans l'app We-Go, à condition que ce soit pour le mois en cours (le relevé sera exporté le mois suivant).

🏗️ Pour qu'une borne de recharge apparaisse dans EMAT

# À vérifier Pourquoi c'est important
☐ 1 La borne est rattachée à un site (location) d'un groupe Eiffage dans We-Go Seules les bornes Eiffage sont exportées
☐ 2 Le nom du groupe du site contient "BU" et un numéro à 5 chiffres Ex : BU12345 Chantier Paris. C'est ce qui identifie la Business Unit dans EMAT
☐ 3 La borne possède un identifiant EMI3 C'est le code unique de la borne dans le système We-Go

🆘 Mon problème n'est pas résolu — que faire ?

Si après avoir vérifié toutes les cases, les données ne remontent toujours pas, voici les informations à fournir à l'équipe technique We-Go :

  1. Le nom complet du conducteur concerné
  2. Sa plaque d'immatriculation telle qu'elle est saisie dans We-Go
  3. Son groupe de facturation (nom exact)
  4. La période concernée (quel mois ne s'est pas synchronisé ?)
  5. Le type de donnée manquante : recharge ? kilométrage ? badge ?

📞 Contact

Pour toute question ou problème de synchronisation : équipe We-Go