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 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.
• Moindre privilège, partout : humains, services et équipements ne disposent que de ce que leur rôle impose.
• Hébergement maîtrisé : données et opérations de production hébergées en Suisse ou dans l'Union européenne, dans des juridictions dont le niveau de protection des données est reconnu équivalent (nLPD, RGPD).

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. 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 et documents déposé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 transitent la voix et l'image de chaque appel d'interphone, l'image prise par la platine, les relevés de compteurs et les journaux techniques

Site web, formulaires, et conservation des contrats partenaires

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

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

Certifiés ISO 27001 selon les déclarations publiques de leurs exploitants. 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 ; É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

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

• Pas d'attaque sur des données réelles. Nous ne mettons pas encore de jeu de comptes de démonstration à disposition : écrivez-nous avant tout essai qui dépasse la simple consultation, et nous conviendrons ensemble d'un périmètre.
• Pas de déni de service, pas d'ingénierie sociale visant nos collaborateurs ou partenaires.
• Pas de divulgation publique avant correctif ou avant 90 jours, sauf exposition active.