Solutions · Institutions & administration
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à construitDeux plateformes propres, publiques et vérifiables aujourd’hui. La première est le site officiel d’une mairie de commune : Laravel 12 sur PHP 8.2 avec MySQL 8, 40 modèles, 32 routes, 10 migrations, avec le contenu éditorial qui change rarement conservé dans un seul fichier de configuration de 1.613 lignes et celui qui change souvent dans la base, modifiable depuis le panneau ; l’authentification dans le panneau est limitée à 5 requêtes par minute, et le journal d’audit est supprimé quotidiennement après 12 mois, avec renvoi explicite au fondement juridique. Les en-têtes de sécurité peuvent être lus de l’extérieur dès maintenant. La deuxième est une plateforme civique en production, avec 65 routes d’interface de programmation, plus de 50 migrations, 103 fichiers de test côté serveur et 59 scénarios de bout en bout, avec vérification de l’accessibilité dans les tests. Ce que nous ne comptons pas comme « livré » : l’interopérabilité avec les services de l’État — le code d’authentification fédérée et de signature électronique est écrit et testé, mais arrêté, car il manque le contrat avec l’autorité et le certificat du système.
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.
Ce que cela comprend
Transparence décisionnelle, projets et décisions, annonces, documents, contacts, budget, plus la déclaration d’accessibilité, l’information sur le traitement des données, la section des données ouvertes et la carte du site. La conformité à la décision du gouvernement est écrite dans le code — dans les modèles et dans la configuration — et pas seulement affirmée dans l’offre.
Ce qui change rarement — données sur la localité, historique, institutions, composition du conseil, contacts, budget — se trouve dans un seul fichier de configuration de 1.613 lignes, lu directement par les modèles ; ce qui change souvent — annonces, galerie, projets et décisions, documents, paramètres de transparence — se trouve dans la base de données et s’édite depuis le panneau. La séparation n’est pas esthétique : elle réduit au minimum ce qu’une mauvaise édition peut casser.
Le panneau couvre exactement les opérations qui se font chaque semaine dans une mairie : une nouvelle annonce, un projet de décision mis en consultation, un document téléchargé, quelques photos. Chaque action d’administration entre dans un tableau d’audit — qui, quoi, quand — parce que dans une institution publique la question « qui a publié cela » a, tôt ou tard, une réponse qui compte.
Cinq requêtes par minute depuis la même adresse pour le formulaire d’authentification ; la sixième reçoit 429. Ce n’est pas un paramètre que nous affirmons : il existe un test automatique qui vérifie exactement le retour du code 429. La différence entre une mesure configurée et une mesure testée ne se voit qu’au moment où quelqu’un change une route et l’oublie.
En production, ils se lisent de l’extérieur : interdiction de l’encadrement dans un cadre, `nosniff`, politique de référent strict, transport sécurisé imposé pendant un an avec sous-domaines, politique d’autorisations qui ferme la géolocalisation, le micro et la caméra, plus une politique de contenu explicite. Nous les vérifions avec une requête, pas avec une promesse.
Les journaux d’audit contiennent des adresses IP. Une tâche s’exécute chaque jour et supprime tout ce qui a plus de douze mois, avec la référence à la base juridique écrite dans le commentaire du code. C’est la différence entre une politique de confidentialité qui dit « nous conservons tant que nécessaire » et un système où le délai s’applique réellement tout seul.
Dans la plateforme civique, la vérification s’exécute dans les tests automatisés selon les critères WCAG 2.0 A et AA plus 2.1 A et AA, avec une ligne de référence par page : tout nouveau problème arrête la livraison, même si le niveau général n’a pas changé. Pour une institution publique, l’accessibilité n’est pas une option d’image, et la déclaration d’accessibilité ne s’écrit pas sans avoir fait tourner quelque chose.
La page d’accueil publie des données structurées de type organisation gouvernementale, avec l’adresse postale. Cela compte pour la manière dont l’institution apparaît dans les résultats et pour les systèmes qui lisent automatiquement ; c’est aussi l’une des rares catégories pour laquelle la documentation du moteur montre encore le résultat enrichi avec des questions fréquentes — mais « bien connu et faisant autorité » n’est pas une case que nous cochons nous-mêmes, donc nous ne le vendons pas comme livrable.
Nous ne déclarons pas comme livrée la liaison avec la plateforme de paiements de l’État, avec la magistrale d’interopérabilité ou avec le cabinet du citoyen : nous n’avons pas de code pour eux dans aucun dépôt. L’authentification fédérée et la signature électronique, nous les avons écrites et testées, mais arrêtées — il manque le contrat avec l’autorité et le certificat du système. Quant à l’hébergement sur l’infrastructure de l’État, là où il est obligatoire, c’est une exigence de procédure, pas une option technique.
Traseul
La première livraison est la liste des sections obligatoires pour le type de votre institution et leur correspondance avec ce que vous publiez aujourd’hui. De là, on voit ce qui manque, ce qui existe sur papier et ce qui est publié à un endroit qu’on ne peut pas citer. Le design vient après la liste, pas l’inverse.
Ce qui change rarement va dans la configuration, ce qui change souvent va dans la base, avec panneau. Nous livrons la structure complétée avec les données réelles de l’institution — pas avec du texte de remplissage — car un site d’institution avec du contenu provisoire ne peut être évalué par personne et, en général, reste ainsi.
La limite au formulaire d’authentification avec un test qui la vérifie, le journal d’audit avec suppression programmée à échéance, les en-têtes de sécurité vérifiés de l’extérieur, la page d’information sur le traitement des données avec les bases juridiques nommées. Nous livrons le résultat des vérifications, pas seulement la configuration.
Nous remettons le dépôt, le document de mise en service et les accès, plus une formation pour la personne qui publiera les annonces. La livraison n’est pas considérée comme terminée tant qu’un fonctionnaire n’a pas publié lui-même une annonce qui apparaît sur le site.
Les données
Les règles diffèrent d’un secteur à l’autre. Voici celles qui s’appliquent aux institutions & administration.
Un cas
La situation
Le panneau d’administration d’un site de mairie tient un journal d’audit : qui a publié, quoi et quand. Le journal contient des adresses IP, donc il contient des données personnelles. Presque tous les sites de ce type résolvent le problème dans une phrase de la politique de confidentialité — « nous conservons les données tant que nécessaire » — et cela se termine ainsi.
Ce que nous avons construit
J’ai rédigé le terme comme une tâche programmée : une routine s’exécute chaque jour et supprime du journal tout ce qui est plus ancien que douze mois, avec la référence au fondement juridique écrite dans le commentaire au-dessus du code. À la même étape, j’ai mis la limite sur le formulaire de connexion — cinq requêtes par minute depuis la même adresse — et un test automatisé qui vérifie le retour du code 429, afin que la mesure ne disparaisse pas silencieusement lors d’une refactorisation.
Ce qui en est sorti
La politique publiée et le comportement du système disent la même chose, et la différence peut être vérifiée : le terme est une ligne de code qui s’exécute chaque nuit, pas une intention. Les en-têtes de sécurité se lisent de l’extérieur avec une seule requête.
Ce que le cas ne dit pas
L’hébergement, les artefacts de publication et la configuration du serveur restent des informations internes. Quant au contenu — les données sur la localité, la composition du conseil, le budget — il appartient à l’institution et est fourni par elle : nous avons construit la structure et le panneau, pas les données.
Questions
La liste provient de la Décision du Gouvernement 728/2023 : transparence décisionnelle, projets et décisions, annonces, documents, contacts, budget, ainsi que les pages d’accessibilité et d’information concernant le traitement des données. Nous les construisons comme structure dès le départ. Dans le travail que nous citons, la conformité est écrite dans le code — dans les modèles et dans la configuration — et pas seulement affirmée dans l’offre.
Oui, et c’est la moitié du travail. Les annonces, les projets de décision, les documents et la galerie sont modifiés depuis le panneau. Ce qui reste dans la configuration, c’est le contenu qui change rarement — historique, géographie, composition du conseil — précisément pour qu’une édition de routine ne puisse pas endommager la structure.
Oui. Chaque action d’administration entre dans un tableau d’audit, avec l’acteur, le rôle, le type d’événement et le moment. Le journal contient aussi l’adresse IP, donc c’est une donnée personnelle et elle a un terme : tout ce qui est plus ancien que douze mois est supprimé chaque jour.
À la sixième requête en une minute depuis la même adresse, il reçoit 429. Ce n’est pas une affirmation : un test automatisé vérifie exactement ce code de réponse. En plus, les en-têtes de sécurité de la réponse réelle peuvent être lus de l’extérieur — l’interdiction de mise en cadre, `nosniff`, la politique de référence, le transport sécurisé imposé et une politique de contenu explicite.
Le code est écrit et testé, mais arrêté par un commutateur, et le test par défaut vérifie justement que l’état arrêté ne fuit rien. Ce qui manque n’est pas le code : il manque le contrat avec l’autorité et le certificat du système. La variante qui fonctionne aujourd’hui est que le citoyen signe sur le portail officiel et téléverse le document signé en retour. Nous préférons le dire avant l’appel d’offres, pas après.
Nous n’avons pas de code pour elle, dans aucun dépôt — de même pour le bus d’interopérabilité et pour le cabinet du citoyen. Nous l’avons vérifié avec une recherche par mot entier dans tous nos projets. Lorsqu’une institution en a besoin, c’est un travail d’intégration avec ses propres conditions et son propre calendrier d’accords, et c’est ainsi que nous l’écrivons dans l’offre.
Là où c’est obligatoire par décision gouvernementale, oui, et c’est une exigence de procédure, pas un choix technique. Nous le traitons comme tel dès le début, parce que cela change le mode de publication et la liste des accords nécessaires, pas seulement l’adresse du serveur.
Avec une vérification qui s’exécute dans les tests automatisés, selon les critères WCAG 2.0 A et AA plus 2.1 A et AA, avec une ligne de référence par page : tout nouveau problème bloque la livraison. La déclaration d’accessibilité est rédigée après l’exécution de la vérification, pas avant — sinon c’est un texte qui contredit la page sur laquelle il se trouve.
Dans la plateforme civique, la photographie brute reste une preuve privée ; seule la version remaniée arrive en public, avec la provenance conservée et l’approbation explicite d’un modérateur, et la personne qui remanie n’est pas celle qui approuve. Si l’état d’une image devient incertain, le dossier est retiré automatiquement du public. Ce sont des contraintes dans la base de données, pas des instructions pour l’opérateur.
Racontez-nous votre processus. Ensemble, nous décidons ce qui vaut la peine d'être construit, ce que nous pouvons connecter et comment nous vérifions le résultat.