Initial local backup snapshot
This commit is contained in:
commit
acd9e14ba5
367 changed files with 118038 additions and 0 deletions
359
cahier-des-charges-techniques-ccds.md
Normal file
359
cahier-des-charges-techniques-ccds.md
Normal file
|
|
@ -0,0 +1,359 @@
|
|||
# Cahier des Charges Techniques & Specifications Fonctionnelles
|
||||
|
||||
## Projet
|
||||
|
||||
**Systeme d'Information et de Logistique Evenementielle Interconnecte**
|
||||
**Client :** Communaute de Communes Des Savanes (CCDS)
|
||||
|
||||
## 1. Architecture technique & configuration globale
|
||||
|
||||
### 1.1 Exigences environnementales & compatibilite
|
||||
|
||||
Le systeme doit fonctionner comme une plateforme web complete, sans imposer l'installation d'une application native externe aux agents techniques ou aux usagers.
|
||||
|
||||
Exigences :
|
||||
|
||||
- aucune application PWA, APK ou iOS dediee ne doit etre obligatoire ;
|
||||
- toutes les interactions doivent etre possibles depuis un navigateur web standard ;
|
||||
- l'interface d'administration doit etre optimisee pour bureau et tablette ;
|
||||
- l'interface terrain / restitution doit etre concue en approche mobile-first pour des ecrans de 4 a 7 pouces ;
|
||||
- les emails emis par la plateforme doivent etre compatibles avec Outlook, Gmail, Apple Mail, Yahoo et les principaux webmails.
|
||||
|
||||
### 1.2 Gestion de la securite, roles et permissions (RBAC)
|
||||
|
||||
La base de donnees et la logique applicative doivent implementer strictement trois niveaux d'acces.
|
||||
|
||||
#### Super-administrateur
|
||||
|
||||
- acces complet en lecture / ecriture sur l'ensemble du systeme ;
|
||||
- seul role autorise a creer, suspendre ou supprimer des comptes ;
|
||||
- seul role autorise a configurer l'inventaire materiel global ;
|
||||
- seul role autorise a modifier les variables de pilotage du systeme ;
|
||||
- seul role autorise a definir les stocks plafonds, les valeurs de remplacement et les regles sensibles.
|
||||
|
||||
#### Administrateur
|
||||
|
||||
- instruction complete des demandes associations ;
|
||||
- validation / refus des dossiers ;
|
||||
- affectation des services et agents techniques ;
|
||||
- pilotage du calendrier, de la logistique et des retours ;
|
||||
- traitement des dossiers de cautionnement et d'arbitrage en cas de litige ;
|
||||
- impossibilite de modifier la structure de base de l'inventaire ou les comptes utilisateurs.
|
||||
|
||||
#### Utilisateur simple / agent de terrain
|
||||
|
||||
- acces limite a ses missions affectees ;
|
||||
- interface mobile epuree ;
|
||||
- consultation et cloture de ses seules missions logistiques ;
|
||||
- absence d'acces aux modules globaux d'administration, stock, comptes, statistiques et reglage.
|
||||
|
||||
### 1.3 Journal d'audit inviolable
|
||||
|
||||
Le systeme doit integrer un journal d'audit en mode **append-only** :
|
||||
|
||||
- aucune modification d'une ligne d'audit ne doit etre possible ;
|
||||
- aucune suppression d'une ligne d'audit ne doit etre possible, y compris pour le super-administrateur ;
|
||||
- les ecritures doivent etre ajoutees chronologiquement uniquement.
|
||||
|
||||
Chaque enregistrement doit contenir au minimum :
|
||||
|
||||
- `timestamp` : date et heure issues exclusivement de l'horloge serveur ;
|
||||
- `user_id` et `user_role` ;
|
||||
- `action_type` ;
|
||||
- `payload` lisible en langage clair ;
|
||||
- `ip_address`.
|
||||
|
||||
Exemple attendu :
|
||||
|
||||
`Le 18/05 à 14h22, l'Admin X a accepté la demande #412`
|
||||
|
||||
## 2. Specifications des modules back-office
|
||||
|
||||
### 2.1 Tableau de bord operationnel
|
||||
|
||||
Le tableau de bord est l'ecran d'accueil par defaut apres authentification administrative.
|
||||
|
||||
Il doit fonctionner comme un centre de decision et se mettre a jour de facon dynamique sans rechargement complet de page.
|
||||
|
||||
Composants attendus :
|
||||
|
||||
#### Bandeau d'alertes logistiques
|
||||
|
||||
- **Alerte rouge** : nombre de restitutions en retard
|
||||
Condition : `date actuelle > date restitution + 3 jours`
|
||||
- **Alerte orange** : nombre de litiges / degradations non arbitres
|
||||
- **Badge bleu** : nouvelles demandes en attente d'instruction
|
||||
|
||||
Chaque indicateur doit etre cliquable et appliquer un filtre direct sur les dossiers concernes.
|
||||
|
||||
#### Flux operationnel journalier
|
||||
|
||||
Deux colonnes :
|
||||
|
||||
- **Departs / matin** : mises a disposition ou livraisons du jour
|
||||
- **Retours / apres-midi** : restitutions attendues au jour J
|
||||
|
||||
Chaque ligne doit faire apparaitre :
|
||||
|
||||
- l'association ;
|
||||
- le type de mission ;
|
||||
- le statut d'assignation ;
|
||||
- un acces rapide au dossier.
|
||||
|
||||
#### Composant de visualisation des stocks
|
||||
|
||||
- graphique donut ou barres ;
|
||||
- quantites disponibles / engagees / bloquees ;
|
||||
- lecture simple par categorie de materiel.
|
||||
|
||||
#### Fil d'activite
|
||||
|
||||
- affichage des 5 derniers evenements du journal d'audit ;
|
||||
- lecture chronologique claire ;
|
||||
- acces au journal complet.
|
||||
|
||||
### 2.2 Module unifie "Dossier & assignation logistique"
|
||||
|
||||
Le systeme doit supprimer les blocages de navigation entre consultation et action.
|
||||
|
||||
#### Depuis la fiche dossier
|
||||
|
||||
La fiche complete d'une demande acceptee doit integrer un bloc :
|
||||
|
||||
`Assigner un service recuperateur`
|
||||
|
||||
Ce bloc doit permettre :
|
||||
|
||||
- de choisir un service ou agent via un menu relie a l'annuaire interne ;
|
||||
- de valider l'assignation sans quitter la fiche ;
|
||||
- de declencher le workflow de terrain.
|
||||
|
||||
#### Depuis l'ecran d'assignation
|
||||
|
||||
Un bouton secondaire :
|
||||
|
||||
`Voir la demande`
|
||||
|
||||
doit ouvrir un panneau lateral ou une drawer affichant :
|
||||
|
||||
- details de l'association ;
|
||||
- liste complete du materiel ;
|
||||
- dates ;
|
||||
- lieu / manifestation ;
|
||||
- informations utiles a la decision.
|
||||
|
||||
### 2.3 Calendrier logistique predictif
|
||||
|
||||
Le calendrier doit etre relie a l'inventaire reel.
|
||||
|
||||
#### Regle d'indexation stock
|
||||
|
||||
Lorsqu'une demande est validee sur une periode donnee :
|
||||
|
||||
- les quantites reservees doivent etre deduites du stock global ;
|
||||
- cette deduction ne s'applique que sur la plage temporelle concernee.
|
||||
|
||||
#### Affichage visuel attendu
|
||||
|
||||
Chaque dossier doit produire trois phases visibles :
|
||||
|
||||
- **Sortie / livraison** : bleu
|
||||
- **Manifestation / indisponibilite stock** : phase d'utilisation
|
||||
- **Alerte restitution** : jaune
|
||||
|
||||
#### Interactions attendues
|
||||
|
||||
Au clic sur un evenement du calendrier :
|
||||
|
||||
- consulter l'agent ou service affecte ;
|
||||
- reassigner la mission ;
|
||||
- telecharger le PDF finalise si disponible.
|
||||
|
||||
### 2.4 Cartographie interactive & implantation territoriale
|
||||
|
||||
La cartographie doit etre connectee a la base de donnees et servir a la fois le grand public et l'administration.
|
||||
|
||||
Technologies recommandees :
|
||||
|
||||
- Leaflet.js
|
||||
- ou Mapbox GL JS
|
||||
|
||||
Traitements attendus :
|
||||
|
||||
- geocodage automatique des adresses via `api-adresse.data.gouv.fr` ou `Nominatim`
|
||||
- stockage des coordonnees geographiques
|
||||
- clustering obligatoire pour eviter la surcharge visuelle
|
||||
|
||||
Filtres attendus :
|
||||
|
||||
- annuaire public par thematique ;
|
||||
- vue logistique admin ;
|
||||
- heatmap / densite ;
|
||||
- filtres territoriaux sur Iracoubo, Kourou, Saint-Elie, Sinnamary.
|
||||
|
||||
## 3. Specifications du workflow mobile terrain
|
||||
|
||||
### 3.1 Declenchement & routage
|
||||
|
||||
Un traitement planifie quotidien doit verifier les dossiers.
|
||||
|
||||
Pour tout dossier dont la restitution theorique est a **J-4** :
|
||||
|
||||
- generer un jeton d'acces securise temporaire ;
|
||||
- construire une URL unique ;
|
||||
- injecter cette URL dans l'email du service ou agent affecte.
|
||||
|
||||
Exemple de forme attendue :
|
||||
|
||||
`https://ccds.fr/restitution/v1?token=sha256_unique_hash`
|
||||
|
||||
### 3.2 Interface mobile & gestion non bloquante
|
||||
|
||||
Lors de l'ouverture sur smartphone :
|
||||
|
||||
- les donnees de mise a disposition sont pre-remplies et figees ;
|
||||
- l'agent ne modifie pas les donnees source de la demande ;
|
||||
- le constat terrain se fait sur l'etat reel de restitution.
|
||||
|
||||
#### Bloc "Restitution de materiel"
|
||||
|
||||
Boutons radio exclusifs :
|
||||
|
||||
- `Conforme`
|
||||
- `Non conforme / Partiel`
|
||||
|
||||
Comportement attendu :
|
||||
|
||||
- `Conforme` valide globalement le retour ;
|
||||
- `Non conforme / Partiel` active obligatoirement le bloc observations.
|
||||
|
||||
#### Bloc "Observations contradictoires"
|
||||
|
||||
Cases a cocher :
|
||||
|
||||
- equipement manquant
|
||||
- accessoires / visserie manquants
|
||||
- armature deformee
|
||||
- toile / bache dechiree
|
||||
- impact / choc majeur
|
||||
- restitution sale
|
||||
- materiel humide
|
||||
|
||||
Des qu'une case est cochee :
|
||||
|
||||
- le champ texte libre devient obligatoire.
|
||||
|
||||
### 3.3 Double signature, horodatage et resilience GPS
|
||||
|
||||
#### Horodatage certifie
|
||||
|
||||
Le backend doit ecraser toute date / heure issue de l'appareil.
|
||||
|
||||
La date officielle est generee exclusivement par le serveur au moment de la soumission.
|
||||
|
||||
#### Gestion robuste de la geolocalisation
|
||||
|
||||
Le script `navigator.geolocation` doit :
|
||||
|
||||
- fonctionner en asynchrone ;
|
||||
- comporter un timeout strict de `5000 ms` ;
|
||||
- ne jamais bloquer la validation finale.
|
||||
|
||||
Scenarios :
|
||||
|
||||
- **Succes** : les coordonnees sont jointes a la soumission
|
||||
- **Echec** : la valeur `Non disponible` est enregistree, mais la validation continue normalement
|
||||
|
||||
#### Signature tactile
|
||||
|
||||
Le systeme doit integrer :
|
||||
|
||||
- une zone de signature pour l'agent ;
|
||||
- une zone de signature pour l'emprunteur ;
|
||||
- les qualites associees ;
|
||||
- un rendu suffisamment fluide pour un usage doigt / stylet.
|
||||
|
||||
### 3.4 Generation dynamique du PDF & archivage
|
||||
|
||||
Apres validation finale :
|
||||
|
||||
- le serveur compile le document officiel ;
|
||||
- fusionne les donnees, signatures et metadonnees ;
|
||||
- applique le logo CCDS ;
|
||||
- produit un PDF A4 sur une page si le contenu le permet.
|
||||
|
||||
Contraintes de sortie :
|
||||
|
||||
- CSS imprimee calibree ;
|
||||
- signatures visibles ;
|
||||
- mise en page stable ;
|
||||
- envoi automatique en piece jointe :
|
||||
- a l'association ;
|
||||
- a la DSU ;
|
||||
- mise a jour du statut en base.
|
||||
|
||||
## 4. Protocole expeditif automatise : gestion des litiges
|
||||
|
||||
Si la restitution est saisie comme `Non conforme / Partiel` ou `Mauvais etat` :
|
||||
|
||||
### 4.1 Rupture de flux & gel logistique
|
||||
|
||||
Le dossier passe en :
|
||||
|
||||
`LITIGE / ATTENTE ARBITRAGE`
|
||||
|
||||
Le materiel concerne doit etre marque indisponible pour :
|
||||
|
||||
- bloquer son retour dans le calendrier ;
|
||||
- empecher sa relocation par erreur.
|
||||
|
||||
### 4.2 Interface d'arbitrage financier
|
||||
|
||||
La fiche admin du dossier doit permettre :
|
||||
|
||||
- de saisir le cout d'un devis ;
|
||||
- de saisir un cout interne ;
|
||||
- ou d'appliquer la valeur de remplacement a neuf issue de l'inventaire.
|
||||
|
||||
### 4.3 Notification & cloture
|
||||
|
||||
Le systeme doit proposer :
|
||||
|
||||
- un bouton `Generer courrier de litige`
|
||||
- un document pre-rempli pour notifier l'association
|
||||
|
||||
Le dossier ne peut etre cloture definitivement qu'apres arbitrage explicite parmi :
|
||||
|
||||
- retenue partielle sur caution
|
||||
- encaissement total
|
||||
- classement sans suite
|
||||
|
||||
La decision doit :
|
||||
|
||||
- mettre a jour le stock ;
|
||||
- liberer ou non le materiel ;
|
||||
- etre ecrite dans le journal d'audit.
|
||||
|
||||
## 5. Vision d'ensemble
|
||||
|
||||
La plateforme doit etre comprise comme un **ecosysteme logistique connecte et predictif**.
|
||||
|
||||
Elle doit permettre :
|
||||
|
||||
- de centraliser la gestion associative ;
|
||||
- de piloter le materiel dans le temps ;
|
||||
- de fluidifier les workflows terrain ;
|
||||
- de proteger juridiquement et financierement la collectivite ;
|
||||
- d'offrir a la direction un vrai centre de controle.
|
||||
|
||||
## 6. Resultat attendu
|
||||
|
||||
Le systeme final ne doit pas etre un simple outil de gestion administrative.
|
||||
|
||||
Il doit devenir :
|
||||
|
||||
- une plateforme de service public numerique ;
|
||||
- un centre de pilotage logistique ;
|
||||
- un outil de tracabilite ;
|
||||
- un support de decision ;
|
||||
- et un cadre fiable pour l'arbitrage, le stock et les operations terrain.
|
||||
Loading…
Add table
Add a link
Reference in a new issue