Privacy Policy

PalmaPlan Privacy Policy

Version of 12/10/2026.

This page tells you what PalmaPlan knows about you, why, for how long, and what you can do about it. It is written to be read to the end: plainly, with no filler, and without promising anything the product does not actually do.

This is the English version of legal/confidentialite.md. Both are written, not translated word for word; where a legal term matters, the French version is the reference, because the controller is established in France.

Who is responsible

Xavier Baril, a private individual, in France. PalmaPlan is a one-person project.

Contact: contact@palmaplan.com — to exercise your rights, ask about this page, or report a security problem. One address, because one person reads it.

Where your data is. PalmaPlan is in beta, before version 1.0, and it is online at palmaplan.com. The service runs on a server rented from OVH, in a data centre in France. The mail it sends goes out through Scaleway, in Paris, and it is also with Scaleway, in Paris, that copies of our backups are deposited — encrypted before they leave the server. These are our two processors: they process your data on our behalf, under a contract that binds them to it, and section 6 says exactly what each of them sees. There is no analytics service and no advertising: nobody else processes your data for us. If you choose "Continue with Google", Google is involved too, on its own account (§ 8).

In short

We sell nothing, resell nothing, and run no advertising. There is nothing to monetise in your data; that would be a different product.
No trackers, no analytics, no third-party tools. Your browser contacts nobody but PalmaPlan. That is also why you have not seen a cookie banner.
No profiling, no automated decisions about you.
Your data is stored in the European Union — in France with OVH, in Paris with Scaleway —, and these two processors are the only ones that process it for us (§ 6).
You export everything with one button, and you delete your account with one button.
Deleting your account erases everything that identifies you — but what you wrote in other people's schedules stays, signed "Deleted user". We explain why in detail below: it is the most important part of this page.

1. What we collect, and why

Your account

Your email address, your name, and your password — of which we never keep the password itself, only a one-way fingerprint. If you chose "Continue with Google", we also keep the account identifier Google gives us. This is what lets you sign in and be recognised by the people you work with. Without it, there is no service.

Your sessions

When you sign in, your browser receives a cookie; we keep a fingerprint of it, the date, and the browser name your device reports, so that you can see and close your open sessions from your profile.

An email address belongs to whoever proves it

An account only truly holds its address once the address is proven: by the verification link received in the mailbox, by a "forgot password" link, or by Google certifying the address. So someone may have created an account at your address without proving it. The day you prove it, that account does not stay theirs:

if it is empty — no schedule, no access to someone else's schedule, no trace in a change log, no invitation, no comment, no token or agent, no absence, no report: nothing on the list written in our code —, it is erased, the way an account is erased (§ 5), and you start again with a new account at your address. Invitations that had been sent to that address stay yours: they belong to the address, not to the erased account;
otherwise, you take it over, with what it contains: its sessions are closed, its agents and tokens revoked, its Google link removed, and the old password is worth nothing — you choose one, or, if you go through Google, the account has no password at all and only your Google opens it. The screen tells you so when you arrive, and invites you to look at what the account contains if it was not yours.

The product already did this from 30/09/2026 through "forgot password" (taking the account over), without this page saying so; since 05/10/2026 it does it through all three routes, and erases the account when it is empty. If you create an account at an address that is not yours, know therefore that it may be erased, or taken over with what you put in it, by the person the address belongs to.

The verification link, opened anywhere other than in a session of the account, asks you for that account's password — or, if you do not know it because the account is not yours, has you choose one and takes the address as above. An account with no password (created through Google) has nothing to ask; within a session of the account, one click is enough.

What you put in your schedules

Rows, bars, dates, columns, notes, files you attach, comments you write. This is your content: we do not read it, we draw nothing from it, we store it to give it back to you — with one exception, which is yours alone to make: the snapshot you can attach to a bug report (see "Your reports and your ideas" below). If you put information about other people in it — a name on a task, say — that is your decision and your responsibility; we are only the means of storage.

The change log

Every change to a schedule is recorded: who, what, when. This is not surveillance, it is how the product works: it is what makes undo, history, going back to a past state, and seeing other people's edits live possible. Without this log, undo and history would not exist.

Sharing

When you are a member of a schedule, we keep your role, who invited you, and when. Other members of a schedule can see your name and email address in the member list: that is what a share between identified people requires.

Your absences

You can say when you will not be there: a period (leave from 4 to 22 August), a day or a half-day, or a day that comes back (every Friday, every other Friday). We keep the dates and a reason picked from a closed list — leave, part-time, training, other. There is no free text field, and never a medical reason: a planning tool does not need to know why you are away, only that you are, and health data has no business here.

The other members of the schedules you share can see your absences and their reason, as can the agents they have authorised: that is what they are for, seeing which work falls when someone is not there. Apart from them and the instance administrator, nobody sees them — not even someone whose schedule has a row in your name, if you are not a member of it. One exception, which only a schedule's owner decides: if they publish that schedule and tick “Show the absences calendar” (unticked by default), anyone with the link sees your display name and the dates you are away on that schedule — never the reason, never your email address, never your account identifier; unticking the box or unpublishing removes them at once. You change them whenever you like; the instance administrator can too, a schedule owner cannot. An absence moves nothing in a schedule: it flags a risk.

Invitations

When you invite someone by email, we keep their address for as long as the invitation lives. It is the address of someone who asked us for nothing: we use it only to send that invitation, never for anything else, and it is erased shortly afterwards. If you are that person and you want your address gone immediately, write to us — it is done the same day.

Notifications and the evening digest

We tell you what happened on your schedules while you were away, in the product and — if you want — in one summary message per day. These are service messages: they only report what happened on your own schedules, they offer nothing, and they are plain text with no images and no tracking links — we do not know whether you open them. You can turn the digest off in your preferences. These messages, like invitations and verification or reset links, go out through our mail provider, Scaleway (§ 6).

Agents you authorise

PalmaPlan can be driven by an agent — an assistant, a script, an MCP client. If you authorise one, we keep what is needed to recognise it and a record of what it wrote in your schedules. Authorising an agent means showing it your schedules: what it does with them is no longer up to us, and you can revoke its access at any time from your preferences.

Your reports and your ideas

When something does not work, you can report it from the screen: "Report a problem", in your account menu, in the editor's menu, or under an error message. When an idea comes to you, you can suggest it: "Suggest an idea", in your account menu and in "My reports and ideas". It is the same form, which opens on a choice: "Report a bug" or "Suggest an idea". It is something you choose to do; nothing is sent without it.

For a bug, we keep what you write — what happened, what you expected, the severity you pick — and a context captured by the screen, which the form shows you in full before you send it: the PalmaPlan version, the address of the screen (stripped of the secrets an address can carry), the identifier of the open schedule — not its contents —, your browser and language, the last errors shown (their code and message) and the types of your last changes to that schedule, without their labels. Nothing else: the server rejects any field this list does not name.

A separate box, unticked by default, lets you attach a snapshot of the open schedule as it stands when you send: some problems only reproduce with the data. Without that box, only the schedule's identifier is sent. If you tick it, the server takes the copy itself, and only of a schedule you can read; it may therefore contain what other members wrote in it. It is kept with the report so that the problem can be reproduced; the administration screen does not display it.

For an idea, we keep what you write — your idea, and what it would bring you — and a reduced context, also shown before you send it: the PalmaPlan version, the address of the screen (stripped of its secrets) and your language. Not the open schedule, not your browser, not your errors, not your changes, and never a snapshot: an idea is not reproduced, and the contents of a schedule do not help to understand it — even if the box arrived ticked, the server ignores it. The form does not ask you for a severity for an idea: it sends "annoying" by default, kept with it.

What they are for. A report is for fixing defects in the service. An idea is for collecting your suggestions, to decide what PalmaPlan does next: it is read, and it may be classified — the part of the product it touches, a rough size of the effort, the other ideas it joins. This second purpose is new on 05/10/2026 (see § 11). Both rest on our legitimate interest: a service that works, and that evolves with what the people using it ask for. Nothing else: no usage statistics, no profiling, no marketing. Who reads them: the instance administrator, and nobody else — together with your name and email address, to know who the report or idea comes from. The administrator can publish a reply, which you find, with the type and status of each, in your preferences under "My reports and ideas". An account can send ten in any twenty-four-hour period, bugs and ideas together.

The server's technical log

So that the service runs and a failure can be understood, the server records what it is asked: the method, the path (stripped of the secrets it can carry), the time. It also records certain actions, with the technical identifier of the account concerned: a session closed because an account had too many open (with the reported browser), what was done when an address was proven by its owner while another account held it (the identifiers of both accounts, never the address), the sending of the evening digest, an account disabled or re-enabled by the instance administrator. The messages the service sends — an invitation, a reset link, the evening digest — go out through its mail service and are not written to this log. It does not record your IP address — the mechanism that slows down sign-in attempts keeps it in memory for a few minutes and never writes it anywhere. It never records a password, nor the content of what you send.

In front of the service, the web server that receives connections keeps its own access log: it records the IP address of each request, with the requested path stripped of its secrets. It rotates, and its retention is in § 3.

Backups

A complete copy of the database is made every day and the last fourteen are kept on the server, so that nobody loses their work to a crash. A copy of each is deposited off the server, with Scaleway, in Paris, encrypted before it leaves with a key Scaleway does not have: it keeps files it cannot read. And our host, OVH, takes on its own side a daily copy of the whole server, which it keeps for twenty-four hours, and which is not encrypted.

2. What we do not do

No advertising, no ad partners, no advertising identifiers.
No selling, renting or sharing of your data with anyone.
No analytics, no heatmaps, no session recording.
No third-party trackers, no fonts or scripts loaded from another domain. The application is served entirely by PalmaPlan.
No profiling and no automated decision-making about you: what an agent does, you asked it to do.
No reading of your schedules to train a model, improve the product or produce statistics. They are stored, not mined. The only copy of a schedule outside that rule is the snapshot you attach yourself to a bug report, kept to fix the problem you report; an idea never carries one.
No report or idea passed on to anyone. What you report or suggest stays on the instance, and only its administrator reads it.
No transfer of your data outside the European Union, with one reservation, which we would rather write down: our host can access the server remotely, for its security and maintenance, and its list of sub-processors names two companies of its group established in Canada and the United Kingdom — two countries the European Commission recognises as providing adequate protection (§ 6). And if you choose "Continue with Google", you sign in with a company whose group is established outside the Union (§ 8).

3. How long we keep what

This is the complete list, in order. It is the same table as the one in legal/retentions.md in our code repository, where every duration is listed next to the piece of program that enforces it: we would rather give you a duration you can verify than one we merely announce.

Data	Retention
Your account: email address, name, password fingerprint, link to a Google account	As long as the account exists. On account deletion, all of this is erased immediately; only an empty technical identifier remains, with no time limit
Your open sessions: the cookie fingerprint, the reported browser, the dates	30 days after last use, on a rolling basis; erased on sign-out, on password change, on account deletion, and when the person the account's address belongs to proves it and takes the account over
The `palmaplan_session` cookie on your device	30 days
The `palmaplan_google` cookie, for the round trip to Google	10 minutes
The `palmaplan_public` cookie, for unlocking a password-protected published schedule	24 hours
A schedule's contents: rows, bars, columns, notes, attached files	As long as the schedule exists; 30 days after it is moved to the bin
A schedule's change log: who did what, when	The life of the schedule — 30 days after it is moved to the bin. Deleting your account does not erase it: it removes your name from it
A schedule's daily versions	30 days; the most recent one is kept whatever its age, and a version you have named stays for the life of the schedule
The comments, replies and actions you wrote in a schedule	The life of the schedule; your name is removed from them when you delete your account
Your access to other people's schedules: the role, who invited you, when	As long as the access lasts; erased when the owner revokes it and on account deletion
Your display and mail preferences	As long as the account exists; erased on account deletion
Your absences: the periods, half-days and recurring days you set, with their reason (leave, part-time, training, other)	30 days after their last day; a recurring absence with no end date, as long as the account exists; all of them are erased on account deletion
Your reports and your ideas: the type (bug or idea), what happened or your idea, what you expected or what it would bring you, the severity, the captured context (version, screen without address secrets, schedule identifier, browser, language, last errors, types of the last commands — for an idea, the version, the screen and the language only), the schedule snapshot if you allowed it (never for an idea), and what was done about them (status, published reply, conclusion and decision)	90 days after the report or idea is closed; while it is open, no time limit; all of them are erased on account deletion
Your read notifications	30 days
Your unread notifications	1 year
An invitation, and the invited email address	7 days to be accepted; the record is erased 30 days after it is accepted, expires or is revoked
A password reset request	The link is valid for 1 hour; the record is erased after 24 hours
An email verification request	The link is valid for 24 hours; the record is erased after 7 days
An email-change request, and the address requested	The link is valid for 24 hours; the record is erased after 7 days
An account that was never verified: its email, its password, everything it holds	Seven days after it was created, the same as the verification record itself; an account verified in time, even barely, is never targeted, nor one that has access to a schedule or that a schedule's history names — that of a person invited who has not yet confirmed their address. And sooner, if the person the address belongs to proves it: erased at once if it is empty, otherwise taken over by them with what it contains
An invitation code, and who created it	No time limit while it remains open; erased 30 days after it is revoked or fully used
Your named tokens: the label, the secret's fingerprint, the scopes, the dates	As long as the account exists, revoked or not — the list of your tokens is your own history and stays readable in your preferences; everything is erased on account deletion
Agents you authorised through OAuth: the client and its refresh tokens	An access token lasts 30 days, a refresh token 90 days; traces of an unused agent are erased 90 days after its last use, and everything goes on account deletion
OAuth authorisation codes	10 minutes
The public link of a published schedule	As long as publication lasts; the record is removed on unpublishing, and republishing draws a new link
The server's technical log	At most 30 MB, which is a few days of operation; it no longer carries IP addresses
The web server's access log, which carries IP addresses	7 days at most, by rotation
Daily database backups	14 days — fourteen rotating copies
Copies of those backups deposited off the machine, encrypted	14 days, like the local ones; the bucket that receives them, at Scaleway, erases on its own any file older than 15 days
The list of deleted accounts: a technical identifier and a date, kept outside the database	No time limit — it is what makes a deletion effective after a backup is restored

4. Your rights, and how to use them

In your profile, under Your data:

See what we hold: the list by category, each with its retention.
Export everything: one button, one file. It contains your account, your preferences, your sessions, your tokens, the agents you authorised, your access rights, the schedules you own in PalmaPlan's exchange format — re-importable as they are, elsewhere —, your comments, your notifications, your invitations, your entries in the change log, in plain language, your absences, and your reports and your ideas — each with its type (bug or idea), the captured context, its status, the published reply and, where there is one, the conclusion recorded about it (its kind and its summary) and the administrator's decision. An idea's classification (the part of the product, the effort, the ideas it joins) is not included: it is internal analysis, like a bug's. The snapshot of a schedule you may have attached is not included: it is a copy of a schedule, perhaps someone else's; the export only says that you attached it, and when. It does not contain password fingerprints or token secrets — they would teach you nothing and teach everything to whoever stole the file — nor other people's schedules, which are their data and not yours.
Delete your account: one button, and section 5 says exactly what happens.

Under Profile: correct your name and email address, whenever you like.

In writing, to contact@palmaplan.com: restriction of processing, objection to processing, or anything the buttons do not cover. We answer within one month. We built no interface for those two rights because an interface that only pretended would be worse than an email that reaches a real person.

You may lodge a complaint with the French data protection authority, the CNIL (3 place de Fontenoy, TSA 80715, 75334 Paris Cedex 07, cnil.fr), which is the competent authority since the controller is established in France. If you live or work in another EU or EEA country, you may also lodge your complaint with your own national authority. That is your right, and we have no objection to it.

5. Deleting your account: what goes, what stays, and why

This is the part of the page to read before you sign up, not after. We say it plainly, because you should be able to disagree at the point of choosing.

What is erased, immediately

Your email address, your name, your password fingerprint, the link to your Google account. Your sessions, your tokens, the agents you had authorised. Your notifications, your preferences, your access to other people's schedules, your absences, your reports and your ideas — in full, snapshot included. The invitations you sent that were never accepted — they carry somebody else's address, and nothing justifies keeping them — and those addressed to you. And the pending links that carry an address: an email verification link, an email-change request you had not confirmed. After that, PalmaPlan holds no data that identifies you, and has no way left of knowing who you were.

What stays

A technical identifier, and what you wrote in other people's schedules: the change log entries, your comments, your replies, the actions you were responsible for. Everywhere your name used to appear, it now reads "Deleted user".

Why

Because the change log is not a trail we keep out of caution: it is how the product works. Undo replays changes backwards; history and date comparison replay them forwards. Erasing your entries from a shared schedule would not remove a trail — it would break other people's schedules, make their undo inconsistent, and stop them going back to a past state. We chose to protect their work by removing your identity rather than destroying theirs.

What we do not claim

We do not claim that the result is anonymisation in the full legal sense: an identifier remains, and what you wrote remains. Someone holding information from elsewhere could, in theory, make a connection. What we do claim is narrower and verifiable: on our side, the link is broken, and irreversibly so.

That is our position, resting on data minimisation and on the legitimate interest in preserving the integrity of other people's schedules — which overlaps with the exception the Regulation provides where erasure would harm the rights of others. We believe it is the right call; it is arguable, and you are entitled to argue it. Write to us.

If you really want everything gone

The owner of a schedule can delete it entirely, and its change log goes with it thirty days later. So if the entries that trouble you are in a schedule you own, you have the means to make them all disappear. If they are in someone else's schedule, the fate of that schedule is theirs to decide.

If you own schedules

We refuse to delete your account while you still own a schedule — a schedule with no owner has nobody left to manage its access. The screen tells you which ones and offers you both paths: transfer them to a member, or delete them. Schedules in the bin still count as owned, and you can empty them at once rather than waiting thirty days. You are never held back: deleting is always possible.

Backups

Deletion is immediate in the service and effective in the backups within fourteen days, the time it takes for the daily copies to rotate — ours on the server as well as the encrypted ones deposited with Scaleway, which the bucket receiving them erases after fifteen days in any case. The copy of the whole server that our host keeps disappears within twenty-four hours. If we ever had to restore a backup, we replay the deletions made since, before putting the service back online: that is a step written into our internal procedure, not an intention.

Before you go

The last screen offers to export your data. We do not send people away empty-handed.

6. Who can see your data

You, and the author of PalmaPlan, who administers the instance.
Other members of a shared schedule: your name, your email address in the member list, what you write in the schedule, and your absences with their reason.
Anyone an owner gives the link of a published schedule to. A published schedule shows the schedule, its comments and the technical identifiers of their authors. It shows neither names nor email addresses — unless the owner has ticked “Show the absences calendar”: the link then also shows the members' display names and the dates they are away, never the reason, the email address or the account identifier. Publishing is a deliberate act by the owner, revocable at any time, and the link can be password-protected.
The agents you authorised, within the rights you gave them.
Your reports and your ideas: the instance administrator alone. Neither the members of your schedules, nor a public link, nor the agents you authorised can see them, and none is passed on to a third party.
Our two processors, OVH and Scaleway, each for what it does for us, detailed below.
Nobody else. No analytics tool, no advertising provider, no other provider. A new processor would be named here, with what it processes and where its servers are, before it goes into service.
And if there were a legal obligation to disclose something to an authority, we would comply; it has never happened.

Our processors

A processor processes your data on our behalf, on our instructions, without doing anything with it for itself. Both of ours are bound by a data processing agreement — an annex to their contract, which we accepted before going live — that commits them to confidentiality, to security, to helping us answer your requests, and to notifying us of a data breach.

OVH SAS (head office in Roubaix, France), our host. The whole service runs on a server it rents to us, in a data centre in France chosen when ordering, which it undertakes not to move without our agreement. It therefore holds everything: the database, our fourteen daily backups, the server's logs. That server's disk is not encrypted (§ 9): OVH technically has access to your data, and it is its contract that prevents it, not technology. It can access the server remotely, for its security and maintenance, including from two companies of its group in Canada and the United Kingdom, two countries recognised as adequate by the European Commission; its contract also commits it to oppose requests from third-country authorities. Finally, it keeps on its own a daily copy of the whole server, for twenty-four hours.

Scaleway SAS (head office in Paris), for mail. The messages PalmaPlan sends — invitations, verification and reset links, the evening digest — go out through its transactional email service, which exists in Paris only. It therefore sees the recipient's address — including that of an invited person who has no account — and the content of the message. It does not archive messages: they are transmitted, then deleted. It does keep, for each send, the sender, the recipient, the subject and the delivery outcome, for a period its documentation does not set; this page will state it as soon as we have obtained it from them. No open or click tracking feature is documented for this service, and our messages carry no image and no tracking link.

Scaleway SAS, for backup copies. A copy of each daily backup is deposited in a private storage space, in Paris, encrypted on our server before it leaves, with a key Scaleway does not have: it keeps files it cannot read. These copies rotate with ours, and the space that receives them erases on its own any file older than fifteen days.

The certificate that encrypts your exchanges with palmaplan.com comes from a certificate authority, Let's Encrypt, which sees only a domain name — no data about you: it is not a processor.

7. Cookies: there are three, and there is no banner

PalmaPlan sets three cookies, and not one more. All three are HttpOnly — a script cannot read them — and scoped to PalmaPlan.

Cookie	What it does	Duration
`palmaplan_session`	Keeps you signed in from one page to the next	30 days
`palmaplan_google`	Holds the round trip to Google when you choose that button, and only then	10 minutes
`palmaplan_public`	Remembers that you gave the password of a protected published schedule — when that schedule is embedded in another site's page, this cookie is kept apart for that site (partitioned) and is of no use anywhere else	24 hours

No trackers. No analytics. No cookies from another site. No advertising.

And that is why there is no banner. Cookies strictly necessary to provide a service you explicitly asked for are exempt from consent — this is what Article 82 of the French Data Protection Act provides, transposing the European directive on privacy in electronic communications, and it is the reading the CNIL follows in its guidelines on trackers. Our three cookies are exactly that: without them you cannot stay signed in, sign in with Google, or open a protected schedule.

A banner would therefore have nothing to ask you. We would rather tell you why there isn't one than show you one to look serious. And if we ever considered analytics, it would come with a real choice, or it would not come at all.

8. "Continue with Google"

This option is optional, and it is offered on palmaplan.com, on the sign-in page as well as the sign-up page. Before you click:

Google is not our processor: it is a separate company, whose group is established outside the European Union, which signs you in on its own account, under its own rules and its own privacy policy;
you sign in at Google, on Google's site; we never see your Google password;
Google passes us four things: an account identifier, your email address, whether it is verified, and your name. Nothing else, and we ask for nothing else;
Google learns that you use PalmaPlan, simply because you went through it. That is true of every site offering this button. If that bothers you, create an account with an email address and a password: the product is identical;
you can unlink your Google account at any time from your profile;
Google's screen shows, for PalmaPlan, a support address, palmaplan-assistance@googlegroups.com: its messages reach the same person as contact@palmaplan.com, which remains the address for exercising your rights.

9. Security: what we do, and what we do not promise

What we do:

your password is never stored, only a fingerprint computed by a deliberately slow function built for the purpose (scrypt), with a different salt for each one;
no secret — session, token, invitation link, reset link — is stored in the clear: only a fingerprint is, and a token is shown to you once;
cookies are HttpOnly and Secure, and palmaplan.com is served over HTTPS, with a TLS certificate (Let's Encrypt): your exchanges with the service are encrypted in transit;
access rights are checked on every request, before anything is read;
sign-in attempts are rate-limited without your IP address being stored — and a verification link followed outside a session of the account, which asks for its password, counts against the same limit;
one backup per day, fourteen days of history, and a copy of each off the server, encrypted (AES-256-GCM) before leaving it, with a key kept elsewhere than with the provider that stores it;
and we have a written procedure for a data breach, with the deadlines the law imposes: we notify the CNIL within 72 hours from the moment we learn of it — including when it is one of our processors that tells us, which their contracts provide for "without undue delay", with no number of hours — and, if the risk to you is high, we notify you.

What we do not promise:

the database is not encrypted at rest, nor is the server disk that holds it: our contract with OVH leaves that encryption to us, and it is not in place. The same goes for the fourteen backups kept on that server and for the twenty-four-hour copy our host keeps; only the copies deposited with Scaleway are encrypted;
the server has no particular security qualification: it is not SecNumCloud-qualified;
PalmaPlan is a beta, run by one person, on one server, with no availability commitment. If that does not suit your data, that is a legitimate reason to wait for version 1.0 — and we would rather write it down than let you believe otherwise.

10. Children

PalmaPlan is a project planning tool meant for professional use. It is not designed for children, and we do not knowingly collect data from anyone under 15. If that happened, write to us and the account will be deleted.

11. Changes to this page

This page is versioned with PalmaPlan's code, in legal/confidentialite.en.md in the repository. Every change is therefore a dated, readable record: you can see what changed, when, and next to which change in the product. We do not rewrite the past.

A change that alters what we do with your data — a new provider, a new purpose, a longer retention — is announced in the product, not just published here.

What changed on 12/10/2026, with palmaplan.com going live: where your data is (at the top of this page) — on an OVH server in France, no longer on the author's machine; our two processors, OVH and Scaleway, named with what they process and where (§ 6, "Our processors"); the reservation about our host's remote access (§ 2); "Continue with Google", now offered (§ 8); mail, which goes out through Scaleway and is no longer written to the server log (§ 1); the web server's access log, which now exists (§ 1 and § 3); the backup copies deposited off the server, encrypted, and the copy our host keeps (§ 1, § 3 and § 5); what we do and do not promise on security (§ 9). This page had promised to name a host before it went into service: it does so in the very commit that puts the service online.

A new purpose, on 05/10/2026: collecting your suggestions. From that day, you can suggest an idea from the screen, and we keep it to decide what PalmaPlan does next — which is not fixing a defect, and which this page did not say. What we keep of it, for how long and who reads it: § 1 ("Your reports and your ideas"), § 3, § 4, § 5 and § 6. Nothing sent before that day changes purpose: a report received before it remains a bug report.

What changed a second time on 05/10/2026, with version 0.27.0: ideas — a new purpose, collecting your suggestions, announced above — and what we keep of them (§1 "Your reports and your ideas", §2, §3, §4, §5 and §6); an email address belongs to whoever proves it — the account created at your address without proving it, erased or taken over when you prove it, and the password that the verification link asks for when opened outside a session of the account (§1, §3 and §9); what the server's technical log really carries, which this page described too briefly (§1).

What changed on 05/10/2026: reports — what we keep and why (§1, "Your reports"), the exception of the snapshot you attach yourself (§1 and §2), their retention (§3), the export (§4), deletion (§5), and who can see them (§6). The version of 03/10/2026 still carried the date 02/10/2026 here: that is corrected.

Date of this version: 12/10/2026.

Contact

contact@palmaplan.com — for your rights, your questions, and to report a security problem. Write in French or in English.