portail-associations/cahier-des-charges-techniques-ccds.md

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.