Le passeport est une promesse.
Voici comment nous la tenons.

Les fonctions serveur de l’application s’exécutent à Francfort (fra1), à côté du stockage de données principal, un cluster Postgres géré sur AWS eu-central-1 (Francfort). Les contenus clients, les données des espaces clients et les pistes d’audit y sont stockés. Les fonctionnalités d’IA envoient le texte qu’elles traitent à l’API Gemini de Google, qui le traite aux États-Unis.

Les ressources statiques et les pages publiques des passeports sont servies par un réseau edge mondial, depuis l’emplacement le plus proche du lecteur ; seules les ressources publiques et non sensibles (logos, textes marketing, HTML des pages du résolveur) y sont mises en cache. Par principe, les réponses d’API authentifiées ne passent pas par le cache.

Les domaines personnalisés des espaces clients (par exemple dpp.brand.com) sont servis par la même plateforme. Nous n’entretenons aucune infrastructure de secours qui transférerait des données stockées hors de l’UE.

Toutes les connexions au résolveur, à l’administration des espaces clients et à l’API utilisent TLS 1.2 ou supérieur. HSTS est appliqué avec un max-age de deux ans et le preload activé. Les pages sont servies avec X-Frame-Options SAMEORIGIN et Referrer-Policy strict-origin-when-cross-origin ; une Content-Security-Policy fonctionne en mode report-only.

Au repos, les volumes de stockage Postgres sont chiffrés en AES-256 par le fournisseur. Les identifiants d’intégration (Akeneo, Centra, Shopify, inriver, Delogue, jetons REST personnalisés) sont conservés dans un coffre chiffré propre à chaque espace client ; la clé de chiffrement est conservée hors de la base de données. Les clés d’API de LLM fournies par l’espace client (BYOK) sont chiffrées de la même manière.

La connexion se fait par lien magique envoyé par e-mail ou par Google. Les sessions sont conservées dans des cookies Secure, SameSite=Lax, limités à notre domaine.

Chaque table contenant des contenus clients est protégée par la sécurité au niveau des lignes (Row-Level Security) de la base de données. Un utilisateur d’un espace client ne peut jamais lire les données d’un autre espace client — la contrainte est appliquée au niveau de la base de données, pas seulement dans le code applicatif. L’accès du personnel est encadré séparément par une table staff_users et exige un motif opérationnel consigné dans le journal d’audit.

Les rôles au sein d’un espace client sont admin, editor et viewer — un admin gère les membres et tout le reste, un editor travaille sur les passeports et les données mais ne peut pas modifier qui a accès, un viewer consulte. À côté figurent des rôles destinés aux autorités pour le passeport public (economic-operator, distributor, refurbisher, recycler, market-surveillance, competent-authority). L’usurpation d’identité par le personnel n’est possible que par un processus signé et audité.

Les secrets de l’application résident exclusivement dans des variables d’environnement chiffrées de la plateforme. Aucun secret n’est versé dans le gestionnaire de code source, aucun secret n’est journalisé, et les clés d’API collées dans une conversation sont considérées comme compromises et renouvelées sur-le-champ.

Lorsqu’un espace client s’intègre à un système externe, l’identifiant est conservé par espace client dans le coffre chiffré décrit ci-dessus. Les renouvellements, expirations et changements de périmètre apparaissent dans le panneau Intégrations ; les échecs d’accès sont consignés dans la piste d’audit de l’espace client.

La base de données principale est sauvegardée en continu, avec restauration à un instant donné sur une fenêtre glissante. Des instantanés chiffrés quotidiens sont conservés selon un calendrier adapté à l’offre de l’espace client ; une conservation à long terme est disponible sur demande pour les catégories réglementées.

Pour les clients qui exigent un hébergeur de sauvegarde indépendant (conformément à l’EN 18221 §4.5), nous écrivons en parallèle vers un niveau de stockage séparé, de sorte que le passeport reste résoluble même si l’application principale est indisponible. La spécification de l’hébergeur de sauvegarde est communiquée aux prospects sous NDA.

L’état de l’infrastructure en temps réel — disponibilité, incidents et maintenances planifiées — est publié sur status.dppagent.com. Les incidents passés indiquent ce qui s’est produit, ce que nous avons changé et ce que nous avons détecté la fois suivante.

Nous acceptons les signalements de divulgation responsable à security@dppagent.com. Les signalements sont triés sous un jour ouvré et corrigés selon un calendrier fonction de la gravité. Les chercheurs de bonne foi sont protégés contre toute action en justice, cités sur demande, et ne sont pas tenus de signer un NDA pour soumettre un signalement.

Pour les incidents confirmés ayant un impact sur les clients, nous suivons une procédure documentée de réponse aux incidents : confinement d’abord, information du propriétaire de l’espace client dans le délai prévu au contrat, rapport post-incident publié sur la page d’état, et correction de la cause profonde suivie jusqu’à sa clôture.

La plateforme DPP Agent et ce qu’elle produit sont conçus selon la série de normes du CEN/CENELEC JTC 24 (EN 18216 accès, EN 18219 identifiants, EN 18221 cycle de vie et continuité, EN 18223 structure et interopérabilité), le profil de référence CIRPASS-2 et les exigences au niveau des champs de l’ESPR (règlement 2024/1781) et du règlement de l’UE relatif aux batteries (2023/1542). Les données des passeports sont conformes à GS1 Digital Link, avec les identifiants d’application GTIN, lot, CPV et numéro de série.

En tant que responsable du traitement / sous-traitant opérant depuis l’UE, nous sommes soumis au RGPD et proposons sur demande un accord de traitement des données standard. Les flux de données clients sont documentés dans notre liste de sous-traitants ultérieurs, modifiée avec un préavis de 30 jours en cas de changement important.

Nous ne détenons pas actuellement de certification SOC 2 ou ISO 27001. Lorsqu’une certification sera obtenue, nous publierons ici le rapport et le périmètre de l’audit. Les clients Enterprise peuvent demander sous NDA le dossier de revue de sécurité actuel, la synthèse du test d’intrusion et la liste de contrôle interne.