# Sécurité de PDF Blocks Comment l’API PDF Blocks traite les documents que vous lui envoyez, et les contrôles qui sous-tendent le service, du chiffrement à la réponse aux incidents. Cette page décrit la sécurité de l’**API de traitement de documents PDF Blocks**, le service qui reçoit, transforme et renvoie vos documents PDF. C’est là que vos données sont traitées, c’est donc le sujet ici. Il s’agit d’un service **stateless** qui ne stocke rien, et il fonctionne séparément de nos systèmes de compte et de facturation, qui ne reçoivent jamais vos documents. Cette page s’adresse aux équipes sécurité et achats qui nous évaluent ; si vous avez besoin d’un contrôle qui n’est pas couvert ici, contactez [security@pdfblocks.com](mailto:security@pdfblocks.com). **Vous préférez un document ?** Téléchargez le [PDF Blocks Security Whitepaper (PDF)](/pdf-blocks-security-whitepaper.pdf) : une synthèse partageable de tout ce qui figure sur cette page. ## Deux engagements qui définissent l’API L’essentiel de ce qui rend PDF Blocks sûr à adopter tient à deux réalités structurelles du fonctionnement de l’API : - **Nous ne stockons jamais vos documents.** L’API traite chaque fichier en mémoire et renvoie le résultat dans la même réponse. Les documents ne sont jamais écrits dans une base de données ni dans un stockage durable. Un envoi volumineux peut être brièvement mis en tampon dans un fichier temporaire pendant la durée d’une seule requête, et il est supprimé dès que la requête se termine. - **Notre pipeline est déterministe et n’utilise aucun LLM.** Chaque action est une manipulation de document implémentée en code : le même document et les mêmes paramètres produisent toujours la même sortie. Aucun grand modèle de langage ne lit vos documents, le pipeline n’appelle aucun service d’IA tiers, et rien de ce que vous nous envoyez n’est utilisé pour entraîner ou affiner un modèle. ## Comment vos documents sont traités Lorsque vous envoyez un document à l’API, il est reçu via TLS, traité en mémoire et renvoyé en flux dans la réponse. Rien du contenu du document n’est conservé. Pour chaque requête, nous n’enregistrons que des métadonnées, à savoir un hash de la clé d’API, l’action demandée, le nombre d’octets d’entrée et de sortie, le statut de la réponse et un horodatage, que nous utilisons à des fins de facturation, de sécurité et de prévention des abus. Le traitement que nous effectuons pour votre compte est régi par notre [Avenant relatif au traitement des données](/docs/trust/dpa), disponible pour les clients entreprise. Comme les documents ne sont jamais persistés, il n’y a aucune donnée de document à exporter, à supprimer ou pour laquelle produire un certificat de destruction : la garantie est structurelle plutôt qu’une politique que nous devons faire appliquer. ## IA et apprentissage automatique PDF Blocks n’est pas un produit d’IA. Des actions telles que fusionner, diviser, faire pivoter, apposer un filigrane, estampiller et protéger par mot de passe sont des transformations déterministes écrites en code, et elles constituent la totalité de ce que l’API fait de votre fichier. Aucun grand modèle de langage ne lit vos documents, et aucun contenu de document n’est envoyé à un service d’IA tiers. Quelques opérations doivent travailler sur l’aspect d’une page plutôt que sur sa structure. La lecture d’un code-barres en est l’exemple le plus clair : localiser le symbole sur la page et le décoder peut faire appel à l’informatique visuelle. Il s’agit d’analyse d’image, pas d’un modèle de langage, et cela s’exécute dans le même environnement isolé sans accès sortant à Internet que tout le reste. Dans un cas comme dans l’autre, la règle est la même : **nous n’entraînons pas de modèles d’apprentissage automatique sur vos documents**, et nous n’utilisons jamais leur contenu pour autre chose que l’opération que vous avez demandée. ## Chiffrement - **En transit.** Toutes les connexions sont chiffrées avec TLS. Nous appliquons une politique moderne TLS 1.3 / 1.2, et les requêtes en HTTP simple sont redirigées de manière permanente vers HTTPS. Le trafic entre les composants internes de l’API est lui aussi chiffré avec TLS. - **Au repos.** L’API ne conserve aucun stockage durable, il n’y a donc rien à chiffrer au repos, par conception. Un envoi volumineux peut être brièvement mis en tampon dans un fichier temporaire pendant la durée d’une seule requête ; ce fichier est supprimé dès que la requête se termine et n’est jamais conservé. ## S’authentifier auprès de l’API Les requêtes sont authentifiées par une clé d’API, qui identifie votre compte afin que nous puissions authentifier la requête et comptabiliser l’utilisation pour la facturation. Nous ne stockons chaque clé que sous forme de hash SHA-256 assorti d’un court préfixe d’affichage ; la clé complète est affichée une seule fois, à sa création, et n’est ensuite jamais récupérable auprès de nous. Les clés peuvent être révoquées à tout moment, et les révocations sont conservées comme piste d’audit. Les clés sont rattachées à un plan, qui régit les régions, les tailles de document et les volumes qu’elles peuvent utiliser. Une clé d’API est un identifiant d’utilisation, pas une porte vers vos données. Elle nous indique à quel compte appartient une requête afin que nous puissions l’autoriser et la comptabiliser sur votre plan, et c’est tout ce qu’elle fait. Il n’existe aucun endpoint qui liste, télécharge ou rejoue les documents que vous avez déjà traités, parce que nous ne les avons jamais stockés. Quelqu’un qui vole une clé peut consommer votre quota, ce pourquoi les clés peuvent être révoquées instantanément, mais il **ne peut atteindre aucun de vos documents**. La réponse à chaque requête est l’unique copie, et elle vous appartient. ## Infrastructure L’API s’exécute sur Amazon Web Services et Microsoft Azure, définie en infrastructure-as-code et déployée par un pipeline automatisé et revu. Propriétés clés : - **Isolation réseau.** Le traitement des documents s’exécute dans des réseaux privés isolés *sans accès sortant à Internet*, de sorte qu’il ne peut pas exfiltrer de données, même en principe. - **Protection en périphérie.** L’API est protégée par un pare-feu applicatif web avec rate limiting. - **Hôtes durcis et éphémères.** Le calcul s’exécute sur des images de base à jour et corrigées ; les disques des instances sont chiffrés et sont détruits lorsqu’une instance est retirée. - **La sécurité physique** des centres de données sous-jacents est héritée d’AWS et de Microsoft Azure, qui maintiennent des attestations SOC 2, ISO 27001 et PCI DSS pour leurs installations. ## Régions et résidence des données Vous choisissez le lieu de traitement de vos documents en vous adressant à un endpoint régional ; la requête est traitée entièrement au sein de cette juridiction et nulle part ailleurs. L’API est disponible dans les régions suivantes, chacune *stateless* et exécutant le catalogue complet des actions : | Région | Endpoint | | ----------------------------- | ----------------------- | | Global (routage par latence) | api.pdfblocks.com | | États-Unis | us.api.pdfblocks.com | | États-Unis (aligné sur HIPAA) | hipaa.api.pdfblocks.com | | Union européenne | eu.api.pdfblocks.com | | Royaume-Uni | uk.api.pdfblocks.com | | Canada | ca.api.pdfblocks.com | | Australie | au.api.pdfblocks.com | | Japon | jp.api.pdfblocks.com | | Inde | in.api.pdfblocks.com | | Brésil | br.api.pdfblocks.com | Comme le traitement est *stateless*, la résidence des données se résume à une seule décision : l’hôte auquel vous envoyez la requête. Les détails figurent dans notre documentation [Régions et résidence des données](/docs/api/regions-and-data-residency). L’endpoint aligné sur HIPAA est destiné aux flux de travail impliquant des informations de santé protégées, sous un Business Associate Agreement signé. Voir [HIPAA](/docs/trust/hipaa). ## Sécurité applicative et sécurité du développement - Chaque modification est versionnée, revue par un pair et fusionnée via une intégration continue qui exécute des tests automatisés unitaires, d’intégration et de contrat avant qu’un code puisse être livré. - Chaque commit est analysé par des outils de sécurité automatisés, analyse statique du code applicatif et audit des vulnérabilités des dépendances, et les mises à jour de dépendances sont proposées automatiquement puis revues. - Les déploiements s’authentifient avec des identifiants fédérés de courte durée (aucune clé cloud à longue durée de vie) et exigent une étape d’approbation humaine explicite pour atteindre la production. - Les livraisons font l’objet de contrôles de santé et sont annulées automatiquement si une nouvelle version échoue à son auto-test de disponibilité. ## Gestion des vulnérabilités et réponse aux incidents Les vulnérabilités sont identifiées en continu, par l’analyse des dépendances, l’analyse statique, les avis des fournisseurs et les signalements externes, triées par gravité et corrigées selon des délais définis, les problèmes critiques étant traités en quelques jours. Nous gérons les incidents de sécurité selon un plan documenté comportant des gravités et des étapes de réponse définies, et nous informons les clients concernés des incidents confirmés ou suspectés ayant un impact sur eux sans retard injustifié, conformément à notre [Avenant relatif au traitement des données](/docs/trust/dpa) et au droit applicable. ## Disponibilité et résilience - Dans chaque région, l’API fonctionne avec une capacité redondante répartie sur plusieurs zones de disponibilité, derrière des répartiteurs de charge soumis à des contrôles de santé, avec remplacement automatique de la capacité défaillante. - Les déploiements utilisent des mises à jour progressives avec annulation automatique, de sorte qu’une livraison ratée n’interrompt pas le service. - Comme l’API est *stateless*, la reprise n’est qu’une question de capacité saine, il n’y a aucune donnée de document à restaurer, et une perturbation dans une région n’affecte pas les autres. ## Journalisation et supervision Nous ne journalisons que les métadonnées de requête, à savoir l’action, le nombre d’octets, un hash de la clé d’API, le statut et l’horodatage, et **jamais** le contenu de vos documents. Les journaux masquent les identifiants et les jetons. Des métriques et des alarmes d’infrastructure surveillent les taux d’erreur, la latence et la santé des hôtes afin que nous puissions détecter et traiter rapidement les problèmes. ## Correspondance de nos contrôles avec les cadres courants L’API PDF Blocks est conçue pour s’aligner sur les critères qu’évaluent des cadres formels tels que SOC 2 et ISO 27001. Le tableau ci-dessous résume la correspondance entre nos contrôles et les Trust Services Criteria de SOC 2 ; nous nous ferons un plaisir de présenter à un évaluateur les preuves qui sous-tendent chacun d’eux. | Trust Services Criterion | Comment l’API PDF Blocks y répond | | --- | --- | | **Security** (critères communs) | TLS 1.3 en transit ; pare-feu applicatif web et rate limiting ; réseaux privés isolés sans accès sortant ; clés d’API stockées sous forme de hash ; accès au moindre privilège ; analyse automatisée des vulnérabilités. | | **Availability** | Capacité redondante répartie sur plusieurs zones de disponibilité, contrôles de santé, une API multirégion et des déploiements progressifs avec annulation automatique. | | **Confidentiality** | Documents traités en mémoire et jamais stockés ; chiffrement en transit ; segmentation réseau stricte ; obligations de confidentialité imposées au personnel et aux sous-traitants ultérieurs. | | **Processing Integrity** | Opérations déterministes sur les documents ; revue par les pairs, intégration continue et tests de contrat qui conditionnent chaque livraison ; gestion des changements avec déploiement automatique soumis à des contrôles de santé. | | **Privacy** | Aucune conservation des documents ; documents jamais partagés avec un sous-traitant ultérieur ; aucune utilisation des données clients pour entraîner une IA ; résidence des données sélectionnable par région. | ## Sous-traitants ultérieurs Le traitement des documents s’exécute sur Amazon Web Services et Microsoft Azure. Le contenu de vos documents **n’est partagé avec aucun sous-traitant ultérieur** : il est traité au sein de notre propre infrastructure, dans la région à laquelle vous vous adressez. La liste complète des sous-traitants ultérieurs, avec la finalité et la localisation de chaque prestataire, est tenue à jour sur notre page [Sous-traitants ultérieurs](/docs/trust/subprocessors). ## Documentation disponible sur demande Les clients et prospects du plan **Business** peuvent demander, sous accord de confidentialité mutuel, nos politiques de sécurité internes (Sécurité de l’information, Contrôle d’accès, Cryptographie, Protection et conservation des données, Gestion des vulnérabilités, Développement sécurisé, Réponse aux incidents et Continuité d’activité) ainsi qu’un questionnaire de sécurité complété. Écrivez à [security@pdfblocks.com](mailto:security@pdfblocks.com) pour commencer. ## Signaler une vulnérabilité Si vous pensez avoir trouvé une vulnérabilité de sécurité dans PDF Blocks, merci de la signaler à [security@pdfblocks.com](mailto:security@pdfblocks.com). Nous accueillons favorablement la divulgation coordonnée, nous accuserons réception de votre signalement et vous demandons de nous laisser une possibilité raisonnable de corriger avant toute divulgation publique. Nos coordonnées lisibles par machine sont publiées sur [/.well-known/security.txt](/.well-known/security.txt).