Soluzioni · Istituzioni & amministrazione
Le sezioni richieste dalla delibera governativa, scritte nel codice e aggiornate dal funzionario — non aggiunte alla fine, come allegato.
Un comune o un’istituzione ha un elenco fisso di sezioni obbligatorie, un obbligo di trasparenza decisionale e un funzionario che deve pubblicare un annuncio senza chiamare un programmatore. Costruiamo esattamente questo, con un registro di audit che si cancella da solo entro il termine e con un limite ai tentativi di autenticazione.
Già costruitoDue piattaforme proprie, pubbliche e verificabili oggi. La prima è il sito ufficiale di un comune: Laravel 12 su PHP 8.2 con MySQL 8, 40 template, 32 route, 10 migrazioni, con il contenuto editoriale che cambia raramente tenuto in un unico file di configurazione di 1.613 righe e con quello che cambia spesso nel database, modificabile dal pannello; l’autenticazione nel pannello è limitata a 5 richieste al minuto, mentre il registro di audit viene cancellato quotidianamente dopo 12 mesi, con riferimento esplicito alla base giuridica. Le intestazioni di sicurezza si possono leggere dall’esterno già ora. La seconda è una piattaforma civica in produzione, con 65 route di interfaccia di programmazione, oltre 50 migrazioni, 103 file di test lato server e 59 scenari end-to-end, con verifica di accessibilità nei test. Ciò che non indichiamo come “consegnato”: l’interoperabilità con i servizi statali — il codice di autenticazione federata e di firma elettronica è scritto e testato, ma disattivato, perché mancano il contratto con l’autorità e il certificato di sistema.
Un sito di istituzione pubblica non si giudica da come appare, ma da un elenco. La Delibera di Governo 728/2023 stabilisce quali sezioni devono esistere: trasparenza decisionale, progetti e decisioni, annunci, documenti, contatti, bilancio. Sono obbligatorie, si verificano e non si negoziano. Per questo le costruiamo fin dall’inizio, come struttura, non le aggiungiamo alla fine — aggiunte in coda risultano formali e inutili, e questo si vede subito.
La seconda condizione è più pratica: l’istituzione deve poter pubblicare da sola. Un avviso di gara, un progetto di decisione messo in consultazione, una foto da un evento — se tutto passa attraverso uno sviluppatore, l’informazione di interesse pubblico resta su carta o in un gruppo di social network, e il sito diventa una vetrina morta. Abbiamo separato intenzionalmente due tipi di contenuto: quello editoriale che cambia raramente — geografia, storia, istituzioni, contatti, bilancio — sta in un unico file di configurazione letto direttamente dai modelli; quello che cambia spesso sta nel database e si modifica dal pannello.
La terza condizione è quella che nessuno chiede nel capitolato: che cosa succede con i dati. Un pannello di amministrazione pubblica ha bisogno di un limite ai tentativi di autenticazione — alla sesta richiesta in un minuto dallo stesso indirizzo, la risposta è 429, e questo è coperto da un test automatico, non supposto. Il registro di audit contiene indirizzi IP, quindi è dato personale: un’attività programmata lo pulisce ogni giorno da tutto ciò che ha più di dodici mesi, con la base giuridica scritta nel commento del codice, non in un documento separato che nessuno apre.
E, infine, la parte di cui preferiamo parlare prima della gara: l’interoperabilità con i servizi governativi. L’autenticazione federata e la firma elettronica sono scritte e testate da noi, ma disattivate tramite un interruttore, perché mancano il contratto con l’autorità e il certificato di sistema — manca la carta, non il codice. Per la piattaforma di pagamento dello Stato, la dorsale di interoperabilità e l’area personale del cittadino non abbiamo alcun codice, in alcun repository, e lo scriviamo come tale.