Introduction & Contexte
Ce projet de fin d’études a été réalisé dans le cadre de mon BTS SNIR (Systèmes Numériques, option Informatique et Réseaux) au Lycée Pilote Innovant International (LP2I) en 2019. Conçu de bout en bout par un groupe de trois étudiants dont je faisais évidemment parti, il consistait à élaborer un système matériel et logiciel complet de contrôle d’accès en salle informatique. Les objectifs de ce projet se structurait en deux phases :
Dans un premier temps, il fallait assurer la sécuriser l’accès à une salle pour un public désigné, puis dans un second temps, il fallait contrôler les horaires de passage des étudiants afin de valider leur présence.
Ce projet exigeait une immersion totale dans l’écosystème de l’Internet des Objets (IoT) en interfaçant des équipements réseaux industriels avec un serveur de base de données. Au sein de cette équipe, notre organisation a exigé une répartition claire des rôles : un développeur qui s’occupait de l’interface web et de la base de données, un second élément qui se chargeait de l’acquisition des données du lecteur principal, et pour ma part, le traitement des tests avancés des protocoles de connexion matériels, des retours d’informations du lecteur NANO RFID, et la communication bidirectionnelle avec la base de données.
Rappel des Objectifs
Objectifs matériels et réseaux : L’établissement d’une communication réseau fiable via Ethernet entre des lecteurs de badges (un modèle Inveo RFID-IND-U2 à l’extérieur et un NANO RFID à l’intérieur), une gâche électrique de verrouillage, et un serveur web local Apache/MySQL hébergé sous XAMPP.
Objectifs logiciels et fonctionnels : La création d’un système logique capable de vérifier l’identité d’un utilisateur, de recouper cette information avec des critères stricts liés à son emploi du temps, et de déclencher les avertisseurs physiques (LEDs et buzzer). Le système devait donc différencier un badge valide d’un badge non reconnu via des signaux sonores et visuels distincts.
Livrables : La délivrance d’une base de données relationnelle opérationnelle, des scripts en langage PHP de traitement des trames réseau, ainsi qu’une interface web d’administration permettant aux techniciens d’ajouter des badges et aux enseignants de consulter l’historique des passages.
Enjeux, Risques & Contraintes
Lors de ce projet, nous avons été confrontés à quelques contraintes. Je vous les énumère les plus majeurs ci-dessous :
L’exigence du Temps Réel et de la Fiabilité: Pour ce premier cas, c’était le traitement des données qui devait s’effectuer instantanément. Par exemple, dans le cas où un identifiant du badge était valide dans la base MySQL, alors le système devait renvoyer les instructions d’ouverture à la gâche sans latence perceptible pour garantir la fluidité des entrées. Une attente trop longue de l’utilisateur, cela aurait pu démontrer le manque de fiabilité de notre mécanisme et donc créer une certaine frustration chez les utilisateurs.
Résilience réseau & intégrité des scripts : Il s’agit d’un autre risque majeur inhérent à cette architecture : la communication client-serveur. En effet, si le script PHP chargé de parser la requête HTTP GET (contenant notamment l’adresse MAC du lecteur, l’ID du badge et l’état des entrées in/out) venait à échouer, alors l’accès à la salle devenait physiquement impossible.
Instabilité matérielle et bugs logiciels : La gestion de l’électronique embarquée implique aussi des aléas. Nous avons été confrontés à des dysfonctionnements critiques liés à la version du firmware des lecteurs Inveo (en version initiale 0.35), rendant la gestion simultanée des LEDs et du buzzer impossible sans l’intervention directe du constructeur.
Les différentes étapes du projet
1) Analyse matérielle & structure du projet
Afin de bien comprendre les tenants et les aboutissants de ce projet, nous avons procédé à un inventaire rigoureux des composants IoT. Ci-dessous, les éléments matériels que nous avions à disposition :
Ensuite, nous avons procédé à l’élaboration des différents diagrammes UML (Déploiement, Séquence, Cas d’utilisation). Cette étape est essentielle pour la conception, la visualisation et la documentation de la structure du projet et le comportement d’un système logiciel avant de commencer son développement.
Il en était de même pour le diagramme de Gantt qui permettait la représentation visuelle et chronologique de notre projet.
2) Développement backend & modélisation
Pour cette étape, nous avons procédé à la création du schéma relationnel liant les identifiants uniques des badges aux informations des étudiants et aux créneaux horaires. On procède ensuite à la connexion au serveur MySQL via l’interface PDO (PHP Data Objects) pour garantir une meilleure sécurité.
Ensuite, on procède à l’écriture des requêtes SQL croisant l’ID du badge avec la table autorisation pour vérifier la validité de l’heure de passage avant l’insertion d’une trace d’horodatage.
3) Programmation de l’Interface et des scripts
Configuration du serveur pour récupérer et traiter les variables passées dans l’URL par les lecteurs réseau. Génération de trames XML spécifiques en fonction des scénarios :
Si le profil est autorisé, alors une lumière verte apparaît et la gâche se déclenche permettant l’accès à la salle.
Dans le cas inverse, si le profil est refusé, alors une lumière rouge apparaît, la porte reste fermée et l’accès à la salle est donc impossible.
4) Tests d’Intégration & résolution d’Incidents
Face à un dysfonctionnement matériel bloquant l’utilisation des avertisseurs, nous avons contacté le support Inveo en Pologne pour obtenir un correctif. Le déploiement du nouveau firmware (version 0.40) a engendré de nouveaux bugs (conflits d’activation matérielle où seul le buzzer fonctionnait sur un boîtier, et seules les LEDs sur l’autre), exigeant une longue série de tests croisés, de débogage des chemins de scripts et de nouveaux échanges techniques.
Retour d’expérience & Perspectives d’avenir
Ce projet fut fondamental dans mon parcours académique, car il a matérialisé la convergence fascinante entre le code informatique immatériel et l’infrastructure physique et électronique.
J’ai réellement pris conscience des différents de criticité des protocoles de communication en réseau et de l’intégrité des bases de données relationnelles dans des contextes réels de sécurité biométrique et d’accès.
Aussi, le fait de devoir déboguer du matériel instable et d’interagir avec le support technique d’un constructeur a forgé ma méthodologie de résolution d’incidents.
Aujourd’hui, fort de mes expériences et de mon parcours, je mettrais davantage l’accent sur la sécurité.