La sécurité chez Pleaxy

Pleaxy fonctionne sur Amazon Web Services, dans la région US East (Virginie du Nord). Le backend est sans serveur (Amazon API Gateway, AWS Lambda et Amazon DynamoDB), et l’application ainsi que ce site sont servis depuis Amazon S3 via Amazon CloudFront.

Chaque requête est soumise à une limite de débit applicable à l’ensemble de l’API, et les flux de factures ainsi que l’assistant intégré à l’application disposent de leurs propres limites par clé et quotidiennes pour contenir les abus.

• Les comptes sont gérés par Amazon Cognito. La connexion utilise le protocole Secure Remote Password (SRP) : votre mot de passe n’est donc jamais envoyé aux serveurs de Pleaxy ni stocké par eux.
• Les adresses e-mail sont vérifiées à l’inscription, et les mots de passe doivent comporter au moins 8 caractères, dont une majuscule, une minuscule et un chiffre.
• Tout utilisateur peut activer la validation en deux étapes avec une application d’authentification. Elle est facultative, non imposée, et nous ne proposons pas de codes par SMS.
• Tout utilisateur peut ajouter une clé d’accès (passkey) et se connecter avec son visage, son empreinte digitale ou le code PIN de son appareil. Une clé d’accès ne fonctionne que sur le site de Pleaxy lui-même : un site imitant celui-ci ne peut donc pas l’utiliser. Votre mot de passe continue de fonctionner en parallèle.
• Avec l’offre Enterprise, une entreprise peut configurer l’authentification unique avec son propre fournisseur d’identité : Okta, Microsoft Entra ID ou tout fournisseur SAML 2.0 ou OpenID Connect. Les administrateurs vérifient d’abord le domaine de messagerie de l’entreprise, peuvent imposer l’authentification unique à tous ceux qui l’utilisent et gardent des administrateurs d’accès d’urgence qui peuvent toujours se connecter avec un mot de passe.
• Le jeton d’accès de chaque requête API est vérifié cryptographiquement, et votre appartenance à l’espace de travail est revérifiée à chaque requête : lorsqu’un administrateur retire quelqu’un, cette personne perd l’accès à l’espace de travail dès sa requête suivante, et non à l’expiration de son jeton.
• Les clés API sont elles aussi révoquées automatiquement : lorsqu’un administrateur retire quelqu’un, ou fait passer son rôle d’Administrateur à un autre rôle, toutes les clés API que cette personne a créées dans l’espace de travail sont révoquées dans le cadre de la même modification, et l’administrateur qui effectue la modification est informé des clés révoquées.

Chaque entreprise travaille dans son propre espace de travail. Chaque enregistrement est stocké sous la clé de son espace de travail, et chaque requête est vérifiée côté serveur par rapport à l’appartenance de l’appelant à l’espace de travail avant toute lecture ou écriture de données. Deux éléments sont partagés par conception : les bons de commande et les factures sont visibles par les deux parties à la transaction, et les acheteurs qui invitent des fournisseurs peuvent trouver les profils de fournisseurs vérifiés (nom de l’entreprise, adresse e-mail de contact et noms des espaces de travail dans lesquels le fournisseur est actif).

Les espaces de travail acheteurs comportent six rôles achats (Administrateur, Lecture seule, Contrats et fournisseurs, Relations, Demandes d’achat et Finance), chacun accordant, pour chaque module, un accès nul, en lecture, en création ou en modification. Les autorisations sont appliquées par l’API, et pas seulement masquées dans l’interface. Les espaces de travail fournisseurs utilisent un modèle plus simple, avec un administrateur et des membres.

• Chaque étape de validation est attribuée à une personne précise, et seule cette personne peut la valider ou la refuser. Une étape à laquelle personne n’est attribué reste en attente jusqu’à ce qu’un administrateur y affecte quelqu’un.
• Une clé API ne peut jamais valider ni refuser une étape de validation. Elle ne peut pas non plus modifier les circuits de validation, les règles d’automatisation, les seuils de validation automatique ni les plafonds de dépenses : seule une personne connectée le peut. Une intégration peut émettre des bons de commande et des factures, mais la nécessité d’une validation humaine est déterminée uniquement par les règles que fixe votre équipe.
• Les bons de commande et les factures peuvent néanmoins être validés automatiquement si vos administrateurs activent des règles d’automatisation, ou si des administrateurs ou des utilisateurs Finance définissent un seuil de validation automatique. Ces validations sont enregistrées comme automatiques.
• Chaque validation, refus, réattribution ou étape ignorée est conservé dans l’historique des validations du document, avec son auteur (ou l’automatisation concernée) et sa date.
• Un demandeur ne peut valider sa propre demande que s’il est le seul valideur possible, et cette validation est enregistrée comme une auto-validation. Une entreprise ne peut pas émettre de bons de commande ou de factures à elle-même.

• Une facture qu’un acheteur saisit pour un fournisseur, à partir d’un PDF reçu par e-mail, d’un scan ou d’une copie papier, contient des coordonnées bancaires qui ne viennent pas du fournisseur. Elle est bloquée jusqu’à ce que le fournisseur la confirme dans Pleaxy, ou qu’un utilisateur de l’acheteur qui ne l’a pas saisie confirme les coordonnées bancaires avec le fournisseur par téléphone. D’ici là, elle ne peut être ni validée, ni payée, ni exportée pour paiement.
• Un fournisseur peut signaler qu’une facture n’est pas la sienne ou ne porte pas ses coordonnées bancaires. Une facture signalée reste bloquée définitivement.
• Quand une facture envoyée depuis le propre compte d’un fournisseur porte des coordonnées bancaires différentes de celles de sa dernière facture à cet acheteur, chaque administrateur du fournisseur est prévenu dans Pleaxy et par e-mail. L’e-mail n’indique que le mode de paiement, la banque et les quatre derniers caractères du compte, jamais le numéro complet.
• Depuis cette alerte, un administrateur du fournisseur peut bloquer en une seule étape le compte d’où vient la facture : il est déconnecté de tous ses appareils, les clés API qu’il a créées sont révoquées et la facture est signalée à l’acheteur. Si c’est une clé API qui a envoyé la facture, seule cette clé est révoquée. Chaque blocage est enregistré.
• Les coordonnées bancaires d’une facture que personne n’a confirmée ne servent jamais de référence pour comparer la suivante.

• Les clés API sont générées à partir de 32 octets aléatoires et affichées une seule fois. Nous ne stockons qu’une empreinte à clé (HMAC-SHA256), jamais la clé elle-même, et la comparons en temps constant.
• Chaque clé appartient à un seul espace de travail et à un seul rôle (les clés fournisseurs portent en outre des portées explicites) et peut être révoquée à tout moment. Seul un administrateur connecté peut créer ou révoquer des clés ; une clé ne peut pas en générer une autre. Les clés d’une personne sont révoquées automatiquement lorsqu’elle est retirée de l’espace de travail ou cesse d’être administrateur, et la réintégrer ne rétablit pas une clé révoquée.
• Le serveur MCP de Pleaxy, qui permet aux agents IA d’appeler Pleaxy, utilise la même API et la même clé à portée limitée. Il ne bénéficie d’aucun privilège supplémentaire.

• En transit : HTTPS uniquement. Le HTTP simple est redirigé, le stockage refuse les connexions non chiffrées, et les navigateurs sont invités à utiliser HTTPS à chaque visite (HSTS), en plus des en-têtes de sécurité standard d’AWS.
• Au repos : les bases de données, le stockage de fichiers, les files d’attente et les secrets sont tous chiffrés au moyen de clés gérées par AWS.

Les secrets applicatifs sont conservés dans AWS Secrets Manager et Systems Manager Parameter Store, jamais dans le code source ni dans la configuration de déploiement.

Chaque connexion de facturation cloud est en lecture seule, créée dans votre propre compte et révocable depuis votre propre console. Nous ne vous demandons jamais vos mots de passe ni vos clés d’accès cloud. Sur AWS, vous créez un rôle de facturation avec un External ID propre à la connexion, et Pleaxy endosse ce rôle. Google Cloud et Microsoft Azure utilisent une connexion fédérée : aucun secret n’est donc stocké. Pour Oracle Cloud Infrastructure (OCI), Pleaxy génère une clé de signature d’API pour la connexion et vous ne téléversez que sa clé publique ; la clé privée n’est stockée que chiffrée avec AWS KMS, et la suppression de la clé dans Oracle révoque l’accès. Les données de facturation déjà importées restent dans votre espace de travail jusqu’à leur suppression.

Les fournisseurs d’IA que vous connectez directement (OpenAI, Anthropic, Mistral, OpenRouter, Databricks, CoreWeave et Snowflake) utilisent une clé que vous créez dans leur console. Pleaxy la vérifie par une lecture avant de l’enregistrer, ne s’en sert que pour lire l’usage et les coûts, et la conserve uniquement chiffrée avec AWS KMS, liée à cette seule connexion ; ensuite, seuls ses quatre derniers caractères sont affichés. Pour Snowflake, Pleaxy génère une paire de clés et vous n’attribuez que la clé publique à un utilisateur de service. La déconnexion supprime la clé immédiatement, et la révoquer dans la console du fournisseur coupe aussi l’accès ; l’usage IA déjà importé reste dans l’historique.

Les limites de dépense chez un fournisseur sont optionnelles et utilisent un identifiant distinct que vous créez pour cela seul, jamais celui de la connexion en lecture seule : un rôle AWS limité aux budgets, un compte de service Google Cloud ou une application Azure fédérés comme la connexion, ou une autre clé d’administration OpenAI ou Anthropic, chiffrée de la même façon. Pleaxy le vérifie avant de l’enregistrer, et vous pouvez le retirer à tout moment.

Les formulaires fiscaux, attestations d’assurance et lettres bancaires sont conservés dans un espace de stockage privé et ne sont accessibles que par des liens signés à durée de vie courte. La suppression d’un document efface toutes ses versions stockées.

• L’assistant intégré à l’application fonctionne avec Claude d’Anthropic via Amazon Bedrock, appelé depuis notre propre compte AWS dans la région US East.
• Pleaxy ne conserve pas les transcriptions des conversations. Une action proposée par l’assistant est conservée brièvement pour que vous puissiez la confirmer.
• L’assistant agit en tant qu’utilisateur connecté, avec exactement ses autorisations. Les validations, les enregistrements de paiement, les résolutions d’écarts et les modifications de règles d’automatisation sont seulement proposés : une personne confirme chacun d’eux à l’aide d’un bouton. L’assistant peut également refuser un document, créer un bon de commande, transformer un bon de commande en facture, relancer le rapprochement d’une facture ou envoyer une relance sans étape de confirmation distincte ; il a pour consigne de ne le faire qu’à votre demande, vérifiez donc ce qu’il vous annonce avant d’agir.

• Une piste d’audit AWS CloudTrail couvrant l’ensemble du compte enregistre chaque appel à l’API de gestion d’AWS, avec validation de l’intégrité des fichiers journaux, conservée 365 jours dans un bucket dont la politique interdit la suppression. Toute modification de la piste ou de cette politique déclenche une alerte.
• Des alarmes automatiques surveillent les erreurs et la latence de l’API, les tâches en échec et les synchronisations de facturation en échec, avec un canal distinct pour les alertes de sécurité.
• Les bases de données de production bénéficient de la restauration à un instant donné et de la protection contre la suppression, et le stockage des documents est versionné.
• Les journaux d’accès à l’API sont conservés 30 jours et les journaux applicatifs 90 jours.

Si vous pensez avoir découvert un problème de sécurité dans Pleaxy, écrivez à support@pleaxy.ai en donnant les détails. Merci de nous laisser un délai raisonnable pour le corriger avant de le divulguer publiquement.

Le RGPD est une loi, et non une certification, et nous concevons Pleaxy pour s’y conformer. Pour les données que vous saisissez dans votre espace de travail (salariés, fournisseurs, bons de commande, factures et documents), vous êtes le responsable du traitement et Pleaxy est votre sous-traitant, agissant uniquement sur vos instructions. Pour les données de compte, de facturation et du site web, Pleaxy est le responsable du traitement.

• Accord de traitement des données (DPA) : écrivez-nous si vous en avez besoin. Il couvre la liste de nos sous-traitants ultérieurs, les mesures de sécurité décrites sur cette page et les clauses de transfert ci-dessous.
• Lieu de stockage des données : aux États-Unis (AWS US East). Les transferts de données personnelles de l’UE et du Royaume-Uni sont encadrés par les clauses contractuelles types de l’UE et l’addendum britannique (UK Addendum) prévus dans notre DPA.
• Vos droits : les demandes d’accès, de rectification et d’effacement sont traitées sur demande ; voir notre Politique de confidentialité.

Nous ne vendons pas d’informations personnelles et ne les « partageons » pas à des fins de publicité comportementale inter-contextes, au sens où le droit californien définit ces termes, et le site web de Pleaxy n’utilise aucun traceur publicitaire ou analytique.

Pleaxy ne traite jamais vos données de carte. Les paiements d’abonnement sont traités sur les pages hébergées par Stripe, et Stripe est un prestataire de services certifié PCI DSS niveau 1.