Charte sécurité.

01Principes directeurs

Neolia opère une infrastructure qui touche à des éléments sensibles du logement : qui ouvre la porte, qui sonne à l'interphone, comment l'énergie est consommée. Nous traitons la sécurité comme une caractéristique du produit, pas comme une couche de conformité ajoutée après coup. Quatre principes guident nos décisions :

• Vérifié plutôt qu'annoncé : chaque mesure décrite ici correspond à un contrôle que nous pouvons rejouer sur nos serveurs et dont nous pouvons montrer le résultat. Nous n'annonçons pas de dispositif que nous ne serions pas en mesure de démontrer.
• Surface minimale : rien n'est joignable depuis internet qui n'a pas besoin de l'être. Bases de données, caches et interfaces d'administration refusent toute connexion venue de l'extérieur : en production, elles ne répondent que sur le réseau privé qui relie nos trois machines ; en développement et en préproduction, où il n'y a pas de réseau privé, c'est le pare-feu de chaque machine qui les ferme. Le contrôle se rejoue en ouvrant une connexion depuis n'importe où : elle est refusée.
• Moindre privilège, partout : humains, services et équipements ne disposent que de ce que leur rôle impose.
• Hébergement maîtrisé : la base de données est en Suisse, les serveurs d'exploitation sont en Allemagne, dans l'Union européenne, avec une copie de sauvegarde chiffrée de la base suisse. Ces deux juridictions offrent un niveau de protection reconnu équivalent (nLPD, RGPD). Nous préférons le dire complètement : certains prestataires sont établis aux États‑Unis, pour l'envoi des courriels, les notifications sur votre téléphone, les encaissements et la lecture assistée des documents déposés. Ils sont nommés un par un à l'annexe 2 du contrat de traitement.

Ce document couvre l'infrastructure d'exploitation, les applications mobiles et le cycle de déploiement. Il ne remplace pas une revue de sécurité par un tiers, que nous n'avons pas encore fait réaliser. Aucun test d'intrusion externe, aucun audit de certification et aucun programme de récompense n'a eu lieu à ce jour : le premier que nous ferons réaliser sera annoncé ici, avec sa date.

02Hébergement et localisation

La base de données est hébergée en Suisse, dans la région de Zurich. Les serveurs d'exploitation sont en Allemagne, dans l'Union européenne. Une copie de sauvegarde chiffrée de la base de données suisse y est faite chaque nuit et gardée 14 jours. Les données applicatives et l'infrastructure reposent donc sur deux fournisseurs distincts, et chaque environnement dispose de ses propres machines. Nous préférons le dire complètement : ces cinq machines sont dans le même centre de données, à Nuremberg. Elles protègent d'une panne de machine, pas d'une panne de bâtiment.

Base de données, authentification, documents déposés et contrats partenaires signés

Supabase, région de Zurich (Suisse)

Serveurs d'exploitation (production, développement et test)

Hetzner Online GmbH, centre de Nuremberg, Allemagne (Union européenne). Y sont traités l'acheminement des appels d'interphone et leur voix et image (non enregistrées), les comptes téléphoniques des logements, l'image prise par la platine, les relevés des compteurs et le réseau radio des compteurs, les jetons qui permettent d'envoyer les notifications aux téléphones, les comptes et photos des installateurs, les journaux techniques, et une copie de sauvegarde chiffrée de la base de données suisse, faite chaque nuit et gardée 14 jours

Site web, formulaires et suivi commercial

Cloudflare (réseau de diffusion mondial, points de présence européens). Le suivi commercial et les pièces jointes de la messagerie partenaire y sont conservés, dans un magasin dont la région n'est pas fixée. Les contrats partenaires signés sont conservés à Zurich depuis le 24 septembre 2026

Lecture assistée, assistant de la plateforme et relecture des dictées

Anthropic, États-Unis. Un bail, une facture, un relevé bancaire, la photo d'un compteur ou un message échangé dans la plateforme y est envoyé pour être lu. L'assistant de la barre de recherche y envoie la question posée, un résumé chiffré du parc de la régie et les résultats de la recherche. La relecture d'une dictée y envoie le texte transcrit et la liste des noms d'immeubles, de rues, de localités et d'artisans de la régie, jamais la voix. Les transferts sont couverts par l'accord de traitement des données d'Anthropic, intégré à ses conditions commerciales, et par les clauses contractuelles types adaptées au droit suisse

Prise de rendez-vous en ligne

Cal.com, instance européenne cal.eu, données conservées dans l'Union européenne. L'éditeur ferme cette instance le 1^er novembre 2026 ; la solution retenue ensuite sera indiquée ici avant cette date

Datacentres

Un certificat sur trois est à notre dossier, et nous préférons dire lequel. Celui de Hetzner, l'hébergeur de nos serveurs d'exploitation, est en notre possession : ISO/IEC 27001:2022, n^o ZN‑2025‑35, délivré par SOCOTEC Certification Deutschland, valable jusqu'au 26 septembre 2028, et nos cinq machines sont rattachées par une mesure au site qu'il couvre, Nuremberg. Supabase et Cloudflare déclarent publiquement la même certification, mais ils ne remettent leurs attestations qu'à leurs formules d'entreprise : nous ne les détenons donc pas, et nous ne les présentons pas comme acquises. Ce n'est pas une question de délai, c'est une question d'abonnement. Dans tous les cas, cette certification est celle de l'exploitant du centre de données, jamais celle de Neolia : Neolia n'est certifiée par aucun référentiel

Localisation des données identifiantes

Suisse pour la base de données ; Allemagne pour l'exploitation technique et pour la copie de sauvegarde chiffrée de la base de données ; États-Unis pour les prestataires listés à l'annexe 2 du contrat de traitement, envoi des courriels, notifications et analyse assistée des documents compris

En dehors du calendrier de prise de rendez-vous affiché sur /demo, dans son propre cadre, le site que vous lisez ne charge aucune ressource d'un tiers : ni police d'écriture, ni bibliothèque d'animation, ni mesure d'audience. Tout est servi par le domaine de la page, de sorte que votre adresse IP n'est communiquée à personne d'autre que l'hébergeur du site.

03Chiffrement

Nous ne chiffrons pas le disque de nos serveurs d'exploitation. Un chiffrement de disque protège d'un vol de machine dans le centre de données, pas d'un accès obtenu par le réseau ; nous préférons l'écrire plutôt que de laisser croire le contraire.

04Accès aux serveurs

Les contrôles ci-dessous sont appliqués sur l'ensemble de nos serveurs et revérifiés automatiquement chaque heure.

• Connexion par clé uniquement : l'authentification par mot de passe est désactivée, le compte administrateur du système ne peut pas se connecter à distance, et les mots de passe vides sont refusés.
• Trois tentatives d'authentification au maximum, puis blocage automatique des adresses qui insistent.
• Deux pare-feux indépendants, l'un chez l'hébergeur et l'autre sur chaque serveur, fermés par défaut : chaque machine n'expose que ce que son rôle impose.
• Bases de données, caches et interfaces d'administration hors d'atteinte depuis internet, joignables uniquement par le réseau privé.
• Revue des clés autorisées : chaque clé présente correspond à une personne ou à un composant identifié, et l'apparition d'une clé inconnue déclenche une alerte.
• Aucun secret dans un fichier lisible par tous ni dans une ligne de commande, où il serait visible de n'importe quel utilisateur de la machine.
• Journal d'audit tenu hors de la base qui le produit, pour qu'un accès à cette base ne permette pas d'effacer la trace de ce qui y a été fait.

Côté Client et résident

• Profils distincts selon le rôle, chaque compte ne voyant que les immeubles qui le concernent.
• Les identifiants d'appel et le jeton de session sont conservés dans le coffre chiffré du téléphone et exclus des sauvegardes vers le nuage, de sorte qu'une sauvegarde restaurée sur un autre appareil ne donne pas accès à l'interphone.

05Surveillance et réaction automatique

Nos serveurs sont surveillés en continu par quatre boucles indépendantes, qui réparent seules ce qu'elles savent réparer et alertent pour le reste.

Deux garde-fous encadrent ces réparations automatiques. Elles sont limitées à trois tentatives par problème et par jour, après quoi la machine est gelée et une alerte part vers un humain, avec rappel quotidien tant que le problème dure. Et tout ce qui touche à l'accès distant, réactivation d'une connexion par mot de passe ou apparition d'un nouveau port public, n'est jamais corrigé automatiquement mais signalé : une correction ratée sur l'accès distant transformerait la réparation en panne.

06Développement et déploiement

• Infrastructure décrite en code et versionnée : pare-feux, configuration des serveurs et déploiements sont des fichiers relus et historisés, pas des gestes manuels.
• Déploiement vérifié des configurations sensibles : contrôle de validité avant application, sauvegarde de l'état précédent, test de bon fonctionnement après redémarrage et retour arrière automatique si le test échoue.
• Mise en service par paliers : une modification passe par l'environnement de test avant la production, et la production refuse une mise en service qui n'a pas déjà tourné en test.
• Aucune donnée de production copiée sur un poste de travail, et aucun secret dans le dépôt de code.

07Sauvegardes et mises à jour

• Sauvegardes quotidiennes de la base de données et des serveurs d'exploitation, avec rotation, chiffrées avant de quitter la machine qui les produit. Il n'existe pas de réplication entre deux régions de Suisse, et nous ne publions pas d'objectif chiffré de reprise ni de perte de données maximale tant qu'un exercice de restauration ne l'a pas éprouvé.
• Correctifs de sécurité appliqués automatiquement sur l'ensemble des serveurs.
• Redémarrages maîtrisés : après une mise à jour qui l'exige, les serveurs redémarrent un par un, jamais ensemble, et l'opération est reportée tant qu'un appel d'interphone est en cours.

08Gestion d'incident

Notre traitement d'un incident suit toujours le même ordre : détecter, contenir, corriger, rétablir, comprendre. Chaque incident donne lieu à une analyse écrite, et à un résumé communiqué aux personnes touchées lorsque l'impact dépasse un cas isolé.

Notification

• Clients (régies) : notification dès la confirmation de l'incident, par courriel du compte technique.
• Personnes concernées : si la violation présente un risque élevé, notification individuelle avec recommandations pratiques.
• PFPDT / autorités : notification dans les délais de l'art. 24 nLPD et de l'art. 33 RGPD.

09Divulgation responsable

Si vous avez identifié une vulnérabilité dans nos services, nous vous remercions de nous la signaler de manière coordonnée.

Règles du jeu

• Comptes de test : sur demande à contact@neolia.ch, nous ouvrons un espace de test sur notre environnement de préproduction, staging.manager.neolia.ch. Il comprend une régie fictive, deux comptes (une direction et un collaborateur limité à un immeuble) et deux immeubles fictifs, sans aucune donnée de client. Les comptes se ferment d'eux-mêmes après 30 jours. Travaillez avec ces comptes plutôt qu'en production.
• Sur la même demande, nous ouvrons aussi, sur la préproduction, une entreprise d'installation fictive sur Neolia Pro et deux logements fictifs dont les identifiants ouvrent le portail web des habitants. Ces comptes se ferment d'eux-mêmes après 30 jours.
• Pas d'attaque sur des données réelles : n'utilisez aucun compte de résident, de régie ou d'installateur qui ne soit pas le vôtre, et arrêtez-vous dès que la vulnérabilité est démontrée.
• Pas de DoS, pas d'ingénierie sociale visant nos collaborateurs ou partenaires.
• Pas de divulgation publique avant correctif ou avant 90 jours, sauf exposition active.