Une sécurité que vous pouvez vérifier, et pas seulement croire.

À l’intérieur de la plateforme, la frontière PII remplace les noms des employés, des managers et des signataires, les noms des employeurs et des entreprises, les dates, les adresses e-mail professionnelles et les identifiants d’employés par des pseudonymes cohérents avant qu’une requête n’atteigne le moteur, puis les rétablit dans la réponse. Elle s’applique aux appels au moteur de la plateforme RH, du worker de cycle de vie, de ZeugnyAI Chat (qui n’atteint le moteur que par la plateforme) et de la passerelle Word.

Pour chaque certificat, les RH peuvent ouvrir chaque passage vers et depuis le moteur : l’heure, le sens, le nombre d’éléments remplacés par catégorie, le SHA-256 de la charge utile et les pseudonymes utilisés. Les vraies valeurs n’y sont jamais affichées. La vue s’exporte en CSV.

Toutes les applications n’acceptent que HTTPS, avec TLS 1.2 au minimum ; TLS 1.3 est négocié en pratique. Le serveur de base de données n’accepte que les connexions TLS, avec TLS 1.2 au minimum, et les connexions de la plateforme à la base de données demandent TLS.

Azure chiffre au repos la base de données, les sauvegardes et le stockage de fichiers. En plus, la plateforme chiffre les correspondances de pseudonymes et les clés API du moteur avec AES-256-GCM, sous des clés maîtresses conservées dans Azure Key Vault. Les autres enregistrements reposent sur le chiffrement d’Azure.

Une fois le délai de conservation écoulé (par défaut, 10 ans après la fin de la relation de travail), une tâche horaire occulte le nom, l’adresse e-mail, la date et le lieu de naissance et la nationalité d’un ancien employé, efface les brouillons et supprime les correspondances de pseudonymes. Les affectations de poste, la piste d’audit et les certificats délivrés sont conservés ; les certificats délivrés contiennent toujours le nom. Nous fixons un autre délai pour votre entreprise sur demande ; une configuration en libre-service est prévue.

Les employés déposent eux-mêmes leurs demandes d’accès et de suppression sous « Confidentialité », et les RH suivent chacune d’elles selon un délai de 30 jours. L’effacement occulte les données de l’employé, retire les entrées du coffre-fort et les partages, et délivre un reçu. Une demande d’accès produit un récapitulatif ; une copie téléchargeable des données est prévue.

La plateforme peut détruire la clé de pseudonymisation d’une entreprise, ce qui rend illisibles les correspondances stockées. La fonction est développée et testée ; sa mise à disposition comme action d’exploitant est prévue. Les copies de sauvegarde expirent selon le calendrier de sauvegarde habituel.

Le texte des certificats est rédigé par des modèles sur Microsoft Azure AI Foundry, sur une ressource à Switzerland North avec un déploiement EU Data Zone Standard, de sorte que les requêtes sont traitées dans la zone de données de l’UE. Les étapes de décision, d’extraction et de recherche utilisent aussi Microsoft Decision-1 (une ressource Azure AI Foundry à Sweden Central avec un déploiement EU Data Zone Standard), OpenRouter et Voyage AI, et la plateforme utilise OpenRouter directement pour suggérer des intitulés de poste et des tâches. Les fournisseurs ne reçoivent que du texte pseudonymisé. Chaque requête que le moteur envoie à OpenRouter exige des fournisseurs qui ne collectent pas de données d’utilisateurs, sans réglage permettant de le désactiver. Le routage sans conservation de données (zero data retention) est prévu.

Les mots de passe sont hachés avec scrypt et comptent au moins 8 caractères. Les adresses e-mail sont vérifiées avant la première connexion par mot de passe, et les liens magiques sans mot de passe expirent après 5 minutes. Les tentatives de connexion sont limitées en fréquence par adresse IP.

Les sessions sont stockées sur le serveur et peuvent être révoquées. Les cookies de session sont HttpOnly, Secure et SameSite=Lax, et expirent après 7 jours. Un compte désactivé est refusé dès sa requête suivante.

Avec l’authentification unique, la MFA de votre fournisseur d’identité s’applique à chaque connexion. Les comptes du personnel dans notre plan de contrôle exigent un second facteur (code d’authentification ou code de secours) à chaque session, et aucune connexion d’opérateur au moteur n’est délivrée sans lui. Un second facteur intégré pour la connexion par mot de passe des clients est prévu.

Authentification unique par entreprise avec OIDC ou SAML, domaines vérifiés par DNS, attribution des rôles à partir des groupes et mode SSO exclusif en option. Elle est activée dans le Cloud géré, et nous connectons votre fournisseur d’identité sur demande. SCIM 2.0 crée et désactive des utilisateurs et met fin à leurs sessions ; un utilisateur provisionné sans rôle reçoit le rôle RH le moins privilégié (coordinateur RH), et les points de terminaison SCIM sont soumis à des limites de fréquence. L’auto-hébergement se connecte à tout fournisseur OIDC.

Chaque route vérifie des autorisations fondées sur les relations. Les coordinateurs RH peuvent rédiger des brouillons, mais ne peuvent ni finaliser, ni passer outre un constat, ni signer, ni télécharger le document officiel. Les représentations du personnel ne voient que des chiffres agrégés ; les managers voient leurs propres collaborateurs directs.

Dans le Cloud géré, les entreprises partagent une seule base de données suisse. L’application confine chaque requête à une entreprise et vérifie les autorisations sur chaque objet. L’auto-hébergement donne à chaque client sa propre base de données. Un contrôle au niveau des lignes imposé par la base de données elle-même est prévu comme seconde couche.

Les personnes sans compte, comme un manager qui évalue, un relecteur de brouillon ou l’employé qui récupère un certificat, reçoivent des liens qui donnent accès à un seul objet, expirent et peuvent être révoqués. La plateforme ne stocke qu’un hachage SHA-256 de chaque jeton de lien.

Les comptes du personnel ne sont créés que sur invitation et exigent un rôle d’administrateur, et chaque action dans le plan de contrôle requiert sa propre autorisation. Chaque session du personnel doit passer un second facteur (code d’authentification ou code de secours) avant de pouvoir utiliser le plan de contrôle, et aucune connexion d’opérateur au moteur n’est délivrée sans lui. Le personnel ne peut pas usurper l’identité d’un utilisateur : les points de terminaison d’usurpation d’identité (impersonation) de l’administration sont désactivés. Les modifications des entreprises, des clés du moteur et du personnel sont journalisées.

Les connexions et les envois de formulaires sont vérifiés par rapport à l’origine de la requête, et les cookies de session sont SameSite=Lax.

Les quatre applications web (application, plan de contrôle, chat et site web) envoient HSTS, une Content-Security-Policy avec un nonce par réponse, une protection contre l’intégration dans un cadre (X-Frame-Options DENY et frame-ancestors none), X-Content-Type-Options nosniff et une politique de référent. Les pages sensibles envoient en plus les en-têtes no-store et no-referrer.

La connexion est limitée en fréquence par adresse IP. Chaque page de lien public, y compris les pages publiques de vérification derrière le code QR, autorise 60 requêtes par minute et par client, et les points de terminaison SCIM autorisent 600 requêtes par minute par entreprise et par client.

Chaque entreprise a sa propre clé du moteur, avec une limite de débit de requêtes ; elle peut être renouvelée par rotation et révoquée. Le moteur n’en stocke qu’un hachage SHA-256, et la plateforme la stocke chiffrée avec AES-256-GCM. Les résultats ne sont lisibles que par la clé ou l’entreprise qui les a créés.

Les scans téléversés de certificats papier signés doivent être au format PDF, PNG ou JPEG, de 10 Mo au plus, et le contenu du fichier doit correspondre au type déclaré.

Les secrets de production se trouvent dans Azure Key Vault, avec un accès basé sur les rôles et la suppression réversible, et parviennent aux applications sous forme de références Key Vault. Aucun n’est stocké dans le code source, et la production refuse de démarrer sans ses clés.

La production s’exécute sur des services gérés : conteneurs Azure App Service et Azure Database for PostgreSQL pour la plateforme, Cloudflare Workers pour le moteur. Nous n’avons aucune machine virtuelle propre à maintenir.

Les applications accèdent à la base de données par un point de terminaison privé. La base de données a aussi un point de terminaison public. La liste d’autorisation de son pare-feu contient les plages d’adresses de Cloudflare, afin que les Cloudflare Workers, dont le moteur, puissent s’y connecter via Hyperdrive. Lors des migrations, des déploiements et des sauvegardes, une règle temporaire autorise le runner CI qui effectue le travail et est supprimée à la fin du job. TLS et des mots de passe protègent chaque connexion.

Les ressources Azure sont définies dans des modèles versionnés, et les paramètres des applications proviennent de fichiers versionnés qui font référence à Key Vault.

Les notifications sont envoyées depuis notifications.zeugny.com, qui publie une politique DMARC « reject » ; le domaine principal zeugny.com publie lui aussi une politique DMARC « quarantine ». Les notifications contiennent l’adresse du destinataire, des noms et un lien. security@, privacy@ et hello@zeugny.com sont des boîtes surveillées.

Chaque étape du cycle de vie et chaque modification est inscrite dans un journal d’audit dans lequel chaque entrée porte le hachage de la précédente, de sorte qu’une entrée modifiée rompt la chaîne. La chaîne est vérifiée à l’ouverture d’un dossier ou d’une page de vérification, et le dossier de chaque certificat peut être téléchargé avec ses entrées d’audit.

Toutes les cinq minutes, un moniteur distinct vérifie l’état de la plateforme, du worker et du plan de contrôle. Une fois par jour, il exécute une analyse complète d’un certificat fictif via le moteur. Des tests de disponibilité Azure surveillent le moniteur lui-même depuis trois emplacements en Europe, de sorte qu’une panne de l’un ou de l’autre déclenche une alerte.

Les journaux d’application, HTTP et de base de données vont vers Azure Log Analytics à Switzerland North et sont conservés 30 jours. Les journaux de requêtes du moteur ne contiennent que des métadonnées ; les journaux d’exécution du moteur sur Cloudflare peuvent contenir des fragments de texte pseudonymisé.

Si un incident touche vos données, nous informons votre contact désigné sans retard injustifié après l’avoir confirmé, en indiquant ce qui s’est passé, quelles données sont concernées et ce que nous faisons à ce sujet. Un plan écrit de réponse aux incidents est rédigé et sera publié après examen juridique ; des exercices réguliers sont prévus.

La base de données peut être restaurée à n’importe quel moment des 35 derniers jours. En outre, une tâche planifiée réalise chaque nuit un dump de toutes les bases de données. Elle s’exécute sur un runner CI exploité par ZeugnyAI, qui se connecte via TLS, écrit chaque dump dans un fichier temporaire, le transfère vers Azure Storage à Switzerland North et supprime le fichier. Les 30 derniers dumps de chaque base sont conservés, et les dumps supprimés restent récupérables 30 jours de plus. Les sauvegardes stockées, à un instant donné et dumps, se trouvent à Switzerland North et sont répliquées vers Switzerland West, une seconde région suisse.

La procédure de restauration est documentée. Restauration testée le 9 novembre 2026 : une restauration à un instant donné de la base de données de production vers un serveur temporaire s’est achevée en 7 minutes et son contenu a été vérifié. D’autres tests de restauration, à intervalles réguliers, sont prévus.

Le Cloud géré s’exécute dans Azure Switzerland North. Les sauvegardes de la base de données et le stockage de fichiers sont répliqués dans une seconde région suisse, Switzerland West. Une restauration de la sauvegarde de la base de données vers Switzerland West a été testée le 10 novembre 2026. Une base de données de secours avec basculement automatique est prévue.

Chaque modification de la branche principale qui réussit les contrôles est déployée dans un environnement de préproduction distinct. Une mise en production exige un test de fumée réussi en préproduction pour le même commit. Le moteur n’atteint la production qu’à partir de commits qui ont réussi les contrôles : une tâche CI fait avancer la branche release jusqu’au commit testé, et Cloudflare déploie depuis cette branche.

Les contrôles de types, les tests unitaires et d’intégration et les builds de production s’exécutent pour chaque modification, et les tests de bout en bout s’exécutent pour les modifications qui les concernent. Les dépendances s’installent à partir d’un lockfile figé.

Le développement, la préproduction et la production utilisent des bases de données, des clés et des coffres de clés séparés. Les tests n’utilisent jamais de données ni d’identifiants de production.

Les mises en production passent par des contrôles automatisés. Le pipeline de production du moteur ne déploie qu’à partir d’une branche release, que la CI avance vers un commit une fois les tests réussis pour ce commit sur la branche principale. Le pipeline de production de la plateforme ne s’exécute que pour des commits de la branche principale avec une exécution CI réussie, et seulement après une exécution d’acceptation dans l’environnement de préproduction. Les clients en auto-hébergement peuvent examiner chaque modification dans leur dépôt. Une relecture indépendante imposée pour chaque modification est prévue.

Les instantanés du code source remis aux clients sont contrôlés avant publication pour détecter des chaînes ressemblant à des secrets et des chemins interdits. Les alertes sur les vulnérabilités des dépendances (Dependabot) sont activées sur les dépôts de la plateforme et du moteur. L’analyse du code et l’analyse des secrets du dépôt sont prévues.

Les clients en auto-hébergement reçoivent un instantané de la plateforme limité à une liste d’autorisation, sous forme de dépôt privé, et construisent eux-mêmes les conteneurs. Les outils internes sont exclus, et une version est interrompue si des chemins interdits ou des chaînes ressemblant à des secrets sont trouvés.

L’accès de production est limité à des administrateurs nommément désignés, selon le principe du strict nécessaire. Une séparation formelle des fonctions entre développement et exploitation est prévue.

Chaque fournisseur qui traite des données pour le Cloud est listé sur cette page avec sa finalité, les données qu’il reçoit et son emplacement.

Des politiques écrites formelles pour la sécurité de l’information, le contrôle des accès, la réponse aux incidents et les fournisseurs sont rédigées et seront publiées après examen juridique. Cette page décrit la pratique actuelle.

Un test d’intrusion externe est prévu. Les clients en auto-hébergement sont les bienvenus pour tester leur propre installation à tout moment ; pour le Cloud géré, nous convenons avec vous du périmètre et du calendrier.