Analisi tecnica & documentazione

1Executive summary

Il progetto Grenoble & GreenApp è un sistema digitale end-to-end per la gestione del riuso di dispositivi elettronici (device IT ed elettrodomestici) nella Métropole di Grenoble. È composto da tre superfici coordinate che insieme gestiscono il ciclo vita del device dal conferimento alla ricollocazione (o smaltimento certificato).

2Obiettivi di progetto

Obiettivi funzionali

• Digitalizzare il processo dei Centri del Reimpiego (Pôle R), oggi in gran parte cartaceo o su fogli Excel locali.
• Tracciare ogni device dal conferimento al destino finale (riuso, riparazione o smaltimento RAEE).
• Attivare i cittadini come attori del riuso, non solo conferitori passivi, tramite un'app dedicata che semplifica la donazione e offre trasparenza.
• Ottimizzare la logistica con ritiri a domicilio pianificati e giri ottimizzati.
• Collegare la domanda (bandi sociali, scuole, famiglie vulnerabili) con l'offerta (device ricondizionati) in modo automatico.
• Rendicontare l'impatto ambientale e sociale per ADEME, Métropole, stakeholder e bandi.

Obiettivi non-funzionali

• Compliance GDPR end-to-end: wipe certificato dei dati personali sui device, consenso granulare degli utenti.
• Multi-Pôle R: scalabile a 14+ centri sulla Métropole.
• Multilingua: FR primario, IT e EN secondari.
• Offline-capable per gli operatori sul campo.

3Architettura generale

Il sistema adotta un'architettura client-server a più superfici con backend unificato. Tutte e tre le app parlano con lo stesso set di API, sulla stessa base dati. Questo garantisce coerenza: quando un operatore registra un cambio di stato su Grenoble Mobile, l'utente su GreenApp vede l'aggiornamento in pochi secondi.

┌──────────────┐   ┌─────────────────┐   ┌──────────────┐
│  GreenApp    │   │     Grenoble    │   │  Grenoble    │
│  (citoyen)   │   │     (webapp)    │   │  Mobile      │
│  📱 RN       │   │     🖥  Next    │   │  📱 RN       │
└──────┬───────┘   └────────┬────────┘   └──────┬───────┘
       │                    │                    │
       │      HTTPS / WSS   │      HTTPS / WSS   │
       └──────────┬─────────┴──────────┬─────────┘
                  │                    │
           ┌──────▼────────────────────▼──────┐
           │          API Gateway             │
           │    (REST + GraphQL + WebSocket)  │
           └──────┬─────────────────────┬─────┘
                  │                     │
         ┌────────▼──────┐    ┌─────────▼──────┐
         │   Core API    │    │  Auth Service  │
         │  (Node.js)    │    │  (JWT + 2FA)   │
         └────────┬──────┘    └────────────────┘
                  │
      ┌───────────┼───────────┬──────────┐
      │           │           │          │
  ┌───▼──┐  ┌─────▼────┐  ┌───▼────┐ ┌───▼────┐
  │Mongo │  │PostgreSQL│  │ Redis  │ │ S3     │
  │(dati)│  │ (audit)  │  │(cache) │ │(files) │
  └──────┘  └──────────┘  └────────┘ └────────┘
      

Perché questa architettura

• API Gateway: punto unico di ingresso per autenticazione, rate limiting, logging, routing. Tutte le app usano lo stesso contratto.
• MongoDB per dati applicativi: schemi flessibili (un device ha attributi diversi per categoria), facile evoluzione.
• PostgreSQL per audit log: dove serve immutabilità, transazionalità rigida, interrogazioni analitiche.
• Redis per cache e session: ridurre latenza sui dati hot, gestire token refresh.
• S3 (o MinIO on-prem): foto device, documenti firmati, export PDF.
• WebSocket (Socket.io): push live di cambi di stato, notifiche real-time.

4Le 3 superfici utente

4.1 Grenoble — Webapp gestionale

Chi la usa: operatori dei Pôle R, admin di centro, analisti, super admin Métropole.

Dove: browser desktop (Chrome/Firefox/Safari). Responsive ma ottimizzata per schermi ≥ 1280px.

Ruolo nel sistema: single source of truth. È qui che si decide: valutazione, routing a riparatore, assegnazione beneficiario, chiusura del ciclo. È anche il luogo della reportistica e dell'amministrazione.

4.2 GreenApp — App mobile cittadino

Chi la usa: cittadini privati, aziende (referenti CSR), enti (referenti tecnici).

Dove: iOS 16+ e Android 10+. Download da App Store / Play Store.

Ruolo nel sistema: porta d'ingresso e di uscita per il cittadino. Qui si avviano le donazioni, si prenotano i ritiri, si richiedono i device. È il canale che trasforma la passività ("porta la roba al cassonetto") in partecipazione attiva ("traccia dove va il tuo vecchio PC e vedi chi lo riceve").

4.3 Grenoble Mobile — Companion operatore

Chi la usa: operatori Pôle R in mobilità (stessi account della webapp).

Dove: iOS 16+ e Android 10+. Distribuzione interna (MDM / TestFlight / enterprise).

Ruolo nel sistema: estensione mobile del gestionale. Gli operatori non stanno solo in centro: fanno ritiri, consegne, conferimenti esterni. Serve uno strumento nativo con fotocamera, GPS, firma touch, operatività offline.

5Flusso end-to-end del device

Un esempio concreto: un notebook Dell Latitude 5420 donato dal cittadino Marc Dubois, che finisce nelle mani di uno studente del Collège Olympique.

6Ciclo vita e stati del device

Ogni device passa attraverso una sequenza ben definita di stati. Ciascuno stato ha precondizioni, azioni possibili, e app/ruolo responsabile.

7Come interagiscono webapp e app

Il modello di interazione è event-driven: ogni azione su una superficie può emettere eventi che altre superfici ascoltano. Esempi tipici:

7.1 Cittadino prenota ritiro → operatore vede

7.2 Operatore aggiorna stato → cittadino notificato

7.3 Matching AI propone, operatore decide

8Sincronizzazione e real-time

Real-time push (WebSocket)

Quando un utente è attivo in una delle app, mantiene una connessione WebSocket. Il backend pubblica eventi su "room" logiche: user:123, pole:grenoble-centre, role:operator. Gli eventi più frequenti:

• device:state-changed → notifica cittadino + aggiornamento dashboard
• pickup:new → badge sul calendario operatori
• chat:message → notifica team (Grenoble Mobile)
• assignment:proposed → suggerimento matching

Modalità offline (Grenoble Mobile)

Gli operatori possono lavorare senza connessione (es. ritiro in zona con copertura scarsa). L'app mantiene una coda di operazioni locale:

• Ogni azione (scan QR, foto, firma) viene salvata localmente in SQLite.
• Le foto vengono compresse e inserite in una upload queue.
• Al rientro online, la coda viene sincronizzata in background.
• In caso di conflitto (es. device già modificato via webapp), il server ha l'ultima parola e l'operatore vede un alert.

Caching

Redis ospita: sessioni utente, cache del catalogo device (TTL breve), contatori aggregati (KPI dashboard), risultati query matching.

9Ruoli e permessi (RBAC)

Il sistema usa un modello Role-Based Access Control con 5 ruoli predefiniti, più possibilità di override per utente singolo.

I ruoli si applicano anche sulle app mobile: Grenoble Mobile accetta solo utenti operatore o admin. GreenApp è per "cittadino" (ruolo separato gestito via France Connect / social login).

10Integrazioni esterne ⚠ da valutare

Priorizzazione suggerita

1. Must-have fase 1: ADEME (obbligatorio per RAEE), mappe base, push notifiche base
2. Nice-to-have fase 2: France Connect (aumenta adozione), firma digitale legale
3. Optional fase 3: AI vision, CAF, integrazione social

11Privacy, GDPR, sicurezza

Dati personali trattati

• Anagrafiche conferitori: nome, contatti, indirizzo, codice identificativo (NIR per persone fisiche).
• Dati device: seriali, IMEI — non considerati personali se il wipe è eseguito.
• Beneficiari: dati simili + potenzialmente dati sensibili (ISEE, QF, composizione famiglia).

Principi applicati

• Minimizzazione: raccolta solo dei dati necessari per lo scopo.
• Consenso granulare: l'utente GreenApp può consentire/negare separatamente notifiche, geolocalizzazione, analytics, marketing.
• Wipe certificato: prima di ogni riuso o smaltimento, i dati sul device sono cancellati con tool certificato (overwrite + verifica). Report archiviato.
• Diritto all'oblio: l'utente può eliminare account da GreenApp; i dati personali sono rimossi dal DB entro 30 giorni (fatto salvo obbligo di conservazione legale).
• Portabilità: export dati utente in formato JSON.

Sicurezza tecnica

• HTTPS ovunque (HSTS).
• Password hash bcrypt (cost 12+).
• JWT short-lived (15 min) + refresh token rotazione.
• 2FA obbligatorio per admin e Super Admin.
• Rate limiting su endpoint sensibili.
• Audit log immutabile (PostgreSQL + hash chain).
• Crittografia at-rest sul DB.
• Backup giornalieri cifrati, retention 30 giorni.
• Hosting UE (compliance GDPR).

12Stack tecnologico proposto

13Roadmap e fasi

Proposta di suddivisione in 3 fasi per un MVP utile in 4–5 mesi e poi estensioni.

Fase 1 — MVP (3 mesi)

• Grenoble webapp: login, dashboard, conferimento, registro device, dettaglio, uscita semplice
• Backend con anagrafiche base, stati device, audit
• GreenApp (lite): onboarding, donazione con prenotazione ritiro, tracking base
• Integrazione minima: push notifiche, mappe base

Fase 2 — Estensione (2 mesi)

• Grenoble Mobile operatore completa
• Riparatori + portale partner
• Bandi + matching AI base
• Report ESG base
• Calendario ritiri

Fase 3 — Maturità (2 mesi)

• GreenApp full: catalogo, richieste device, gamification completa
• Smaltimento RAEE + integrazione ADEME
• Multi-Pôle R + dashboard Métropole
• Utenti & permessi avanzati, audit log
• Integrazioni opzionali (France Connect, DocuSign, ecc.)

14Punti aperti per la call

Da discutere con il cliente nell'incontro del 23/04/2026 ore 15:00:

Scelte prodotto

1. Grenoble Mobile operatore è necessaria come app separata? O basta una versione responsive della webapp ottimizzata mobile?
2. Quali bandi sociali sono attivi oggi? Per tararci sui criteri reali di matching.
3. Aziende conferitori: servono CSV massivi? Serve un portale B2B dedicato o l'app basta?
4. Lingue: partire solo in FR e aggiungere IT/EN dopo? O multilingua da subito?
5. Gamification GreenApp: livello di gamification desiderato? Classifica pubblica o privata?

Scelte tecniche

1. Hosting: cloud UE (AWS eu-west-3 Parigi, OVH) o on-premise Métropole?
2. Stack: conferma Node/React o sono preferite altre tecnologie (es. Django/Rails)?
3. Integrazioni prioritarie: quali delle 8 proposte sono effettivamente in scope per la fase 1?
4. Firma digitale: serve valore legale (eIDAS) o basta ricevuta di conferma?

Scelte operative

1. Numero di Pôle R: quanti centri in fase 1, e quanti previsti a regime?
2. Operatori: quanti per Pôle R? Hanno già dispositivi mobili aziendali?
3. Riparatori partner: quale modello contrattuale? Accesso diretto alla webapp o invio via email/PDF?
4. Rendicontazione: quali report sono prioritari per Métropole e ADEME?

Scelte strategiche

1. Modello di adozione cittadini: come promuovere GreenApp (campagna Métropole, QR in ecocentri, partnership scuole)?
2. Estensione geografica: progetto replicabile in altre Métropole FR? Vogliamo progettare multi-tenant da subito?
3. Budget e tempi: scadenze di delivery? Milestone commerciali?