Standards et guides de mise en œuvre
L'application conducteur : particuliers et flottes
Une application de recharge se juge dans les dix secondes qui précèdent le démarrage d'une session. Tout le reste — gestion de compte, historique, support — est secondaire par rapport à ce moment.
Le moment qui compte
Un conducteur qui approche une borne a besoin, dans l'ordre : la confirmation que le connecteur est réellement disponible (pas seulement « en ligne »), un moyen de démarrer la session qui fonctionne même avec un signal faible, et une confirmation immédiate que la recharge a commencé. Les applications qui échouent sur ce point ne le font pas bruyamment — les conducteurs cessent simplement de faire confiance au réseau et vont ailleurs.
- Afficher le statut du connecteur en direct, pas celui de la borne. Un site à quatre connecteurs avec une prise cassée ne doit pas apparaître comme « disponible ».
- Prendre en charge le démarrage par badge (NFC/RFID) comme solution de repli au démarrage via l'application. Ne faites pas de l'application un point de défaillance unique pour l'autorisation.
- Confirmer le démarrage de session par un signal visible sans ouvrir l'application — une LED ou un bip de la borne, pas seulement une notification push qui peut être retardée.
Exigences pour les particuliers
- Planification d'itinéraire : recherche de bornes tenant compte du trajet et de la fiabilité réelle, pas seulement des emplacements enregistrés.
- Tarification transparente : le prix affiché avant le démarrage d'une session doit être celui réellement facturé, frais d'immobilisation inclus, affiché clairement plutôt qu'en petits caractères.
- Clarté sur l'itinérance : lorsqu'une session passe par un partenaire d'itinérance (OCPI), l'application doit indiquer honnêtement quel réseau exploite la borne physique — les conducteurs résolvent les problèmes plus vite quand ils savent qui appeler.
- Moyens de paiement adaptés au marché : mobile money et carte, pas carte uniquement. Ce n'est pas optionnel sur la plupart des marchés africains.
Là où les besoins des flottes diffèrent
Les opérateurs de flottes ne sont pas de simples particuliers avec plus de véhicules — ils ont besoin de primitives entièrement différentes :
- Planification de dépôt : logique de file d'attente et de réservation pour que les véhicules chargent dans l'ordre dont le dépôt a besoin, pas au premier arrivé.
- Répartition des coûts : les sessions doivent être attribuables à un véhicule, un conducteur et un centre de coût, avec des données exportables pour la comptabilité de flotte — pas seulement un reçu individuel.
- Accès multi-conducteurs : un même véhicule peut être conduit par différentes personnes selon les équipes ; l'autorisation doit suivre le véhicule ou l'équipe, pas le compte d'un seul conducteur.
- Recharge jusqu'à une cible, pas jusqu'au plein : les logiciels de planification de flotte ont souvent besoin que l'application/l'API permette d'arrêter à un niveau de charge ou une durée cible, pour gérer la santé de la batterie et le débit du dépôt.
- API en priorité : les clients flotte voudront intégrer les données de session et de statut dans leurs propres systèmes de répartition ou de télématique. Traitez l'API comme un produit, pas comme un à-côté de l'application.
Réalités d'accessibilité et de connectivité
Concevez pour des conditions de faible bande passante et des appareils Android plus anciens, qui représentent une large part du parc installé sur les marchés cibles. Une application conducteur qui exige un téléchargement initial volumineux ou une connexion haut débit permanente exclura précisément les utilisateurs qui ont le plus besoin d'une recharge publique fiable.