Retour aux projetsÉtude de cas phare · 2025
  • AIoT
  • Vision par ordinateur
  • Systèmes embarqués

Mobilité intelligente · Bénin

Smart ParkingAIoT System

Un prototype de quatre places reliant réservation mobile, accès physique sécurisé, occupation détectée par caméra et supervision en temps réel.

La maquette réunit quatre places marquées, une caméra en hauteur, un retour local et une barrière motorisée dans un même environnement fonctionnel.
04
Places de parking
10 s
Intervalle de capture
04
Couches connectées
01
Prototype intégré

Premier prix

Hackathon Smart Cities · FRIARE · Avril 2025
Distinction / 2025

01 · Le problème

La croissance urbaine dépasse les modes actuels de gestion du stationnement.

Dans les zones urbaines en développement du Bénin, les infrastructures et les pratiques de gestion du stationnement peinent à suivre la demande. Le stationnement anarchique réduit l’espace public utilisable, perturbe la circulation et expose conducteurs comme piétons à des risques évitables.

Les services locaux existants ne couvrent que certaines étapes. Les conducteurs manquent encore d’un moyen fiable pour réserver avant le déplacement, identifier une place libre à l’arrivée et entrer sans intervention manuelle. Les gestionnaires ne disposent pas d’une vue intégrée de l’occupation et de l’activité du parking.

Pression

Une demande urbaine croissante

La mobilité et l’activité économique augmentent la pression sur des espaces de stationnement limités.

Friction

Un stationnement désorganisé

Le stationnement informel obstrue la circulation, occupe l’espace public et accroît les risques.

Manque

Une automatisation locale limitée

Réservation, guidage, accès physique et supervision fonctionnent rarement dans un même système adapté au contexte local.

La question directrice

Comment développer une solution technologiquement avancée, adaptée au contexte local, pour améliorer la gestion des parkings dans les zones urbaines du Bénin ?

02 · Application mobile

Réserver avant d’arriver.

L’application mobile transforme la disponibilité en temps réel en parcours de réservation guidé, puis accompagne la même réservation jusqu’au paiement et à l’accès physique.
  1. 01

    Consulter la disponibilité

    Les places libres et le taux d’occupation sont actualisés sur l’accueil.

  2. 02

    Choisir un créneau

    L’heure d’arrivée, la durée et les besoins d’accessibilité structurent la demande.

  3. 03

    Confirmer et payer

    Un acompte confirme la réservation et active le parcours d’accès.

  4. 04

    Retrouver son accès

    La réservation conserve son statut et son code d’accès.

03 · Architecture de bout en bout

Une boucle opérationnelle. Quatre couches produit.

L’application mobile initie les actions. FastAPI applique les règles métier et synchronise l’état. Le cœur AIoT observe le parking physique. Le dashboard transforme cet état partagé en visibilité opérationnelle.

01
MobileRéservation, paiement et code d’accès.
02
BackendValidation, API et mises à jour WebSocket.
03
Cœur AIoTCapture, vision et décision d’occupation.
04
DashboardSupervision et opérations.

Le prototype physique

Les décisions logicielles atteignent la barrière.

La maquette réunit quatre places marquées, une caméra en hauteur, un retour local et une barrière motorisée dans un même environnement fonctionnel.

  • ESP32
  • ESP32-CAM
  • Clavier 4×4
  • LCD 16×2
  • Servomoteurs
  • Capteurs ultrasoniques
Clavier, LCD, contrôleur ESP32 et actionnement de la barrière sur le prototype.

04 · Pipeline de vision

Transformer une image en quatre états de stationnement.

Chaque ROI est corrigée en perspective avant que YOLO mesure la surface occupée par les véhicules détectés. Un seuil de 2 % met à jour l’état de la place.

Un éditeur PyQt créé pour le projet enregistre la géométrie de chaque place depuis la vue réelle de la caméra.
Vérifications qualitativesScénarios observés · aucune affirmation de précision
Scénario A · Les quatre places sont observées comme occupées.
Scénario B · Deux places sont occupées et deux sont libres.

05 · Contrôle d’accès

Une réservation ouvre une vraie barrière.

Le code d’accès relie une réservation numérique à une action physique, tandis que le matériel local rend l’interaction compréhensible.

  1. 01

    Saisir le code à six chiffres

    Le clavier capture le code et permet sa correction avant validation.

  2. 02

    Valider avec FastAPI

    Le backend vérifie la réservation, l’état du paiement et le créneau.

  3. 03

    Guider et ouvrir

    Le LCD affiche le retour et le numéro d’une place libre avant l’ouverture du servomoteur.

  4. 04

    Détecter le passage et fermer

    Le signal ultrasonique aide le contrôleur à fermer la barrière après le passage du véhicule.

06 · Supervision opérateur

Le même état du parking devient opérationnel.

Le dashboard rassemble disponibilité, occupation, réservations actives et données administratives dans une interface de supervision.

  • Disponibilité en temps réel
  • Réservations
  • Paiements
  • Utilisateurs

07 · Décisions d’ingénierie

Les difficultés ont conduit à de meilleurs outils.

Calibration

La définition manuelle des ROI était trop lente.

Un éditeur PyQt dédié a rendu la géométrie des places visuelle, ajustable et persistante.

Concurrence

L’entrée et la sortie devaient fonctionner ensemble.

Deux tâches FreeRTOS s’exécutent sur les cœurs de l’ESP32, avec un mutex protégeant l’accès Wi-Fi et HTTP partagé.

Électronique

La tension et le nombre de broches ont imposé un autre câblage.

Une alimentation 5 V adaptée et des extensions I2C en cascade prennent en charge le LCD et le clavier sans épuiser les broches de l’ESP32.

Ce qui est démontré

  1. 01Parcours de réservation et d’acompte dans l’application mobile.
  2. 02Validation du code à six chiffres et actionnement physique de la barrière.
  3. 03Acquisition ESP32-CAM et décisions qualitatives sur l’occupation.
  4. 04État backend partagé avec les interfaces utilisateur et opérateur.

Ce qui reste à valider

  1. 01Précision, rappel, mAP et F1 au niveau des décisions.
  2. 02Robustesse en faible luminosité et face aux déplacements de caméra.
  3. 03Résilience hors connexion et synchronisation ultérieure.
  4. 04Déploiement sur des sites plus grands avec plusieurs caméras.

Le résultat

Un prototype AIoT fonctionnel où logiciel produit, vision par ordinateur et matériel embarqué partagent un même état opérationnel.

La maquette à quatre places démontre l’interaction complète. La validation quantitative de la vision et la résilience à l’échelle d’un site constituent l’étape d’ingénierie suivante.