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à costruitoDouă platforme proprii, publice și verificabile azi. Prima e site-ul oficial al unei primării de comună: Laravel 12 pe PHP 8.2 cu MySQL 8, 40 de șabloane, 32 de rute, 10 migrări, cu conținutul editorial care se schimbă rar ținut într-un singur fișier de configurare de 1.613 linii și cu cel care se schimbă des în bază, editabil din panou; autentificarea în panou e limitată la 5 cereri pe minut, iar jurnalul de audit se șterge zilnic după 12 luni, cu trimitere explicită la temeiul legal. Antetele de securitate se pot citi din exterior chiar acum. A doua e o platformă civică în producție, cu 65 de rute de interfață de programare, peste 50 de migrări, 103 fișiere de test pe partea de server și 59 de scenarii capăt-la-capăt, cu verificare de accesibilitate în teste. Ce nu trecem la „livrat”: interoperabilitatea cu serviciile de stat — codul de autentificare federată și de semnătură electronică e scris și testat, dar oprit, pentru că lipsesc contractul cu autoritatea și certificatul de sistem.
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.