CHAPITRE III.

CHOIX DE LA TECHNOLOGIE ET MISE EN PLACE DE

LA SOLUTION

Ce chapitre détaille le choix technologique et la mise en œuvre du

système automatique de barrière. On présente le cahier des charges
(objectifs du projet, description des modules, budget prévisionnel, planning,
conditions de déploiement), puis la sélection des plateformes candidates.

3.1 Cahier des charges

3.1.1 Présentation du projet

Le projet vise à automatiser l’accès d’une barrière sécurisé en

reconnaissant automatiquement la plaque d’immatriculation d’un véhicule et
en ouvrant une barrière si le véhicule est autorisé. L’objectif général est
d’améliorer la sécurité et la fluidité d’accès : un véhicule s’approche, un
capteur déclenche la prise d’une photo de la plaque, un programme la lit et
la compare à la base de données, puis en cas de validation la barrière
s’ouvre mécaniquement. La solution exploite la vision par ordinateur (Open
CV) et l’OCR (Tesseract) pour détecter la plaque, ainsi qu’un microcontrôleur
(Arduino) pour piloter le moteur de la barrière. Les objectifs spécifiques sont:

 Automatiser la capture et la reconnaissance de la plaque

d’immatriculation (traitement d’image avec Open CV et OCR qui permet de
transformer une image en texte modifiable et exploitable par un ordinateur.)
；
 Gérer une base de données des plaques autorisées (ajout/suppression
via interface utilisateur) ；
 Piloter mécaniquement la barrière par un servomoteur via Arduino；
 Garantir la fiabilité et la sécurité du système (détection anti-intrusion,
journalisation des passages, respect de la vie privée).
 Le périmètre retenu pour le prototype inclut l’installation d’une caméra
haute définition, d’un capteur IR (ou ultrasons) pour détecter le véhicule,
d’un Arduino gérant la barrière, et d’une interface de supervision (application
Windows ou Web). L’architecture visée reste modulaire : capteurs et caméras
sur site, microcontrôleur pour la commande motrice.

3.1.2 Description du projet

Le système se compose des modules suivants :

 Caméra : capture l’image de la plaque lorsque le capteur détecte un

véhicule.
 Capteur ultrason : détecte la présence d’un véhicule à l’entrée,
déclenchant la prise d’image. Le capteur signale l’ordinateur (via Arduino).
 Base de données : stocke la liste des plaques autorisées et
l’historique des passages (date, heure, résultat). On va utiliser SQLite (fichier
local), l’essentiel est qu’il soit accessible en local sur le PC sans coût
supplémentaire.
 Arduino Uno : reçoit des commandes série. Si la plaque est validée,
l’Arduino actionne la barrière (via un servomoteur ou un relais). L’Arduino
assure le contrôle temps-réel du moteur sans surcharge.
 Barrière (servi/moteur) : actionnée par le servomoteur piloté par
Arduino. Par exemple, un servomoteur 5V monté sur la barrière du portique,
ou un petit moteur DC avec un driver de puissance.

Le flux d’information principal est :

1. Le capteur détecte un véhicule et envoie un signal.
2. La caméra capture l’image de la plaque du véhicule.
3. Le PC Windows reçoit l’image et lance le traitement : détection
de plaque (Open CV), OCR (Tesseract) pour extraire le texte.
4. Le programme compare la plaque extraite à la base de données.
5. Si la plaque est autorisée, le PC envoie une commande série à
l’Arduino (par ex. caractère ‘O’ pour OUVERTURE).
 6. L’Arduino active le servomoteur pour ouvrir la barrière. Sinon la
barrière reste fermée (message ‘N’ pour refus).
7. Le système enregistre dans les logs l’événement (date, plaque,
validation).

Figure 1 : Illustration de flux d'information

Cette configuration modulaire (caméra + PC + Arduino) permet la

montée en charge : le PC Windows offre assez de puissance pour l’ANPR en
temps réel, tandis que l’Arduino gère efficacement le contrôle direct de
l’actionneur. Le coût matériel total reste modéré (voir §3.1.3) et le système
peut évoluer (ajout de caméras, amélioration logicielle, extension réseau,
etc.).

3.1.3 Coût du projet

Le budget estimé (par prototype) est résumé ci-dessous. Les

montants sont indicatifs et peuvent varier selon fournisseurs ; ils
incluent les tarifs approximatifs du matériel en dollars (incluant TVA).
Les logiciels prévus sont open-source ET gratuits:
 Composant Modèle/type Qté Prix FC Total

Caméra ESP32 1 70.000 70.000

Kit Complet Arduino

Microcontrôleur 1 200.000 200.000
pour 1 site

Python, Open
Logiciels et frais CV, Tesseract,
20.000 20.000
d’utilisation IDE Arduino,
bibliothèques

Main d’oeuvre 110.000 110.000

Total 380.000

Table 1 : Cout du projet

3.1.4 Chronogramme du projet

Un planning prévisionnel sur six à huit mois est proposé,

comprenant les phases d’analyse, de préparation, de développement,
d’essais et de déploiement. Les dates ci-dessous (2026) sont
indicatives. Chaque phase comporte des jalons (revues formelles,
démonstrations, validation client). Le diagramme Gantt simplifié ci-
dessous (Mermaid) illustre la répartition temporelle :
 Figure 2 : Chronogramme du projet
Ce planning inclut un chevauchement des tâches de
développement (PC et Arduino) et prévoit des phases de test
intermédiaires. Les dates peuvent être adaptées en fonction des
retours (itérations supplémentaires). L’approche incrémentale –
livraisons fréquentes – garantit une montée en puissance progressive
du prototype.

3.1.5 Conditions d’applicabilité

 Prérequis techniques : le site doit disposer d’une alimentation

électrique stable et d’au moins une prise RJ45 ou Wi-Fi pour éventuelle
communication externe. Le PC Windows doit être à jour (Windows 10 64-bit
minimum avec .NET Framework et drivers nécessaires. La caméra doit être
protégée contre la pluie/vent si installation extérieure (boîtier étanche, filtre
IR).
 Environnement optique : l’éclairage doit être suffisant pour la
caméra (lumière naturelle ou artificielle). En cas de faible luminosité, ajouter
une source IR/LED ou flash synchronisé. Éviter reflets et éblouissements sur
les plaques (position adaptée). Les véhicules doivent être immobilisés ou très
lentement mobiles lors de la capture (vitesse limitée).
 Contraintes légales : la CNIL considère la plaque d’un véhicule
comme donnée personnelle identifiant indirectement une personne physique.
 Le traitement (capturer, stocker) doit respecter le RGPD : accès
restreint, suppression des données inutiles, chiffrement éventuel des logs, et
conservation des images seulement si nécessaire (par exemple anonymiser
après X jours). Informer les usagers de la collecte (panneau d’information) si
applicable. En cas d’accès à internet (consultation distante), sécuriser les
échanges (HTTPS, VPN).
 Contraintes humaines : les utilisateurs finaux (agents de sécurité)
devront être formés à l’utilisation de l’interface de gestion (ajout/suppression
de plaques autorisées, consultation des logs). Un protocole de secours doit
exister (par exemple ouverture manuelle si le système automatique échoue,
arme de secours électrique). L’ergonomie doit être simple pour limiter les
erreurs humaines.
 Fiabilité et redondance : prévoir l’auto-diagnostic (ouverture des
logs, watchdog sur Arduino) pour détecter les pannes (caméra HS, PC bloqué,
Arduino non connecté, etc.). Privilégier l’alimentation ininterruptible
(onduleur) pour le PC et l’Arduino en cas de coupure courte afin de pouvoir
fermer proprement. Les mises à jour logicielles doivent être planifiées hors
heures de service.

3.2 Choix et présentation de la solution

3.2.1 Présentation des plateformes possibles

Plusieurs plateformes matérielles/logiciels sont envisageables

pour les calculs de l’ANPR (Reconnaissance Automatique des Plaques
d'Immatriculation/ Automatic Number Plate Recognition) et le pilotage :

 PC Windows (Win11) : un ordinateur portable équipé d’un processeur

multicœur (Intel, 8 Go de RAM
Avantages : puissance de calcul élevée (traite images et OCR
rapidement), large écosystème de logiciels (Open CV, .NET/Python
 natifs), développement et débogage faciles sous Windows. Contrepartie
: consommation électrique plus forte, coût potentiellement supérieur à
un micro-ordinateur. Nécessite Windows 10 64-bit (IDE Arduino 2.x
supporte Win11 Idéal pour des algorithmes avancés et une interface
utilisateur riche.
Arduino (microcontrôleurs) : Arduino Uno
Avantages : contrôle temps-réel des actionneurs, très faible
consommation, grande fiabilité, pas d’OS (pas de temps d’allumage,
pas de multitâche). Inconvénients : RAM et CPU très limités (quelques
Ko de RAM, ne peut pas effectuer de reconnaissance d’images
(manque de puissance). Utile pour piloter la barrière et lire des
capteurs simples, mais nécessite un ordinateur externe pour l’ANPR.

Avantages
Plateforme CPU/RAM OS principaux Inconvenient

Arduino AVR 16– Aucun (écrit en Exécution Ne peut pas faire

20 MHz, C++) temps réel fiable, de traitement
~2 Ko très d’image complexe
RAM 【 16† écoénergétique, (manque de
L255- idéal pour CPU/RAM)
L263】 moteurs/robots【16
†L268-L277】

ESP32 Xtensa FreeRTOS/ Wi-Fi natif, prix Limitations

dual-core Arduino très bas, intégré CPU/RAM pour
160-24Hz (capteur+contrôle OCR, nécessite
, ur) appui d’un PC pour
~520 Ko ANPR
RAM

Cette comparaison synthétique montre que l’ANPR et l’interface

applicative exigent une puissance de calcul (CPU et mémoire) que seul un PC
ou peut fournir ; le microcontrôleur Arduino convient pour le pilotage en
temps réel mais pas pour l’OCR lourd. En particulier, le PC Windows a
l’avantage de gérer de façon fluide Open CV + Tesseract en temps réel, et de
faciliter le développement grâce aux outils graphiques et d’IDE (Visual
Studio, Python). Selon Riverdi, un Arduino excelle pour le contrôle précis des
moteurs/senseurs, tandis qu’un SBC (comme le Pi) est préférable pour
l’image processing et l’IA.1

3.2.2 Choix de la plateforme

Au regard des besoins du projet (reconnaissance de plaques en

temps réel, interface utilisateur, évolutivité), la plateforme retenue est
un ordinateur PC sous Windows 11, associé à un Arduino pour la
commande des actionneurs. Ce choix EST motivé par plusieurs raisons:

 Puissance de calcul : Un PC moderne (ex. processeur Intel i5 ou

mieux, 8 Go de RAM) permet de traiter rapidement des images haute
résolution et d’exécuter Open CV + Tesseract sans goulot d’étranglement. Le
Pi ou les SBC concurrents sont plus lents (environ ×3 sur certaines tâches, ce
qui limiterait le débit de détection en cas d’usage intensif. De plus, le PC peut
servir de serveur de base de données et interface si besoin.
 Environnement de développement : Les outils de développement
Windows (IDEs, bibliothèques, interfaces graphiques) sont très aboutis. Par
exemple, l’IDE Arduino 2.x s’installe sous Windows 10/11, et il est facile de
coder en Python ou C#. Windows assure aussi la compatibilité avec la
majorité des caméras et pilotes USB.
 Disponibilité matérielle : Le responsable du projet dispose déjà d’un
PC Windows performant, ce qui réduit le coût et accélère la mise en place.
Utiliser cet ordinateur comme unité centrale évite l’achat d’un nouvel
appareil dédié (contrairement à l’achat d’un Raspberry Pi).
 Interopérabilité : Windows supporte nativement SQLite, les services
web, les frameworks .NET/C# et Python. Le projet pourra évoluer (par

1
Riverdi, theorie sur l’arduino
exemple ajouter un service web local, tableau de bord, envoi d’emails) sans
contraintes OS. Il est aussi possible d’utiliser WSL (Windows Subsystem for
Linux) pour exécuter des tâches Linux si nécessaire, bien que Tesseract et
Open CV soient disponibles directement sous Windows.
 Arduino : On conserve l’Arduino pour piloter la barrière car son
architecture sans OS est idéale pour le temps réel (constaté par d’autres
projets. Arduino est abordable, il dispose de nombreuses broches pour
capteurs/servos et s’interface en USB/COM simplement. Un Arduino Uno R4
ou Mega (selon nombre de capteurs) est prévu.

En résumé, l’architecture hybride PC Windows + Arduino combine

les points forts de chaque technologie : le PC réalise la vision et la logique
avancée, l’Arduino gère le mouvement moteur de manière fiable. Cette
solution répond aux exigences de performance, de coûts et d’évolutivité : le
PC permet l’OCR rapide et la gestion de base de données, tandis que
l’Arduino se charge du pilotage (communique simplement en série). Le coût
total reste modéré (< 700 € matériel) et l’infrastructure informatique
standard (Windows) facilite la maintenance.

3.3 Configuration de la plateforme

3.3.2 Configuration proprement dite

cur. executes ("""

CREATE TABLE IF NOT EXISTS logs (

id INTEGER PRIMARY KEY AUTOINCREMENT,

date_heure TEXT NOT NULL,

plaque TEXT NOT NULL,

resultat TEXT NOT NULL,

action TEXT NOT NULL

""")
 conn. commit ()

Return conn

Def normaliser_plaque(texte) :

"""Nettoie le texte OCR pour ne conserver que les caractères

utiles."""

Texte = texte. Upper (). Strip ()

Texte = [Link](r"[^A-Z0-9-]", "", texte)

Return texte

Def detecter_zone_plaque(image) :

"""

Tente de localiser une zone rectangulaire correspondant à une

plaque.

Retourne l'image de la plaque si trouvée, sinon None.

"""

gris = [Link](image, cv2.COLOR_BGR2GRAY)

Flou = [Link](gris, (5, 5), 0)

Contours = [Link](flou, 80, 200)

Contours liste, _ = [Link](contours, cv2.RETR_TREE,

cv2.CHAIN_APPROX_SIMPLE)

contours_liste = sorted (contours_liste, key=[Link],

reverse=True) [:10]

for c in contours_liste:

perimetre = [Link](c, True)

approx = [Link](c, 0.02 * perimetre, True)

# Une plaque est souvent approximée par un quadrilatère

if len(approx) == 4:
 x, y, w, h = [Link](approx)

If w > 80 and h > 20 : # seuil minimal pour éviter les faux

positifs

plaque_img = gris [y: y+h, x:x+w]

return plaque_img, (x, y, w, h)

return None, None

Def lire_ocr(image_plaque) :

"""Applique l'OCR sur l'image de plaque."""

# Amélioration simple du contraste

Image_plaque = [Link](image_plaque, None, fx=2, fy=2,

interpolation=cv2.INTER_CUBIC)

image_plaque = [Link](image_plaque, 0, 255,

cv2.THRESH_BINARY + cv2.THRESH_OTSU) [1]

config = "--psm 7 -c
tessedit_char_whitelist=ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
-"

Texte = pytesseract. Image_to_string (image_plaque, config=config)

Return normaliser_plaque(texte)

Def plaque_autorisee (conn, plaque) :

"""Vérifie si la plaque est présente dans la base."""

cur = conn. cursor ()

cur. executes ("SELECT 1 FROM autorisations WHERE plaque =?",

(plaque,))

return cur. fetchone () is not None

Def enregistrer_log (conn, plaque, resultat, action) :

"""Enregistre l'événement dans la base."""

cur = conn. cursor ()

date_heure = [Link] (). strftime ("%Y-%m-%d %H: %M: %S")

cur. executes (
 "INSERT INTO logs (date_heure, plaque, resultat, action) VALUES
(? ?, ?, ?)",

(Date_heure, plaque, resultat, action)

Conn. Commit ()

Def envoyer_commande (ser, commande) :

"""Envoie une commande à l'Arduino."""

Ser. Write (commande. Encode("utf-8"))

# --------------------------------------------------

# PROGRAMME PRINCIPAL

# --------------------------------------------------

def main ():

conn = connecter_base ()

try:

ser = serial. Serial (PORT_COM, BAUD_RATE, timeout=2)

except serial. SerialException as e:

Print (f"Erreur série Arduino : {e}")

return

cam = [Link](0)

if not cam. isOpened ():

Print ("Erreur : caméra non détectée.")

Ser. Close ()

Conn. Close ()

Return

Print ("Système démarré. Appuyer sur 'q' pour quitter.")

while True:

ret, frame = cam. read ()

If not ret :

Print ("Erreur de capture d'image.")

Break

# Affichage pour suivi visuel

Affichage = frame. Copy ()

Plaque_img, bbox = detecter_zone_plaque(frame)

if plaque_img is not None:

Plaque = lire_ocr(plaque_img)

If plaque :

Autorisee = plaque_autorisee (conn, plaque)

X, y, w, h = bbox

If autorisee :

Resultat = "AUTORISÉ"

Action = "OUVERTURE"

Envoyer_commande (ser, "O")

Couleur = (0, 255, 0)

Else :

Resultat = "REFUSÉ"

Action = "FERMÉE"

Envoyer_commande (ser, "N")

Couleur = (0, 0, 255)

Enregistrer_log (conn, plaque, resultat, action)

# Annotation visuelle

[Link](affichage, (x, y), (x + w, y + h), couleur, 2)

[Link](

Affichage,

F"{plaque} - {resultat}",
 (X, y - 10),

cv2.FONT_HERSHEY_SIMPLEX,

0.8,

Couleur,

# Sauvegarde de la capture pour preuve / débogage

Nom_fichier = f"{CAPTURE_DIR} / {[Link] ().

Strftime('%Y%m%d_%H%M%S')} _{plaque}.jpg"

[Link](nom_fichier, frame)

Print (f"Plaque détectée : {plaque} | {resultat}")

[Link]("Controle d'acces", affichage)

if [Link](1) & 0xFF == ord('q'):

break

cam. release ()

ser. close ()

conn. close ()

[Link]()

if __name__ == "__main__":

Main ()

Ce code couvre la capture vidéo, la détection de plaque avec

Open CV, l’OCR, la comparaison en base de données, l’envoi de
commande série à l’Arduino et l’enregistrement des journaux.

2. Configuration de l’Arduino
1. Ouvrir l’IDE Arduino, sélectionner la carte Arduino Uno et le port
COM associé (ex. COM3).
2. Brancher le servomoteur : fil rouge sur 5V, noir sur GND, jaune/blanc
sur pin D9 (PWM).
3. Écrire le code Arduino:
#include <Servo.h>
Servo servoBarriere;
// ----------------------------
// PARAMÈTRES DU SYSTÈME
// ----------------------------
const byte PIN_SERVO = 9;
// Ajuster ces angles selon le montage mécanique réel
Const int ANGLE_FERME = 0 ;
Const int ANGLE_OUVERT = 90 ;

// Temps d'ouverture de la barrière (en ms)

Const unsigned long DELAI_OUVERTURE = 3000 ;
// Vitesse de déplacement du servi
Const int PAS_MOUVEMENT = 1 ;
Const int DELAI_PAS = 15 ;
// ----------------------------
// VARIABLES D'ÉTAT
// ----------------------------
Bool barriereOuverte = false ;
String commandeReçue = « « ;
// ----------------------------
// FONCTIONS
// ----------------------------
Void fermerBarriere () {
For (int pos = [Link]() ; pos >= ANGLE_FERME ;
pos -= PAS_MOUVEMENT) {
[Link](pos) ;
 Delay (DELAI_PAS) ;
}
BarriereOuverte = false ;
[Link]("BARRIERE_FERMEE") ;
}
Void ouvrirBarriere () {
For (int pos = [Link]() ; pos <= ANGLE_OUVERT ;
pos += PAS_MOUVEMENT) {
[Link](pos) ;
Delay (DELAI_PAS) ;
}
BarriereOuverte = true ;
[Link]("BARRIERE_OUVERTE") ;
Delay (DELAI_OUVERTURE) ;
FermerBarriere () ;
}
Void traiterCommande (char cmd) {
Switch (cmd) {
Case 'O’ : // OUVERTURE autorisée
If (! barriereOuverte) {
OuvrirBarriere () ;
}
Break ;
Case 'N’: // REFUS : on garde la barrière fermée
if (barriereOuverte) {
fermerBarriere ();
}
[Link]("ACCES_REFUSE");
 break;
Case 'F’ : // Fermeture forcée
FermerBarriere () ;
break;
default:
[Link]("COMMANDE_INCONNUE");
break;
}
}
// ----------------------------
// INITIALISATION
// ----------------------------
void setup () {
[Link](9600);
[Link](PIN_SERVO);
[Link](ANGLE_FERME);
delay (1000);
[Link]("SYSTEME_PRET");
}
// ----------------------------
// BOUCLE PRINCIPALE
// ----------------------------
void loop () {
if ([Link]() > 0) {
Char cmd = [Link]() ;
// Ignore les retours à la ligne éventuels
if (cmd == '\n' || cmd == '\r') {
Return ;
 }
TraiterCommande(cmd) ;
}
}
Le microcontrôleur Arduino reçoit une commande série émise par
le PC Windows. Lorsque la plaque est validée, le PC envoie le caractère
O, ce qui déclenche l’ouverture du servomoteur. En cas de refus, le
caractère N maintient la barrière fermée. Cette séparation entre
traitement intelligent sur le PC et commande temps réel sur Arduino
permet d’obtenir une solution simple, stable et évolutive.

1. Test Arduino seul : sans PC, on peut envoyer manuellement des

commandes via le Moniteur Série de l’IDE pour vérifier la rotation du
servomoteur (envoyer « O » ou « N »). Vérifier que le mouvement est correct.

2. Câblage IR vers Arduino (optionnel) : Si l’on choisit de faire passer la

détection du capteur IR par l’Arduino, relier le capteur à une broche digitale
(ex. D2). Dans le setup (), définir cette broche en INPUT et dans loop (), lire
l’état (HIGH/LOW). Dès que la broche passe à LOW (véhicule détecté),
Arduino pourrait écrire un signal sur le port série à destination du PC
([Link]("V ») ;). Dans ce cas, le PC n’écoute plus directement un
bouton/senseur, mais lit « V » (voiture) via le câble USB → PC. C’est une piste
si on veut que l’Arduino notifie le PC de l’arrivée d’un véhicule (deux
directions de communication).

Et dans le code Python, on lirait signal = ser. Readline () pour recevoir

'V' avant de capturer la photo.

3. Sécurité et performances
 Sécurité informatique : Étant donné que le PC est connecté
(au moins localement) et gère des données personnelles (plaques),
configurer un compte Windows restreint pour l’application, et un mot de
passe fort. Protéger les accès par un pare-feu, et activer les mises à jour
Windows régulières. Utiliser HTTPS/TLS si l’interface réseau est utilisée (par
ex. requêtes AJAX pour le dashboard).
 Performance : Le PC doit pouvoir traiter les images en temps
réel. Selon PyImageSearch, un système ANPR doit détecter le passage et lire
la plaque en temps quasi réel (chaque voiture en file). Le PC Windows
(multicœur) permet d’obtenir plusieurs images par seconde (typiquement 5–
10 FPS en Full HD avec Open CV + OCR) même en Python pur 2. Il faut calibrer
la capture pour éviter le brouillage (utiliser [Link] en résolution
adéquate). L’exploitation d’accélération GPU/CUDA pour l’OCR n’est pas
étudiée ici (Tesseract classique), mais la configuration actuelle est suffisante
pour un parking de taille moyenne.
 Plan de test et résultats attendus :
 Tests unitaires : vérifier chaque composant séparément (caméra,
OCR sur images de test, lecture base de données, mouvement servomoteur).
Par exemple, capturer plusieurs images types (éclairages variés) et s’assurer
que Tesseract lit correctement au moins 90% des caractères.
 Intégration : tester le flux complet avec un véhicule factice ou un
collage de plaque : détection IR + capture + OCR + commande barrière.
Mesurer le temps moyen de reconnaissance (cible <2 s). Journaliser les
résultats.
 Charge : simuler des passages répétés (parcage intensif) pour s’assurer
que le PC ne surcharge pas (mém. <80%) et que la base de données répond
rapidement.
 Résultats attendus : le système doit reconnaitre correctement la plaque
> 95% dans des conditions normales (bonne luminosité, plaque standard),
ouvrir la barrière pour véhicules autorisés, et logguer tout passage. Les
fausses validations/détections doivent être rares (par ex. reconnaissance
erronée < 5%). Toute détection impossible déclenche un refus de sécurité.

2
PyImageSearch, systeme ANPR
Critiques et suggestions

 Limites du prototype : la fiabilité de l’OCR dépend fortement de la

qualité de l’image et de la lisibilité de la plaque (usure, stickers, reflets). Des
cas de figures complexes (plaque très sale, angle extrême) peuvent entraîner
un échec de reconnaissance. Le prototype simple n’intègre pas de filtrage
avancé d’images (par exemple un réseau neuronal pour la détection initiale),
ce qui pourrait améliorer la robustesse. De plus, le système actuel stocke les
données localement ; en production il faudrait envisager une réplication
sécurisée ou un cloud privé pour éviter une perte complète en cas de panne
PC.

 Améliorations possibles:

 Ajouter un module de notification (SMS ou email) en cas de détection

d’intrus ou de panne majeure.
 Intégrer une interface web responsive pour la gestion à distance des
plaques et la consultation des logs.
 Utiliser un apprentissage automatique (SVM, CNN) pour localiser
dynamiquement la plaque dans l’image, augmentant la tolérance aux
variations d’angle/luminosité.
 Prévoir la mise à jour automatique des composants (mise à jour de
Tesseract, correctifs Windows) hors heures de service.
 Pour la sécurité, chiffrer la base de données des plaques et logs (par
ex. BitLocker sur le disque ou chiffrement fichier).

Dans l’état, la solution présentée est un compromis pragmatique : le

Choix du PC Windows privilégie la rapidité de développement et de

traitement, au prix d’une consommation énergétique supérieure et d’un
moindre caractère « embarqué ». Si le projet évolue vers une production à
plus grande échelle (multi-site, infra distribuée), on envisagerait peut-être
une architecture server-client (serveur central de reconnaissance, terminaux
moins puissants aux portes) ou l’emploi de modules plus spécialisés (vision
embarquée dédiée, Deep Learning).

3.3.3. Conclusion partielle

Ce chapitre a exposé le cahier des charges et la solution technologique

retenue pour l’automatisation d’une barrière de parking par reconnaissance
de plaque sous un environnement Windows. Nous avons défini les objectifs,
décrit le système modulaire (caméra + PC Windows + Arduino), estimé le
coût et planifié le projet.

Une comparaison des plateformes a montré que le PC Windows allié à

un Arduino correspondait le mieux aux besoins (puissance pour l’OCR en
temps réel, fiabilité de la commande moteur). La configuration détaillée
couvre l’installation des outils, le câblage et les exemples de code pour
piloter le système. Les considérations de sécurité et de performance ont été
discutées, de même qu’un plan de test. En implémentant cette solution, on
s’attend à un système fonctionnel capable de reconnaître automatiquement
les véhicules autorisés, améliorant ainsi la sécurité et l’efficacité de la
gestion des accès. Les critiques notent les points d’amélioration (qualité des
images, notifications, synchronisation distante), offrant des pistes pour la
suite du projet.