Prestataire Telecom

Le besoin métier

Le système doit garder une vision cohérente entre le téléphone du technicien et le serveur. Les principaux objets sont les installations identifiées par numéro de commande, les dérangements identifiés par numéro de réclamation, les PCO, les splitters, les équipements réseau, les anomalies et le matériel sérialisé.

L’enjeu principal est la continuité du flux : un technicien peut travailler avec un réseau faible ou absent, puis retrouver la connexion plus tard. Le serveur doit accepter la reprise sans créer de doublons ni perdre la preuve terrain.

Architecture

Workflow terrain et validation

IMPORTÉ → AFFECTÉ → À FAIRE → RÉALISATION PDA
                            ↓
                     PENDING SUPERVISEUR
                     ↙               ↘
               RETOURNÉ           VALIDÉ
                  ↓
             PRIORITÉ REPRISE

Un retour n’est pas traité comme un simple « pending ». Le nombre de retours devient une information métier : premier retour jaune, deuxième orange, troisième et suivants rouge. Le tri est appliqué côté serveur et reproduit localement afin que la priorité reste identique online et offline.

Modules couverts

• Installations : commande, produit, MSAN/PC, PCO ou splitter selon la technologie, réalisation, motif si non réalisable, photos et matériel.
• Dérangements : réclamation, motif, action, preuve et contrôle superviseur.
• PCO / Splitter : référentiel, recherche par proximité, éléments non créés et rattachement aux interventions.
• Anomalies : signalement distinct avec GPS et photo avant, qualification puis création explicite d’une intervention lorsque nécessaire.
• Matériel / stock : numéros de série, possession, mouvement, technicien, société, date et utilisation sur intervention.
• Carte / KMZ : versions de zones, couleurs, transparence, géolocalisation et affichage client/serveur.

Synchronisation offline-first

Chaque écriture mobile reçoit un identifiant stable avant l’envoi. Une file locale conserve les opérations à pousser. Quand la connexion revient, l’application reprend automatiquement avec retry contrôlé. Le serveur renvoie un accusé et une version ; l’élément local n’est déclaré synchronisé qu’après cette confirmation.

Les photos suivent un pipeline séparé pour éviter de bloquer tout un ticket sur un média lourd. Les conflits importants ne sont pas résolus silencieusement : la copie serveur et la modification locale restent disponibles pour produire une décision explicite.

UX orientée intervention

La hiérarchie visuelle met d’abord en avant ce que le technicien doit faire maintenant : priorité, identité du ticket, adresse, équipement, action et preuve. Les champs techniques inutiles comme des identifiants locaux ou timestamps internes ne sont pas exposés. Le bouton retour doit revenir à l’écran précédent et les filtres s’appliquent sans séquence de validation inutile.

Sécurité et exploitation

Les droits ne sont pas seulement des menus masqués : l’API filtre le périmètre par rôle, équipe et ressource. Les opérations critiques sont auditées. Les suppressions administratives, imports et changements de référentiel sont séparés des actions terrain.

Ce que ce projet démontre

Le cœur du projet n’est pas la quantité d’écrans. Il montre comment transformer un flux terrain complexe en états explicites, synchronisables et contrôlables par une équipe de supervision, tout en conservant une UX suffisamment rapide pour être utilisée sur le terrain.