Sécurité & souveraineté des données
Vos données fiscales ne sont jamais hébergées
Les questionnaires sécurité demandent où sont hébergées vos données. Pour la liasse 2259-SD établie avec Pilier2XML, la réponse est : nulle part. La saisie, la génération du fichier XML GIR, la validation XSD et les contrôles DGFiP s'exécutent intégralement dans votre navigateur. Il n'existe ni base de données de liasses, ni transport de données fiscales, ni copie serveur.
L'argument central
« La question n'est pas de savoir où sont hébergées vos données fiscales — c'est qu'elles ne sont jamais hébergées. »
Un outil qui traite vos liasses « sur ses serveurs, en France » reste un outil vers lequel la donnée fiscale de votre groupe — ou de vos clients — transite et est stockée. L'architecture de Pilier2XML supprime cette surface : pas de transport, pas de base multi-tenant, pas de fuite possible côté serveur.
Le schéma de traitement, précisément
Ce qui reste dans votre navigateur
-
La liasse 2259-SD complète
Dénominations, SIREN, NIF, montants, options et élections : stockés dans IndexedDB (copie localStorage), sur votre poste uniquement.
-
La génération du fichier XML GIR
Le fichier GLOBE_OECD est assemblé dans le navigateur, à partir des données locales. Aucun envoi vers un serveur de génération.
-
La validation XSD
Chaque fichier est revalidé contre le schéma officiel GLOBEXML 1.0 dans le navigateur, avant tout dépôt.
-
Les contrôles DGFiP (Annexe 3)
La cartographie officielle des contrôles est exécutée en local ; le rapport PDF est généré sur votre poste.
-
Les sauvegardes chiffrées
Export AES-256-GCM, clé dérivée de votre mot de passe (PBKDF2). Le fichier est écrit sur votre disque — jamais transmis.
Ce que voient nos serveurs — et rien d'autre
-
Votre code d'accès
Vérifié à chaque session contre la base des codes. Aucun compte, aucun mot de passe, aucune adresse email d'utilisateur.
-
Des jetons techniques aléatoires
Un jeton d'appareil (limitation du partage de code) et des identifiants de liasse opaques (UUID aléatoires, pour le décompte du quota). Aucun contenu de liasse ne peut en être déduit.
-
Les requêtes au proxy Sirene
Le SIREN interrogé pour pré-remplir la dénomination — une donnée publique du répertoire INSEE, appelée de serveur à serveur.
-
Les libellés de l'interface
Les textes de l'application (chaînes publiques, sans donnée personnelle), servis comme n'importe quel contenu statique.
Conséquence directe pour les cabinets : les liasses de vos clients ne peuvent pas se mélanger côté serveur, puisqu'il n'y a pas de côté serveur. Chaque poste ne détient que les dossiers qui y ont été saisis.
Mesures techniques — vérifiables par vos équipes
Chacun de ces points se vérifie sans nous croire sur parole : en-têtes de réponse HTTP, onglet Réseau des outils de développement, stockage local du navigateur.
Aucune requête réseau vers un domaine tiers
La politique de sécurité de contenu de l'application impose
connect-src 'self' : le navigateur ne peut adresser aucune requête
fetch/XHR à un autre domaine — c'est le navigateur lui-même
qui la bloquerait. Vérifiable dans l'en-tête
Content-Security-Policy de toute réponse de l'application. Seules
ressources tierces chargées : les images de drapeaux (flagcdn.com), sans cookie
ni identifiant.
Zéro télémétrie tierce
L'application n'embarque aucun outil de mesure d'audience, aucun traceur, aucun service de remontée d'erreurs tiers. Le site éditorial utilise une mesure d'audience sans cookie, auto-hébergée. Aucun bandeau de consentement n'est nécessaire — parce qu'il n'y a rien à consentir.
Politique de sécurité de contenu stricte
Scripts verrouillés par nonce par requête + strict-dynamic,
frame-ancestors 'none' (pas d'intégration en iframe),
object-src 'none', upgrade-insecure-requests. Cookies de
session httpOnly, secure, sameSite ;
protection CSRF ; limitation de débit par IP sur les points d'entrée sensibles.
Sauvegardes chiffrées de bout en bout
L'export de vos liasses est chiffré en AES-256-GCM, la clé étant dérivée de votre mot de passe (PBKDF2). Le chiffrement s'exécute dans le navigateur ; le fichier produit est archivable ou restaurable sur un autre poste sans dépendance serveur.
Conformité au schéma officiel, en local
Validation XSD contre GLOBEXML 1.0 et contrôles DGFiP (Annexe 3) exécutés sur votre poste, avant dépôt — la conformité ne passe pas par un service distant.
Hébergeurs et sous-traitants — la liste réelle
Par transparence, y compris là où un questionnaire cocherait « prestataire non européen » : aucun de ces prestataires ne voit de donnée fiscale, puisque celle-ci ne quitte pas votre navigateur.
| Service | Prestataire | Localisation | Données concernées |
|---|---|---|---|
| Application et base de données (app.pilier2xml.com) | Railway (société américaine) | Union européenne — Amsterdam, Pays-Bas | Serveur applicatif et base PostgreSQL : codes d'accès, jetons techniques, journaux de sécurité. Aucune donnée fiscale. |
| Site éditorial (pilier2xml.com) | Cloudflare Pages (société américaine) | Réseau mondial (CDN) | Contenu éditorial statique uniquement. Aucune donnée applicative. |
| Formulaire de demande d'accès | Web3Forms (relais de formulaire) | Transit vers la messagerie de l'éditeur | Prénom, nom, société, email — avec votre consentement, supprimés après traitement. |
| Répertoire Sirene | INSEE (API publique française) | France | SIREN interrogé (donnée publique), de serveur à serveur. |
Détail des traitements, bases légales et durées de conservation : politique de confidentialité.
Ce que nous ne revendiquons pas
Pilier2XML ne détient à ce jour ni certification ANSSI, ni label CNIL, ni qualification SecNumCloud, et nous ne prétendons pas le contraire. Notre position repose sur un choix d'architecture — l'absence de traitement serveur des données fiscales — dont chaque conséquence est vérifiable techniquement, pas sur un logo de conformité. Si votre revue sécurité exige des éléments complémentaires, écrivez-nous : contact@decuma.fr.
Un questionnaire sécurité à remplir ?
Notre fiche de réponse reprend ces éléments en format question / réponse, prête à joindre à votre dossier.