Comment nous protégeons vos identifiants Odoo.

Quand vous connectez une instance Odoo, seuls ces champs sont persistés dans notre base. Rien d'autre — pas de cookies, pas de tokens de session, pas de clés admin Odoo, aucune donnée d'analytics au-delà de ce qui sert à synchroniser vos factures.

• URL Odoo — par ex. https://acme.odoo.com — pour atteindre votre instance.
• Nom de la base — l'identifiant de la base Odoo — requis par le protocole RPC d'Odoo.
• Identifiant — le login de l'utilisateur Odoo dédié que vous nous provisionnez.
• Mot de passe chiffré — un blob de chiffré. Le clair quitte votre navigateur, est chiffré sur notre serveur, et n'est jamais écrit sur disque sous une forme lisible.

Voici la forme réelle de la table qui contient votre connexion. Notez ce qui en est absent : aucune colonne plaintext_password, aucun password_hint, aucun champ de récupération.

# forme simplifiée de ce qui se trouve en base
odoo_connections (
  id                  SERIAL PRIMARY KEY,
  user_id             INTEGER,
  url                 TEXT,          -- ex. https://acme.odoo.com
  database            TEXT,          -- ex. acme-prod
  username            TEXT,          -- ex. bot@acme.com
  encrypted_password  TEXT,          -- chiffré uniquement — jamais de clair
  ...
)

Trois éléments rendent cette ligne sûre à conserver :

• La colonne password ne stocke que du chiffré — le clair n'existe jamais sur notre infrastructure après chiffrement.
• Du chiffré sans la clé maître est cryptographiquement inutile — pas de dictionnaire, pas de brute force dans un horizon faisable.
• Chaque ligne est liée à un user_id. Notre API refuse de retourner une connexion qui n'appartient pas à l'appelant.

Nous utilisons Fernet, le schéma de chiffrement de la bibliothèque Python cryptography bien auditée. Fernet n'est pas un protocole maison — c'est une spécification bâtie sur des primitives revues depuis des décennies.

Chaque mot de passe que vous enregistrez passe par les deux mêmes fonctions. C'est littéralement tout le code — pas de crypto custom, pas de raccourcis :

# backend/app/core/security.py (extrait)
from cryptography.fernet import Fernet

def encrypt(value: str) -> str:
    return get_fernet().encrypt(value.encode()).decode()

def decrypt(value: str) -> str:
    return get_fernet().decrypt(value.encode()).decode()

Le chiffrement ne vaut que ce que vaut la gestion de clé. La clé maître — celle qui peut transformer un chiffré en votre mot de passe — est délibérément tenue loin des données qu'elle protège.

• Injectée dans le processus serveur au démarrage depuis un magasin de secrets managé. Elle ne touche jamais la base applicative.
• Jamais commitée dans git, jamais écrite dans les logs applicatifs, jamais retournée par un endpoint API.
• Seuls le serveur FastAPI et le worker Celery la détiennent en mémoire, et seulement le temps de vie de ce processus.
• Backups, replicas en lecture, et environnements de staging utilisent des données différentes et ne peuvent pas déchiffrer le chiffré de prod.

Votre mot de passe fait exactement deux sauts quand vous enregistrez une connexion, et exactement un à chaque sync. Les deux sauts sont protégés par TLS avec des suites cipher modernes.

Nous n'acceptons jamais d'identifiants sur une connexion non chiffrée. Le mot de passe n'est déchiffré en mémoire que pour la durée d'un seul appel RPC à votre Odoo, puis effacé.

L'ensemble des processus et des personnes qui peuvent déchiffrer un mot de passe stocké est délibérément minuscule.

• Chemins applicatifs : exactement deux — l'endpoint de test de connexion et le worker de sync en arrière-plan. Les deux dans le repo. Les deux auditables.
• Humains : aucun membre de l'équipe Vizualizer n'a un workflow routinier qui appelle decrypt(). L'accès direct à la base est audité et utilisé pour les migrations, pas pour inspecter les lignes.
• Autres tenants : impossible. Chaque requête est scopée par user_id, contrôle côté serveur depuis le JWT, pas par le frontend.

Même avec des identifiants valides, notre code ne peut pas modifier votre Odoo. Le worker de sync n'appelle que des méthodes en lecture — search_read, read — sur les modèles facture, partenaire et produit.

• Aucun appel write, unlink, ou create n'est jamais émis vers votre Odoo.
• Pas d'automatisation, pas de déclencheurs de workflow, aucun effet de bord sur vos données métier.
• Vous pouvez restreindre encore davantage en donnant à l'utilisateur Odoo de Vizualizer des groupes en lecture seule — ainsi même un bug ou une compromission de notre côté ne pourrait pas altérer vos données.

Les promesses de sécurité ne sont significatives que mesurées contre des menaces précises. Voici comment chaque scénario courant se déroule :

Cliquez sur le × à côté d'une connexion dans la sidebar et la ligne — y compris le mot de passe chiffré — est supprimée immédiatement de notre base.

• La ligne est supprimée par un DELETE dur, pas un soft-delete.
• Les sauvegardes quotidiennes expirent dans notre fenêtre de rétention ; après ça, aucune copie du chiffré ne subsiste.
• Les données de factures synchronisées liées à cette connexion sont supprimées dans la même transaction.

Nous accueillons les revues de sécurité. Chercheur en sécurité, CISO en évaluation, ou client souhaitant mener son propre audit : nous travaillerons avec vous.

Signaler une vulnérabilité, demander des détails d'architecture ou solliciter une fenêtre de pentest : security@hazenfield.com