WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Conception et développement d'une application web pour la gestion des urgences: cas de l'application SOS communautaire


par Mackly Loick Tchicaya
ESCIC - Bachelor en full stack and data  2025
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

1. Tableau de bord autorité :

· Liste des incidents triés par gravité et proximité.

· Statut visuel (rouge = critique, jaune = en attente, vert = résolu).

· Boutons "Prendre en charge" et "Clôturer" pour chaque incident.

· Carte thermique des zones à risques avec filtres temporels.

5.2.2. Principes de design

1. Accessibilité :

· Contraste élevé (WCAG 2.1) pour les utilisateurs malvoyants.

· Support du mode sombre et clair.

· Textes lisibles (taille minimale 14pt).

2. Rapidité de signalement :

· Formulaire simplifié (moins de 5 étapes).

· Auto-complétions des champs (ex. localisation, type d'incident).

· Validation instantanée des données (ex. vérification du format de la photo).

3. Expérience utilisateur (UX) :

· Feedback visuel immédiat (ex. animation de confirmation après signalement).

· Notifications non intrusives (option de désactivation partielle).

· Historique consultable avec filtres personnalisés.

5.3. Base de données

5.3.1. Modèle conceptuel (MERISE)

Le modèle conceptuel décrit les entités et leurs relations :

· Utilisateur : Identifiant, nom, email, téléphone, rôle (citoyen, autorité, admin).

· Incident : Identifiant, type, description, localisation (latitude/longitude), statut, date de signalement.

· Confirmation : Lien entre Utilisateur et Incident (un utilisateur peut confirmer plusieurs incidents).

· Notification : Identifiant, message, date, destinataire (utilisateur), statut (lu/non lu).

5.3.2. Modèle logique et physique (PostgreSQL)

Optimisations :

· Index sur les colonnes fréquemment interrogées (Incident.localisation, Utilisateur.role).

· Partitionnement des tables pour les incidents anciens (> 1 an).

5.4. API REST

5.4.1. Routes principales

Route

Méthode

Description

Rôles requis

/auth/register

Post

Création d'un
compte
utilisateur

Public

/auth/login

Post

Connexion avec
JWT

Public

/incidents

Post

Signalement
d'un incident

Citoyen

/incidents/proches

Get

Liste des
incidents
proches (5 km)

Citoyen,
Autorité

/incidents/:id/confirm

Post

Confirmation
d'un incident

Citoyen

/incidents/:id/take

Post

Prise en charge
d'un incident

Autorité

 

Réponse :

/incidents/:id/close

Post

Clôture d'un incident

Autorité

/notifications

Get

Récupération des notifications non lues

Citoyen,
Autorité

/dashboard/stats

Get

Statistiques (zones à risques, fréquence)

Admin

 

précédent sommaire suivant






La Quadrature du Net

Ligue des droits de l'homme