Gestionnaire de rapports de terrain

1. 01

   J'ai remplacé un processus en trois étapes (formulaire sur WhatsApp, ressaisie manuelle par une autre personne et justificatifs envoyés à part) par un formulaire unique où le technicien enregistre le rapport et joint ses photos, avec les données connues préremplies.

2. 02

   J'ai mis en place l'authentification avec Supabase Auth et l'accès par rôle : chaque technicien ne voit que ses propres rapports, et chaque superviseur ceux des techniciens qui lui sont attribués. Le superviseur vérifie, corrige et approuve ; le système génère le PDF et exporte l'historique vers Excel.

3. 03

   Inventaire des ONT : l'administrateur importe les équipements depuis Excel avec un aperçu des nouveaux, des existants et des doublons ; le superviseur les attribue à chaque technicien, et un rapport n'accepte qu'un ONT attribué à la personne qui le remplit.

4. 04

   Conçue pour le terrain avec un signal faible : les photos sont compressées sur le téléphone avant l'envoi, les requêtes sont relancées quand le réseau échoue et le formulaire prévient avant de se fermer s'il reste des photos non enregistrées.

Chaque rapport d'installation passait par trois étapes : le technicien remplissait un formulaire sur WhatsApp, une autre personne ressaisissait ces données à la main et les photos justificatives étaient envoyées à part. La même information était saisie deux fois, et les photos restaient séparées du rapport auquel elles appartenaient.

Le technicien remplit le rapport depuis son téléphone en quatre sections (informations générales, client, installation et géolocalisation) et téléverse les huit photos justificatives exigées pour chaque installation. Le serveur attribue le technicien, le superviseur et l'équipe à partir de la session, et le champ ONT ne propose que les équipements attribués à ce technicien. Une fois envoyé, le rapport passe en revue : le superviseur le vérifie, corrige ce qu'il faut et l'approuve, et le système génère alors le PDF avec les données et les photos. L'historique s'exporte vers Excel par période. Un administrateur gère les utilisateurs, les équipes et l'inventaire des ONT, importé depuis Excel.

• J'ai servi l'API sous /api sur le même domaine que le frontend, grâce à une règle de réécriture sur Render. Avec le frontend et l'API sur deux sous-domaines d'onrender.com, le cookie de session était tiers et Safari le bloquait : la connexion échouait sur iPhone et fonctionnait sur Chrome pour ordinateur. Le backend refuse désormais de démarrer si les deux origines ne sont pas sur le même site.
• Le PDF est généré avec une limite de 250 Ko : les photos générales sont réduites en premier, et celles de l'ONT et du formulaire R20 restent nettes, car elles servent à la vérification technique. À l'approbation d'un rapport, ses photos sont supprimées du stockage et le PDF sert d'archive ; une tâche hebdomadaire supprime les rapports approuvés de plus d'un an, selon la règle de conservation de l'entreprise.
• Le client ne fixe jamais le statut, le technicien, l'équipe ni la date de règlement : c'est le serveur qui s'en charge. Chaque endpoint sensible applique le filtre par rôle et par ressource à la lecture, puis de nouveau à l'écriture, et les opérations susceptibles d'entrer en conflit (installer ou réattribuer un ONT, approuver ou supprimer un rapport) s'exécutent dans des fonctions transactionnelles Postgres.
• Chaque vulnérabilité corrigée a un test de non-régression dans pytest. L'intégration continue les exécute avec pip-audit, npm audit et gitleaks.

• Si le réseau échoue, chaque requête est relancée deux fois avant d'afficher l'erreur, et si la session a expiré, elle est renouvelée une fois et la requête est répétée.
• Les boutons d'enregistrement et d'envoi sont désactivés pendant qu'une requête est en cours, pour qu'un double appui avec un signal lent ne crée pas de rapport en double. Si le brouillon a été enregistré mais que l'envoi en revue a échoué, la nouvelle tentative met à jour ce même brouillon.
• Avant qu'un rapport passe en revue ou soit approuvé, le serveur vérifie les champs obligatoires, les huit photos, les coordonnées et que l'ONT appartient bien au technicien, puis renvoie la liste exacte de ce qui manque.
• La génération du PDF et l'envoi des photos ont des limites de simultanéité et de fréquence ; quand le serveur est occupé, il répond par un message clair invitant à réessayer au lieu de rester bloqué.

Je l'ai développée seul, de bout en bout : l'API FastAPI, le frontend en React et TypeScript, le modèle de données et les migrations dans Supabase, l'authentification avec Supabase Auth et l'accès par rôle, la génération du PDF, l'export vers Excel et le déploiement sur Render, avec intégration continue sur GitHub Actions. J'en assure aujourd'hui la maintenance.

• Utilisée par cinq techniciens et un superviseur, avec une maintenance continue.
• Le technicien enregistre les données et les photos au même endroit ; plus personne ne ressaisit le rapport à la main.
• Chaque rapport approuvé est conservé en PDF avec ses données et ses huit photos, prêt à être téléchargé depuis le tableau de bord du superviseur.