COMPTE RENDU SAE

[Jade-devB]

COUCOU TOUT LE MONDE

Voici la répartition du travail :

Oleksandr:
Creation de repository GitHub
Departition de travail d’equipe via issues dans repository de GitHub
configuration et explication de la base de donnes sur les VMs de l’equipe
creation de la structure de base Python+flask+html+connection SQL
Maitenance et aide a l’equipe
Algorithm d’auto remplisage

Adam:
Creation et maitenance des algoritmes de plaques et numeros
Creation des algorithmes de recherche
creation des examples de preremplis
algorithm de auto remplisage
Creation de architecture de la base de donnes
creation de shema relationnel

Sérine
Creation de mise en page avec CSS
modification de la structure de aplication
Creation des algorithmes de recherche

• aide compte rendu

Neda
Creation de architecture de la base de donnes
creation de shema relationnel
aide complimentaire sur mise en page/CSS

• aide compte rendu

Jade
Conception de la base des donnes
creation de documentation
commentaires de code
travail actif sur la coherence de projet et la demande du client (chaier de charge)
ajout et correction de base de donnes (ajout des colonnes ‘pollution’ et ‘classe envirementale” sans la perte des donnes )
creation d’un fichier sql complete pour lencement

Travail en equipe
conseption de debut
communication via GitHub
correction des bugs
modification de fichier Readme.md

/!
IMPORTANT : j'ai besoin que vous m'écriviez TOUS ce que vous avez fait. En gros vous détaillez votre partie, à quoi sert votre travail pour le projet, vous regardez bien les consignes du compte rendu données par Acun, et vous m'envoyez un paragraphe par rapport à tout ça (ici en commentaire de ce message ou alors par mail : jade.baillie@etu.unice.fr)
J'ai vraiment besoin que ce soit détaillé pour écrire un max, même si vous formulez n'importe comment on s'en fout, moi je vais tout bien formater et tout reformuler. Et si on utilise l'IA j'essaierai de modifier pour pas que ça se voit et qu'on perde pas de points sur ça !

[Elams730]

Récapitulatif Technique : Développement de l'Application de Gestion des Cartes Grises
Dans le cadre du développement de l'application web de gestion des cartes grises (basée sur Python/Flask et MySQL), j'ai conçu et implémenté plusieurs briques logicielles essentielles. Voici les axes principaux de mon travail :

1. Conception et Algorithmique des Identifiants (Plaques et Numéros)
   J'ai mis en place la logique de génération et de formatage des identifiants uniques du système.
   • Normalisation des formats : Respect strict des standards (ex: format SIV AA-123-AA pour les plaques, structure Année+Lettres+Séquence pour les numéros de carte grise).
   • Algorithmes de génération : Création de scripts SQL et Python capables de générer des numéros de série complexes basés sur le constructeur et la date de fabrication (ex: HON2020... pour Honda), garantissant l'unicité des entrées en base de données.
2. Développement du Moteur de Recherche Avancé
   J'ai développé un module de recherche complet (search.html / app.py) capable de traiter des requêtes simples et complexes via des requêtes SQL dynamiques.
   • Recherche "Intelligente" de Plaque : Implémentation d'un algorithme de nettoyage de données (normalization) coté Python et SQL (REPLACE, TRIM). Cela permet à l'utilisateur de trouver un véhicule qu'il saisisse la plaque avec tirets (AB-123-CD), avec espaces (AB 123 CD) ou attachée (AB123CD).
   • Filtres Complexes et Agrégation : Création de requêtes conditionnelles permettant de filtrer selon des critères croisés (ex: Véhicules de +5 ans ET émettant >120g CO2) et de générer des statistiques par regroupement (classement des marques par volume d'immatriculation).
3. Système d'Auto-remplissage Dynamique (Server-Side)
   Pour améliorer l'ergonomie lors de la création d'une carte grise sans dépendre de scripts clients lourds, j'ai conçu un mécanisme d'auto-complétion géré par le serveur.
   • Architecture : Utilisation d'un dictionnaire de référence en Python (DONNEES_TECHNIQUES_REF) couplé à un rechargement automatique du formulaire.
   • Fonctionnement : Dès la sélection d'un modèle, le formulaire se soumet automatiquement (trigger onchange), le serveur identifie le véhicule et renvoie la page avec les champs techniques (Poids, Puissance, CO2, Permis) pré-remplis, fiabilisant ainsi la saisie des données techniques.
4. Jeu de Données et Scénarios de Test
   Afin de valider le fonctionnement de l'application, j'ai structuré et injecté un jeu de données cohérent (setup_complete.sql).
   • Données relationnelles : Création de relations réalistes entre les tables (Propriétaires ↔ Véhicules ↔ Marques).
   • Exemples pré-remplis : Intégration d'un panel représentatif de véhicules (Motos A2, Citadines, Utilitaires) permettant de tester tous les cas limites des algorithmes de recherche et de calcul (catégories de permis, seuils de pollution).
   Bilan technique : Ce travail m'a permis de maîtriser l'interaction entre le back-end (Python/Flask) et la base de données (SQL avancé).

[slisi92]

1. Mise en page et Design (CSS)

Mon travail sur le CSS a permis de transformer un formulaire brut en une interface organisée et équilibrée.

• Symétrie et Alignement : J'ai utilisé des grilles (display: grid) pour aligner les champs deux par deux. Cela évite d'avoir une liste infinie qui descend tout droit et rend le document plus compact et lisible.
• Design Inclusif (Pour tous, même les plus âgés) : L'interface est conçue pour être accessible à tout le monde. Les polices sont grandes, les contrastes sont forts (noir sur blanc/gris) et les boutons sont larges pour que même une personne peu habituée à l'informatique ou avec une vue plus faible puisse naviguer sans stress.
• Adaptabilité : Le design s'adapte automatiquement (responsive) pour rester clair, que l'on soit sur un grand écran ou une tablette.

2. Structure et Modification (HTML)

J'ai modifié le fichier add.html pour qu'il soit plus logique et plus solide.

• Organisation par sections : Le formulaire est découpé en blocs logiques (Véhicule, Technique, Propriétaire) pour que l'utilisateur avance étape par étape.
• Correction de la structure : J'ai réorganisé les balises
  pour supprimer les espaces vides et les décalages, garantissant que chaque information a sa place exacte.

3. L'Expérience Utilisateur (UX) : "Le confort d'utilisation"

Si tu dois l'expliquer, dis que l'UX c'est faire en sorte que l'application soit intuitive.

• Remplissage intelligent : Grâce à la communication avec Python, si l'utilisateur change de modèle de voiture, les informations déjà saisies ne s'effacent pas (persistance). C'est un gain de temps énorme et moins de fatigue pour l'utilisateur.
• Guidage : J'ai ajouté des exemples dans les cases (placeholders) et des petites notes pour expliquer ce qu'est un numéro VIN, afin de rassurer l'utilisateur pendant qu'il remplit sa demande.

4. Communication entre HTML, CSS et Python

C'est le "moteur" de l'application que j'ai vérifié.

• Vérification du flux : Je me suis assurée que chaque case du formulaire HTML correspondait bien à la bonne donnée traitée par le fichier Python (app.py) et stockée dans la base de données MySQL.
• Interactivité : Aide supplémentaire dans la conception du bouton "Charger modèle" qui fait le lien direct entre la base de données et l'affichage pour pré-remplir les champs techniques automatiquement.

5. Algorithmes de recherche et Aide au compte rendu

• Logique de tri : J'ai participé à la création des méthodes permettant de chercher et retrouver rapidement une carte grise précise parmi des centaines d'autres.
• Organisation du travail : J'ai aidé à structurer le rapport final, à formuler les phrases techniques et à expliquer pourquoi nous avons fait ces choix de couleurs et de disposition pour faciliter la vie des usagers.

[bamani0709-lang]

Contribution personnelle – Partie technique

1. Création et conception du schéma relationnel

Dans le cadre de la SAE 1.04, j’ai participé à la conception du schéma relationnel de la base de données destinée à gérer un service de cartes grises. Ce schéma relationnel a été élaboré à partir de l’analyse détaillée des informations présentes sur une carte grise réelle, tout en respectant les contraintes fonctionnelles et techniques imposées par le sujet.

La base de données est structurée autour de plusieurs entités principales : CATEGORIE_VEHICULE, MARQUE, MODELE, PROPRIETAIRE et CARTE_GRISE. Chaque entité correspond à une table distincte possédant une clé primaire unique de type entier (id_*), garantissant l’identification unique de chaque enregistrement.

2. Description des tables et des relations

2.1 Table CATEGORIE_VEHICULE

La table CATEGORIE_VEHICULE permet de classifier les véhicules selon leur type (deux roues, automobile, camion léger). Elle contient un identifiant unique (id_categorie), le nom de la catégorie ainsi qu’une date de création. Une catégorie peut être associée à plusieurs modèles de véhicules, ce qui correspond à une relation de type 1,N avec la table MODELE.

2.2 Table MARQUE

La table MARQUE stocke les informations relatives aux constructeurs automobiles. Chaque marque est identifiée par un id_marque et possède un nom ainsi qu’un numéro de fabricant unique. Une marque peut fabriquer plusieurs modèles, ce qui se traduit par une relation 1,N entre les tables MARQUE et MODELE.

2.3 Table MODELE

La table MODELE représente les différents modèles de véhicules. Elle est liée à la fois à une marque et à une catégorie de véhicule grâce aux clés étrangères id_marque et id_categorie. Cette table joue un rôle central dans le schéma relationnel, car elle permet de relier les informations générales du véhicule aux données administratives de la carte grise.

Un modèle peut concerner plusieurs cartes grises, ce qui correspond à une relation 1,N entre MODELE et CARTE_GRISE.

2.4 Table PROPRIETAIRE

La table PROPRIETAIRE contient les informations personnelles relatives au propriétaire du véhicule, notamment le nom, le prénom et l’adresse. Chaque propriétaire est identifié par un identifiant unique (id_proprietaire).

Un propriétaire peut posséder une ou plusieurs cartes grises, ce qui correspond à une relation 1,N entre PROPRIETAIRE et CARTE_GRISE. Cette organisation permet de gérer efficacement les cas de multi‑possession de véhicules.

2.5 Table CARTE_GRISE

La table CARTE_GRISE constitue l’élément central de la base de données. Elle regroupe l’ensemble des informations administratives et techniques du véhicule, telles que :

• le numéro de carte grise (unique),
• le numéro d’immatriculation (unique),
• les dates d’immatriculation,
• le numéro de série du véhicule (unique),
• les caractéristiques techniques (poids, cylindrée, puissance, émissions de CO₂),
• la catégorie de permis et la classe environnementale.

Cette table est reliée à la fois au propriétaire du véhicule et au modèle du véhicule, garantissant ainsi la cohérence et l’intégrité des données.

3. Justification des choix de conception

Les choix effectués lors de la conception du schéma relationnel permettent de :

• limiter la redondance des données en séparant les informations par entités,
• respecter les règles de normalisation,
• faciliter l’écriture des requêtes SQL demandées dans la SAE,
• assurer l’intégrité référentielle grâce à l’utilisation de clés étrangères.

Cette structure rend également la base de données évolutive, notamment pour l’ajout futur de nouvelles marques, modèles ou catégories de véhicules.

4. Contribution à la mise en page et au CSS

En complément du travail sur la base de données, j’ai apporté une aide complémentaire sur la mise en page des interfaces HTML ainsi que sur la création du fichier CSS.

Le CSS mis en place repose sur l’utilisation de variables CSS afin de centraliser la gestion des couleurs et d’assurer une cohérence visuelle sur l’ensemble de l’application. Une attention particulière a été portée à l’ergonomie des formulaires et des tableaux, avec des champs clairement identifiés, des boutons différenciés selon les actions et une mise en page responsive adaptée aux différentes tailles d’écran.

Ce travail permet d’améliorer l’expérience utilisateur et de rendre l’application plus intuitive et plus agréable à utiliser.

5. Création de l’architecture de la base de données

En complément du schéma relationnel, j’ai participé à la création de l’architecture globale de la base de données. Cette étape consistait à organiser logiquement les différentes tables afin de garantir une structure cohérente, compréhensible et facilement exploitable.

L’architecture a été pensée de manière à séparer clairement les données selon leur rôle : informations administratives, informations techniques des véhicules et informations relatives aux propriétaires. Cette organisation permet de limiter les redondances, de faciliter la maintenance de la base et d’assurer une bonne évolutivité du système.

6. Création d’un fichier SQL complet pour le lancement de la base

J’ai également contribué à la création d’un fichier SQL complet permettant le lancement et l’initialisation de la base de données. Ce fichier regroupe l’ensemble des instructions nécessaires pour :

• la création de la base de données,
• la création des différentes tables,
• la définition des clés primaires et étrangères,
• la mise en place des contraintes d’unicité et d’intégrité.

Ce script SQL permet de recréer entièrement la base de données de manière automatisée sur un serveur MySQL, garantissant ainsi un déploiement rapide et fiable du projet. Il constitue une base solide pour les phases de tests, de démonstration et de maintenance.

Bilan personnel

Ma contribution au projet a principalement porté sur la conception du schéma relationnel, la création de l’architecture de la base de données, l’élaboration du fichier SQL de lancement ainsi que sur l’amélioration visuelle de l’interface via le CSS. Ces éléments ont joué un rôle essentiel dans la réussite du projet en garantissant une base de données cohérente, fonctionnelle et facilement exploitable.

[bamani0709-lang]