Sécurité et déploiement
Autonome ne signifie pas incontrôlé.
Un collaborateur IA ZeyDo travaille seul, dans les limites que vous fixez. Ces limites sont tenues par l'application, pas par une consigne au modèle.
- Permissionspar métier
- Validationquand vous la voulez
- Journalde chaque action
- Coffrepour vos clés
- Lecture du dossier « Devis à relancer »
- Brouillon de relance écrit pour 3 clients
- Envoi en attente de votre relecture
- Texte relu et validé, envoi consigné
- Outil refusé : hors des permissions du poste
Le parcours d'une action
De la demande à la trace, rien n'échappe
- DemandeUne tâche planifiée, ou ce que vous demandez à voix haute.
- Vérification des permissionsLe collaborateur n'atteint que ce que son métier et vous lui ouvrez.
- Approbation si nécessaireUn outil qui modifie, un envoi : votre clic, sur le texte exact.
- ExécutionDans son dossier de travail, ou dans ceux que vous avez désignés.
- TraçabilitéChaque appel d’outil, abouti ou refusé, est consigné.
Schéma de fonctionnement : chaque étape est tenue par l'application.
Trois déploiements
Là où vos données doivent rester
Local
Les modèles tournent chez vous, sur la ZeyDo Station ; rien ne sort pour être traité.
Vos fichiers→ La Station→ Vos dossiers
Hybride
Le quotidien en local sur la Station, l'API pour ce que la machine ne porte pas. Vous êtes prévenu avant.
La Station→ Vous êtes prévenu→ L'API d'IA
Cloud
Pour un ou deux collaborateurs IA, sans machine : ils passent par l'API d'IA que vous choisissez.
ZeyDo Desktop→ L'API d'IA→ Vos dossiers
Ce que tient l'application
Huit garanties, écrites dans le code
- Permissions par métierCe qu’un collaborateur IA peut atteindre se déduit de sa fiche, jamais de l’écran.
- Votre clic pour modifierUn outil qui modifie quelque chose demande votre accord.
- Un dossier à luiPar défaut, le collaborateur ne lit et n’écrit que dans son propre dossier.
- Aucun envoi à l’aveugleAucun e-mail ne part sans que le texte exact ait été relu.
- Vos clés au coffreVos clés d’API restent sur votre poste, dans le coffre du système.
- Tout est consignéChaque appel d’outil et chaque envoi laissent une trace.
- Vos comptes, vos mainsPas de connexion automatique : vous vous connectez vous-même.
- Réglages annulablesUn réglage du chef d’équipe s’annule en un geste.
ZeyDo Quantum-Ready Security Architecture
Conçue pour l'ère post-quantique
Un ordinateur quantique assez puissant casserait les clés publiques classiques (RSA, courbes elliptiques). Le risque commence avant lui : des données interceptées aujourd'hui pourraient être déchiffrées plus tard (« harvest now, decrypt later »). L'architecture de sécurité ZeyDo est conçue pour que toute la flotte passe à la cryptographie post-quantique sans remplacement massif de matériel, avec une chaîne de confiance auditable de l'usine jusqu'au Control Plane.
Ce qui protège chaque Box
- Une identité propre : une clé Ed25519 créée sur la Box, et chaque requête vers la plateforme signée.
- Des mises à jour signées : un paquet dont la signature ne correspond pas est refusé.
- Des secrets scellés en AES-256-GCM, avec une clé dérivée par échange X25519.
- Des licences, mises à jour et Skill Packs signés deux fois, en Ed25519 et en ML-DSA-65 (FIPS 204) : une signature qui manque suffit à refuser.
- Le disque des données chiffré en LUKS2. Sa clé sera scellée à la puce TPM 2.0 à la mise en service des Box.
La couche post-quantique s'ajoute aux algorithmes classiques éprouvés, en hybride : il faudrait casser les deux. Les algorithmes sont ceux des normes FIPS 203 et 204 ; les bibliothèques employées ne sont pas certifiées FIPS 140-3.
| Besoin | Référence | Rôle chez ZeyDo |
|---|---|---|
| Signature post-quantique | ML-DSA-65 (NIST FIPS 204), en hybride avec Ed25519 | En service : licences, mises à jour et Skill Packs portent les deux signatures, et les deux sont exigées |
| Établissement de secret | ML-KEM-768 (NIST FIPS 203), en hybride avec X25519 (X-Wing) | En service : chiffrement des Skill Packs. Prévu : canal entre la Box et le Control Plane |
| Signature alternative | SLH-DSA (NIST FIPS 205) | Prévu : choix conservateur pour certains rôles de signature |
| Chiffrement symétrique | AES-256-GCM | En service : secrets scellés et données persistantes |
| Empreintes | SHA-256, puis SHA-384 / SHA-512 | En service : SHA-256. Prévu : SHA-384 / SHA-512 pour les artefacts signés |
| Transport | TLS 1.3 | En service. Prévu : échange de clés hybride post-quantique |
Il ne s'agit pas d'installer un ordinateur quantique dans la Box : le sujet est la résistance de la cryptographie dans la durée, et la capacité de migrer.
Principes directeurs
Changer d'algorithme sans changer de machine
- Crypto-agilitéAucun service métier ne dépend d’un algorithme écrit en dur : la signature et le chiffrement passent par une seule brique par langage, qui nomme son profil dans chaque clé et chaque signature.
- Hybride pendant la transitionMécanismes classiques éprouvés et post-quantiques combinés, pour ne jamais parier sur un seul.
- Identité forte de chaque BoxUne clé propre à chaque Box et des échanges authentifiés des deux côtés. L’ancrage dans la puce TPM 2.0 se fera à la mise en service des Box.
- Démarrage et mises à jour vérifiablesSecure Boot, images signées, manifestes de mise à jour signés, retour arrière contrôlé.
- Inventaire cryptographiquePour chaque appareil : algorithmes, bibliothèques, certificats et profil déployés.
- Migration pilotée par politiqueLes profils cryptographiques sont versionnés et déployés par le Control Plane, sans remplacer le matériel.
Profils cryptographiques
Une migration pilotée, Box par Box
L'architecture prévoit que le Control Plane déploie un profil versionné et que chaque Box réconcilie son état réel avec l'état voulu. Une Box en retard passerait en « non conforme » avec un plan de remédiation, sans être coupée brutalement, sauf faille critique. Aujourd'hui, le profil hybride classique + post-quantique est celui des signatures en service.
| Profil | Usage | Politique |
|---|---|---|
| CRYPTO-1 | Compatibilité classique contrôlée | Transition seulement, pour les équipements anciens |
| CRYPTO-2 | Hybride classique + post-quantique | Profil par défaut retenu pour la transition |
| CRYPTO-3 | Post-quantique préféré | Quand l’écosystème et les certificats sont stabilisés |
| CRYPTO-4 | Réservé | Pour les recommandations et migrations suivantes |
Chaîne de confiance
Une PKI ZeyDo à autorités séparées
C'est la chaîne de confiance que l'architecture prévoit. Chaque action sensible est reliée à un acteur (humain, agent, service ou appareil), à un client, à une ressource et à un identifiant de corrélation. Les autorités intermédiaires se renouvellent ; une clé compromise se révoque sans réinstaller la flotte.
- Racine de confiance ZeyDoHors ligne ou en HSM. Jamais utilisée par les applications du quotidien.
- Autorité des appareilsÉmet les certificats des Box, liés à leur puce TPM à la mise en service.
- Autorité des servicesControl Plane, API et workers, avec des certificats courts et renouvelables.
- Autorité de signature du codeImages système, mises à jour, Skill Packs : séparée de l’identité des appareils.
- Autorité des identités de collaborateurs IAUn collaborateur IA garde son identité logique quand il change de Box.
Références : NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), recommandations du NIST sur l'agilité cryptographique, feuille de route coordonnée de l'Union européenne pour la transition post-quantique.
Un environnement managé
ZeyDo tient la Box à jour
- La Box est préparée et tenue à jour par ZeyDo.
- Vous choisissez, tâche par tâche, ce qui passe par l’API et ce qui reste en local.
- Les résultats s’écrivent dans vos dossiers.
