Dossier technique

Pour le service informatique d'une collectivité qui envisage Aprop : ce que c'est, où ça tourne, ce que ça garde, qui y accède, comment c'est protégé, sauvegardé et rendu. Chaque affirmation de cette page correspond à du code ou à un document que l'éditeur peut montrer. Les limites sont dites à la fin, pas cachées au milieu.

En six lignes

Aprop est une application web installable (PWA) de coordination interne des événements municipaux, entre les services d'une mairie et ses élus. Aucun compte d'administré, aucune donnée de citoyen.
Site et données sont hébergés à Paris par Clever Cloud SAS (Nantes), société de droit français, ISO/IEC 27001 et hébergeur de données de santé. Aucun transfert hors Union européenne.
Une base PostgreSQL chiffrée au repos, sauvegardée chaque jour par l'hébergeur et chaque nuit par l'application (vingt et un jours glissants).
Un code de commune non devinable, un registre d'appareils que le maire verrouille, un second code pour les élus vérifié côté serveur. Des rôles, pas des comptes nominatifs.
Deux dépendances côté serveur, aucun script tiers dans le navigateur, politique de sécurité du contenu, TLS 1.2 et 1.3 seulement.
Export intégral des données à tout moment, contrat de sous-traitance article 28 fourni, registre des traitements tenu. Un éditeur, personne physique, et un code documenté pour que la commune ne dépende de personne.

1. Architecture

Trois pièces, et rien d'autre.

Le client : une application web en JavaScript sans cadriciel ni bibliothèque tierce, servie depuis aprop.fr, installable sur téléphone et ordinateur (Chrome, Edge, Safari, Firefox). Elle fonctionne hors ligne sur la copie locale de la commune et se synchronise dès que le réseau revient. Elle se met à jour seule, avec un interrupteur côté serveur pour geler les mises à jour un jour de réunion.
Le serveur : une application Node.js (version 22 ou plus) sur Clever Cloud, zone Paris, qui sert le site, l'application et neuf points d'API, et qui exécute quatre tâches de nuit (sauvegarde, garde des sauvegardes, rappels du matin, purge du journal). Déploiement depuis le dépôt git sans coupure de service.
La base : PostgreSQL managé par Clever Cloud, zone Paris, chiffré au repos. Un enregistrement JSON par commune (l'état complet, avec un numéro de révision et une empreinte), et des magasins séparés pour les fichiers, les abonnements aux notifications, le registre des appareils, les sauvegardes, les incidents.

Flux

téléphone / poste de l'agent ──HTTPS──▶ aprop.fr (Node.js, Paris) ──▶ PostgreSQL (Paris) ◀── état de la commune, fichiers, notifications navigateur de l'agent ──▶ Open-Meteo : nom de la commune + date (météo d'un événement) navigateur de l'agent ──▶ OpenStreetMap : coordonnées d'un signalement (adresse, carte à la demande) serveur ──▶ service de notifications du navigateur (Apple, Google, Mozilla) : message chiffré de bout en bout serveur ──▶ Brevo (Paris) : courriels à l'éditeur seulement (alertes, demandes de démonstration)

Le serveur n'appelle aucun autre service. Le navigateur n'en appelle que les deux cités, et seulement quand l'agent utilise la fonction. La politique de sécurité du contenu interdit tout le reste.

Dépendances

Côté serveur, deux bibliothèques : pg (client PostgreSQL, licence MIT) et web-push (notifications, licence MPL-2.0). Côté navigateur, aucune. Pas de cadriciel, pas de CDN, pas de police chargée depuis un tiers. C'est une surface d'attaque courte, et un code qu'une personne peut lire en entier : environ quatorze mille lignes, client, serveur et fonctions comprises.

2. Les données

Catégorie	Contenu	Durée
Événements	titre, date, lieu, tâches par service, documents joints, fil de coordination, feuille de présence d'un conseil	durée du contrat
Signalements	titre, catégorie, lieu, position, photo (métadonnées retirées), service, priorité, statut	durée du contrat
Projets, procédures, feuille de route	titres, étapes, notes, échéances	durée du contrat
Élus et équipes	nom, fonction, rattachements (pas d'adresse, pas de téléphone personnel)	durée du contrat
Journal d'activité	horodatage, rôle auteur, phrase courte ; ni adresse IP ni identifiant d'appareil	treize mois glissants, purge automatique chaque nuit
Registre des appareils	identifiant aléatoire, nom lisible, dernière ouverture, version	retrait par la commune
Sauvegardes	un instantané de chaque commune par nuit	vingt et un jours glissants

Ce qui n'est pas collecté : aucune donnée d'administré (un signalement décrit un lieu, pas une personne), aucune géolocalisation d'agent (la position enregistrée est celle du signalement, saisie volontairement), aucune mesure d'audience, aucun cookie, aucune adresse IP hormis un compteur anti-énumération sur les codes de commune inconnus. Les photos sont redimensionnées et recompressées dans le navigateur avant l'envoi, ce qui retire leurs métadonnées, position comprise.

Réversibilité : depuis les réglages, la commune produit à tout moment le « Dossier complet » (document imprimable ou PDF) et le fichier de données intégral (JSON, lisible par un autre outil). À la fin du contrat, les données sont supprimées sous trente jours, sauvegardes comprises après leur cycle de vingt et un jours. Les données créées par la commune dans Aprop restent les siennes, archives publiques comprises.

3. Accès et identité

Le code de la commune : un secret non devinable (préfixe lisible et suffixe aléatoire), transmis dans un en-tête de requête, jamais dans une adresse. Un code n'ouvre que sa commune : les espaces sont cloisonnés côté serveur. Au-delà de quarante codes inconnus en dix minutes depuis une même adresse, le serveur répond 429.
Le registre des appareils : chaque téléphone ou poste porte un identifiant aléatoire tiré sur lui-même et un nom lisible. Le maire peut verrouiller la commune : un appareil inconnu s'inscrit alors en attente et n'obtient rien tant qu'il n'est pas approuvé depuis un appareil déjà approuvé. Retirer un appareil lui coupe l'accès au serveur en quelques secondes. Soixante appareils au plus par commune.
Le code élus : un second code, distinct, vérifié sur le serveur et jamais renvoyé au navigateur. Huit échecs en dix minutes ferment la vérification pour le reste de la fenêtre. Le déverrouillage expire au bout de douze heures dans un simple onglet, trente jours sur une application installée.
Des rôles, pas des personnes : Aprop authentifie neuf services et les élus. Le journal signe « Services techniques » ou « M. le Maire ». Il n'y a ni comptes nominatifs, ni mots de passe individuels, ni annuaire à synchroniser : c'est un choix de conception pour un outil de coordination, et une limite dite plus bas.
L'éditeur : une clé de service, transmise en en-tête, donne accès aux fonctions d'exploitation (sauvegardes, restauration, tableau de bord) ; le tableau de bord ne montre que des compteurs, jamais un contenu de commune. Les consoles de l'hébergeur et du dépôt de code sont protégées par une double authentification.

4. Sécurité des échanges et du navigateur

HTTPS sur tout le service, certificats renouvelés automatiquement, TLS 1.2 et 1.3 seulement (1.0 et 1.1 refusés), HSTS un an.
Politique de sécurité du contenu (CSP) : aucun script venu d'un autre site, aucune connexion hors des services cités en 1, aucun cadre sauf la carte OpenStreetMap, et le site lui-même ne peut être encadré par personne. Sur la vitrine, chaque page n'autorise que ses propres scripts, reconnus par empreinte.
En-têtes de protection : X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy (microphone refusé, caméra et position réservées à l'application).
Les fichiers déposés (photos, PDF) sont servis dans un bac à sable qui neutralise tout script embarqué ; types et taille sont contrôlés à l'envoi (cinq mégaoctets au plus).
Tout ce que le navigateur affiche est échappé ; l'audit externe de septembre 2026 a passé les cinquante-sept points d'injection sans trouver de faille.
Un point de contact de sécurité est publié au format standard : /.well-known/security.txt.

5. Hébergement et exploitation

Hébergeur : Clever Cloud SAS, 4 rue Voltaire, 44000 Nantes (RCS Nantes B 524 172 699), société de droit français, certifiée ISO/IEC 27001 et hébergeur de données de santé, qui opère ses propres centres de données en France. Application et base de données en zone Paris. Aucun prestataire soumis au droit américain dans la chaîne de traitement des données de la commune.
Déploiement : depuis le dépôt git, sans coupure ; chaque version est numérotée et les téléphones se mettent à jour seuls, avec un interrupteur côté serveur.
Journaux : le serveur journalise le chemin et le code de réponse de chaque requête, jamais la chaîne de requête, jamais un code de commune, jamais un contenu. Les journaux techniques de l'hébergeur relèvent de sa propre politique.
Surveillance : un point d'état public (/api/sante), un tableau de bord d'exploitation à compteurs, un chien de garde qui vérifie chaque matin que chaque commune a sa sauvegarde de la nuit et alerte l'éditeur par courriel sinon.
Disponibilité : objectif contractuel de 99 % en moyenne mensuelle. Une seule instance applicative, sans haute disponibilité : c'est un outil de coordination, pas un système de secours, et l'application continue de fonctionner hors ligne pendant une interruption.

6. Sauvegardes et reprise

Chaque nuit à 2 h UTC, un instantané de chaque commune est archivé, conservé vingt et un jours. Avant toute intervention de l'éditeur sur un espace, l'état en place est archivé, ce qui permet de revenir en arrière.
La base PostgreSQL est, en plus, sauvegardée chaque jour par l'hébergeur.
La restauration d'un instantané est une opération écrite dans le guide d'exploitation de l'éditeur ; un exercice de restauration est mené chaque mois sur un espace de démonstration, et sa date est tenue dans le journal de maintenance.
Plan de reprise : le code vit dans un dépôt git, les données dans les instantanés. Un redéploiement chez un autre hébergeur européen, avec restauration des instantanés, se fait en quelques heures.

7. Protection des données (RGPD)

La commune est responsable de traitement ; l'éditeur est sous-traitant au sens de l'article 28. Une annexe contractuelle le formalise : instructions, confidentialité, assistance, audit, sous-traitants ultérieurs, durées, suppression en fin de contrat.
Sous-traitant ultérieur : Clever Cloud, seul. Les services appelés par le navigateur de l'agent (Open-Meteo, OpenStreetMap, service de notifications) sont nommés dans l'annexe avec ce qu'ils reçoivent.
Violation de données : l'éditeur notifie le référent et le délégué à la protection des données de la commune sous vingt-quatre heures ; la commune saisit la CNIL dans son délai de soixante-douze heures.
Registre : l'éditeur tient le sien (article 30.2) et fournit à la commune la matière de sa fiche (article 30.1). L'analyse d'impact relève de l'appréciation de la commune ; au vu des données (pas de catégorie particulière, pas de profilage, petite échelle), elle n'est pas requise à notre lecture, et l'éditeur fournit la matière si la commune la décide.
Le journal d'activité sert la coordination, pas le contrôle individuel : le contrat l'écrit, et la commune informe ses agents et consulte ses instances si nécessaire.

Le détail, en langage courant, est sur la page Conformité et données.

8. Qualité, audits, maintenance

Deux cent quarante vérifications automatiques à chaque version : logique métier, fusion serveur des écritures simultanées, en-têtes, politique de contenu, crons, conformité des promesses écrites avec le code.
Un audit externe en lecture seule du dépôt et du service, les 2 et 3 septembre 2026 (sécurité, RGPD, pertes de données, ergonomie), suivi d'un rapport de corrections ; une revue de conformité le 15 octobre 2026 avant la mise à disposition d'une première commune.
Aucun test d'intrusion externe à ce jour (dit plus bas).
L'éditeur est une personne physique, entrepreneur individuel. Pour que la commune ne dépende de personne : export intégral à tout moment, code court et documenté (guide d'exploitation, procédure de restauration, procédure de rotation d'un code), réversibilité contractuelle, et une clause de remise du code source : si l'éditeur cesse son activité ou ne peut plus assurer le service, la commune reçoit le code et sa documentation, avec une licence gratuite limitée à son propre usage, par ses services ou par un prestataire de son choix.

9. Accessibilité

Pas de déclaration de conformité RGAA, faute d'audit complet. Une vérification outillée (axe-core, WCAG 2.2 AA) a été passée le 15 octobre 2026 sur toutes les pages et les écrans principaux, et ce qu'elle a relevé a été corrigé. La page Accessibilité dit ce qui a été vérifié et ce qui ne l'a pas été.

10. Ce que nous ne faisons pas

Pas de comptes nominatifs ni d'authentification unique (SSO) avec l'annuaire de la collectivité. Les accès sont des rôles et des appareils approuvés. Si la collectivité l'exige, c'est une évolution à étudier, pas une case à cocher.
Pas de haute disponibilité : une instance, un hébergeur. Une interruption se traduit par un mode hors ligne, pas par une perte de données.
Pas de qualification SecNumCloud : elle n'est pas requise pour ces données, et nous ne la revendiquons pas. Les certifications citées (ISO 27001, HDS) sont celles de l'hébergeur, pas celles d'Aprop.
Pas de test d'intrusion externe : les audits menés sont des revues de code et de service. Nous accueillons un test d'intrusion commandé par la collectivité, sur un espace d'essai.
Pas de déclaration de conformité RGAA sans audit complet.
Pas de retrait automatique des appareils inactifs : c'est la commune qui retire un appareil, depuis son registre.

Pour aller plus loin

Écrire à contact@aprop.fr. L'éditeur fournit sur demande : l'annexe « données personnelles », son registre de sous-traitant, le guide d'exploitation, le rapport de l'audit de septembre 2026 et ses corrections, et un espace d'essai pour les vérifications du service informatique.

Dernière mise à jour : 15 octobre 2026. Version de l'application au jour de la mise à jour : 230.