Architecture et sécurité d'Auditix
Document destiné aux directions des systèmes d'information évaluant Auditix — architecture technique, isolation des données, authentification et pratiques de sécurité mises en œuvre.
Ce que couvre ce document
Auditix est une plateforme SaaS multi-tenant d'audit de maturité et de conformité (CMMI, TMMi, COBIT, ISO 27001, ISO 9001). Chaque organisation cliente (cabinet d'audit ou direction interne) dispose d'un espace strictement isolé des autres. Ce document explique comment cette isolation, l'authentification et le traitement des données sont concrètement mis en œuvre — pas une déclaration d'intention, mais une description de ce qui est réellement implémenté aujourd'hui.
Nous préférons décrire précisément ce qui existe plutôt que de sur-vendre — la section Transparence & feuille de route en fin de document liste explicitement ce qui n'est pas encore en place.
Architecture technique
Trois fournisseurs, chacun spécialisé sur son rôle — pas d'infrastructure auto-gérée.
HTTPS/TLS
rendu & logique métier
+ RLS
(logos)
100 % côté serveur
Aucune base de données ni serveur n'est géré manuellement par nos équipes — l'infrastructure repose entièrement sur des fournisseurs cloud spécialisés, chacun responsable de la sécurité physique et réseau de sa couche.
Couches applicatives (à l'intérieur de Vercel)
Le nœud « Vercel » du schéma précédent n'est pas monolithique — voici sa décomposition en couches, du navigateur jusqu'à la base de données.
Isolation des données entre organisations
Le point le plus souvent posé par une DSI sur un SaaS multi-client : comment est garantie l'étanchéité entre nos données et celles d'un autre client ?
L'isolation n'est pas assurée uniquement par la logique applicative (qui pourrait contenir un bug), mais directement au niveau de la base de données, via le mécanisme Row Level Security (RLS) de PostgreSQL. Concrètement : chaque table de données (audits, réponses, clients, plans d'action…) porte une règle d'accès appliquée par la base de données elle-même, à chaque requête, quel que soit le chemin par lequel cette requête est émise.
Un bug dans le code applicatif (un filtre oublié, une requête mal construite) ne peut pas contourner cette règle — elle est appliquée par la base de données elle-même, pas par le code qui l'interroge. C'est le même principe utilisé par les plateformes SaaS multi-tenant à grande échelle.
Une organisation ne peut techniquement lire ou modifier que les données rattachées à son propre identifiant d'organisation. Ce périmètre est vérifié à chaque requête, pas seulement à la connexion.
Authentification & contrôle d'accès
Pas d'inscription publique
Auditix n'a pas de formulaire d'inscription ouvert au public. Chaque organisation est provisionnée individuellement après mise en place d'un contrat, et son premier utilisateur active son compte via un lien d'invitation à usage unique. Cela réduit la surface d'attaque par rapport à un système d'inscription ouvert (pas de création de compte automatisée, pas de bourrage d'identifiants sur un formulaire public).
Rôles par organisation
| Rôle | Portée |
|---|---|
| Propriétaire | Accès complet à l'organisation, y compris la gestion de l'équipe. |
| Admin | Accès complet aux audits et à la gestion de l'équipe. |
| Auditeur | Peut mener les audits qui lui sont assignés. |
| Lecteur | Lecture seule — peut en plus être restreint à un sous-ensemble précis des unités/clients de l'organisation (utile pour une direction interne : un lecteur RH ne voit pas les données Finance, par exemple). |
Support technique — accès en lecture seule, jamais silencieux
Lorsqu'une intervention de support ou une démonstration nécessite qu'un administrateur Delta Technologies consulte l'espace d'un client, cet accès est structurellement en lecture seule : la base de données elle-même refuse toute écriture sur ce chemin (même en cas d'anomalie applicative), et l'administrateur n'apparaît jamais comme membre de l'organisation cliente.
Si une intervention de support nécessite exceptionnellement une écriture (correction de données, assistance avancée), cela requiert que le client donne explicitement son accord en ajoutant temporairement l'équipe de support comme membre de son organisation — jamais un accès accordé unilatéralement par Delta Technologies.
Chiffrement des données
Séparation des environnements
Le développement et les tests s'effectuent sur un environnement (base de données, configuration) totalement distinct de l'environnement de production utilisé par les clients. Aucune donnée de test ne transite vers la production, et aucune donnée client n'est utilisée à des fins de développement.
Confidentialité du traitement des rapports
Les rapports d'audit (Word, graphiques) sont générés directement sur nos serveurs applicatifs — aucune donnée d'audit n'est envoyée à un service tiers pour la génération de graphiques, de documents ou de mise en forme. C'est un choix délibéré : les rapports d'audit portent une mention de confidentialité, et leur contenu ne doit transiter par aucun intermédiaire externe au traitement.
Gestion des mots de passe
Authentification par email et mot de passe (8 caractères minimum), gérée par le service d'authentification de Supabase — les mots de passe ne sont jamais stockés ni consultables en clair par Delta Technologies. La récupération d'un mot de passe oublié s'effectue aujourd'hui via une intervention de l'équipe Delta Technologies (voir la section suivante pour l'évolution prévue de ce point).
Transparence & feuille de route
Ce qui est en place aujourd'hui, et ce qui est identifié pour évolution — sans enjoliver.
| Contrôle | État |
|---|---|
| Isolation des données par organisation (RLS base de données) | ✓ En place |
| Chiffrement en transit (HTTPS/TLS) | ✓ En place |
| Chiffrement au repos | ✓ En place |
| Accès sur invitation uniquement, pas d'inscription publique | ✓ En place |
| Rôles et portées par organisation | ✓ En place |
| Séparation environnements développement/production | ✓ En place |
| Traitement des rapports 100 % interne, aucun service tiers | ✓ En place |
| Surveillance et correction des vulnérabilités de dépendances (audit régulier, patchs appliqués dès disponibilité) | ✓ En place |
| Authentification à double facteur (MFA) | ◐ Non disponible actuellement |
| Réinitialisation de mot de passe en libre-service | ◐ Non disponible actuellement — géré manuellement par notre équipe |
| Journal d'audit horodaté des accès administrateur | ◐ En cours de définition |
Les niveaux d'engagement contractuels précis (disponibilité garantie, rétention des sauvegardes) dépendent du palier d'infrastructure souscrit auprès de nos fournisseurs cloud et peuvent être précisés sur demande spécifique, en fonction du contrat envisagé.