Cahier des Charges Détaillé - Application GMAO FibreOps

1. Introduction et Périmètre du Projet

1.1. Contexte et Justification

Le projet vise à développer une solution de Gestion de Maintenance Assistée par Ordinateur (GMAO) pour une entreprise d'infrastructure réseau opérant sur le continent africain. L'analyse des maquettes fournies (index, consultation, dashboard, planning, etc.) révèle une focalisation claire sur le cycle de vie des incidents (maintenance corrective) et la coordination des équipes terrain (techniciens).

Justification du besoin : L'objectif est de remplacer les processus manuels ou fragmentés par un système centralisé, justifié par la nécessité d'améliorer :

Le Temps Moyen de Réparation (MTTR), crucial dans l'exploitation des réseaux.

La Traçabilité et la Qualité des Données (qui seront standardisées via le module configuration.html).

L'Efficacité des Techniciens en leur fournissant un outil mobile adapté.

1.2. Objectifs Détaillés du Projet

La solution doit atteindre les objectifs suivants :

Optimisation Opérationnelle : Assurer une affectation et un suivi des interventions en temps réel, réduisant les déplacements inutiles et les temps morts (supporté par planning.html et cartographie.html).

Aide à la Décision : Fournir aux managers des indicateurs de performance clairs et immédiats sur l'état du parc et l'activité des équipes (via dashboard.html).

Conformité et Facturation : Simplifier la liaison entre l'intervention technique et l'aspect financier grâce à la gestion des devis (gestion_devis.html).

1.3. Architecture de la Solution

La solution sera scindée en deux plateformes principales, justifiées par les différents cas d'usage des utilisateurs :

Plateforme Web (Back Office) : Orientée gestion, administration, supervision et reporting.

Plateforme Mobile (Front Office) : Orientée exécution, terrain et mobilité.

2. Exigences Fonctionnelles (Plateforme Web)

La plateforme Web est le centre de contrôle de l'activité de maintenance.

2.1. Gestion de la Sécurité et des Utilisateurs

Argumentation : Les pages login.html et configuration.html prouvent l'existence de rôles distincts (Admin, Agent, Technicien) et d'une logique de connexion sécurisée (hachage SHA-256). Cette segmentation est vitale pour la confidentialité des données et l'intégrité du système.

Exigence Fonctionnelle :

Authentification : Le système doit gérer des profils utilisateurs et associer un niveau d'habilitation (rôle) à chaque compte.

Permissions : L'accès aux modules critiques (Configuration, Dashboard, Gestion Devis) doit être conditionné par le rôle de l'utilisateur (par exemple, seul l'Admin peut accéder à configuration.html).

Gestion des Comptes : Le module de configuration doit permettre la création, la modification et la désactivation des comptes, y compris l'assignation du rôle.

2.2. Gestion du Référentiel et Normalisation des Données

Argumentation : Le fichier configuration.html est central. Il liste l'ensemble des entités métiers (Clients, Localisations, Causes, Types de Cause, Statuts) qui doivent être standardisées. Sans normalisation, les données de consultation.html et dashboard.html deviennent inutilisables pour l'analyse.

Exigence Fonctionnelle :

Création, Lecture, Modification et Suppression (CRUD) de toutes les listes de valeurs prédéfinies (Clients, Localisations, Causes, Services, Axes, etc.).

Le référentiel des Statuts d'Incident doit être personnalisable par l'administrateur, tout en conservant des statuts "système" non modifiables (Ouvert, En Cours, Résolu) pour garantir la cohérence du cycle de vie.

2.3. Cycle de Vie des Incidents (Maintenance Corrective)

2.3.1. Déclaration (index-ameliore.html)

Argumentation : Le formulaire détaillé de index-ameliore.html impose la saisie de champs structurés (Client, Localisation, Cause, Priorité). Ceci est essentiel pour la bonne qualification de l'incident dès sa création.

Exigence Fonctionnelle :

Saisie Obligatoire : Tous les champs critiques doivent être obligatoires pour soumettre le formulaire.

Identification : Génération automatique d'un identifiant unique et horodaté lors de la déclaration.

Assignation : Possibilité d'assigner l'incident à un ou plusieurs techniciens assignables (gmao-assignable-techniciens dans configuration.html).

2.3.2. Consultation et Détail (consultation.html et detail_incident.html)

Argumentation : La page consultation.html prouve un besoin de recherche et de filtrage sophistiqués (par Client, Statut, Priorité). La page detail_incident.html confirme la nécessité d'une vision historique et collaborative (via les commentaires).

Exigence Fonctionnelle :

Recherche Multi-Critères : Filtrage dynamique par ID, Client, Statut, Technicien et Plage de Dates.

Historique : Enregistrement et affichage de l'historique de l'incident (Date, Heure, Ancien Statut, Nouveau Statut, Modifié par).

Collaboration : Ajout de commentaires par les utilisateurs autorisés pour échanger sur la résolution.

2.4. Gestion du Planning et des Ressources

2.4.1. Planning Unifié (planning.html)

Argumentation : L'intégration de FullCalendar dans planning.html montre un besoin de visualiser non seulement les incidents (correctif) mais aussi les événements de maintenance (préventif, marches). Cette unification est cruciale pour l'optimisation des ressources.

Exigence Fonctionnelle :

Vue Centralisée : Affichage des tâches correctives et préventives dans une interface calendrier (Jour, Semaine, Mois).

Gestion des Conflits : Le système doit alerter le manager en cas de chevauchement d'assignation pour un même technicien.

Filtres Avancés : Filtrage du planning par Technicien, Type d'Événement et Criticité pour une meilleure gestion de la charge.

2.4.2. Cartographie et Supervision (cartographie.html)

Argumentation : L'usage de Leaflet dans cartographie.html et la géolocalisation des incidents et des techniciens actifs est indispensable pour le dispatching en zone étendue.

Exigence Fonctionnelle :

Visualisation des Incidents : Affichage des points géolocalisés des incidents ouverts/en cours, avec des couleurs basées sur la Priorité ou le Statut.

Localisation des Techniciens : Affichage de la dernière position connue ou simulée des techniciens actuellement en intervention (avec rafraîchissement régulier).

2.5. Gestion Financière (gestion_devis.html)

Argumentation : La page gestion_devis.html confirme que la GMAO doit supporter une dimension commerciale. La gestion des devis permet de lier le coût de l'intervention aux actions techniques.

Exigence Fonctionnelle :

Création de Devis : Outil de création permettant de lier un devis à un Incident et à un Client.

Catalogue de Prix : Utilisation d'un référentiel de prix (bordereau) pour faciliter la saisie des lignes de prestation.

Calcul Automatique : Le système doit calculer automatiquement les totaux HT, la TVA (au taux local de 18% par défaut) et le TTC.

Export : Génération d'un document exportable (PDF) et facilitation de l'envoi par e-mail (lien mailto).

3. Exigences Fonctionnelles (Application Mobile pour Techniciens)

L'application mobile remplace la page mes_taches.html par une interface optimisée pour le terrain. Elle est la clé de voûte de l'efficacité opérationnelle.

3.1. Accès Mobile aux Tâches

Argumentation : Le technicien est un utilisateur mobile par essence. La page mes_taches.html doit être l'écran principal de l'application mobile, mais adaptée pour l'accès instantané et la manipulation sur smartphone.

Exigence Fonctionnelle :

Liste Priorisée : Affichage des tâches (Incidents et Préventifs) assignées, classées par date d'échéance et par priorité.

Consultation Rapide : Accès direct aux informations de localisation et de description, et à l'historique pour préparer l'intervention.

3.2. Exécution et Compte-Rendu d'Intervention

Argumentation : La saisie des rapports doit être simple et complète pour garantir la qualité de la donnée remontée.

Exigence Fonctionnelle :

Traçabilité du Temps : Fonctionnalités de "Check-in" et "Check-out" pour horodater précisément l'arrivée et le départ du technicien sur site.

Géolocalisation d'Intervention : Enregistrement des coordonnées GPS lors du Check-in pour confirmer la présence du technicien sur le lieu d'intervention.

Rapport Multimedia : Saisie du compte-rendu textuel, possibilité d'enregistrement vocal (si faisable techniquement), et intégration de photos (avant/après) prises directement via l'appareil photo du téléphone.

Clôture : Changement de statut vers "Résolu Provisoire" ou "Résolu Définitif" directement depuis le mobile.

3.3. Contraintes de Mobilité (Mode Hors-Ligne)

Argumentation : Les zones d'intervention en Afrique peuvent avoir une couverture réseau limitée ou inexistante. Le mode hors-ligne est une EXIGENCE CRITIQUE pour la continuité de l'activité.

Exigence Technique :

L'application doit charger toutes les informations nécessaires à la tâche (détail, formulaire de rapport) et les stocker localement.

Le technicien doit pouvoir exécuter toutes les actions (saisie du rapport, photos, changement de statut) hors connexion.

Synchronisation : Une fois la connexion rétablie, l'application doit automatiquement et silencieusement synchroniser toutes les données collectées vers le serveur central.

4. Exigences Techniques et Opérationnelles

4.1. Architecture Technique

Technologies : La plateforme Web sera développée sur des technologies modernes (HTML5/CSS3/JavaScript) avec un framework réactif pour l'interface (comme Tailwind CSS) garantissant le responsive design.

Base de Données : Une base de données relationnelle ou non-relationnelle capable de supporter de lourdes charges et de gérer la géolocalisation doit être envisagée (ex: PostgreSQL avec PostGIS ou MongoDB).

Application Mobile : Le développement doit être réalisé sur une plateforme permettant l'accès aux fonctionnalités natives (GPS, Appareil photo) et le mode hors-ligne (ex: Flutter, React Native, ou natif iOS/Android).

4.2. Sécurité et Hébergement

Hébergement : Solution Cloud sécurisée et haute disponibilité (SaaS) garantissant un taux de disponibilité supérieur à 99.9%.

Sécurité des Données : Cryptage des données en transit (HTTPS) et au repos (base de données). Application stricte des règles d'autorisation basées sur les rôles.

Sauvegarde : Mise en place d'une politique de sauvegarde journalière avec une durée de rétention définie.

4.3. Performance et Ergonomie

Web : Temps de chargement des listes (Consultation) inférieur à 3 secondes.

Mobile : L'interface utilisateur mobile doit être intuitive, avec des boutons de grande taille et des formulaires optimisés pour la saisie rapide et l'utilisation avec des gants ou dans des conditions difficiles.

FIN DU CAHIER DES CHARGES