Politique de confidentialité

Dernière mise à jour : 22 octobre 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 à quoi consentir, parce qu'aucune collecte n'a lieu - seulement cet avis, pour que tu saches ce qui est conservé et où. Effacer le stockage du site dans ton navigateur supprime tout cela à tout moment, tout comme Paramètres → Stockage → Effacer toutes mes données, qui désactive aussi Sync au passage. (Selon la directive ePrivacy Art. 5(3), un stockage strictement nécessaire au service que tu as demandé ne nécessite pas de consentement - seulement de la transparence, ce que sont à la fois ce document et l'avis affiché dans l'application.)

signed by Lolly2026-10-21vector SVG31 paths~4.2k nodes88 groups58 KBVérifie par toi-mêmeRécupérer le fichier signé signed by Lolly2026-10-21vector SVG31 paths~4.2k nodes88 groups58 KBVérifie par toi-mêmeRécupérer le fichier signé

Ta propre sauvegarde de ces données - le pack lolly-backup produit par Exporter mes données - 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 Lolly2026-10-21vector SVG2 paths824 nodes5 groups12 KBVérifie par toi-mêmeRécupérer le fichier signé signed by Lolly2026-10-21vector SVG2 paths824 nodes5 groups12 KBVérifie par toi-mêmeRécupérer le fichier signé

Prepare for sharing conserve les entrées de travail, les découvertes privées et les tables de remplacement en mémoire, sans les ajouter automatiquement à l'historique, aux liens, aux sauvegardes ou à la synchronisation. L'inspection et le remplacement n'envoient pas le contenu des fichiers à un serveur et ne valident pas d'identifiants en ligne. Les utilisateurs choisissent de copier, télécharger, envoyer ou explicitement enregistrer un résultat dans leur bibliothèque ; un résultat enregistré suit ensuite les réglages habituels de sauvegarde et de synchronisation de la bibliothèque. Les fichiers de recette omettent les contenus précédents et les tables littérales. Les rapports de synthèse contiennent des comptages, des identifiants de portée et des empreintes de fichiers. La CLI peut aussi enregistrer un fichier de relecture privé contenant les valeurs d'origine, uniquement sur demande explicite avec --review-file . Effacer ou quitter une vue de préparation dans le navigateur libère son état de travail ; ce n'est pas une promesse d'effacement forensique de la mémoire du navigateur ou du système.

Chaque requête réseau que l'application peut effectuer

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, Bluesky et Discord, sont réservées au bureau de la même façon, et leurs hôtes sont absents de la politique web pour la même raison. Cinq 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, une instance distante vers laquelle tu pointes le shell, et ton propre serveur Mastodon, serveur WebDAV ou bucket S3 (les deux derniers aussi comme espace de synchronisation). Aucune de ces lignes n'est dans la politique, et chacune ne se produit que quand tu tapes une adresse et que tu agis dessus. La ligne Penpot atteint Penpot via l'origine propre de l'application, elle est donc couverte par 'self' . 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.

À part deux types de lignes, 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). Les deux types sont les lignes Envoyer, qui envoient le seul fichier que tu as choisi, et la ligne de synchronisation, qui envoie une copie de ton travail vers le stockage que tu as choisi et vers aucun serveur Lolly. Toute autre exception est nommée 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 : Verify ne fournit désormais aucun résolveur, donc la vérification SEAL ne fait aucune requête réseau. Aucune application Lolly ne recherche aujourd'hui les clés SEAL dans le DNS : les applications de bureau et mobile exécutent la même vue Verify, et la commande lolly validate en ligne de commande ne vérifie pas SEAL. Un fichier dont l'enregistrement SEAL porte sa clé en ligne est vérifié hors ligne, et Verify déclare la signature cohérente en interne sans confirmer le domaine. Un fichier dont la clé vit uniquement dans le DNS affiche La signature SEAL n'a pas pu être vérifiée, avec la raison "no key resolver and no inline key".

signed by Lolly2026-10-21vector SVG11 paths~4.3k nodes18 groups52 KBVérifie par toi-mêmeRécupérer le fichier signé signed by Lolly2026-10-21vector SVG11 paths~4.3k nodes18 groups52 KBVérifie par toi-mêmeRécupérer le fichier signé 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

Actif sur lolly.tools. Chaque URL https://lolly.tools/tool/<tool-id>.<ext>?<inputs> est vraiment rendue, et les entrées voyagent dans cette URL. La section ci-dessous explique ce que cela signifie pour toi, et un opérateur peut désactiver la fonctionnalité sur sa propre instance.

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. Une URL de rendu en hotlink n'est donc pas l'endroit pour des informations personnelles : ne lui donne que ce que tu mettrais sur une page publique.
• 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 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 quatre 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.
• lolly_rebrand (rénove un ancien diaporama vers un système de design, à

travers ses étapes plan , compile et inspect ) accepte les octets d'un diaporama de la même façon, et les traite en mémoire, pour cet appel uniquement - rien n'est écrit sur disque ni conservé une fois la réponse envoyée. Sa première étape, capabilities , indique en mots où iraient tes octets avant que tu n'en envoies : sur un serveur local auto-hébergé, le diaporama ne quitte jamais cette machine ; sur un serveur hébergé, appeler lolly_rebrand y envoie le diaporama, dans les limites de taille et de nombre de diapositives que donne cette même étape.

• Les outils d'image (lolly_look, lolly_sample_color et lolly_trace_edges) peuvent aussi recevoir un fichier image de l'appelant, traité de la même façon : en mémoire, pour cet appel seulement. Tous les autres outils fonctionnent à partir des paramètres de l'appel : texte, nombres, couleurs, URL, identifiants d'assets de catalogue, ou un document que l'appelant fournit.
• 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 Lolly2026-10-21vector SVG7 paths~2.0k nodes11 groups24 KBVérifie par toi-mêmeRécupérer le fichier signé signed by Lolly2026-10-21vector SVG7 paths~2.0k nodes11 groups25 KBVérifie par toi-mêmeRécupérer le fichier signé

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). Lolly la hache avant de créer un bucket de contrôle des abus de courte durée ; l'adresse brute n'est jamais envoyée à ce stockage. Le bucket expire au bout d'environ une minute et n'est pas utilisé à des fins de suivi. Les journaux d'accès d'hébergement ordinaires sont distincts et décrits ci-dessous.

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 aucune donnée personnelle pour nous. Elle n'a ni analytics, ni suivi, ni serveur à elle. La page Extension de navigateur décrit son fonctionnement.

Ce qu'elle fait. L'application web Lolly peut lui demander une capture d'écran d'une page web, ou le contenu d'une page pour démarrer un système de design à partir d'un site web. Chaque demande ouvre dans l'extension une fenêtre d'approbation qui indique le site demandeur, s'il veut une capture d'écran ou le contenu de la page, et l'adresse de la page. Ce n'est qu'après ton clic sur Approve once que l'extension ouvre cette page dans un onglet d'arrière-plan temporaire, prend la capture ou lit la page, remet le résultat à l'onglet Lolly qui l'a demandé et ferme l'onglet. Chaque demande a besoin de sa propre approbation.

Données.

• Nous ne collectons rien. Le résultat va uniquement à la page Lolly qui l'a demandé, dans le même navigateur. L'extension ne stocke aucun contenu de page et n'ajoute aucun autre destinataire.
• Requêtes réseau. La page que tu approuves se charge comme dans n'importe quel onglet, avec tout ce que cette page demande elle-même. Lire le contenu d'une page récupère aussi les feuilles de style de cette page et quelques-unes de ses images d'icônes et de logos, depuis l'intérieur de la page, et ces récupérations n'envoient aucun cookie vers d'autres sites. L'extension ne fait aucune autre requête, et aucune n'est envoyée à un serveur Lolly.
• Ta session de navigateur. La page se charge avec ta session de navigateur, comme si tu l'ouvrais toi-même, donc une page où tu es connecté peut mettre des informations privées dans le résultat.
• Les adresses que tu approuves ne servent qu'à charger cette page-là pour cette demande-là. Elles ne sont ni journalisées ni partagées.

Permissions.

• debugger - pour prendre la capture d'écran via le DevTools Protocol (le même mécanisme qu'utilise l'application de bureau Lolly).
• tabs - pour ouvrir et fermer l'onglet temporaire, et pour vérifier que ni la page Lolly ni la page cible n'a bougé depuis ton approbation.
• scripting - pour lire le contenu d'une page dans l'onglet temporaire, après que tu as approuvé cette demande.
• storage - pour noter les ids de ses onglets temporaires en stockage de session, afin qu'ils se ferment quand même si le navigateur arrête l'extension pendant une demande. Aucun contenu de page n'est stocké.
• *Accès optionnel aux sites (http:///, https:///) - non accordé à l'installation. Quand tu cliques sur Approve once*, l'extension demande à Chrome l'accès au seul site de cette demande, et Chrome te le demande la première fois pour chaque site. Un site que tu as déjà autorisé exige quand même une nouvelle approbation pour chaque demande.

Rien de tout cela n'est utilisé pour lire, surveiller ou transmettre ta navigation au-delà de la demande que tu as approuvé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 , lolly_redact ou lolly_rebrand , qui est traité en mémoire et jamais écrit sur disque ou dans un journal, comme décrit ci-dessus.

Les services publics réduisent la journalisation applicative. Le serveur MCP journalise le démarrage, la configuration et les avertissements de rendu ; il ne tient aucun journal de requêtes à lui et ne journalise ni les jetons ni les adresses des appelants. Le relais Penpot journalise le nom de chaque commande et le statut de réponse de Penpot, jamais les en-têtes, les jetons ni le fichier. Le service de certificats journalise ses réglages de démarrage et ses avertissements de configuration, plus deux lignes dépouillées en cas d'échec : un code de statut d'échec d'envoi sans adresse de destinataire, et une ligne d'échec fixe sans texte d'erreur, sans trace de pile ni URL (une erreur de fournisseur peut contenir des valeurs d'identité ou des identifiants). 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.) ; notre fournisseur de stockage de contrôle des abus, qui ne reçoit que des clés de bucket dérivées à sens unique et de courte durée, jamais l'adresse IP brute ; 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 ces fournisseurs sont si limitées

• une adresse e-mail transmise pour envoyer un seul message, des journaux d'accès ordinaires, et

un bucket de contrôle des abus dérivé de courte durée - 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 (Exporter mes données, ci-dessus) ou supprimer (en effaçant le stockage du site dans ton navigateur, comme ci-dessus).

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.

22 octobre 2026 : description corrigée d'un comportement existant. La section sur l'extension de navigateur couvre désormais la fenêtre d'approbation pour chaque demande, l'accès aux sites demandé un site à la fois et la récupération des feuilles de style et des icônes lors de la lecture d'un site web. Également corrigés : les lignes Send to Google Drive et Meeting Planner, la note SEAL (aucune application Lolly ne recherche les clés SEAL dans le DNS), le niveau par défaut de télémétrie d'usage du service d'organisation, les outils d'image MCP et la journalisation applicative des services publics. Le logiciel lui-même n'a pas changé.

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.