Solutions · Institutions & administration
Les sections exigées par la décision gouvernementale, écrites en code et mises à jour par l’agent — pas ajoutées à la fin, comme une annexe.
Une mairie ou une institution a une liste fixe de sections obligatoires, une obligation de transparence décisionnelle et un agent qui doit publier une annonce sans appeler un programmeur. Nous construisons exactement cela, avec un journal d’audit qui s’efface automatiquement à échéance et avec une limite sur les tentatives d’authentification.
Déjà construitDouă 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 site d’institution publique ne se juge pas à son apparence, mais à une liste. La décision du Gouvernement 728/2023 fixe les sections qui doivent exister : transparence décisionnelle, projets et décisions, annonces, documents, contacts, budget. Elles sont obligatoires, vérifiées et non négociables. C’est pourquoi nous les construisons dès le départ, comme structure, et ne les ajoutons pas à la fin — ajoutées à la fin, elles deviennent formelles et inutiles, et cela se voit immédiatement.
La deuxième condition est plus pratique : l’institution doit pouvoir publier seule. Une annonce d’appel d’offres, un projet de décision mis en consultation, une photo d’un événement — si tout passe par un développeur, l’information d’intérêt public reste sur papier ou dans un groupe de réseau social, et le site devient une vitrine morte. Nous avons volontairement séparé deux types de contenu : celui éditorial qui change rarement — géographie, historique, institutions, contacts, budget — reste dans un seul fichier de configuration lu directement par les modèles ; celui qui change souvent reste dans la base de données et se modifie depuis le panneau.
La troisième condition est celle dont personne ne parle dans le cahier des charges : que se passe-t-il avec les données. Un panneau d’administration publique a besoin d’une limite sur les tentatives d’authentification — à la sixième requête en une minute depuis la même adresse, la réponse est 429, et cela est couvert par un test automatique, pas supposé. Le journal d’audit contient des adresses IP, donc c’est une donnée personnelle : une tâche programmée le nettoie chaque jour de tout ce qui est plus ancien que douze mois, avec la base légale écrite dans le commentaire du code, et non dans un document séparé que personne n’ouvre.
Et enfin, la partie dont nous préférons parler avant l’appel d’offres : l’interopérabilité avec les services gouvernementaux. L’authentification fédérée et la signature électronique sont écrites et testées chez nous, mais désactivées par un commutateur, car il manque le contrat avec l’autorité et le certificat du système — il manque le papier, pas le code. Pour la plateforme de paiements de l’État, le bus d’interopérabilité et le cabinet du citoyen, nous n’avons aucun code, dans aucun dépôt, et nous l’écrivons tel quel.