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






Extinction Rebellion







Changeons ce systeme injuste, Soyez votre propre syndic



"Et il n'est rien de plus beau que l'instant qui précède le voyage, l'instant ou l'horizon de demain vient nous rendre visite et nous dire ses promesses"   Milan Kundera