Sécurisé par défaut.
Configurable selon votre niveau de risque.

Non. L'étape qui rend vos documents consultables — transformer le texte en « embeddings » (vecteurs) — est celle que les concurrents externalisent généralement vers une API d'IA tierce, ce qui fait sortir le contenu de vos fichiers de leurs murs. ReefOffice exécute ce modèle localement : bge-m3 (un modèle ouvert multilingue, sous licence MIT) dans Ollama sur votre propre VM. Les vecteurs et le texte sont stockés dans Qdrant, également sur votre VM. L'indexation et la recherche dans votre corpus ne déclenchent donc jamais d'appel sortant vers une IA — le contenu de vos documents reste sur votre serveur. Sur les offres Private AI, la réponse est générée par un modèle ouvert (Qwen par défaut, ou un modèle européen comme Mistral) sur un GPU ReefOffice dans un datacenter certifié ISO 27001 en Allemagne, sous accord de traitement des données — seuls votre question et les extraits correspondants y sont envoyés, rien n'y est stocké, et aucune IA tierce n'intervient jamais. Le seul cas où quelque chose sort, c'est si vous connectez délibérément votre propre clé IA externe sur une offre sans GPU pour des réponses rédigées — et même alors, seuls votre question et les quelques extraits correspondants sont envoyés, jamais l'intégralité du corpus.

Les automatisations prédéfinies (indexation des documents, relance de factures, classement de contrats, configuration d'affaire gagnée, …) s'exécutent dans un moteur d'automatisation réservé à l'opérateur que ReefOffice gère — pas dans Activepieces, l'éditeur no-code utilisé par votre équipe. Les identifiants dont elles ont besoin (vos comptes admin Nextcloud / Dolibarr / Paperless, le relais mail) sont stockés chiffrés et lus uniquement par le job en cours via des identifiants d'exécution limités à ce job ; ils ne sont jamais inscrits dans une définition de flux qu'un utilisateur peut ouvrir. Quand l'agent IA privé déclenche une automatisation approuvée, il appelle un shim local sur liste blanche qui injecte les identifiants côté serveur, donc l'agent ne reçoit jamais d'identifiants généraux du moteur d'automatisation. Votre bac à sable Activepieces ne contient aucun identifiant d'opérateur, et l'accès au moteur est réservé à l'opérateur à chaque déploiement, de sorte qu'un compte obsolète ne peut pas conserver d'accès. Cela élimine la catégorie de risque où une automatisation intégrée devient un moyen d'extraire un mot de passe administrateur.

Exact, et c'est voulu — LUKS est l'outil adapté aux menaces sur les données au repos (disques physiques, mise au rebut et instantanés qui n'incluent pas les éléments de déverrouillage du démarrage). Pour un serveur en fonctionnement, nous appliquons une couche de contrôles distincte intégrée à chaque build NixOS : ptrace est restreint (scope=3) pour empêcher l'inspection des processus, kexec est désactivé afin que le noyau ne puisse pas être remplacé à l'exécution, l'eBPF non privilégié est bloqué, les pointeurs du noyau sont masqués (kptr_restrict=2), userfaultfd non privilégié est désactivé, la création io_uring non privilégiée est restreinte, et les coredumps sont supprimés. La désactivation complète d'io_uring reste disponible pour des déploiements durcis spécifiques, mais le réglage par défaut conserve la compatibilité avec l'infrastructure privilégiée. L'immuabilité de NixOS signifie qu'aucun gestionnaire de paquets ne peut installer silencieusement des binaires inattendus. Une analyse quotidienne des CVE (vulnix) détecte les paquets vulnérables et rapporte les résultats dans le tableau de bord.

Oui — chaque serveur exécute une analyse CVE quotidienne avec vulnix, un outil natif NixOS. Comme NixOS épingle les versions exactes des paquets sous forme de hachages cryptographiques (builds reproductibles), vulnix peut recouper chaque paquet installé avec la National Vulnerability Database en quelques secondes. Les résultats apparaissent dans l'onglet Sécurité de votre tableau de bord avec le nom du paquet, la version et les identifiants CVE. NixOS livre généralement un paquet corrigé dans les 24 à 48 heures suivant la divulgation d'une CVE — l'analyse quotidienne suivante confirme le correctif. C'est quelque chose que la plupart des stacks auto-hébergées ne peuvent pas faire sans un outillage important ; ici, c'est intégré d'office.

Le mode air-gapped est la réponse complète — nous ne détenons aucune clé SSH, donc une compromission totale de notre infrastructure n'a aucun chemin SSH vers votre VM. En mode Géré, le journal d'audit chaîné par hachage enregistre les opérations du plan de contrôle. De plus, vous pouvez activer l'e-mail de synthèse hebdomadaire facultatif depuis les réglages de votre compte : il résume les changements de services, les résultats des mises à jour NixOS et les nombres de CVE sur vos serveurs — vous offrant une confirmation régulière, attendue et facile à lire que rien d'anormal ne s'est produit. Toute anomalie dans cette synthèse est un signal précoce pour consulter le journal d'audit complet.

LUKS protège le système de fichiers racine chiffré si quelqu'un obtient un disque racine retiré ou un instantané du disque racine sans les éléments de déverrouillage du démarrage. ReefOffice utilise LUKS sans intervention afin que les serveurs puissent redémarrer automatiquement, ce qui place la partition de démarrage et l'initrd dans une partie distincte du modèle de menace. Une image complète côté fournisseur incluant le démarrage et le stockage racine n'est pas équivalente à un disque racine chiffré retiré. Les chemins restants sur une VM en fonctionnement, comme la mémoire au niveau de l'hyperviseur ou l'accès runtime, relèvent des contrôles, contrats et audits du fournisseur plutôt que de LUKS.

Un attaquant devrait compromettre la VM en fonctionnement, ou obtenir suffisamment d'éléments de démarrage et d'accès disque pour déverrouiller le système de fichiers racine chiffré, puis lire /etc/reefoffice/secrets.env. La clé de sauvegarde ne se trouve jamais dans la base de données du plan de contrôle ReefOffice. Si votre exigence de conformité impose que la clé de sauvegarde soit inaccessible sous toute compromission au niveau de la VM, le mode zero-knowledge retire à ReefOffice la garde de la clé après la remise.

Lors de la première connexion SSH après le provisionnement, le plan de contrôle enregistre la clé d'hôte publique de la VM (Trust On First Use — TOFU). Chaque connexion ultérieure vérifie que la clé correspond à cet enregistrement. Une non-concordance — indiquant que la VM a été remplacée ou qu'un MITM a été inséré — fait échouer la connexion immédiatement et est inscrite au journal d'audit. Cela signifie qu'une VM malveillante ne peut pas intercepter silencieusement le trafic de gestion, même si le DNS ou le routage IP est compromis.

Votre serveur tourne chez Contabo GmbH, une société d'hébergement allemande fondée en 2003, avec ses propres datacenters à Munich et à Nuremberg — pas un revendeur. Contabo sert plus de 225 000 clients dans 190 pays sur plus de 450 000 serveurs, et un suivi indépendant par HOSTtest a mesuré 100 % de disponibilité au T3 2025 et au T4 2024. Contabo est une société allemande immatriculée (Amtsgericht München, HRB 180722).