Security & data sovereignty
Your tax data is never hosted
Security questionnaires ask where your data is hosted. For a 2259-SD return prepared with Pilier2XML, the answer is: nowhere. Data entry, GIR XML generation, XSD validation and the DGFiP checks all run entirely in your browser. There is no database of returns, no transport of tax data, no server-side copy.
The central argument
“The question is not where your tax data is hosted — it is that it is never hosted at all.”
A tool that processes your returns “on its servers” — wherever they are — is still a tool your group's (or your clients') tax data transits to and is stored in. Pilier2XML's architecture removes that surface entirely: no transport, no multi-tenant database, no possible server-side leak.
The processing scheme, precisely
What stays in your browser
-
The complete 2259-SD return
Entity names, SIRENs, TINs, amounts, elections: stored in IndexedDB (localStorage mirror), on your machine only.
-
GIR XML generation
The GLOBE_OECD file is assembled in the browser from local data. Nothing is sent to a generation server.
-
XSD validation
Every file is revalidated against the official GLOBEXML 1.0 schema in the browser, before any filing.
-
DGFiP checks (Annexe 3)
The official check cartography runs locally; the PDF report is generated on your machine.
-
Encrypted backups
AES-256-GCM export, key derived from your password (PBKDF2). The file is written to your disk — never transmitted.
What our servers see — and nothing else
-
Your access code
Checked against the code database on each session. No account, no password, no user email address.
-
Random technical tokens
A device token (code-sharing limitation) and opaque filing identifiers (random UUIDs, for quota counting). No return content can be derived from them.
-
Sirene proxy requests
The SIREN queried to pre-fill the company name — public data from the French INSEE register, called server-to-server.
-
Interface wording
The application's UI strings (public text, no personal data), served like any static content.
The direct consequence for firms: your clients' returns cannot mix server-side, because there is no server side. Each machine holds only the engagements entered on it.
Technical measures — verifiable by your teams
Each of these points can be verified without taking our word for it: HTTP response headers, the Network tab of the browser devtools, the browser's local storage.
No network request to any third-party domain
The application's Content Security Policy enforces
connect-src 'self': the browser cannot address any
fetch/XHR request to another domain — the browser
itself would block it. Verifiable in the
Content-Security-Policy header of any application response. The only
third-party resources loaded: country-flag images (flagcdn.com), with no cookie or
identifier.
Zero third-party telemetry
The application embeds no analytics, no tracker, no third-party error-reporting service. The editorial site uses cookieless, self-hosted audience measurement. No consent banner is needed — because there is nothing to consent to.
Strict Content Security Policy
Scripts locked by a per-request nonce + strict-dynamic,
frame-ancestors 'none' (no iframe embedding),
object-src 'none', upgrade-insecure-requests. Session
cookies are httpOnly, secure, sameSite;
CSRF protection; per-IP rate limiting on sensitive endpoints.
End-to-end encrypted backups
Your exported returns are encrypted with AES-256-GCM, the key being derived from your password (PBKDF2). Encryption runs in the browser; the resulting file can be archived or restored on another machine with no server dependency.
Conformity to the official schema, locally
XSD validation against GLOBEXML 1.0 and DGFiP checks (Annexe 3) run on your machine, before filing — conformity never goes through a remote service.
Hosting providers and subprocessors — the real list
In full transparency, including where a questionnaire would tick “non-European provider”: none of these providers ever sees tax data, because it never leaves your browser.
| Service | Provider | Location | Data involved |
|---|---|---|---|
| Application and database (app.pilier2xml.com) | Railway (US company) | European Union — Amsterdam, Netherlands | Application server and PostgreSQL database: access codes, technical tokens, security logs. No tax data. |
| Editorial site (pilier2xml.com) | Cloudflare Pages (US company) | Global network (CDN) | Static editorial content only. No application data. |
| Access-request form | Web3Forms (form relay) | Transit to the publisher's mailbox | First name, last name, company, email — with your consent, deleted after processing. |
| Sirene register | INSEE (French public API) | France | Queried SIREN (public data), server-to-server. |
Detailed processing, legal bases and retention periods: privacy policy (in French).
What we do not claim
Pilier2XML holds, to date, no ANSSI certification, no CNIL label and no SecNumCloud qualification — and we do not pretend otherwise. Our position rests on an architectural choice — the absence of any server-side processing of tax data — whose every consequence is technically verifiable, not on a compliance logo. If your security review needs further elements, write to us: contact@decuma.fr.
A security questionnaire to fill in?
Our response sheet covers these points in question / answer format, ready to attach to your file.