Peut-on conserver son journal dans le cloud en toute sécurité ?

Peut-on conserver son journal dans le cloud en toute sécurité ? Il n'existe pas de réponse universelle. La bonne question porte d'abord sur ce qu'il faut protéger, contre qui, et sur le pire scénario : une divulgation sans autorisation, une perte définitive ou les deux. Viennent ensuite le service précis, son architecture, les appareils et les paramètres du compte.

Le cloud peut faciliter synchronisation, redondance et récupération. Il ajoute aussi au parcours des données les systèmes du fournisseur, des comptes, des sauvegardes, des métadonnées et des dépendances juridiques ou opérationnelles. Un chiffrement de bout en bout correctement mis en œuvre, sans clé de contenu détenue par le fournisseur, peut réduire l'accès de ce dernier. Il ne protège pas un terminal compromis, chaque exportation, chaque procédure de récupération ni toutes les métadonnées.

Ce guide sert à bâtir un modèle de menace. Ce n'est ni un classement à jour des applications, ni une promesse de secret absolu. Fonctions et politiques évoluent : il faut consulter la documentation et les réglages du service, de l'offre, de la plateforme et de la version effectivement utilisés.

La sécurité ne se limite pas à la confidentialité

Il peut aussi être important de retrouver le journal après la perte d'un téléphone, un problème de compte, la fermeture d'un service ou une suppression accidentelle. Une architecture qui empêche presque tout recours au fournisseur renforce parfois la confidentialité, mais peut rendre irréversible la perte d'une clé.

Parmi les menaces plausibles figurent une personne devant un appareil déverrouillé, un compte détourné, un logiciel malveillant sur un terminal, des privilèges internes excessifs, une intrusion chez le fournisseur, un fichier partagé par erreur, une exportation lisible, une demande légale ou la disparition de la seule copie exploitable.

Probabilité et conséquences changent selon la personne et selon la page. Un risque rare mais dévastateur peut compter davantage qu'un désagrément fréquent et mineur.

Des notes sur la vie quotidienne n'appellent pas forcément le même dispositif qu'un texte identifiant un tiers, contenant des données de santé ou susceptible de provoquer un tort grave. Omettre des noms ou séparer le contenu particulièrement sensible réduit les conséquences, quel que soit le mode de stockage.

Repérer toutes les voies d'accès

Notre guide sur les personnes susceptibles de lire un journal numérique présente la liste complète. Ces voies dépendent du produit ; elles ne signifient pas que toutes les applications cloud fonctionnent de la même manière.

Le fournisseur. Lorsqu'un service stocke un contenu lisible ou contrôle les clés de déchiffrement, certains systèmes autorisés et membres du personnel disposant de privilèges peuvent techniquement y accéder. Règles internes, droits et journaux d'audit limitent éventuellement cette capacité, sans équivaloir à une impossibilité cryptographique.

Les sous-traitants. Hébergement, supervision, analyse, assistance et paiement supposent des données différentes pour des rôles différents. Un prestataire de paiement ne reçoit pas automatiquement le texte du journal. La liste publiée des sous-traitants et des catégories de données est plus informative qu'une supposition d'accès général.

Les autorités. Un fournisseur peut recevoir une demande juridiquement valable concernant les données qu'il possède. Compétence, procédure, portée, notification et recours possibles varient. Le chiffrement n'annule pas la procédure légale ; il modifie les données lisibles que l'entreprise peut techniquement détenir. Ce texte ne constitue pas un conseil juridique.

Les personnes qui attaquent le service. Le rapport annuel Cost of a Data Breach d'IBM porte sur des organisations ayant subi des violations. Il éclaire les coûts et les environnements de ces incidents, mais n'estime pas la probabilité d'une intrusion visant une application de journal précise ou les pages d'une personne donnée.

Les personnes et logiciels présents sur un terminal. Appareil déverrouillé, compte partagé, notification visible ou sauvegarde lisible peuvent contourner la protection du fournisseur. Un logiciel malveillant sur un appareil autorisé peut également voir le texte en clair. Codes d'accès, mises à jour, verrouillage automatique, protection du compte et gestion des exportations répondent à des risques distincts.

Le choix « cloud ou local » ne suffit pas : il faut situer les copies lisibles et les clés utilisables.

Les limites des différentes formes de chiffrement

En transit. Le chiffrement protège les données durant leur trajet entre deux points. Il n'indique pas à lui seul si l'appareil émetteur, le service destinataire ou le stockage ultérieur ont accès au texte en clair.

Au repos. Le chiffrement protège un support ou une base de données selon un modèle de clés défini. Quand le service contrôle les clés nécessaires au fonctionnement, ses systèmes autorisés peuvent encore traiter le contenu. Cette protection reste utile contre certaines atteintes au stockage et ne doit pas être présentée comme inutile.

De bout en bout. L'E2EE désigne généralement un contenu chiffré sur un terminal autorisé et déchiffré uniquement sur des terminaux autorisés, sans clé de contenu détenue par le service intermédiaire. Création des clés, ajout d'appareils, récupération, partage, sauvegardes, exportations et qualité de l'implémentation fixent la frontière réelle. Identifiants de compte, dates ou autres métadonnées peuvent rester visibles.

Le chiffrement de bout en bout peut empêcher le fournisseur de produire un contenu lisible qu'il ne possède pas. Il ne promet pas la sécurité de tous les appareils et de toutes les copies, l'absence de métadonnées ou l'impossibilité d'atteindre une autre source par voie légale. Usage sur plusieurs appareils, partage, récupération et exportations rendent trop large la formule « accessible à une seule personne ».

Un espace cloud choisi par l'utilisateur ne règle pas tout

Cette solution peut réduire la garde des données par l'éditeur du journal et faciliter le déplacement des fichiers. Le fournisseur cloud, la récupération du compte, les applications connectées, la sécurité des appareils et les autorisations du journal restent cependant dans le système.

L'article de 2019 consacré au logiciel local-first par Kleppmann et ses collègues présente la maîtrise par l'utilisateur, l'accès hors ligne et le contrôle à long terme comme objectifs de conception. Il reconnaît aussi la responsabilité de l'utilisateur concernant les sauvegardes et la prévention des pertes. Il s'agit d'un argument de conception appuyé sur des prototypes, pas de la preuve que toute mise en œuvre où chacun apporte son stockage est automatiquement confidentielle, durable ou bien sécurisée.

Si une application disparaît, une exportation standard ou un fichier sous contrôle personnel peut subsister. Rien ne garantit pour autant la lisibilité future d'une base propriétaire ni la poursuite de la synchronisation. À l'inverse, le stockage géré par l'éditeur peut proposer de bons outils de restauration et de migration. Il faut examiner le format d'exportation, la suppression, la conservation, la couverture des sauvegardes et une procédure de récupération réellement testée.

Confidentialité technique et bénéfices psychologiques

Aucune donnée directe ne montre qu'un meilleur chiffrement cloud produit davantage de bénéfices liés au journal. La confidentialité peut jouer sur la volonté de se confier, mais confidentialité technique, sentiment de confidentialité, ouverture dans un exercice d'écriture et résultats psychologiques sont des variables différentes.

La rétrospective publiée par James Pennebaker seul en 2018 examine les recherches sur l'écriture expressive et précise que les mécanismes ne sont pas élucidés. Elle n'établit pas la « levée de l'inhibition » comme mécanisme confirmé, ne garantit pas d'améliorations générales de santé physique ou mentale et ne montre pas qu'un journal doit être dépourvu de toute retenue pour aider.

Une analyse observationnelle publiée par Jon Penney en 2016 a relevé des variations de fréquentation de certains articles de Wikipédia après des révélations publiques sur la surveillance. Elle n'étudiait ni journaux, ni chiffrement, ni comportement individuel d'écriture, ni santé mentale. Elle ne peut donc pas établir que le stockage cloud provoque l'autocensure dans un journal.

Une enquête menée par PEN America en 2015 interrogeait des auteurs au sujet de la surveillance et rapportait des changements déclarés dans leur recherche et leur communication. Ce n'était pas une étude randomisée sur le journal et elle ne permet pas de mesurer l'effet de l'architecture de stockage sur des résultats thérapeutiques.

Nos synthèses sur ce que les recherches sur le journal permettent d'affirmer et sur le journal et l'anxiété distinguent les résultats de protocoles précis des promesses concernant la pratique ordinaire. Un dispositif jugé acceptable peut faciliter l'écriture en pratique ; cela ne fait pas de la confidentialité un mécanisme nécessaire ou suffisant.

La confidentialité peut influer sur l'envie d'écrire. La recherche n'établit pas une chaîne simple chiffrement → sincérité → bénéfice pour la santé.

Sept vérifications concrètes

• Définir la menace. Nommer ce dont il faut se protéger et déterminer si la divulgation, la perte ou la perte d'accès est le principal souci.
• Cartographier les copies. Examiner appareils, stockage de l'éditeur, cloud choisi par l'utilisateur, caches, sauvegardes, aperçus de notification et exportations.
• Cartographier les clés. Chercher qui peut déchiffrer, comment un nouvel appareil est autorisé et ce qui se produit lors de la récupération ou du partage.
• Protéger comptes et terminaux. Employer des verrous adaptés, le verrouillage automatique, des identifiants uniques, l'authentification multifacteur lorsqu'elle existe et des logiciels à jour.
• Lire le périmètre des promesses. « Chiffré » peut couvrir le texte sans inclure titres, dates, diagnostics ou index. Un audit n'étaye que les composants et la version examinés.
• Tester récupération et exportation. Vérifier la restauration d'une copie autorisée et l'obtention d'un fichier exploitable, sans oublier une version non protégée.
• Étudier conservation et suppression. Rechercher ce qui disparaît, ce qui peut rester dans les sauvegardes et la durée de conservation des données de compte ou métadonnées.

Ce que prouvent la documentation et les audits

Une page de sécurité utile désigne les éléments protégés et les adversaires concernés. Elle distingue texte, pièces jointes, titres, dates, index, données de compte, diagnostics et paiements. Dire « les données sont chiffrées » reste incomplet sans expliquer si le fournisseur peut déchiffrer le contenu pendant le fonctionnement normal.

La documentation sur les clés devrait expliquer la création de la première clé, l'ajout d'un appareil et la perte du mot de passe, du téléphone ou du secret de récupération. Si l'assistance restaure des pages lisibles sans appareil déjà autorisé ni secret connu du seul utilisateur, un autre élément de clé ou un tiers de confiance le permet nécessairement. Ce n'est pas toujours un défaut : le système peut privilégier la récupération, mais la frontière d'accès change.

Une évaluation indépendante fournit des éléments précieux dans les limites de sa date, de la version, de son périmètre et de ses exclusions. L'examen d'une bibliothèque cryptographique ne couvre pas automatiquement notifications, droits du serveur, récupération, analyse, configuration cloud ou mise à jour ultérieure. Le code ouvert rend l'inspection possible, sans prouver à lui seul que la version distribuée correspond au code étudié ou que le service est correctement configuré.

Confidentialité et suppression sont également distinctes. Retirer une page de l'application visible ne l'efface pas nécessairement tout de suite des appareils synchronisés, des tâches en attente, des sauvegardes ou de la copie d'un destinataire. Une fenêtre de conservation facilite la récupération d'une suppression accidentelle et retarde l'effacement définitif. Il importe que cette durée soit expliquée et adaptée à la sensibilité du contenu, plutôt que d'imposer une règle unique.

Avant de confier au système des écrits irremplaçables, teste les pannes ordinaires. La restauration fonctionne-t-elle après un changement d'appareil ? L'exportation est-elle complète et lisible sans le service ? Reste-t-elle chiffrée ou devient-elle un simple fichier ? Que se passe-t-il lorsque mot de passe et matériel de récupération sont tous deux perdus ? Un plan écrit de restauration fait partie de la sécurité ; une confidentialité qui aboutit de façon prévisible à une perte définitive peut ne pas convenir.

Une réponse pratique fondée sur le risque

Le cloud peut constituer un choix raisonnable lorsque ses voies d'accès et ses compromis de récupération correspondent au modèle de menace. Un E2EE assorti d'une bonne gestion des clés peut réduire sensiblement l'accès du fournisseur. Un stockage sous contrôle personnel ou local-first peut améliorer autonomie et portabilité. Aucun de ces labels n'élimine les risques liés aux terminaux, comptes, sauvegardes, exportations, métadonnées ou pertes.

Aucune règle fondée sur les données n'impose une architecture unique à tout journal privé. Si une divulgation risque d'entraîner de graves conséquences personnelles, juridiques ou de sécurité, il est possible de minimiser les informations identifiantes, de séparer le contenu le plus sensible ou de solliciter des conseils qualifiés en sécurité ou en droit.

Une fois trouvé un dispositif utilisable, notre guide pour prendre l'habitude de tenir un journal explique pourquoi les recherches ne prescrivent ni fréquence ni format obligatoires.

Consulte la documentation actuelle, vérifie les paramètres sur chaque appareil et prépare volontairement sauvegarde et récupération. Aucune case à cocher ne rend le stockage cloud absolument sûr.