Privacy
Read this first
This document is not legal advice. It was written by the team that writes the product, from what the code actually does, and it must be reviewed by a lawyer before any payment is taken.
It is published anyway because a verified, provisional text is worth more than a contract template describing some other product.
Last updated: 25 September 2026.
Controller
This page carries the information required by articles 13 and 14 of regulation (EU) 2016/679, the GDPR: which data is processed, why, on what basis, for how long, who it is entrusted to, and how to exercise your rights.
The controller is Joffrey Herard, Sole proprietor (French “micro-entreprise”), whose head office is at Maison L, 34 rue de Solférino, 51100 Reims, France. Any request about your data can be addressed to [email protected]. The full identity is in the legal notice.
No data protection officer has been appointed: the activity falls under none of the cases where article 37 of the GDPR makes it mandatory — not a public body, no large-scale systematic monitoring, no large-scale processing of sensitive data. It is therefore not an oversight, and the publisher answers in person.
What your organisation puts in, and who decides
A distinction better stated than guessed at. For your account — the email address that identifies you, your display name, your language — the publisher is the controller, and answers for the paragraphs below.
For what an organisation puts into the product, the organisation decides: it chooses what it writes there, including people records carrying the name and email address of people who have no account here and were never asked. The publisher then merely hosts and runs the tool on its behalf.
What is collected
Your account
Email address, display name, Argon2 hash of the password, language, and the date the account was created. Nothing else: no phone number, no postal address, no date of birth, no photograph.
Your work
Whatever your organisation puts into the tool: swimlanes, milestones, tasks, tags, people records, links between tasks. That data belongs to the organisation. A person record may carry a name and an email address typed by a colleague, for someone who has no account.
Invitations
Inviting someone into an organisation records their email address, the role offered to them and the date. That person has no account here yet, and this is the only data Jalon holds about them: no name, nothing else. It is used to check the link they received and to show the list of pending invitations.
Technical traces
IP addresses are used only to rate-limit the public authentication and invitation routes. They are counted in the database, alongside the number of calls and nothing else, and erased at the latest three hours after the last counted call.
The audit log keeps five facts and five only: successful sign-in, role change, removal of a member by an administrator, ownership transfer, organisation deletion. It contains no IP address. Failed sign-ins are not recorded.
Why, and on what basis
Each block below describes one processing operation: the data involved, what it is for, the legal basis under article 6 of the GDPR that allows it, and how long it stays.
Your account
Email address, display name, password hash, language, creation date. Purpose: opening your account and running it. Legal basis: performance of the contract between you and the publisher — without this data there is no account. Retention: until the account is deleted.
Your organisation’s work
Swimlanes, milestones, tasks, labels, people records, links between tasks. Purpose: providing the service the organisation asked for. Retention: as long as the organisation exists, and it can erase part or all of it at any time.
The legal basis splits in two here, and saying so is better than announcing only one. What the publisher does with this data — hosting it, serving it, backing it up — rests on the contract with the organisation and on that organisation’s instructions alone: nothing else is done with it, and it is used neither for the publisher’s own purposes nor to train anything.
But towards the people described, it is the organisation that picks the basis, because the organisation is the controller: performance of the contract for its own members, who have an account here and know what they are doing with it. And its legitimate interest for a people record describing someone with no account — that person has no contract with either the organisation or the publisher, and provided nothing themselves, so it falls to the organisation to be able to justify the processing, to inform that person under article 14 of the GDPR, and to receive their objection if they raise one.
The audit log
Five facts, and five only: successful sign-in, role change, removal of a member by an administrator, ownership transfer, organisation deletion. Purpose: letting an organisation know who did what to its access, and letting the publisher handle a security incident. Legal basis: the legitimate interest of the publisher and of the organisation in the security of the service. Retention: six months for sign-ins, twelve months for the four organisation events.
Rate limiting by IP address
The IP addresses calling the public authentication and invitation routes. Purpose: preventing passwords being tried in bulk or invitations being flooded. Legal basis: the legitimate interest in the security of the service. Retention: three hours at most after the last counted call — the counter is kept in the database, so that a redeployment does not reset it, and then erased.
Service emails
Your email address and the content of the message sent: password reset, invitation, task assignment, daily report, weekly report. Purpose: running the account and the tool. Legal basis: performance of the contract. No newsletter and no marketing is ever sent.
Subscription and payment
For an organisation that subscribes to the Pro plan: its Stripe customer and subscription identifiers, its plan, the state of its subscription, the end of its current period, and the body of the events received from Stripe. Purpose: knowing whether the organisation may write, and keeping track of its subscription. Legal basis: performance of the contract; and, for what Stripe keeps of invoices, the legal obligation borne by the publisher. The buyer’s name, billing address and VAT number are entered at Stripe, not here.
The connected forge
Only if your organisation connects GitLab, GitHub or both, and nothing in this block concerns an organisation that connects neither. Data: the access token of each connected forge, encrypted at rest and never shown again in full; the identity of the account the token belongs to; and a local copy of what Jalon reads from the forge for the chosen projects — projects, issues and their labels, the history of labels added and removed, environments, merge requests and deployments. Purpose: composing the flow indicators from the projects the organisation designates. Jalon reads from the forge, and writes nothing to it.
Legal basis: the organisation determines it, as for its work above, since it is the organisation that sets up the connection and chooses the projects — the publisher is only a processor here. Retention: the local copy lives as long as the connection exists, and is purged as soon as the organisation changes forge; the bodies of received deliveries are deleted after thirty days; label histories left orphaned are deleted on every scheduler round. These three durations are applied by code, not by intent.
For how long
Working data is kept as long as the organisation exists. The account is kept until it is deleted, and for at most three years after the last sign-in: past that point, an email announces the deletion, which takes place thirty days later if no sign-in has occurred in the meantime. Signing in during those thirty days cancels the deletion. An account that owns an organisation where other people work is not deleted by this pass: ownership must be transferred first.
The audit log is purged automatically, by a daily pass: six months for sign-ins, twelve months for the four organisation events. Those durations are written in the code and applied by an actual delete, not by an intention.
Events received from Stripe are kept in two stages. Their body — the one carrying the name, email address, billing address and VAT number entered on the payment page — is erased after thirty days and replaced by a dated marker; the row, which by then identifies no one, is deleted after one year. Both durations are applied by a daily pass, like those of the audit log.
And when an organisation is deleted, the body of its Stripe events is erased at once, without waiting for the thirty days. What remains is that a payment was received, not from whom.
An invitation is deleted thirty days after its life ends: thirty days after it is accepted, or thirty days after it expires if nobody accepted it. That delay leaves time to answer “why does this link no longer work”; after it, the invited person’s address remains nowhere. This deletion is applied by the same daily pass as the durations above.
Database backups are kept for thirty days on the server that holds the database, then removed by rotation. Since 18 September 2026 they are also replicated to a second machine, where they are kept for ninety days: a backup that would vanish along with the machine it protects protects nothing. Deleted data may therefore survive in those copies for up to ninety days; they are restored only in the event of a failure, never to reconstruct what was deleted.
Who is trusted with what
OVH — email
Transactional email is sent through the OVH mailbox [email protected], over STARTTLS on port 587. OVH therefore sees the recipient address and the message content: password reset, invitation, task assignment, daily report and weekly report.
Worth knowing, because it was measured rather than assumed: the sending domain publishes a correct SPF record, but no DKIM signature and a DMARC policy set to observation only. A message may therefore be filtered as spam by some recipients.
Hosting
The application and its database run on a server administered by the publisher, in France, with no third-party application host: no cloud provider has access to the database.
Stripe — payment
An organisation subscribing to the Pro plan pays on a page hosted by Stripe. Your card number is never entered on this site and does not pass through Jalon’s servers: Stripe receives it, keeps it and issues the invoices. The buyer’s name, billing address and, if given, VAT number are entered on that page, and Stripe puts them on the invoice.
What Jalon sends to Stripe is short: the email address of the account subscribing, and an organisation identifier. What Jalon receives back and keeps are the subscription events, stored as Stripe sends them — so they may carry the buyer’s identity and billing address.
GitLab or GitHub — only if you connect to one
The nuance matters: a forge — GitLab, GitHub, or both — is involved only for organisations that set up a connection. An organisation that connects to neither exchanges nothing with either, and none of this paragraph concerns it.
When a connection is set up, a personal access token is stored encrypted at rest (ChaCha20Poly1305, key held outside the database), by the same mechanism whether the forge is GitLab or GitHub. Only its last four characters are kept in clear, so the screen can say which token is in place without ever showing it in full.
Jalon then reads from the connected forge, for the selected projects: projects, issues and their labels, the history of labels added to and removed from those issues, the project’s label catalogue, its deployment environments, merge requests, deployments, the status of a deployment when the forge does not provide it with the list, milestones and the issues attached to them, and the identity of the account the token belongs to. It keeps a local copy to compute the metrics. When an administrator imports milestones, their name, description, dates and the titles of their issues are copied into roadmap milestones and tasks. Jalon writes nothing to either GitLab or GitHub.
Transfers outside the European Union
The core of the service does not leave the Union: the application, the database and the backups are on a server in France, and outgoing mail goes through OVH, a company established in the Union. No request leaves your browser for a third party from these pages — no analytics, no font, no image from elsewhere.
Two processing operations can, however, take data outside the Union, and neither happens by default. The first is the forge, reserved for Pro: if your Pro organisation connects an account on gitlab.com or github.com, the token and the calls go to those services, operated by US companies. If it connects an instance it hosts itself — self-managed GitLab, GitHub Enterprise Server — nothing goes anywhere but to that instance: the address on record decides, and nothing else.
The second is payment. For an organisation established in France, the contracting party is Stripe Payments Europe, Limited, an Irish company; providing the service nevertheless sends data to Stripe, LLC in the United States. Subscribing to the Pro plan sends it the data described above. Neither transfer happens without an act by the organisation — setting up a Pro connection, or subscribing — and an organisation that does neither sees none of its data leave the Union.
Transfers to GitLab Inc., GitHub, Inc. and Stripe, LLC are covered first by the EU–US Data Privacy Framework, an adequacy decision under article 45 of the GDPR to which all three companies state that they adhere. Their documents also provide for the European Commission’s standard contractual clauses for transfers not covered by an adequacy decision, a safeguard under article 46. The entities, locations, clauses and official evidence reviewed on 20 September 2026 are recorded in the internal register. You can obtain a copy of the safeguards by writing to [email protected].
Your rights
You have the right to access your data, to rectify it, to erase it, to restrict processing, to portability, and to object — on grounds relating to your particular situation — to the processing based on legitimate interest, which here means the audit log and the rate limiting by IP address. No processing relies on your consent: there is therefore nothing to withdraw, and that is also why no banner is shown to you.
What decides on its own, and what does not. There is no profiling in this product: nothing scores you, ranks you, compares you to anyone, and none of your personal characteristics feeds any calculation. Automated mechanisms do exist, and here they are in full: the rate limiting that refuses a repeated call on the public authentication and invitation routes; the notice emails sent to an organisation that exceeds its plan limits; the subscription state recomputed on every event received from Stripe; the move to read-only described below; the daily purges of the audit log, of Stripe events and of invitations; the deletion of an account left three years without a sign-in, after thirty days’ notice; and the refusal to delete an account that still owns an inhabited organisation. All of them apply a rule to counts and states — never a judgement about a person.
Two clarifications rather than one convenient claim. Moving an organisation to read-only is enforced by the product: for exceeding the Free plan limits, only thirty days after the notice email; for a late payment, as soon as Stripe reports it. Reading is never blocked, and paying, opening the Stripe portal or removing a member remain possible. And how these mechanisms qualify under article 22 of the GDPR is not settled here — it falls under the legal review announced at the top of this page. In every case a human answers at the contact address, and none of these rules is beyond the reach of a complaint.
Access and portability: the owner of an organisation can export its working data as JSON from the Organisation page — organisation, members, swimlanes, milestones, tasks, people records, the label catalogue and the board columns. Neither snapshots nor the organisation’s time zone are included.
Erasure: account deletion happens from the Account page, without going through anyone. It is immediate and final, and its exact sequence — the refusal if you own an inhabited organisation, the solo organisations taken with it, what survives — is described in the terms of use.
Rectification: the display name and the account language can be changed from the Account page, in its Identity section. The email address cannot be changed there — it is the sign-in identifier and the only way to recover a password; a change request goes through the contact address in the legal notice.
Restriction and objection have no screen: they are exercised by writing to [email protected], as is any request the screens above do not cover. You get an answer within one month, which may be extended by two months if the request is complex — you are told if it is.
Two limits, stated plainly: what you placed in someone else’s organisation is not yours, and that organisation is who to ask; and the events received from Stripe are not erased on request but on the durations stated above — the body after thirty days, the row after one year —, deleting the organisation erasing the body at once.
Complaint
If, after writing to [email protected], you consider that your rights are not being respected, you can lodge a complaint with the French data protection authority — CNIL, 3 place de Fontenoy, TSA 80715, 75334 Paris Cedex 07, or at cnil.fr.
This is without prejudice to any judicial remedy.