Sécurité
Dernière mise à jour le 14 septembre 2026. Seules les mesures qui existent sont listées. Ce qui manque est indiqué comme manquant.
Pourquoi cette page est directe. Une personne seule dit à un compagnon des choses qu'elle ne dit à personne d'autre : ce qui fait mal, ce qui lui fait peur, qui a arrêté d'appeler. Si cela fuyait ce ne serait pas un simple inconvénient, ce serait une humiliation. Cette page indique donc ce qui est réellement en place et, à la fin, ce qui ne l'est pas encore.
Où en sont les choses
Une machine dédiée dans l’UE, pas d’hébergement mutualisé. Fournisseur : Hetzner Online GmbH.
La parole est traitée en direct. Aucun enregistrement à divulguer, saisir ou perdre.
Certificats de Let's Encrypt, renouvelés automatiquement.
Un long jeton aléatoire par personne. Aucun compte partagé, aucun mot de passe à réutiliser ou perdre.
La connexion par mot de passe au serveur est totalement désactivée.
Indiqué par son nom dans la politique de confidentialité. Aucun autre ne reçoit de données.
Comment la mémoire de chacun reste la sienne
C’est le risque qui compte le plus dans un service comme celui-ci : quelqu’un qui ouvre une conversation et entend la vie d’un inconnu, ou pire, sa propre vie lue par quelqu’un d’autre.
Chaque requête porte le token propre à la personne. Chaque recherche de mémoire est limitée à ce token au niveau de la base de données, donc il n’existe pas de requête qui puisse renvoyer les épisodes d’une autre personne. Les tokens sont longs et aléatoires, pas séquentiels, donc ils ne peuvent pas être devinés ni parcourus en incrémentant un nombre.
Nous testons cela à chaque changement de code. Deux compagnons sont créés, l'un reçoit une mémoire, et le test essaie ensuite d'y accéder par le jeton de l'autre. S'il y arrive un jour, le changement n'est pas livré. Ce n'est pas une règle écrite sur une page, c'est un test qui doit réussir.
Ce qui quitte notre serveur, et ce qui ne quitte pas
Stockés seulement sur notre machine : texte de conversation, mémoire, profils, noms des membres de la famille, dates, notes de santé et d’humeur.
Quitte notre machine : la parole en direct et le texte de la conversation, pour le fournisseur du modèle de parole nommé dans la politique de confidentialité, pour la reconnaissance et la réponse. Selon les conditions de leur API ce contenu n'est pas utilisé pour entraîner des modèles. C'est la seule partie d'une conversation qui va ailleurs, et nous préférons le dire clairement plutôt que vous le découvriez.
Envoyé nulle part : rien n’est vendu, rien ne va à des annonceurs, et il n’y a aucun script d’analytics ou de suivi sur ce site. Il n’y a pas de bandeau de cookies parce qu’il n’y a rien à accepter.
Chercher des informations sans fuite
Quand James trouve une clinique, un livre ou une recette, il interroge des services publics ouverts : OpenStreetMap, Open Library, Wikisource, TheMealDB. Ils reçoivent le terme de recherche et une zone approximative, jamais un nom et jamais rien d’autre de la conversation.
Nous utilisons des sources réelles volontairement plutôt que laisser un modèle de langage répondre de mémoire. Une adresse de clinique inventée avec assurance, donnée à quelqu’un qui a besoin d’un médecin, est une défaillance de sécurité et pas un détail cosmétique.
Messages d’urgence
Seuls le message lui-même et l'identifiant du destinataire vont au fournisseur de messagerie. La conversation non. Chaque tentative est enregistrée avec son résultat, et un échec est signalé à voix haute à la personne plutôt que d'être avalée en silence. Croire qu'une aide arrive alors que ce n'est pas le cas est le pire résultat que ce système puisse produire, donc c'est traité comme une propriété de sécurité, pas comme un confort.
Garder le logiciel honnête
- Des tests automatiques tournent avant chaque déploiement, couvrant l’isolation des mémoires, le refus d’inventer une conversation passée, le compte rendu honnête des messages en échec, et les règles de crise.
- Chaque fichier modifié sur le serveur en production est d’abord sauvegardé, avec un horodatage, pour qu’un mauvais changement puisse être annulé immédiatement.
- Les secrets sont gardés dans des fichiers lisibles seulement par le compte de service, jamais dans la page, jamais dans le dépôt.
- Le système de consignes interdit d’inventer des souvenirs. La suite de tests vérifie le comportement, car une règle dans une consigne est une demande et un test est une preuve.
Ce qui n’est pas encore en place
Les lister est le but de la page. N’importe qui peut revendiquer les bonnes parties.
- Chaque base de données est chiffrée au repos. SQLCipher, AES-256, sur notre propre serveur en Finlande. Le fichier de clé est lisible par root seul, et les copies en clair faites pendant la migration ont été détruites, pas simplement supprimées. L'audio n'est jamais écrit sur le disque.
- Aucun audit de sécurité indépendant. Aucune société externe n'a examiné ce système. Nous le dirons sur cette page quand ce sera fait, avec la date.
- Aucune certification ISO 27001 ou SOC 2. Nous n'avons ni l'un ni l'autre et nous ne laissons pas entendre le contraire.
- Le disque lui-même n’est pas chiffré. Les bases de données le sont (voir ci-dessus), mais le chiffrement complet du disque est désactivé, ce qui est normal pour une machine qui doit redémarrer sans assistance. L'accès physique à l'hôte reste donc une vraie limite de risque et nous comptons pour cela sur les contrôles du centre de données du fournisseur.
- La clé de la base de données vit sur le même serveur. Il le faut, pour que James réponde à trois heures du matin sans qu'un humain déverrouille quoi que ce soit. Le chiffrement protège donc un disque volé ou un fichier de sauvegarde divulgué. Il ne protège pas contre un attaquant qui a déjà un accès administratif au serveur en fonctionnement. Quiconque prétend le contraire pour un service comme celui-ci survend ce service.
- Pas d’authentification à deux facteurs sur les comptes, parce qu'il n'y a pas de mots de passe : l'accès est le lien privé. C'est plus simple pour une personne de 80 ans et cela signifie aussi qu'un lien divulgué est un compte divulgué. Dites-le-nous et nous le réémettons immédiatement.
- Pas de programme officiel de prime aux bugs. Mais voyez ci-dessous, et nous répondons.
Si vous trouvez un problème
Écrivez à security@hellojames.io ou legal@hellojames.io. Dites-nous ce que vous avez trouvé et comment le reproduire. Nous répondons sous 72 heures, nous ne vous menacerons pas, et nous vous créditerons si vous le voulez.
Si vous pensez que des données ont été exposées, dites-le dans l'objet du message et nous le traitons immédiatement comme un incident : autorité notifiée sous 72 heures si nécessaire, et personnes concernées averties directement avec des mots simples.