Sallia

Sécurité & transparence

Cette page est le dossier de due diligence de Sallia : elle répond aux questions que pose une collectivité qui instruit sérieusement l'achat d'un logiciel — où sont les données, qui y a accès, comment le service est protégé, ce que les audits ont trouvé, ce que le contrat engage, et ce que le produit ne sait pas encore faire. Elle est publique, sans envoi sur demande, limites comprises.

Sallia — gestion des salles et équipements communaux · Édité par Wilder Labs · Version du 3 septembre 2026 · Dernier audit interne intégral : 28 mai 2026

Comment lire ce document

Chaque réponse porte une étiquette : Vérifié pour ce qui est constaté sur le service réellement en ligne, Partiel pour ce qui existe mais avec une réserve, Limite assumée pour ce qui n'existe pas encore et que nous ne présentons donc pas comme acquis.

Nous ne nommons aucune commune cliente et ne publions aucun détail d'infrastructure exploitable.

1. Méthode

Ce dossier a été établi en confrontant le contrat publié, la documentation interne et le service réellement en production.

Sur quoi reposent les affirmations de ce document ? Vérifié

Sur des observations faites sur l'environnement de production : en-têtes HTTP relevés sur les adresses publiques réellement servies, code exécuté par le service (et non la copie de travail des développeurs, qui peut en diverger), et interrogations en lecture seule de la base. Chaque « vérifié » correspond à un constat, chaque « limite » à une absence constatée.

Wilder Labs n'est pas un organisme d'audit : ce document décrit un état des lieux, il ne vaut pas certification.

2. Architecture & hébergement

Ce que le service est techniquement, et où résident les données.

Qu'est-ce que Sallia, techniquement ? Vérifié

Une application web hébergée (SaaS), accessible depuis un navigateur, sans installation sur les postes de la mairie. Chaque commune cliente dispose de son propre sous-domaine et de son espace de données dédié. Trois surfaces coexistent : l'espace de travail des agents, le portail public destiné aux habitants et aux associations, et un espace association pour les utilisateurs réguliers.

Où les données sont-elles hébergées ? Vérifié

Chez OVH SAS, société française, sur une infrastructure située en France. L'application, la base de données, le stockage des fichiers et les sauvegardes sont opérés par Wilder Labs sur cette infrastructure : aucun composant n'est délégué à un service de stockage ou de calcul tiers.

Le stockage des photos d'états des lieux, des conventions et des pièces jointes est un stockage objet auto-hébergé, joignable uniquement depuis le réseau interne du serveur. Il n'est accessible depuis Internet par aucun chemin direct.

Les fonds de carte proviennent-ils d'un fournisseur américain ? Vérifié

Non. Les cartes proviennent de l'IGN, établissement public français, via la Géoplateforme de l'État — le service qui alimente cartes.gouv.fr. Ce n'est pas seulement une intention : la politique de sécurité envoyée par le serveur à chaque page n'autorise que cette source pour les images cartographiques, et un fournisseur tiers ajouté par erreur serait bloqué par le navigateur lui-même.

L'aide à la saisie d'adresse interroge la Base Adresse Nationale (service public français). Ces deux services reçoivent l'adresse IP du visiteur et, pour la seconde, le texte saisi dans le champ adresse. Ces appels partent directement du navigateur de l'usager : ils n'apparaissent donc pas dans la liste des prestataires appelés par nos serveurs.

Y a-t-il des outils de mesure d'audience ou de publicité ? Vérifié

Aucun. Pas de traceur publicitaire, pas d'outil de mesure d'audience tiers, pas de réseau de diffusion de contenu externe pour les données. Recherche exhaustive menée sur l'ensemble des fichiers servis en production : aucune occurrence des solutions courantes du marché.

3. Isolation entre communes

Sallia est mutualisé : plusieurs communes sont servies par la même application. Voici comment l'étanchéité entre elles est garantie.

Quel est le modèle d'isolation ? Vérifié

Chaque commune cliente dispose d'un espace de données dédié et cloisonné au niveau de la base. L'espace applicable à une requête est déterminé par le serveur, à partir du sous-domaine appelé, avant toute exécution : il n'est jamais transmis par le navigateur ni modifiable depuis le client. Un visiteur ne peut donc pas, par la seule navigation ou en manipulant une adresse, faire remonter les données d'une autre commune.

Les fichiers déposés (photos d'états des lieux, documents) sont eux aussi rangés par commune dans le stockage objet, et les accès délivrés à l'application sont limités à l'espace de la commune concernée.

L'isolation repose-t-elle uniquement sur la discipline du code ? Partiel

Non : elle repose aujourd'hui sur plusieurs couches indépendantes — le cloisonnement des espaces de données, la détermination de la commune côté serveur, et un compte technique restreint dont les droits sont limités aux seules données de Sallia. Ce compte n'a aucun accès, même en lecture, aux données des autres applications éditées par Wilder Labs qui partagent la même infrastructure. Cette restriction a été mise en place et vérifiée en conditions réelles, sans interruption de service.

Renforcement en cours Une couche de protection supplémentaire, opérant directement au niveau de la base de données, est en cours de généralisation. Elle est déjà en service sur une autre application de notre catalogue, a été validée en environnement de développement, et se déploie par vagues prudentes sur Sallia pour ne prendre aucun risque sur le service rendu aux communes déjà en production. À ce jour, la protection effective est assurée par les couches décrites ci-dessus ; celle-ci les durcit, elle ne les remplace pas.

Des fonctions techniques traitent-elles les données de plusieurs communes à la fois ? Vérifié

Oui : deux fonctions techniques traitent des données de plusieurs communes en une seule opération — l'acheminement des courriels sortants et le traitement des demandes d'assistance. Elles sont nécessaires au fonctionnement du service (un courriel doit partir même quand personne n'est connecté). Les données y sont filtrées par commune à chaque lecture, et ces fonctions ne sont pas accessibles depuis les interfaces utilisateur des communes.

4. Sous-traitants et destinataires

La liste complète des tiers qui voient passer une donnée, en distinguant ceux que nos serveurs appellent de ceux que le navigateur de l'usager appelle directement.

Quels tiers sont appelés par nos serveurs ? Vérifié

DestinataireRôleLocalisationÉtat
OVH SASHébergement (application, base, fichiers, sauvegardes)FranceActif
Brevo (Sendinblue SA)Acheminement des courriels transactionnelsFranceActif
Stripe Payments EuropeEncaissement de l'abonnement Sallia (Wilder Labs → commune) uniquementIrlande, UEActif
DINUM — FranceConnectAuthentification des habitants, si la commune l'activeFranceVoir §7
WilderSign (Wilder Labs)Signature électronique des conventions de locationFrance, infrastructure Wilder LabsActif

Brevo voit l'adresse du destinataire et le contenu du courriel — donc, selon le message, le nom d'un locataire, la salle et la date. WilderSign, bien qu'édité par Wilder Labs, est un service distinct et un destinataire réel de données personnelles (nom, signature, preuve horodatée).

Quels tiers sont appelés directement par le navigateur ? Vérifié

L'IGN Géoplateforme et la Base Adresse Nationale (voir §2), tous deux services publics français, et Stripe au seul moment du paiement de l'abonnement par la commune. Ces appels ne transitent pas par nos serveurs : le tiers reçoit donc l'adresse IP du poste concerné.

Aucun des grands fournisseurs américains d'informatique en nuage n'intervient dans le traitement des données métier : ni pour l'hébergement, ni pour le stockage des fichiers, ni pour les sauvegardes, ni pour la mesure d'audience — qui est simplement absente (§2).

Des données partent-elles vers un service d'intelligence artificielle ? Vérifié

Non. Le produit contient des fonctions optionnelles susceptibles de s'appuyer sur un service d'IA, mais elles ne sont configurées sur aucune commune et ne peuvent donc pas s'exécuter : aucune donnée de commune n'a été transmise à ce titre.

Engagement pris pour la suite L'activation d'un tel service ne doit pas pouvoir se faire par un simple réglage technique global. Nous nous engageons à ne recourir à aucun service d'IA sur les données d'une commune sans son accord écrit préalable, et à conditionner l'activation à un réglage propre à chaque commune. Cette clause n'est pas encore inscrite au contrat : elle le sera.

Comment sommes-nous informés d'un changement de sous-traitant ? Partiel

Les conditions particulières de service prévoient une notification par courriel avec un préavis minimum de 30 jours, un droit d'opposition de la commune, et une résiliation sans préavis si l'opposition est motivée par une non-conformité au RGPD.

Limite assumée Cet engagement est aujourd'hui purement organisationnel : aucun mécanisme technique ne le déclenche automatiquement, et la liste contractuelle des destinataires n'a pas toujours suivi l'évolution du produit. Deux engagements vérifiables y répondent : publier la liste des destinataires à une adresse stable et datée (cette page), et intégrer au contrôle automatique de chaque mise en production une vérification des domaines externes appelés.

5. Sécurité

Ce qui protège le service, et ce qui n'est pas encore en place. Nous décrivons les mécanismes sans publier les paramètres qui aideraient quelqu'un à les contourner.

Comment les utilisateurs sont-ils authentifiés ? Vérifié

Par session serveur, avec un cookie inaccessible au code de la page, jamais transmis en clair, jamais envoyé depuis un autre site, et expirant automatiquement. Aucun jeton d'authentification n'est stocké dans le navigateur ni transporté dans une adresse — une adresse contenant un jeton fuit par l'historique, les journaux et les en-têtes de navigation.

Les mots de passe sont stockés sous forme d'empreinte non réversible, jamais en clair, jamais journalisés. Les formulaires de connexion et de mot de passe oublié répondent de façon identique que le compte existe ou non : il est impossible de constituer la liste des agents d'une commune en sondant le service. Une protection contre les tentatives répétées est en place, et elle est indexée sur le compte visé, non sur l'adresse du demandeur — elle résiste donc à une attaque répartie sur de nombreuses adresses.

La double authentification est-elle disponible ? Partiel

Oui, avec une application d'authentification standard, un secret chiffré et des codes de récupération stockés sous forme d'empreinte. Le mot de passe seul ne suffit pas à ouvrir une session lorsqu'elle est activée.

Limite assumée La double authentification est disponible et activable par chaque agent dès aujourd'hui. Un réglage permettant à une commune de la rendre obligatoire pour l'ensemble de ses agents est en préparation.

Quel niveau de chiffrement protège les échanges ? Vérifié

TLS 1.2 et TLS 1.3 uniquement — les protocoles antérieurs sont refusés. Tout accès en clair est redirigé de façon permanente vers la version chiffrée, et le domaine et ses sous-domaines sont inscrits sur la liste de préchargement des navigateurs : un navigateur refuse toute connexion non chiffrée, y compris à la toute première visite. Certificats renouvelés automatiquement.

Quelles protections contre l'injection de code dans les pages ? Vérifié

Une politique de sécurité de contenu stricte, effectivement servie et non simplement déclarée : les scripts ne peuvent provenir que de Sallia, sont autorisés un par un au moyen d'une valeur unique régénérée à chaque réponse, et les gestionnaires d'événements écrits dans le HTML sont interdits. La vérification a été refaite sur le portail public d'une commune, c'est-à-dire sur la surface réellement exposée aux habitants, et pas seulement sur la page d'accueil.

Les en-têtes de sécurité complémentaires attendus sont présents, y compris ceux qui empêchent l'intégration de nos pages dans un site tiers et la fuite d'adresse par référent.

Limite actuelle La politique autorise encore les feuilles de style écrites dans la page. L'impact est très inférieur à celui d'un assouplissement sur les scripts — cela n'autorise pas l'exécution de code — et c'est le dernier assouplissement restant à retirer.

Le service est-il protégé contre les abus de volume ? Vérifié

Oui, par une limitation de débit à plusieurs étages, distincte selon qu'il s'agit d'un visiteur anonyme ou d'une session authentifiée, et bornée dans tous les cas par un plafond absolu. Le service tourne derrière un relais : la limitation s'appuie sur l'adresse résolue par la chaîne de confiance configurée et non sur un en-tête que le client pourrait fabriquer. Le dispositif a été éprouvé en conditions réelles sur la production, sans toucher aucun compte réel.

Quelles données sont chiffrées au repos ? Partiel

Les secrets d'authentification et d'intégration sont chiffrés en base au moyen d'un chiffrement authentifié standard : une donnée altérée est rejetée plutôt que déchiffrée silencieusement. L'implémentation a été relue en cherchant spécifiquement les erreurs classiques de ce mode de chiffrement ; elles sont évitées. La clé n'est ni dans le code, ni en base, ni versionnée : elle est fournie au service par sa configuration d'exécution.

Les sauvegardes d'archivage long terme sont chiffrées avant stockage. La copie quotidienne de proximité est compressée, protégée par les droits d'accès du système de fichiers, puis transférée hors du serveur de production.

Limite assumée Aucune procédure de renouvellement de la clé de chiffrement n'est outillée à ce jour. Il n'y a pas de faille, mais pas non plus de remédiation rapide si cette clé devait être renouvelée. Le correctif est identifié.

Des secrets figurent-ils dans le code source ? Vérifié

Aucun secret de production n'est versionné. Les fichiers de configuration, certificats et clés sont exclus du dépôt ; seul un gabarit à valeurs vides y figure. Les secrets critiques sont déclarés en mode bloquant : le service refuse de démarrer si l'un d'eux manque, ce qui élimine par construction la classe de défaut « valeur de repli oubliée dans le code ». Une recherche automatique de secrets exposés est exécutée sur le code et son historique à chaque modification proposée, ainsi qu'une fois par semaine.

Une politique de divulgation responsable est publiée à l'adresse standard /.well-known/security.txt.

Existe-t-il un journal d'audit ? Partiel

Un journal d'activité applicatif existe, propre à chaque commune (aucun mélange possible), alimenté en usage réel, consultable et exportable par la commune elle-même depuis son espace d'administration, avec filtres. Il couvre la facturation, les demandes de réservation, les événements, les comptes et rôles, les associations, les prêts de clés et de matériel, les subventions et le cimetière.

Limite actuelle Ce n'est pas une piste d'audit opposable : les connexions n'y sont pas encore tracées, et le journal ne dispose ni de chaînage cryptographique ni d'un mécanisme d'écriture seule qui garantirait son inaltérabilité. Rendre ce journal opposable est un chantier identifié.

Un second journal, propre aux parcours FranceConnect, enregistre les adresses IP et le navigateur uniquement sous forme d'empreinte salée, jamais en clair — contrôlé sur l'intégralité de ses entrées : aucune adresse lisible n'y figure.

Comment les correctifs de sécurité arrivent-ils en production ? Vérifié

La chaîne de livraison est entièrement scriptée ; personne ne copie de fichier à la main sur le serveur. Dans l'ordre :

  1. vérification du code et exécution des tests avant toute construction ;
  2. construction hors production, image identifiée par son empreinte puis signée cryptographiquement ;
  3. aucun déploiement automatique en production : un geste manuel explicite est requis, pour qu'aucune modification n'atteigne une commune sans qu'un humain l'ait voulu à cet instant ;
  4. la production ne construit rien — elle vérifie la signature et refuse une image non signée ou altérée ;
  5. sauvegarde de la base avant toute migration, avec contrôle que la sauvegarde est bien exploitable ; une sauvegarde absente ou tronquée interrompt le déploiement ;
  6. migrations jouées avant la bascule : jamais de nouveau code servi contre une base non migrée ;
  7. tests de bon fonctionnement, puis parcours d'interface dans un vrai navigateur, protections actives ;
  8. retour arrière automatique vers la version précédente si l'un de ces contrôles échoue.

S'y ajoutent une suite de tests de bout en bout jouée chaque nuit et un examen de sécurité automatique hebdomadaire des composants utilisés.

Deux limites actuelles Ce dispositif a déjà été mis à l'épreuve et il a échoué une fois, en août 2026 : le contrôle final a bien détecté un problème, mais le retour arrière automatique n'a pas fonctionné. La cause a été identifiée et corrigée le jour même, et la version de repli est désormais déterminée et vérifiée avant chaque déploiement. Par ailleurs, l'examen de sécurité hebdomadaire est encore en mode « avertissement » : il signale sans bloquer une mise en production. La production est à jour aujourd'hui ; le passage en mode bloquant est prévu pour ne plus en dépendre.

Dans quel délai une faille est-elle corrigée ? Partiel

La chaîne décrite ci-dessus permet de porter un correctif en production en moins d'une heure, sauvegarde et contrôles compris : le délai de correction n'est jamais allongé par le délai de livraison. En pratique, une faille critique est corrigée et déployée le jour même ; une vulnérabilité élevée sur un composant tiers, dans la semaine.

Limite assumée Ces délais décrivent une pratique observée, pas un engagement contractuel : aucun délai de correction n'est aujourd'hui inscrit aux conditions de service. Une commune qui souhaite un engagement chiffré peut le demander ; il est tenable au vu de la chaîne de déploiement, mais il n'est pas encore écrit.

Des tests d'intrusion sont-ils réalisés ? Limite assumée

Non.

Ce qui existe : des audits de sécurité internes complets et documentés, couvrant l'authentification et les sessions, les injections, l'isolation entre communes, la gestion des secrets, les notifications entrantes, les téléversements, les en-têtes de sécurité, la limitation de débit et les fuites de données personnelles. S'y ajoutent les analyses automatiques hebdomadaires et une politique de divulgation responsable publiée.

Ce qui n'existe pas : un test d'intrusion conduit par un cabinet tiers indépendant. Aucun rapport de ce type ne peut donc être produit.

Toute commune qui en fait un point d'instruction peut mandater le prestataire indépendant de son choix : nous nous engageons à traiter ses conclusions selon les mêmes délais que nos propres audits.

6. Protection des données (RGPD)

Rôles, documentation, durées réellement appliquées et droits des personnes.

Qui est responsable de traitement ? Vérifié

La commune cliente est responsable de traitement au sens de l'article 4.7 du RGPD : elle décide des finalités (gestion du domaine public communal, instruction des dossiers de location). Wilder Labs est sous-traitant au sens de l'article 28 : il héberge et opère la plateforme pour le compte de la commune, sans définir les finalités. Conséquence pratique : les administrés exercent leurs droits auprès de leur commune en priorité.

Cette répartition est cohérente sur les trois documents de référence : politique de confidentialité publique, convention de sous-traitance et registre des traitements.

Une convention de sous-traitance (article 28) est-elle fournie ? Vérifié

Oui. Un modèle complet, conforme aux clauses contractuelles types de la Commission européenne (décision d'exécution 2021/915), est prêt à signer par chaque commune : objet, sous-traitance ultérieure, droits des personnes, notification de violation, sécurité, sort des données en fin de contrat, registre et audit. Il est communiqué sur demande à dpo@sallia.fr.

Un registre des traitements et une analyse d'impact existent-ils ? Partiel

Oui : un registre couvrant les traitements du produit, avec finalités, bases légales, catégories de données, durées et destinataires, et une analyse d'impact (AIPD) conduite selon la méthodologie PIA de la CNIL, qui analyse cinq scénarios de risque avec mesures et niveau résiduel documentés, et conclut à un risque acceptable.

Limite actuelle Ces documents internes sont en cours de mise à jour : certaines mentions sont devenues inexactes, notamment sur l'identification de l'hébergeur et sur des fonctions optionnelles depuis retirées du produit. L'hébergement réel est en France, et les fonctions concernées ne sont pas actives ; la correction des documents est en cours.

Les durées de conservation annoncées sont-elles réellement appliquées ? Vérifié

Oui : les durées annoncées ont été vérifiées en confrontant la politique publiée, le code et les données réelles.

DonnéeDurée annoncéeConstat
Pièces justificatives d'un dossier de location (pièce d'identité, assurance, justificatif de domicile)Purge automatique 30 jours après clôture du dossier, paramétrable de 7 à 90 joursTraitement automatique quotidien, exécution réelle constatée dans les journaux ; aucune pièce en retard chez les communes utilisatrices
Journal d'activité90 jours glissantsPurge automatique quotidienne, exécution réelle constatée ; aucune entrée au-delà de la durée annoncée
Demandes refusées ou annuléesNon annoncée publiquementPurgées quelques semaines après clôture — sera ajouté à la politique publiée
Limite de la vérification Le mécanisme de purge est volontairement prudent : il s'abstient au moindre doute sur la clôture du dossier, ce qui exclut toute suppression prématurée. Le revers est qu'une pièce pourrait théoriquement rester en base si le signal de clôture n'arrivait jamais. L'ajout d'un plafond absolu, indépendant de l'état du dossier, est identifié.

Comment un habitant exerce-t-il ses droits ? Vérifié

Un parcours public existe sur le portail de chaque commune, en deux temps : dépôt de la demande, puis exécution après confirmation par un lien signé envoyé à l'adresse concernée et valable 24 heures — ce qui évite qu'un tiers exerce les droits d'autrui.

  • Accès et portabilité : export structuré des demandes, événements, paiements, contacts, états des lieux et inscriptions liés à l'adresse du demandeur.
  • Effacement : anonymisation des données identifiantes plutôt que suppression physique des lignes, pour préserver l'intégrité comptable des pièces de facturation — pratique admise par l'article 4.5 du RGPD.

Que se passe-t-il en cas de violation de données ? Partiel

Le cadre contractuel existe : notification de l'éditeur vers la commune dans un délai court et fixé, obligation pour la commune de notifier la CNIL sous 72 heures avec notre assistance documentaire, information des personnes concernées le cas échéant.

Limite assumée La clause existe ; l'exercice n'a jamais été joué. Il n'existe pas à ce jour de procédure opérationnelle testée (qui fait quoi, dans quel ordre, avec quels modèles de courrier) permettant de démontrer que le délai de 72 heures serait tenu en conditions réelles. C'est identifié comme un chantier prioritaire : une clause non éprouvée n'est pas une garantie.

Y a-t-il des transferts hors Union européenne ? Vérifié

Non pour le traitement principal : l'infrastructure est en France, et les sous-traitants ultérieurs actifs sont établis dans l'Union. Les fonctions optionnelles susceptibles d'impliquer un service non européen ne sont configurées sur aucune commune, et nous nous engageons (§4) à ne pas les activer sans accord écrit préalable et sans réglage propre à chaque commune.

7. FranceConnect

L'état réel de FranceConnect sur Sallia, section par section.

FranceConnect est-il utilisable sur Sallia aujourd'hui ? Limite assumée

Oui, à une condition qui ne dépend pas de nous : que la commune obtienne sa propre habilitation auprès de la DINUM (démarche Datapass). Sans elle, le bouton FranceConnect n'apparaît nulle part sur le portail : la fonction est simplement absente, ce n'est pas un affichage dégradé.

Une habilitation mutualisée, qui aurait permis à toutes les communes clientes de s'appuyer sur un dossier porté par Wilder Labs, a été demandée et n'a pas abouti. L'architecture technique correspondante existe et fonctionne, mais elle reste inerte : c'est la clé administrative qui manque, pas le mécanisme.

Conséquence commerciale que nous assumons : FranceConnect ne doit pas être compté comme un acquis dans une décision d'achat de Sallia. Le portail public, l'identification par compte et l'ensemble des parcours de réservation fonctionnent intégralement sans lui. FranceConnect est un plus, conditionnel — et le délai d'instruction annoncé par la DINUM (quelques semaines) ne préjuge pas de l'issue.

Qu'est-ce qui est déjà prêt côté logiciel pour FranceConnect ? Vérifié

  • Une implémentation complète du protocole (démarrage, retour, récupération du profil, déconnexion globale), validée de bout en bout sur l'environnement de test de FranceConnect.
  • Un écran d'administration où la commune saisit ses propres identifiants une fois son habilitation obtenue.
  • Un guide pas-à-pas pour l'agent qui monte le dossier Datapass : formulation de la finalité, base légale, adresses à déclarer, pièces à joindre.

Quelles données sont demandées, et lesquelles sont conservées ? Partiel

DonnéeUsageConservation
Identifiant techniqueRattache une demande ou un compte à une identité vérifiéeConservé sur la demande ou le compte
Prénom, nomPré-remplit et verrouille les champs d'identité du formulaireConservés dans la demande
Adresse électroniquePré-remplit le formulaire et permet de retrouver un compte existantConservée dans la demande ou le compte
Date de naissanceTransmise au formulaire (vérification de majorité)Conservée si l'usager valide sa demande

Jamais demandés : adresse postale, téléphone, genre, identifiant fiscal, données de santé, identité pivot complète. Le téléphone et l'adresse, lorsqu'ils sont nécessaires à la réservation, sont saisis par l'usager hors FranceConnect.

Deux garanties de fond : les champs d'identité pré-remplis sont rendus non modifiables — un usager ne peut pas s'authentifier sous une identité puis réserver sous une autre — et la mention « identité vérifiée » n'est apposée que si l'adresse transmise correspond à celle de la demande.

Réserve en cours de correction Nos pages publiques dédiées à FranceConnect ont été rédigées avant plusieurs évolutions et comportent des mentions désormais inexactes, dont une sur la date de naissance et une sur le statut de notre habilitation. Elles sont en cours de réécriture pour être alignées sur le tableau ci-dessus. Pour une réponse à consultation, c'est le tableau ci-dessus qu'il faut retenir.

Une commune peut-elle voir ou utiliser l'identification d'une autre ? Vérifié

Non. La commune concernée est retrouvée à partir de la session ouverte au démarrage du parcours, jamais à partir d'une valeur que le navigateur pourrait fabriquer. Le rapprochement avec un compte agent est doublement filtré par commune. L'identifiant de session est régénéré avant l'ouverture de la session applicative. Un compte inconnu du service n'ouvre aucune session. Enfin, la configuration, le cache et les journaux d'authentification sont cloisonnés par commune : la suppression d'un espace efface ses propres traces et rien d'autre.

8. Régie publique, paiement et chaîne comptable

Spécifique au secteur communal : où s'arrête l'outil, où commence la responsabilité du régisseur et du comptable public.

Comment Sallia s'insère-t-il dans une régie de recettes ? Vérifié

Sallia est un outil au service de la régie, pas un opérateur de régie. La création de la régie par délibération, la nomination du régisseur, son cautionnement et les contrôles du comptable public (article L1611-4 du CGCT) restent entièrement de la responsabilité de la commune : Wilder Labs ne se substitue à aucun de ces actes.

Point décisif : Sallia ne détient, ne route et n'encaisse à aucun moment l'argent des usagers sur un compte de l'éditeur. Soit le paiement en ligne redirige l'habitant directement vers le dispositif de la DGFiP, sur le numéro de collectivité de la commune, soit c'est un règlement hors ligne que la mairie encaisse elle-même. Le rôle de Sallia est de présenter le tarif, générer la référence, déclencher l'appel, recevoir le statut retour et tracer la facture.

Le paiement en ligne PayFiP est-il opérationnel ? Limite assumée

Le code est réel et conforme au guide d'intégration de la DGFiP : appel du service officiel, validation stricte des paramètres, gestion des différents codes de retour, tests automatisés sur la construction et l'interprétation des échanges. Il remplace une intégration antérieure devenue non conforme.

Mais aucune commune cliente n'a à ce jour de convention PayFiP active, et le module n'a donc jamais été éprouvé sur un paiement réel de bout en bout. Ce n'est pas un blocage technique : la convention avec la direction départementale des finances publiques, le compte de dépôt de fonds et la déclaration des adresses de retour sont des démarches administratives que seule la commune peut engager. Tant qu'aucun numéro de collectivité n'est renseigné, le service refuse proprement tout appel, avec un message explicite pour l'agent — pas un échec silencieux.

Comment la caution est-elle gérée ? Vérifié

La commune choisit son mode : chèque de garantie conservé et encaissé seulement en cas de dégâts, encaissement par le dispositif de la DGFiP, ou suivi par la trésorerie hors Sallia. Le mode chèque, qui est le choix par défaut, fonctionne dès aujourd'hui sans aucune démarche administrative.

Ce qui rend une retenue opposable va au-delà du canal d'encaissement : le statut de caution est dérivé automatiquement de l'état des lieux de sortie, avec un délai de restitution calculé. En cas de dégâts constatés, le logiciel génère un justificatif de retenue visant l'article 1731 du Code civil, reprenant les éléments dégradés ou manquants et leurs photos, avec traçabilité du montant retenu et notification au locataire.

Stripe est-il utilisé pour l'argent des habitants ? Vérifié

Non. Stripe encaisse uniquement l'abonnement Sallia que Wilder Labs facture à la commune — une recette privée de l'éditeur. Aucun paiement d'habitant ne transite par ce canal : aucune page du portail habitants n'y conduit, et les points d'entrée correspondants refusent explicitement l'appel côté serveur si la commune n'a pas retenu ce mode. Le formulaire de carte n'est jamais affiché dans Sallia et aucune donnée bancaire ne transite par nos serveurs.

Les factures sont-elles au format Factur-X ? Et Chorus Pro ? Partiel

Les factures émises sont produites au format Factur-X profil Minimum : le fichier structuré est généré et réellement attaché au PDF, avec les marqueurs d'archivage attendus. Des tests automatisés en vérifient la structure à chaque livraison. La validation par l'outil de référence du secteur n'est pas encore intégrée à la chaîne automatique : les tests vérifient la présence des bons marqueurs, pas une conformité certifiée.

Chorus Pro — à ne pas confondre Il n'existe aucune intégration automatique avec Chorus Pro : Sallia ne dépose pas de facture par interface applicative. Le produit permet de renseigner les codes de service et d'engagement de la commune à titre d'aide-mémoire, rien de plus. Une facture générée par Sallia doit être déposée manuellement par la commune si son destinataire l'exige. C'est une facture compatible Chorus Pro, pas une intégration.

Qu'est-ce qui est explicitement exclu du périmètre ? Vérifié

  • Pas de comptabilité publique : Sallia ne tient pas la comptabilité M14/M57, ne produit aucune écriture comptable et ne remplace aucun logiciel de gestion financière communale.
  • Pas d'intégration Hélios : aucune transmission au système d'information de la DGFiP. Le rapprochement entre les encaissements et la comptabilité du poste comptable reste un acte du régisseur et du comptable public.
  • Pas de tenue de régie : délibération, nomination, cautionnement et contrôles restent des actes de la commune et de sa direction départementale des finances publiques.

Sallia produit en revanche les exports de titres de recettes attendus, dans le format utilisé par les collectivités.

9. Cadre d'achat et marchés publics

Sous quel régime une commune achète Sallia, et ce qu'elle peut légitimement exiger au contrat.

Quel régime de commande publique s'applique ? Vérifié

Un abonnement à un service numérique conclu par une commune relève du code de la commande publique en tant que marché public de services. Le seuil de dispense de procédure est fixé à 40 000 € HT (article R2122-8 du CCP) ; au-delà, et jusqu'au seuil européen, la commune est en procédure adaptée.

Un abonnement Sallia se situe très largement sous ce seuil. L'estimation doit toutefois se faire sur la durée totale du besoin, options comprises (article R2121-4) : c'est à la commune d'apprécier si elle raisonne en valeur annuelle ou pluriannuelle.

La commune peut-elle acheter sans mise en concurrence ? Vérifié

Oui, en dessous du seuil, l'article R2122-8 le permet, à condition de choisir une offre pertinente, de faire bonne utilisation des deniers publics et de ne pas contracter systématiquement avec le même prestataire lorsque plusieurs offres adaptées existent.

Recommandation, même sans obligation de publicité : formaliser un devis signé ou un bon de commande valant marché, pour la traçabilité attendue par le comptable public et le contrôle de légalité.

À qui appartient un développement spécifique ? Vérifié

Un développement demandé et financé nommément par une commune, en dehors du tronc commun, lui appartient : la cession de droits est formalisée par écrit, chaque droit cédé faisant l'objet d'une mention distincte quant à son étendue, sa destination, son lieu et sa durée (article L131-3 du code de la propriété intellectuelle).

Distinction maintenue en toutes circonstances : le socle mutualisé de Sallia reste la propriété de Wilder Labs, la commune en recevant une licence d'usage. Seul le développement spécifique lui est cédé.

Quelles pièces de candidature Wilder Labs peut-il fournir ? Partiel

Les informations légales de l'entreprise (numéros d'identification, code d'activité, immatriculation, régime de TVA) figurent aux mentions légales. Les formulaires de candidature usuels et les attestations délivrées par les organismes tiers sont établis à la demande pour chaque consultation : il n'existe pas de dossier de candidature pré-constitué.

Pour toute réponse à une procédure formalisée, une relecture du contrat-cadre par un conseil en droit de la commande publique est recommandée, notamment sur la rédaction des clauses de réversibilité et de propriété intellectuelle.

10. Accessibilité numérique

L'obligation pèse sur la commune ; la conformité du logiciel la conditionne.

Quel référentiel s'applique, et à qui ? Vérifié

NiveauRéférencePortée
Obligation légaleLoi n° 2005-102 du 11 février 2005, art. 47, modifié par la loi n° 2018-771Accessibilité des services en ligne des personnes publiques
ApplicationDécret n° 2019-768 du 24 juillet 2019Impose trois livrables : schéma pluriannuel, plan d'action annuel, déclaration
Référentiel techniqueRGAA 4.1106 critères — le référentiel opposable en France
EuropéenEN 301 549 (directive UE 2016/2102)Présomption de conformité au niveau européen ; le RGAA en est la déclinaison française
Commande publiqueCCP art. R2111-6Les spécifications d'un achat destiné à des personnes physiques doivent intégrer l'accessibilité

L'obligation de l'article 47 pèse sur la commune, pas sur l'éditeur privé. En pratique, cela ne dispense de rien : le portail est le service en ligne de la commune, donc la conformité de Sallia conditionne la sienne — et l'amende administrative prévue par le décret frappe la commune, pas l'éditeur. C'est exactement ce qu'un acheteur public cherche à sécuriser au contrat.

Quel est le niveau réellement atteint ? Limite assumée

Une déclaration d'accessibilité est publiée et déclare l'état « partiellement conforme » au RGAA 4.1 — l'état le plus prudent des trois possibles. Un référent accessibilité est nommé, joignable à une adresse dédiée, avec un engagement de réponse sous cinq jours ouvrés et les voies de recours vers le Défenseur des droits au complet. La rubrique des contenus non accessibles est spécifique et non cosmétique : elle assume nommément l'absence de tests avec lecteurs d'écran et l'audit non réalisé des composants dynamiques complexes.

Ce niveau est déclaratif. Il n'a jamais été mesuré par un audit externe. Sallia ne dispose d'aucune attestation d'accessibilité opposable. La conformité RGAA ne se certifie pas au sens d'une accréditation, mais un audit par un prestataire tiers indépendant, produisant la grille des 106 critères et un taux chiffré, est le seul élément qui transformerait la déclaration actuelle en engagement défendable. Tant qu'il n'a pas eu lieu, tout niveau annoncé reste une déclaration sur l'honneur.

Trois réserves complémentaires : la déclaration ne porte pas encore de taux de conformité chiffré ; l'environnement de test attendu par la méthodologie RGAA (couple lecteur d'écran + navigateur) n'a pas été utilisé ; et les contrôles automatisés ne couvrent aujourd'hui que des pages publiques, pas les écrans authentifiés que les agents utilisent quotidiennement.

Le schéma pluriannuel de mise en accessibilité existe-t-il ? Limite assumée

Non, et il est régulièrement confondu avec la déclaration. Le décret impose trois documents distincts : un schéma pluriannuel de trois ans maximum, publié en ligne ; un plan d'action annuel ; et la déclaration d'accessibilité. Seule la dernière existe aujourd'hui, et le plan d'action n'est ni annuel ni détaché.

Ce schéma relève de la commune en tant qu'entité assujettie : Wilder Labs ne peut pas le signer à sa place. Nous pouvons en revanche en fournir la trame et la partie technique, en livrable d'accompagnement à la mise en service.

Écart de périmètre à connaître La déclaration publiée est aujourd'hui rédigée au nom de l'éditeur et sur le périmètre du site sallia.fr. Or l'entité assujettie est la commune, et son service en ligne réel est son propre portail. Une commune qui s'appuierait telle quelle sur cette page ne remplirait pas son obligation. La déclinaison de la déclaration au nom de chaque commune et sur son périmètre est un livrable identifié.

11. API, interopérabilité et équipe

Ce qu'une commune peut brancher sur Sallia, ce qui n'existe pas, et qui écrit le code.

Sallia expose-t-il une API ? Partiel

Oui, deux surfaces distinctes.

Une API versionnée authentifiée par clé, avec trois opérations : lister les salles actives, connaître les créneaux occupés d'une salle sur une période, déposer une demande de réservation. La clé n'est jamais stockée en clair (seule son empreinte l'est) et le secret n'est affiché qu'une fois à sa création. Chaque clé porte un périmètre de droits, une limite de débit propre, une date d'expiration facultative et une date de révocation, et elle est rattachée à une seule commune. Une demande déposée par ce canal arrive au statut « en attente », marquée comme telle : aucune réservation n'est confirmée sans l'accord d'un agent.

Des points d'accès publics sans authentification, prévus pour être appelés depuis le site de la commune : calendrier d'occupation du mois, grille tarifaire d'une salle, catalogue de matériel prêtable, dépôt d'une demande. Ils ne servent que des informations déjà publiques et respectent le réglage de discrétion de chaque événement : une réservation marquée « invisible » n'apparaît nulle part, une réservation « masquée » apparaît comme occupée sans le nom du locataire.

Limite actuelle L'API est fonctionnelle mais aucune commune ne l'utilise à ce jour. C'est un outil disponible, pas un usage éprouvé sur plusieurs intégrations. Sur un projet d'intégration réel, prévoir un accompagnement plutôt qu'une simple remise de documentation.

Existe-t-il une documentation exploitable par un prestataire tiers ? Partiel

Une description machine au format OpenAPI 3.1 est servie par le service lui-même, générée à partir du code — elle ne peut donc pas décrire une opération qui n'existe plus. Un prestataire peut l'importer dans les outils du marché et disposer immédiatement des schémas de données, des codes d'erreur et du mode d'authentification. Une page de documentation lisible décrit par ailleurs les points d'accès publics avec des exemples.

Réserve : l'explorateur interactif embarqué charge sa bibliothèque d'affichage depuis un service tiers, ce que notre propre politique de sécurité interdit — la page se charge donc mais reste vide. C'est un défaut connu, sans conséquence de sécurité ; la description OpenAPI et la page de documentation, elles, fonctionnent.

Le planning est-il exportable vers Outlook ou Google Agenda ? Vérifié

Oui, par abonnement au format iCalendar : la commune récupère depuis son tableau de bord une adresse d'abonnement personnelle à coller dans son agenda, qui se met à jour tout seul. Le flux couvre les réservations des 90 derniers jours et des deux prochaines années, avec la salle, son adresse, le type d'occupation et les horaires.

  • L'adresse est protégée par un jeton comparé en temps constant ; sans lui, le flux refuse l'accès. Si le mécanisme de signature n'est pas configuré, la fonction se coupe proprement plutôt que de servir un calendrier non protégé.
  • La discrétion est respectée jusque dans l'export : une réservation « invisible » n'est pas exportée, une réservation « masquée » apparaît en « salle louée » sans nom ni notes. Un agent qui partage son agenda ne divulgue donc pas l'identité des locataires.
  • Le changement d'heure est géré sur le fuseau Europe/Paris.
Limite à connaître Le jeton d'abonnement est dérivé d'un secret commun au service. Il n'existe pas encore de fonction permettant de renouveler le seul jeton d'une commune : révoquer un partage demande aujourd'hui une intervention de notre part.

Peut-on intégrer le calendrier dans le site de la commune ? Partiel

Oui, par un widget en cadre intégré : une ligne de code à coller dans n'importe quelle page, quel que soit l'outil du site municipal. Il affiche le calendrier de disponibilité, les tarifs et le bouton de demande. C'est la voie recommandée, la plus robuste.

Une extension pour l'outil de gestion de contenu le plus répandu existe également, mais elle n'est pas publiée sur l'annuaire officiel de cet outil et n'a pas été reprise depuis le changement de nom du produit : sa notice porte encore l'ancien nom. Elle fonctionne, mais nous ne la présentons pas comme un produit fini — le widget reste le choix sûr.

Sallia peut-il notifier un système tiers en temps réel ? Limite assumée

Non : il n'existe aucun mécanisme de notification sortante configurable. Une commune ne peut pas déclarer une adresse à laquelle Sallia enverrait un message à chaque demande reçue, approuvée ou annulée.

Les deux contournements réellement disponibles : interroger périodiquement l'API en lecture, ou s'abonner au flux iCalendar que la plupart des agendas rafraîchissent seuls. Une véritable notification sortante est réalisable et n'est pas un chantier lourd, mais elle n'est pas développée : elle relèverait d'un développement spécifique chiffré, pas d'une fonction du produit.

Quelle est la taille de l'équipe ? Partiel

Une personne. Wilder Labs est une micro-entreprise, et la quasi-totalité du code de Sallia est écrite par son fondateur.

Ce que cela apporte : pas de dilution de la connaissance du produit, un interlocuteur unique, et un délai de correction très court — un correctif signalé le matin peut être en production l'après-midi.

Ce que cela impose de compenser, c'est le risque de dépendance à une personne. Les mesures qui y répondent sont techniques et vérifiables : code intégralement versionné sur une forge maîtrisée, données exportables par la commune, sauvegardes chiffrées et externalisées, chaîne de mise en production entièrement automatisée et documentée (§5), donc reprenable par un tiers compétent. Un dépôt du code sous séquestre peut être inscrit au contrat si la commune le souhaite.

12. Réversibilité et fin de contrat

Le contrat publié décrit une chaîne de réversibilité que le produit n'outille aujourd'hui qu'en partie.

La réversibilité est-elle inscrite au contrat ? Vérifié

Oui, et l'engagement est écrit, public et opposable. Les conditions particulières de service prévoient, à l'article consacré à la réversibilité (article 28.3.h du RGPD) : un export complet des données, une archive des fichiers, une documentation de structure, le tout sous 30 jours et sans frais ; une destruction sécurisée passé 90 jours ; un certificat de destruction sur demande. L'article sur la durée prévoit une résiliation par la commune sous préavis de 30 jours, et un préavis de 6 mois si l'éditeur résilie, pendant lequel il accompagne la migration.

L'existence de la clause n'est pas en cause. Ce qui l'est, c'est qu'elle engage aujourd'hui plus que ce que le logiciel sait faire seul.

La commune peut-elle récupérer ses données seule ? Partiel

En partie. Depuis son espace d'administration, sans nous solliciter, elle télécharge : les titres de recettes (y compris au format attendu par la DGFiP), les paiements de l'année, les événements de l'année, et les emprunts de clés. Ce sont de vrais exports en libre-service, à l'échelle de la commune.

Mais ils couvrent quatre domaines métier, alors que l'espace d'une commune en compte bien davantage. Il n'existe pas encore de fonction « tout exporter » : la récupération complète repose aujourd'hui sur une opération manuelle de notre part, réalisable dans le délai contractuel de 30 jours.

Sous quels formats, et les photos sont-elles incluses ? Limite assumée

  • Export complet de la base : techniquement disponible et fidèle — il restitue les tables, les relations et les contraintes, donc la chaîne réservation → locataire → état des lieux → photos est reconstituable dans une base tierce. Il est produit par une opération manuelle, pas encore livrable en libre-service.
  • Exports thématiques : disponibles en libre-service, mais aplatis pour être lisibles dans un tableur ; ils ne permettent pas de recoller fiablement un fichier à l'autre.
  • Archive des fichiers binaires (photos pleine résolution, conventions signées) : elle n'existe pas. Les originaux sont bien conservés, en pleine résolution et sans recompression — rien n'est dégradé — mais aucun export ne les emballe aujourd'hui. Un export de base livré seul contiendrait donc des références de fichiers sans les fichiers.
  • Documentation de structure : promise au contrat, elle n'est pas générée à ce jour.

Aujourd'hui : l'export de la base est fournissable sous 30 jours ; l'archive des fichiers et la documentation de structure ne le sont pas encore. Les chantiers correspondants sont identifiés et chiffrés.

L'export de fin de contrat est-il facturé ? Vérifié

Non. Le contrat prévoit « sous 30 jours et sans frais » et aucune indemnité de résiliation. Aucun mécanisme de facturation d'un export n'existe, ni dans le produit ni dans la grille tarifaire.

Que devient l'espace après la résiliation ? Limite assumée

Le contrat décrit une fenêtre de trois mois : 30 jours de préavis, 30 jours pour livrer l'export, 90 jours avant destruction. Cette chaîne n'est pas encore outillée dans Sallia. Il n'existe pas d'état intermédiaire « résilié, consultable en lecture seule », pas de compte à rebours automatique, pas d'échéance de destruction déclenchée par une horloge : la suppression est aujourd'hui une opération d'administration déclenchée par un humain.

Cette opération est en elle-même correctement construite : elle produit une sauvegarde complète avant toute suppression et s'interrompt plutôt que de supprimer si cette sauvegarde n'est pas valide. Mais deux réserves sérieuses subsistent, dont l'une contredit l'engagement de destruction : les fichiers ne sont pas encore effacés par cette séquence, et les sauvegardes produites au moment de la suppression ne sont pas encore purgées automatiquement. La destruction n'est donc, à ce jour, ni datée ni complète.

Aucun certificat de destruction n'est par ailleurs généré automatiquement : le contrat prévoit qu'il soit remis sur demande, et il pourrait être rédigé, mais rien dans le système ne permet encore de l'étayer par des volumes et un horodatage.

Limite actuelle Cette chaîne existe déjà, complète et en service, sur une autre application de notre catalogue : cycle de vie de résiliation, mode lecture seule laissant passer les consultations et les exports, envoi de l'export final avec relance, puis suppression seulement après confirmation. Son portage vers Sallia est un travail de transposition, pas de conception. Tant qu'il n'est pas livré, la clause est honorée manuellement.

13. Prix, niveau de service et support

La grille publique, ce qui est verrouillé au contrat, et ce qui relève d'une pratique commerciale qu'il ne faut pas confondre avec un engagement.

Quelle est la grille tarifaire ? Vérifié

OffrePérimètrePrix mensuelEngagement
Gratuit1 salle, usage découverte0 €Sans engagement
Standard1 salle, fonctionnalités complètes9 €Sans engagement
Multi-sallesJusqu'à 5 salles, multi-équipements29 €Sans engagement
Sur-mesureAu-delà de 5 salles, intercommunalité, besoins spécifiquesSur devisSelon contrat

Prix nets : TVA non applicable, article 293 B du CGI (franchise en base). Il s'agit d'un fait de statut fiscal, pas d'une option commerciale : aucune TVA n'est facturée et le montant payé est le montant net. Si le seuil de franchise venait à être dépassé, le régime en vigueur à la date de facturation s'appliquerait, et le changement serait communiqué à l'avance.

Le paiement par mandat administratif est possible : la facture est émise avec les mentions attendues par une collectivité, puis déposée par la commune sur son portail de facturation ou transmise à son service de mandatement (voir §8 sur l'absence de dépôt automatisé).

Quel est l'engagement de disponibilité ? Partiel

Le contrat engage une disponibilité mensuelle visée de 99 %, hors maintenances programmées annoncées sept jours à l'avance. En cas de non-respect sur un mois calendaire, la commune peut demander un avoir au prorata sur la facture du mois suivant.

Deux nuances à ne pas confondre D'une part, ce chiffre est aujourd'hui déclaratif : il n'est pas mesuré par un outil de supervision indépendant et publié. Il n'existe pas encore de page de statut consultable par la commune, ni d'historique chiffré de disponibilité que nous pourrions produire. D'autre part, le mécanisme d'avoir est réel mais limité : c'est un avoir et non une pénalité, il se déclenche sur demande de la commune et non automatiquement, et le contrat ne fixe pas de barème. C'est une clause de bonne foi, pas une grille chiffrée.

Quels délais d'intervention sur incident ? Partiel

NiveauEngagement contractuel
Incident critique4 heures ouvrées (lundi-vendredi, 9h-18h)
Incident majeur1 jour ouvré

Nuance systématique : c'est un délai de prise en charge (début du diagnostic), pas un délai de résolution garanti. Aucun éditeur ne peut engager un délai de résolution ferme, puisque la cause d'un incident n'est pas connue à l'avance. Nous ne disposons pas encore d'un historique horodaté des prises en charge réellement constatées : nous ne communiquons donc aucun délai moyen observé.

Comment le support est-il assuré ? Limite assumée

Par l'éditeur lui-même, par courriel à contact@sallia.fr et, en cas d'urgence, par échange direct. Il n'y a pas de standard téléphonique, pas de portail de tickets public, pas d'astreinte formalisée hors horaires ouvrés, et pas d'équipe de support multi-personnes.

Ce qui est contractuel, ce sont les délais de prise en charge ci-dessus. Si une commune fait du support un point d'instruction, une clause d'astreinte élargie ou un contact de secours peut être négociée en option.

Quelles garanties sur les sauvegardes ? Partiel

Le contrat engage des sauvegardes quotidiennes, conservées 30 jours, restaurables sous 24 heures, avec un archivage chiffré. Les sauvegardes sont produites automatiquement chaque nuit, avec rotation et contrôle d'intégrité, et externalisées hors du serveur de production.

Limite assumée « Restaurables sous 24 heures » est un engagement de moyens écrit, mais aucun exercice de restauration périodique documenté n'existe à ce jour pour Sallia. Nous ne pouvons donc pas produire le compte rendu d'un test de restauration récent et réussi. La mise en place d'exercices réguliers et documentés est identifiée ; elle est déjà en place sur une autre application de notre catalogue.

14. Audits internes : résultats et vulnérabilités traitées

Nous publions les chiffres de nos audits internes et les familles de défauts trouvés — sans nom de fichier, sans adresse d'accès, sans donnée qui aiderait quelqu'un à les exploiter.

Que dit le dernier audit intégral ? Vérifié

Audit interne multi-domaines mené le 28 mai 2026 sur l'intégralité du code source : sécurité applicative, performance et base de données, accessibilité et parcours utilisateur, qualité d'architecture. 53 constats agrégés, traités par ordre de criticité.

5
critiques
17
élevés
21
moyens
10
mineurs
DomaineConstatsTraitementReste à faire
Sécurité applicative15Tous les constats critiques, élevés et moyens traités : contrôle du contenu réel des fichiers déposés, durcissement du cookie de session, limitation des tentatives de connexion persistée en base, politique de sécurité de contenu passée aux valeurs uniques par réponseSurveillance continue
Performance et base de données11Requêtes en escalier supprimées, index et pagination ajoutés, écritures rendues idempotentes, journal d'activité indexéPartitionnement du journal si le volume l'impose
Interface, parcours et accessibilité15Calendrier de réservation utilisable au clavier, menu et fenêtres modales corrigés, contrastes repris, liens d'évitement ajoutésAudit RGAA par un tiers (voir §10)
Architecture et qualité de code12Étapes critiques rendues transactionnelles, code mort retiré, traitement des erreurs resserréDécoupage des routes, tests unitaires

Les 5 constats critiques ont été corrigés et déployés sous 24 heures, les 17 constats élevés dans la foulée. Aucun constat ne portait sur une fuite de données réelle : aucun accès non autorisé à des données de commune n'a été mis en évidence.

Quelles familles de vulnérabilités ont été trouvées ? Vérifié

  • Insertion de contenu non échappé dans des courriels sortants (critique) — corrigé. Des valeurs saisies par un usager étaient reprises dans un courriel sans échappement systématique ; l'échappement est désormais appliqué à toutes les valeurs.
  • Requêtes en escalier sur l'état des lieux (critique) — corrigé. Le chargement d'un état des lieux complet pouvait déclencher plusieurs centaines d'allers-retours vers la base ; réécrit en jointures.
  • Calendrier de réservation inutilisable au clavier (critique) — corrigé. Les cellules cliquables sont devenues de vrais boutons, atteignables au clavier (RGAA 4.1.2 et 13.7).
  • Détail d'erreur technique renvoyé à l'appelant (élevé) — corrigé. Les réponses en erreur renvoyaient parfois le message brut du moteur de base de données ; des messages génériques sont désormais servis.
  • Robustesse du cookie de session (élevé) — corrigé. Politique d'envoi du cookie resserrée pour qu'il ne parte jamais depuis un autre site.
  • Fichiers déposés vérifiés sur leur seul type déclaré (élevé) — corrigé. Le contenu réel du fichier est désormais contrôlé, pas la seule mention fournie par le navigateur.
  • Limitation des tentatives de connexion conservée en mémoire (élevé) — corrigé. Le compteur est persisté en base : il résiste au redémarrage et au fonctionnement sur plusieurs instances.
  • Index manquants sur des clés chaudes (élevé) — corrigé.
  • Étape d'approbation non transactionnelle (élevé) — corrigé. L'approbation d'une demande est devenue une opération unique, sans état intermédiaire incohérent possible.
  • Défauts d'accessibilité fine (élevé à moyen) — corrigés pour l'essentiel ; le reste dépend de l'audit externe décrit au §10.

Ces constats sont ceux d'audits internes. Ils ne remplacent pas un test d'intrusion par un tiers indépendant, qui n'a pas été réalisé (voir §5).

Quel est l'historique des audits ? Vérifié

  • 13 mai 2026 — audit accessibilité mobile et revue de sécurité du module d'état des lieux.
  • 23 mai 2026 — audit interne d'isolation entre communes et purge des espaces de démonstration.
  • 28 mai 2026 — audit intégral (chiffres ci-dessus).
  • 3 septembre 2026 — revue contradictoire interne.
  • À venir — audit d'accessibilité RGAA par un prestataire tiers ; d'ici là, la déclaration reste « partiellement conforme ».

Chaque nouvel audit est publié ici dès qu'il est terminé. Une commune cliente peut obtenir le détail technique des rapports sur demande à contact@sallia.fr, sous accord de confidentialité.

15. Signalement d'une vulnérabilité

Si vous trouvez une faille, nous voulons le savoir — et nous nous engageons sur la façon dont nous y répondons.

Comment signaler, et que se passe-t-il ensuite ? Vérifié

  • Écrire à security@wilderlabs.fr (échange chiffré possible sur demande).
  • Coordonnées également publiées au format normalisé RFC 9116 : /.well-known/security.txt.
  • Nous accusons réception sous 48 heures ouvrées et tenons l'auteur du signalement informé jusqu'au correctif.
  • Cadre de divulgation responsable : aucune poursuite ne sera engagée contre une recherche de bonne foi — test sans impact sur des données réelles, signalement avant publication, délai de correction raisonnable laissé à l'éditeur.

La chaîne de livraison décrite au §5 permet de porter un correctif en production en moins d'une heure ; le délai de traitement dépend donc de l'analyse, pas de la mise en ligne.

Une question que ce document ne couvre pas ?

Écrivez à contact@sallia.fr pour toute question d'instruction ou de contractualisation, ou à dpo@sallia.fr pour la protection des données et la convention de sous-traitance. Nous répondons par écrit, et ce document est mis à jour lorsqu'une réponse fait évoluer un point.