Lösungen · Institutionen & Verwaltung
Die Abschnitte, die der Regierungsbeschluss verlangt, im Code geschrieben und vom Mitarbeiter aktualisiert — nicht am Ende hinzugefügt, wie ein Anhang.
Ein Rathaus oder eine Institution hat eine feste Liste obligatorischer Abschnitte, eine Pflicht zur Entscheidungstransparenz und einen Mitarbeiter, der eine Ankündigung veröffentlichen muss, ohne einen Programmierer anrufen zu müssen. Wir bauen genau das, mit einem Audit-Log, das sich fristgerecht selbst löscht, und mit einer Begrenzung der Authentifizierungsversuche.
Bereits gebautDouă 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.
Eine Website einer öffentlichen Institution wird nicht danach beurteilt, wie sie aussieht, sondern nach einer Liste. Der Regierungsbeschluss 728/2023 legt fest, welche Abschnitte vorhanden sein müssen: Entscheidungstransparenz, Projekte und Beschlüsse, Ankündigungen, Dokumente, Kontakte, Budget. Sie sind obligatorisch, werden geprüft und sind nicht verhandelbar. Deshalb bauen wir sie von Anfang an als Struktur und fügen sie nicht am Ende hinzu — am Schluss hinzugefügt wirken sie formell und unbrauchbar, und das sieht man sofort.
Die zweite Bedingung ist praktischer: Die Institution muss selbst veröffentlichen können. Eine Ausschreibungsankündigung, ein zur Konsultation gestellter Beschlussentwurf, ein Foto von einer Veranstaltung — wenn alles durch einen Entwickler laufen muss, bleibt die Information von öffentlichem Interesse auf Papier oder in einer sozialen Netzwerkgruppe, und die Website wird zu einer toten Vitrine. Wir haben bewusst zwei Arten von Inhalten getrennt: der redaktionelle Inhalt, der sich selten ändert — Geografie, Geschichte, Institutionen, Kontakte, Budget — steht in einer einzigen Konfigurationsdatei, die direkt von den Vorlagen gelesen wird; der Inhalt, der sich oft ändert, steht in der Datenbank und wird im Panel bearbeitet.
Die dritte Bedingung ist die, nach der im Leistungsverzeichnis niemand fragt: Was geschieht mit den Daten. Ein öffentliches Verwaltungs-Panel braucht eine Begrenzung der Authentifizierungsversuche — bei der sechsten Anfrage innerhalb einer Minute von derselben Adresse lautet die Antwort 429, und das ist durch einen automatischen Test abgedeckt, nicht angenommen. Das Audit-Log enthält IP-Adressen, also personenbezogene Daten: Ein geplanter Task löscht täglich alles, was älter als zwölf Monate ist, mit der rechtlichen Grundlage im Kommentar des Codes geschrieben, nicht in einem separaten Dokument, das niemand öffnet.
Und schließlich der Teil, über den wir lieber vor der Ausschreibung sprechen: die Interoperabilität mit staatlichen Diensten. Die föderierte Authentifizierung und die elektronische Signatur sind bei uns geschrieben und getestet, aber per Schalter abgeschaltet, weil der Vertrag mit der Behörde und das Systemzertifikat fehlen — das Papier fehlt, nicht der Code. Für die staatliche Zahlungsplattform, den Interoperabilitäts-Bus und das Bürgerkonto haben wir in keinem Repository Code, und wir schreiben das auch so.