Développeur senior pour saas

1) SAAS Contexte et objectif produit saas

1.1 Objectif

Construire une plateforme SaaS permettant aux sociétés de contrôles non destructifs (CND/NDT) de :
• produire des rapports standardisés (par type de contrôle et norme),
• assurer la traçabilité (audit trail),
• gérer les certifications des inspecteurs,
• signer et exporter des livrables professionnels pour les clients industriels.

1.2 Problème à résoudre

Aujourd’hui, beaucoup de sociétés NDT utilisent Word/Excel + dossiers partagés :
• erreurs de version, templates non homogènes,
• perte de temps à mettre en page,
• traçabilité faible (qui a modifié quoi),
• difficulté à prouver conformité / compétences / signatures.

1.3 Positionnement (wedge)

Le produit doit être imbattable sur :
• création de rapports (rapide, propre, conforme),
• gestion certificats inspecteurs,
• signature + export client,
• preuve (audit trail minimal).

2) Périmètre MVP

2.1 Modules inclus MVP
1. Gestion des organisations (multi-tenant)
2. Utilisateurs & rôles
3. Gestion des inspecteurs + certificats (validité/expirations)
4. Création de rapports à partir de templates standardisés
5. Signature (au minimum “approbation” + verrouillage du rapport)
6. Export PDF + envoi au client (lien / téléchargement)
7. Journal d’audit minimal (création/modification/signature/export)

2.2 Hors périmètre MVP
• Portail client complet avec comptes clients
• Planning/tournées
• Facturation
• Gestion d’équipements / parc complet
• Bibliothèque avancée par normes internationales (on démarre avec 2–3 templates)
• e-signature qualifiée (eIDAS) : trop lourd au MVP (on fait “approbation interne + verrouillage”)

3) Personas, rôles, permissions

3.1 Personas
• Admin société NDT : paramétrage, utilisateurs, templates, exports
• Inspecteur : remplit des données terrain, ajoute pièces jointes, propose le rapport
• Superviseur / Level III / QA : contrôle, corrige, approuve/signe
• Client industriel (destinataire) : reçoit un PDF / lien (sans compte au MVP)

3.2 Rôles (RBAC)
• Owner/Admin : tout
• Manager/QA : valider, signer, gérer templates (optionnel), voir audit
• Inspector : créer/éditer rapports non signés, soumettre
• Viewer : lecture uniquement

Règles clés :
• Un rapport signé/verrouillé n’est plus modifiable (sauf via “révision”).
• Les inspecteurs ne peuvent pas signer si le rôle ne le permet pas.

4) Parcours utilisateur MVP

4.1 Onboarding (Admin)
1. Créer organisation
2. Inviter utilisateurs (email)
3. Créer/activer 2–3 templates de rapports (préchargés)
4. Ajouter inspecteurs / lier un inspecteur à un user (si nécessaire)
5. Saisir certificats (PDF + dates)

4.2 Création d’un rapport (Inspecteur)
1. “Nouveau rapport”
2. Sélection template (UT/RT/PT/MT/VT — ou “Générique MVP”)
3. Saisie :
• client / site / ordre de travail
• pièce / référence / matériau / épaisseur
• méthode / paramètres / résultats
4. Ajouter médias : photos, scans, fichiers
5. “Prévisualiser PDF”
6. “Soumettre à validation”

4.3 Validation & signature (QA)
1. Ouvrir rapport soumis
2. Vérifier : champs obligatoires, cohérence, certificats inspecteurs valides
3. Ajouter commentaires / demander correction OU approuver
4. “Signer / verrouiller”
5. Export PDF + envoi client

5) Fonctionnalités détaillées (MVP)

5.1 Organisations & multi-tenant
• Chaque société = un tenant isolé.
• Données séparées strictement (aucun cross-tenant).
• Support multi-sites (champ “site” simple au MVP).

5.2 Gestion utilisateurs <br /> • Invitation par email + création mot de passe
• Réinitialisation mot de passe
• Journal de connexions (simple)

5.3 Gestion inspecteurs & certifications

5.3.1 Entités
• Inspecteur (nom, prénom, ID interne, email, téléphone optionnel)
• Certificat (type, niveau, norme, organisme, date début, date expiration, fichier PDF)

5.3.2 Types de certificats (exemples)
• Méthode : UT, RT, MT, PT, VT…
• Niveau : Level I/II/III (ou équivalent)
• Norme/Schéma : ISO 9712, ASNT, COFREND, etc. (liste libre au MVP)

5.3.3 Règles
• Alerte visuelle si certificat expiré ou expire bientôt (ex: 30 jours).
• Lorsqu’un rapport utilise une méthode, il doit référencer un inspecteur avec certificat valide correspondant (au moins 1 certificat attaché).
• Upload de fichiers (PDF/JPG/PNG) + stockage sécurisé.

5.4 Templates de rapports

5.4.1 Objectif

Standardiser la structure des rapports et réduire la saisie/mise en forme.

5.4.2 Format template
• Template = structure de sections + champs typés :
• texte court
• texte long
• nombre
• date
• liste (dropdown)
• booléen (check)
• pièce jointe
• Champs “obligatoires” configurables.
• 2–3 templates fournis au départ (ex : VT générique, UT générique, MT/PT générique).

5.4.3 Versioning minimal
• Template a un numéro de version
• Un rapport “fige” la version du template utilisée (si template évolue, rapport existant reste cohérent).

5.5 Rapports (création/édition)

5.5.1 Champs de base communs (obligatoires)
• Numéro de rapport (auto)
• Client (texte)
• Site / localisation (texte)
• Référence ordre de travail / bon d’intervention (texte)
• Date inspection
• Inspecteur(s) assigné(s)
• Méthode (UT/RT/…)
• Conclusion (Conforme / Non conforme / Réparation requise)
• Résumé résultats

5.5.2 Sections typiques (selon méthode)
• Objet du contrôle
• Références et normes appliquées
• Matériel utilisé (optionnel MVP)
• Procédure / paramètres (fréquence, gain, etc.)
• Résultats détaillés
• Défauts / indications
• Annexes (photos, croquis)

5.5.3 Pièces jointes
• Photos terrain
• Croquis
• Fichiers (PDF)
• Limites taille (ex: 20–50MB fichier) + compression/thumbnail

5.6 Signature / verrouillage

5.6.1 MVP : “approbation interne + verrouillage”
• Action “Signer” par rôle autorisé
• Enregistre :
• nom signataire
• date/heure
• hash/empreinte logique du rapport (au moins un “checksum” côté serveur)
• Après signature :
• rapport devient non modifiable
• seule action possible : “Créer révision”

5.6.2 Révisions
• “Créer révision” du rapport signé :
• copie de la dernière version
• nouveau numéro de révision (R1, R2…)
• historique complet conservé

5.7 Export PDF & livraison client
• Export PDF fidèle au template (mise en page propre)
• Ajout automatique :
• page de garde (logo société, infos client, numéro rapport, révision)
• zone signature (nom/date)
• footer avec pagination
• Livraison :
• téléchargement direct
• • option “lien partage” protégé par token (expiration configurable, ex 7/30 jours)

5.8 Audit trail minimal

Journaliser :
• création / modification (champ global “modifié par” + timestamp)
• soumission validation
• approbation / refus + commentaire
• signature
• export
• création de révision

Affichage :
• timeline simple dans la page rapport

6) Exigences non fonctionnelles

6.1 Sécurité
• Auth sécurisée, mots de passe hashés (bcrypt/argon2)
• RBAC strict
• Stockage fichiers isolé par tenant
• URL de partage signées / token
• Logs d’accès aux exports

6.2 Conformité & traçabilité (niveau MVP)
• Données immuables pour versions signées
• Audit trail consultable
• Horodatage serveur (UTC)

6.3 Performance
• Liste rapports paginée
• PDF généré en <10–20s pour rapports “moyens”
• Upload résilient (reprise simple si possible)

6.4 Sauvegardes
• Backup DB quotidien
• Rétention 30 jours minimum (MVP)

7) Modèle de données (proposition)

7.1 Tables principales
• organizations (id, name, settings…)
• users (id, org_id, email, role, status…)
• inspectors (id, org_id, name, linked_user_id nullable)
• certificates (id, inspector_id, method, level, scheme, issuer, start_date, end_date, file_url)
• templates (id, org_id, name, version, schema_json, is_active)
• reports (id, org_id, report_number, template_id, template_version, status, client_name, site, work_order, method, inspection_date, conclusion, created_by, assigned_inspectors[])
• report_fields (report_id, field_key, value_json) ou stockage JSON uni