Politique de confidentialité

Dernière mise à jour : 11 août 2026

La version courte. Les documents, images, vidéos et fichiers que tu crées dans Lolly restent sur ton appareil. Il n'y a pas de comptes pour un usage ordinaire, pas de cookies venant de l'app elle-même et pas d'analytique ni de traceurs nulle part dans le code - pas « on n'utilise pas les données », vraiment absent du code source. Il existe une liste courte et complète d'exceptions où le logiciel parle à un réseau, et chacune d'elles est décrite ci-dessous en détail : ce qui sort, vers qui et quand. La seule exception qui touche à quelque chose de personnel est une connexion que tu dois démarrer explicitement. Si ce n'est pas dans ce document, ça n'arrive pas.

Ce que couvre cette politique

Lolly est un logiciel open source - un moteur, plusieurs coques applicatives (web, bureau, mobile, CLI) et une extension de navigateur - que n'importe qui peut exécuter. Cette politique comporte deux parties :

• Le logiciel lui-même : ce qu'il fait et ne fait pas avec tes données, où qu'il s'exécute. C'est une propriété du code, donc c'est vrai pour tout déploiement de Lolly, le nôtre ou celui de n'importe qui d'autre.
• lolly.tools, le déploiement de référence exploité par SUSE : les choix spécifiques faits pour l'exécution de ses éléments côté serveur optionnels (ce qui est journalisé, pendant combien de temps, par qui).

Si tu utilises une instance Lolly auto-hébergée ou d'entreprise, le comportement du logiciel décrit ci-dessous s'applique toujours, mais l'opérateur de cette instance - et non SUSE - est responsable de tout ce qui est côté serveur : son point de rendu, son serveur MCP, son autorité de certification Content Credentials, s'il en exploite une. Demande-leur leur propre politique. Voir Adoption & gouvernance pour ce qu'implique l'exploitation de Lolly.

L'application : ce qui reste sur ton appareil

Les coques web, bureau et mobile de Lolly exécutent l'intégralité du moteur de rendu côté client. Ouvrir un outil, remplir des champs, prévisualiser et exporter se passent tous sur ton appareil - aucun serveur n'intervient, et l'application fonctionne hors ligne une fois chargée.

L'application ne dépose aucun cookie. Pour fonctionner, elle conserve une petite quantité de données uniquement sur ton appareil, jamais transmises :

• Préférences d'interface - thème, langue, réglages sonores, dimensionnement barre latérale/zoom, choix de tri et d'affichage, conseils d'accueil déjà vus - dans localStorage, pour qu'elles soient disponibles avant que l'application ait fini de démarrer.
• Un cache hors ligne du catalogue d'outils et des aperçus d'assets, pour que la galerie fonctionne sans connexion.
• Compteurs d'usage locaux pour les statistiques de ta carte de profil (nombre d'exports, quels outils) - un petit blob borné dans localStorage, jamais lu par nous, jamais envoyé nulle part.
• Tes propres documents, sessions enregistrées, assets et polices téléversés - stockés dans IndexedDB sur ton appareil, jamais téléversés, jamais lus par personne d'autre que toi.

Rien de tout cela n'est partagé, vendu ni utilisé pour t'identifier ou te suivre. Il n'y a rien à consentir, parce qu'il n'y a aucune collecte en cours - seulement cette notice, pour que tu saches ce qui est conservé et où. Efface tout cela à tout moment avec Profil → Clear all my data, ou en effaçant le stockage du site dans ton navigateur. (En vertu de l'article 5(3) de la directive ePrivacy, un stockage strictement nécessaire au service que tu as demandé ne requiert pas de consentement - seulement de la transparence, ce que sont à la fois ce document et la notice dans l'application.)

signed by Lollyvector SVG2026-08-24Vérifie par toi-mêmeGet the signed file14 paths~2.0k nodes39 groups28 KBsigned by Lollyvector SVG2026-08-24Vérifie par toi-mêmeGet the signed file14 paths~2.0k nodes39 groups29 KB

Ta propre sauvegarde de ces données - le pack lolly-backup produit par Export my data & render everything - est un fichier que tu conserves et contrôles. Il ne touche jamais nos serveurs à moins que tu ne choisisses toi-même de l'envoyer quelque part. Voir Transfert de données.

Utilitaires sur l'appareil

Certains outils - Strip Hidden Data, Compress PDF et d'autres portant le badge "Runs on your device" - opèrent sur un fichier que tu fournis. Le fichier est lu en mémoire dans ton navigateur, transformé localement et proposé en retour au téléchargement. Il n'est jamais téléversé, parce qu'il n'y a aucun serveur dans le circuit vers lequel le téléverser. Ces utilitaires fonctionnent hors ligne, et leur résultat ne porte aucun filigrane ni métadonnée de notre part - le but de la plupart d'entre eux est de retirer & protéger des données, pas d'ajouter un risque.

signed by Lollyvector SVG2026-08-24Vérifie par toi-mêmeGet the signed file1 path7 nodes3 KBsigned by Lollyvector SVG2026-08-24Vérifie par toi-mêmeGet the signed file1 path7 nodes3 KB

Quand l'application communique avec un réseau, en détail

Le tableau ci-dessous est la liste complète de tout ce que l'application récupère ou envoie sur un réseau. Si ce n'est pas ici, l'application ne le fait pas.

Chaque hôte fixe de ce tableau constitue aussi la liste d'autorisation complète de la Content-Security-Policy de l'application, que le navigateur fait respecter. Cette liste n'est donc pas seulement une description de ce que fait le code aujourd'hui, elle est la limite à laquelle le navigateur tient l'application : un futur changement qui tenterait de contacter un autre hôte serait bloqué, et non silencieusement autorisé. Une ligne est l'exception délibérée, et sa propre cellule le précise : Send to LinkedIn n'existe que dans les applications de bureau, si bien que la politique de l'application web ne nomme aucun de ses deux hôtes - l'application web ne pourrait pas les atteindre même si son code l'essayait. Deux autres lignes n'ont pas d'hôte fixe, parce que tu choisis l'adresse au moment de l'utilisation : une URL que tu demandes à un outil de capturer, et une instance distante vers laquelle tu pointes le shell. Aucune des deux n'est dans la politique, et chacune ne se produit que quand tu tapes une adresse et que tu agis dessus. Un déploiement qui ne veut aucune des fonctions optionnelles (une instance d'entreprise avec ses propres polices, par exemple) retire ces hôtes de sa politique, et les fonctions échouent en mode fermé plutôt que de contacter l'extérieur.

Rien de tout cela n'envoie tes documents, projets, sessions ou fichiers téléversés nulle part. Ils existent pour apporter des choses vers ton appareil (outils, polices, modèles), jamais pour envoyer des choses depuis celui-ci, avec les exceptions nommées explicitement dans les sections ci-dessous.

Une note sur ce que nous avons retiré. Verify peut vérifier des signatures SEAL, un système où la clé de signature d'un fichier est publiée dans le DNS. Les navigateurs ne peuvent pas faire de requêtes DNS, donc toute implémentation web doit faire passer la recherche par un résolveur DNS-over-HTTPS tiers - ce qui montrerait à cet opérateur le domaine vérifié plus ton adresse IP. Nous utilisions celui de Cloudflare. Nous ne le faisons plus, et il n'y a pas de remplacement : l'application web ne fournit désormais aucun résolveur, donc la vérification SEAL ici ne fait aucune requête réseau. Les fichiers dont l'enregistrement SEAL porte sa clé en ligne se vérifient toujours entièrement hors ligne. Les fichiers dont la clé vit dans le DNS signalent "no key resolver" à la place, et tu peux les vérifier dans l'application de bureau ou en ligne de commande, qui résolvent le DNS nativement via ta propre machine sans tiers impliqué.

signed by Lollyvector SVG2026-08-24Vérifie par toi-mêmeGet the signed file10 paths~7.6k nodes14 groups84 KBsigned by Lollyvector SVG2026-08-24Vérifie par toi-mêmeGet the signed file10 paths~7.6k nodes14 groups84 KB Tu peux le confirmer toi-même : des vérifications greppables pour cette affirmation et toutes les autres de cette page, avec les commandes exactes et le résultat attendu, se trouvent sur Verify It Yourself.

URL de rendu en hotlink

Actuellement désactivé sur lolly.tools. Chaque URL https://lolly.tools/tool/<tool-id>.<ext> renvoie aujourd'hui une erreur 404. La section ci-dessous décrit ce que fait la fonctionnalité quand un opérateur l'active, et pourquoi nous ne l'avons pas fait. Elle sera activée ici une fois que le service basculera vers une infrastructure exploitée par SUSE, et cette notice changera à ce moment-là.

L'application elle-même reste entièrement sur ton appareil. Séparément, un opérateur peut activer les URL de rendu en hotlink - /tool/<tool-id>.<ext>?<inputs> - pour qu'un lien Lolly partagé puisse apparaître comme une image vivante dans un README, un wiki ou un tableau de bord. Récupérer l'une d'elles demande au serveur de rendre des données publiques d'outil et de catalogue avec les entrées inscrites dans l'URL.

• Pas de comptes, pas de cookies, pas d'état. Le point d'accès est anonyme, et rien n'est lu sur ton appareil. Tes documents, sessions et imports ne quittent jamais ton navigateur - ils ne peuvent absolument pas apparaître dans ces liens.
• Mais l'URL elle-même est enregistrée. La chaîne de requête d'une URL fait partie de la ligne de requête, donc elle apparaît dans les journaux d'accès habituels de la plateforme d'hébergement, tout comme n'importe quel chemin demandé. Si les entrées d'un lien contiennent le nom ou l'email de quelqu'un - un badge nominatif, une signature email - ce texte se retrouve dans ces journaux, et aucune formulation de politique n'y change quoi que ce soit. C'est la raison précise pour laquelle cette fonction est désactivée ici par défaut plutôt qu'activée.
• Les entrées sont de toute façon publiques par construction - elles sont ce que l'auteur ou l'autrice du lien a tapé dans l'URL, lisible par quiconque le lien atteint. Ne mets pas de secrets dans un lien partagé. Lolly propose le chiffrement de liens pour le contenu sensible.
• Les réponses sont mises en cache et limitées en débit comme n'importe quelle image publique, et marquées noindex pour que les moteurs de recherche n'indexent pas tes rendus.

Tu auto-héberges Lolly et tu ne veux pas d'une surface de rendu publique ? Définis LOLLY_DISABLE_RENDER_GET=1 - ce que fait actuellement lolly.tools lui-même - et chacune de ces URL renvoie une erreur 404.

Le serveur MCP (optionnel, pour les agents IA)

Lolly peut aussi être atteint par un agent IA via le Model Context Protocol - un point d'accès exploité par un opérateur (lolly.tools en exploite un ; n'importe qui peut auto-héberger le sien, y compris entièrement isolé du réseau). Il partage la posture sans compte du chemin de rendu, plus trois outils qui manipulent nécessairement des octets de fichiers :

• lolly_transform (exécute un utilitaire sur l'appareil côté serveur, pour le compte de l'agent appelant), lolly_verify (vérifie les Content Credentials) et lolly_redact (masque des régions d'une image ou d'un PDF) acceptent tous les octets d'un fichier de la part de l'appelant. Ils sont traités en processus, en mémoire, et le résultat est renvoyé dans ce même appel - le fichier n'est jamais écrit sur disque et jamais conservé une fois la requête terminée.
• Tous les autres outils - lolly_render, lolly_build_url, lolly_list_tools, lolly_describe_tool - fonctionnent uniquement à partir de paramètres (texte, nombres, couleurs, URL, identifiants d'assets de catalogue), les mêmes entrées que prend une URL de rendu en hotlink.
• L'accès se fait soit par un jeton partagé que l'opérateur délivre aux clients auxquels il fait confiance, soit par OAuth 2.1 sans état : des jetons signés de courte durée vérifiés contre un secret partagé, rien de stocké côté serveur et le jeton lui-même n'est jamais écrit dans un journal ni dans une URL de rendu.

Identité Content Credentials (une connexion que tu dois lancer toi-même)

Lolly peut sceller un Content Credential cryptographique dans tes exports pour que n'importe qui puisse vérifier, hors ligne, qu'un fichier n'a pas été modifié depuis sa sortie de Lolly. Cela, c'est activé par défaut et entièrement local - la clé de signature est générée sur ton appareil et la signature elle-même se fait hors ligne. Sans inscription, cette clé est jetable : une nouvelle paire de clés est générée pour chaque export et abandonnée avec lui. Une fois que tu t'inscris, la clé devient durable et est générée non extractible - même le code de Lolly lui-même ne peut pas la lire, seulement lui demander de signer. Dans les deux cas elle ne quitte jamais ton appareil. Cette section couvre la seule étape optionnelle en plus de cela : inscrire une identité vérifiée, pour que tes exports affichent "Verified - signed by \<your email\>" au lieu d'une clé anonyme. Si tu ignores l'inscription, rien dans cette section ne te concerne, et aucune donnée personnelle ne quitte jamais ton appareil.

signed by Lollyvector SVG2026-08-24Vérifie par toi-mêmeGet the signed file21 paths~10k nodes16 groups112 KBsigned by Lollyvector SVG2026-08-24Vérifie par toi-mêmeGet the signed file21 paths~10k nodes16 groups112 KB

Si tu t'inscris, voici exactement ce qui se passe :

1. Tu choisis une méthode de connexion - GitHub, Google, SUSE (id.suse.com) ou un lien envoyé par e-mail. Pour les trois fournisseurs OIDC, tu es redirigé vers la propre page de connexion de ce fournisseur, régie par sa propre politique de confidentialité, pas la nôtre. Le service de certificats de Lolly ne reçoit en retour qu'une adresse e-mail vérifiée et le nom du fournisseur. Pour le lien par e-mail, l'adresse que tu saisis est transmise à Resend, une API d'e-mail transactionnel, uniquement pour délivrer ce lien-là.
2. Un cookie de courte durée protège la redirection. C'est le seul cookie que pose l'ensemble du système Lolly : lolly_ca_state, HttpOnly, limité à /api/ca, expirant en dix minutes. Il porte une valeur aléatoire, pas un identifiant de suivi, et n'existe que pour empêcher que la redirection OAuth soit falsifiée. Il est effacé dès que la connexion est terminée.
3. Ton adresse IP est utilisée, brièvement, pour prévenir les abus des points d'accès de connexion (pour qu'un script ne puisse pas spammer une boîte de réception ou épuiser le quota d'e-mails) - conservée uniquement en mémoire serveur, pour une fenêtre glissante d'environ une minute, jamais écrite dans un journal ni conservée nulle part.
4. Le service de certificats émet un certificat de courte durée (7, 30, 90 ou 365 jours, à ton choix, plafonné par la politique de l'opérateur) liant ton e-mail vérifié à la moitié publique de la paire de clés générée sur ton appareil. La moitié privée ne quitte jamais ton navigateur.
5. Rien concernant l'émission n'est enregistré. Le service de certificats ne conserve aucun journal d'émission : ni ton e-mail, ni le fournisseur, ni un numéro de série, ni un horodatage. Pas de base de données, pas de ligne de journal, pas de webhook. Ton adresse e-mail n'existe dans la requête que le temps d'être écrite dans le certificat que ton propre appareil reçoit, puis elle a entièrement disparu de notre côté.
6. Après cela, la signature redevient hors ligne pendant toute la durée de vie du certificat. Exporter un fichier ne contacte jamais le service de certificats - seule l'inscription l'a fait.

Le compromis, dit clairement. Une version antérieure de ce service journalisait chaque émission, pour qu'un certificat mal émis ou compromis puisse être tracé. Nous l'avons retiré, parce que ce journal était le seul endroit dans tout Lolly où des données personnelles finissaient sur un serveur, et nous préférons ne pas les détenir plutôt que de les détenir avec soin. Ce que nous perdons, c'est la traçabilité côté serveur : si un certificat est utilisé abusivement, nous ne pouvons pas retrouver qui l'a obtenu. Les certificats sont de courte durée par conception - 7 à 365 jours, à ton choix, plafonnés par l'opérateur - et expirent d'eux-mêmes, ce qui est la protection sur laquelle nous comptons à la place. Les auto-hébergeurs dont les propres obligations exigent un journal d'audit peuvent en ajouter un, et deviennent alors responsables de ce traitement en le faisant.

L'extension de navigateur

L'extension de navigateur Lolly URL Screenshot ne collecte, ne stocke ni ne transmet aucune donnée personnelle. Pas d'analytics, pas de suivi, pas de serveur distant.

Ce qu'elle fait. Quand tu demandes à l'application web Lolly de capturer une URL, l'extension ouvre cette page dans un onglet d'arrière-plan temporaire, la capture dans ton navigateur via le DevTools Protocol, renvoie l'image à l'application et ferme l'onglet. Tout se passe localement, sur ton propre appareil et réseau.

Données.

• Nous ne collectons rien. L'extension n'a aucun serveur et ne fait aucune requête réseau qui lui soit propre.
• Les images capturées vont directement vers l'application Lolly dans le même navigateur - jamais téléversées par l'extension.
• Les URL que tu captures ne servent qu'à charger cette page-là pour cette capture d'écran-là. Elles ne sont ni journalisées ni partagées.

Permissions.

• debugger - pour capturer la page rendue via le DevTools Protocol (le même mécanisme qu'utilise l'application de bureau Lolly).
• tabs - pour ouvrir et fermer l'onglet temporaire dans lequel la page se charge.
• Accès aux hôtes (<all_urls>) - parce que la page que tu choisis de capturer peut être sur n'importe quel site. Chrome affiche cela à l'installation comme un avertissement de permission large. L'extension ne visite jamais que l'URL que tu lui donnes.

Rien de tout cela n'est utilisé pour lire, surveiller ou transmettre ta navigation au-delà de cette unique capture demandée.

Journaux d'infrastructure

Comme tout site web, les serveurs derrière lolly.tools - et derrière tout déploiement de Lolly - génèrent des journaux d'accès de serveur web standard dès qu'une requête les atteint : adresse IP, chemin demandé, horodatage, agent utilisateur. C'est un comportement d'hébergement de base, pas quelque chose que Lolly ajoute en plus, et cela ne contient jamais le contenu de tes documents, parce que ceux-ci n'atteignent jamais un serveur au départ. La seule exception délibérée est un fichier que tu remets explicitement à un appel MCP lolly_transform, lolly_verify ou lolly_redact, qui est traité en mémoire et jamais écrit sur disque ou dans un journal, comme décrit ci-dessus.

Le propre code de Lolly n'écrit rien dans ces journaux. Le serveur MCP ne contient aucune instruction de journalisation. Le service de certificats émet exactement deux lignes, toutes deux en cas d'échec et toutes deux délibérément dépouillées : un code de statut d'échec d'envoi sans adresse de destinataire, et un message d'erreur sans trace de pile ni URL (une trace de pile pourrait contenir un jeton d'inscription). Tout le reste du journal appartient à la plateforme d'hébergement, pas à nous.

Pour lolly.tools, l'hébergement est assuré par Vercel et la rétention des journaux d'accès suit les paramètres par défaut propres à Vercel pour notre offre. Nous ne configurons aucun drain de journaux, aucun export de journaux à long terme et aucun produit d'analytics ou de supervision en plus. Nous ne conservons nous-mêmes aucune copie de ces journaux, ce qui signifie aussi que nous n'avons aucun moyen de les rechercher pour toi - voir Tes droits.

Bases légales, conservation et destinataires

Presque rien ici n'a besoin de base légale, car presque rien n'est traité. Par souci d'exhaustivité, la liste complète :

Destinataires. Les catégories de destinataires sont : notre hébergeur (Vercel Inc.), et - uniquement si tu utilises l'option de connexion par e-mail - un fournisseur d'e-mails transactionnels (Resend). Si tu te connectes avec GitHub, Google ou SUSE (id.suse.com), tu interagis directement avec ce fournisseur sous sa propre politique de confidentialité. Il nous communique une adresse e-mail vérifiée et rien d'autre. Nous ne partageons de données personnelles avec personne d'autre, et nous ne vendons pas de données, ne diffusons pas de publicité et ne profilons pas les utilisateurs.

Transferts hors de l'EEE. Vercel et Resend sont des entreprises américaines. Le calcul des fonctions pour lolly.tools est fixé sur la région de Francfort (fra1) de Vercel, si bien que le traitement a lieu dans l'UE, mais en tant que fournisseurs ayant leur siège aux États-Unis, ils peuvent tout de même accéder aux données en tant que sous-traitants depuis les États-Unis. Ces transferts reposent sur les clauses contractuelles types de la Commission européenne et/ou le cadre EU-US Data Privacy Framework, tel que défini dans l'accord de traitement des données de chaque fournisseur. Comme les données personnelles atteignant l'un ou l'autre fournisseur sont si limitées - une adresse e-mail transmise pour envoyer un seul message, et des journaux d'accès ordinaires - l'exposition est proportionnellement faible.

Prise de décision automatisée. Aucune. Il n'y a ni profilage ni décision automatisée produisant des effets juridiques ou similaires significatifs (Art. 22).

Confidentialité des enfants

Lolly ne collecte sciemment aucune information personnelle auprès de qui que ce soit, quel que soit son âge, dans le cadre normal de l'utilisation de l'application - il n'y a rien à collecter. Le seul endroit où des informations personnelles (une adresse e-mail) sont jamais recueillies est l'inscription à Content Credentials, décrite ci-dessus, qui ne s'adresse pas et n'est pas destinée aux enfants.

Tes droits

Comme presque tout ce que Lolly touche n'est stocké que sur ton propre appareil, la plupart de ce que le droit de la protection des données appelle « tes droits » - accès, correction, suppression, portabilité - sont des choses que tu peux déjà faire toi-même, instantanément, sans demander à personne : tes données résident dans le stockage de ton navigateur, sous une forme que tu peux inspecter, exporter (Export my data & render everything, ci-dessus) ou supprimer (Profile → Clear all my data).

Formellement, en vertu des articles 15 à 22 du RGPD, tu as le droit d'accéder à tes données personnelles, de les rectifier, de les effacer, d'en restreindre ou de t'opposer au traitement (y compris de t'opposer à tout ce que nous fondons sur des intérêts légitimes), à la portabilité des données et - lorsque le traitement repose sur le consentement - de retirer ce consentement à tout moment, sans affecter la licéité de ce qui s'est passé avant ce retrait.

Voici la position honnête sur leur exercice à notre égard. Comme nous ne tenons plus de journal d'émission, nous ne détenons aucune donnée personnelle te concernant que nous puissions consulter, corriger, exporter ou supprimer. Si tu nous écris pour demander ce que nous détenons sur toi, la réponse honnête est « rien », et c'est ce que nous te dirons. La seule catégorie qui existe est les journaux d'accès d'hébergement indexés par adresse IP, détenus par notre hébergeur selon ses valeurs de conservation par défaut. Nous n'avons aucun moyen de les rechercher ou de les supprimer sélectivement, et nous te le dirons plutôt que de prétendre le contraire. Tout ce qui est réellement à toi se trouve sur ton appareil, où tu peux déjà le lire, l'exporter et le détruire sans demander la permission de qui que ce soit.

Tu as le droit de te plaindre. Si tu penses que nous avons mal géré tes données, tu peux déposer une plainte auprès d'une autorité de contrôle de la protection des données - dans l'UE, l'autorité de ton pays de résidence, de ton lieu de travail ou du lieu où tu estimes que l'infraction a eu lieu (Art. 77). Notre autorité de contrôle chef de file est le Bayerisches Landesamt für Datenschutzaufsicht (BayLDA) à Ansbach, en Allemagne. Tu n'as pas besoin de nous contacter d'abord, même si nous aimerions avoir l'occasion de corriger le problème.

Nous ne vendons pas de données. Nous n'en avons pas à vendre.

Modifications de cette politique

La date en haut de page change à chaque fois que ce document change. Une modification qui altère ce qui quitte ton appareil ou ce qui est conservé obtient sa propre ligne ici, pas une modification silencieuse - si tu veux voir ce qui a changé, demande (ci-dessous) ou compare avec la source publique.

Qui est responsable, et comment nous contacter

Le responsable du traitement pour lolly.tools est :

SUSE Software Solutions Germany GmbH Frankenstraße 146 90461 Nürnberg Allemagne

SUSE a nommé un délégué à la protection des données, joignable à privacy@suse.com. Utilise cette adresse pour toute demande formelle relevant de « Tes droits » ci-dessus.

Pour tout ce qui concerne Lolly lui-même - son fonctionnement, pourquoi une chose est ainsi ou une correction à apporter à ce document - contacte Andy Fitzsimon, fitzy@suse.com.

Pour une instance de Lolly auto-hébergée ou d'entreprise, contacte plutôt son exploitant : l'exploitant est le responsable de traitement pour son propre déploiement. SUSE et le projet open source Lolly ne détiennent aucune donnée pour les déploiements qu'ils n'exploitent pas.