Comment Rationale protège ce que votre équipe décide

Deux sortes de données, tenues à part

Rationale sépare ce dont il a besoin pour faire tourner le service de ce que votre équipe écrit. La première sorte (identifiants, états, ancres, horodatages, noms de dépôts, de branches et de fichiers, handles de tâches) est lisible par le serveur, parce que le routage, les avertissements et l'audit en ont besoin. La seconde est chiffrée dans la base de données avec des clés conservées dans l'environnement du déploiement, jamais dans la base ni dans le dépôt : le texte des décisions (question, choix, critères, options écartées, hypothèses, conditions de réexamen et citations), des notes, des tâches, des passations, des résumés, des digests et des titres de session ; les titres, descriptions et fils de revue des pull requests ; les tokens des connecteurs ; et les noms, identifiants, adresses e-mail et photos que Jira et GitHub donnent pour les personnes.

Le contenu de la seconde sorte ne passe jamais dans les colonnes, les journaux, les événements ni les messages d'erreur de la première. Les journaux de requêtes filtrent le texte des décisions et les identifiants de connexion, et les événements d'audit ne portent que des ids, des nombres et des états. Le contenu des décisions est en ajout seul : une modification ajoute une version et n'écrase rien.

Ce qui reste sur vos machines

• Transcriptions. Le client extrait les décisions sur la machine de la personne, avec l'agent qu'elle utilise déjà. Nous recevons les décisions, de courtes citations des propres mots de la personne et des métadonnées (id de session, numéros de tour, dépôt, branche, commit, heure, coût équivalent). La transcription elle-même ne va nulle part sauf chez le fournisseur de l'agent, comme toujours.
• Dépôts. Nous ne les clonons jamais et ne stockons aucun fichier. Une décision est ancrée à des chemins ; quand une décision nomme une classe, une table ou une clé de ticket, la correspondance avec le contenu d'un fichier se fait sur la machine, sur 512 Ko de texte au plus, et ce contenu ne la quitte jamais.
• Chemins de fichiers. Quand votre agent lit ou modifie un fichier, le hook compare son chemin à un index local des décisions ancrées et n'interroge le serveur qu'en cas de correspondance. Un chemin auquel aucune décision n'est ancrée ne quitte jamais la machine.
• Secrets. La valeur d'un secret n'entre jamais dans une décision, une note ou une passation : elle est refusée dans ce que les personnes et les agents écrivent, et caviardée dans le texte capturé et les citations. L'analyse cherche les clés privées, les clés cloud et API, les tokens GitHub, GitLab, Slack et Stripe, les JWT, les mots de passe dans les URL et les valeurs écrites après des mots comme password ou token ; le serveur n'enregistre que le type de secret refusé, jamais la valeur. Les hôtes, les URL et l'endroit où vit un secret (un chemin de coffre, le nom d'une variable d'environnement) sont bienvenus.

En transit

• Chaque connexion à Rationale utilise HTTPS, avec des certificats Let's Encrypt et HTTP Strict Transport Security, sous-domaines compris ; le HTTP en clair est redirigé.
• Le client vérifie TLS avec le magasin de certificats de votre plateforme : un proxy d'entreprise avec son propre certificat racine fonctionne sans rien affaiblir.
• Les livraisons de webhooks de GitHub et de Jira ne sont acceptées qu'avec une signature valide du fournisseur.
• Les e-mails que nous envoyons partent par une connexion chiffrée vers notre fournisseur d'e-mail.
• Ce site web ne dépose aucun cookie, ne charge aucun script tiers et envoie une Content-Security-Policy qui n'autorise que ses propres scripts, par hachage. L'application ne dépose que le cookie signé qui vous garde connecté ; ni l'un ni l'autre ne porte de traceur.

Connexion

• Aucun mot de passe. Rationale n'en stocke aucun. Les personnes se connectent par un lien envoyé à leur e-mail, valable une seule fois, pendant 15 minutes ; le token voyage après le # de l'adresse, que les navigateurs n'envoient jamais à un serveur, et n'atteint donc jamais nos journaux ni le proxy de quiconque. Une session de navigateur dure 30 jours.
• Appareils. rationale init connecte une machine avec un code d'appareil : le client affiche un code de huit lettres, vous le saisissez dans l'application en étant connecté, choisissez l'espace de travail et autorisez ou refusez. Les codes expirent après 10 minutes et sont stockés sous forme de condensés. Le token de l'appareil est remis une seule fois, stocké en condensé SHA-256, limité à un espace de travail, cesse de fonctionner après 90 jours sans usage et peut être révoqué à tout moment depuis la page Devices ; retirer un membre révoque les siens.
• Clients MCP. Claude, ChatGPT, Cursor et tout client MCP se connectent en OAuth 2.1 : enregistrement dynamique des clients, clients publics uniquement, PKCE avec S256 obligatoire, adresses de redirection en HTTPS ou en boucle locale. Les codes d'autorisation durent 5 minutes et sont à usage unique, les tokens d'accès durent une heure, les tokens de rafraîchissement tournent à chaque usage et durent 90 jours. Sur la page de consentement, vous choisissez les espaces de travail que le client peut atteindre ; votre appartenance est revérifiée à chaque requête, et la connexion se révoque depuis la même page Devices.
• Pas de clés API pour les personnes. Il n'existe aucune clé personnelle à coller dans un fichier de configuration ou à laisser fuir dans un dépôt. Les seuls identifiants sont le token d'un appareil et les tokens d'une connexion MCP, chacun révocable séparément.
• Connecteurs. Jira et GitHub se connectent en OAuth avec le compte de chaque membre, jamais avec un token partagé ou un mot de passe. L'aller-retour utilise un état aléatoire à usage unique, valable 10 minutes et lié à la session de navigateur qui l'a lancé.
• Limites de débit. Les liens de connexion, les codes d'appareil, les points de terminaison OAuth et MCP et le script d'installation sont limités en débit par adresse ou par token.

Qui peut voir quoi

• Espaces de travail. Chaque enregistrement appartient à un espace de travail et n'est accessible qu'à travers lui : un espace auquel vous n'appartenez pas est indiscernable d'un espace qui n'existe pas. Les propriétaires gèrent les membres, les connecteurs et le journal d'audit.
• Votre propre vue de Jira et de GitHub. Les connecteurs utilisent OAuth avec le compte de chaque membre, jamais un token partagé ; chaque personne ne voit donc dans Rationale que les tickets, projets, dépôts et pull requests que son propre compte peut voir.
• Enregistrements privés. Une décision, une passation, une tâche créée dans Rationale ou une session entière peut être privée : visible par sa personne et ses propres agents, jamais par l'équipe, propriétaires compris. C'est la personne qui décide, d'un clic ou avec ses propres mots via son agent ; un agent ne change jamais la visibilité de lui-même.
• Les agents agissent en leur nom. Un agent travaille via l'appareil ou la connexion MCP d'un membre, étiqueté comme agent, pour le compte de ce membre. Il ne voit jamais plus que la personne pour laquelle il travaille.

Ce que notre personnel peut et ne peut pas voir

Le personnel de Rationale utilise une administration sur son propre hôte, ouverte par un lien e-mail réservé au personnel dans une session de 8 heures derrière un cookie limité à cet hôte ; une session de membre ne l'ouvre jamais. Elle montre la mécanique de chaque client en chiffres : captures, échecs, appareils, tâches de fond, métriques.

• Elle ne peut pas déchiffrer. Chaque requête d'administration tourne avec un fournisseur de clés qui n'a aucune clé : lire un attribut chiffré lève une erreur au lieu de l'afficher. Un test parcourt toutes les pages d'administration avec un contenu sentinelle et échoue si ce contenu apparaît, en clair ou chiffré.
• Chaque regard est dans votre journal. Chaque page d'administration qui montre les données d'un espace de travail écrit un événement staff.viewed dans le journal d'audit de cet espace, où les propriétaires le lisent sous le filtre Staff.
• Pas de connexion en tant qu'un autre. Le personnel n'a aucun moyen d'ouvrir votre espace de travail à votre place. Aucune page, API ni outil MCP ne peut accorder le statut de personnel : il ne change que depuis la console de production auditée.
• Les consoles sont enregistrées. Une console de production peut lire le contenu ; en ouvrir une écrit donc un événement ops.console_opened avec l'opérateur avant d'accepter la moindre saisie ; si l'événement ne peut pas être écrit, la console ne s'ouvre pas. Nous n'en ouvrons une que pour un support que vous avez demandé, une demande relative à la vie privée ou un incident.
• Les outils de confidentialité sont audités aussi. Exporter ou effacer une personne, exporter ou supprimer un espace de travail passe par des outils audités qui écrivent leurs propres événements, sans contenu ; l'export d'un espace n'est envoyé qu'à l'un de ses propriétaires.

Chaque lecture est consignée

Chaque création, lecture et confirmation d'une décision écrit un événement d'audit : une décision ouverte, une liste ou une recherche affichée, un contexte remis à un agent, un avertissement montré. Les événements portent des ids, des nombres et des états, jamais de contenu, et sont en ajout seul. Les propriétaires lisent le journal de leur espace de travail dans les Réglages, avec l'activité des membres, des agents et du personnel, le canal (web, client, MCP) et l'adresse IP, filtré par changements, lectures ou accès du personnel.

La provenance est explicite sur chaque enregistrement : observé, dérivé, inféré par un agent, ou confirmé par une personne. Un enregistrement ne devient confirmé que par une action humaine : un clic dans l'application, les propres mots de la personne dans une session (le client les vérifie contre la transcription avant l'envoi et écarte tout ce qu'un agent a écrit sur une confirmation), ou la fusion sur GitHub de la pull request qui portait la décision sur sa branche. Un agent qui dit que quelqu'un a confirmé n'est pas une confirmation.

Le client

• Un seul binaire, sans runtime. Il s'installe dans votre répertoire personnel sans sudo et ne modifie jamais vos fichiers de shell. La première installation fait confiance à TLS vers l'hôte des fichiers, comme tout curl | sh ; chaque mise à jour suivante est vérifiée par le client lui-même contre un manifeste signé.
• Chaque version est signée avec minisign. Deux clés publiques sont compilées dans chaque binaire : la clé de release, qui signe chaque manifeste, et une clé de secours hors ligne qui ne sert qu'à remplacer la première ; les clés secrètes ne vont jamais dans un dépôt ni sur un serveur. Une mise à jour qu'aucune des deux n'a signée, un manifeste rejoué ou un retour en arrière de version sont refusés ; la taille et le SHA-256 de chaque fichier sont vérifiés ; un nouveau binaire qui échoue à son autotest est annulé, et rationale update --rollback remet la version précédente à la demande.
• Sa configuration n'est lisible que par votre utilisateur (mode 600). Les hooks ne bloquent jamais votre agent : chacun fait au plus une courte requête, deux secondes au maximum, et celui qui échoue se termine en silence.
• rationale uninstall retire les hooks et le watcher ; révoquer l'appareil dans l'application invalide son token.

Où tourne le service

Un serveur et une base de données PostgreSQL managée chez DigitalOcean, jointe par le réseau privé, avec des sauvegardes quotidiennes et sept jours de récupération à un instant donné. Le pare-feu n'autorise que SSH, HTTP et HTTPS ; SSH se fait par clé uniquement ; les mises à jour de sécurité s'installent sans intervention. Les secrets arrivent au serveur comme variables d'environnement au déploiement, lisibles par root seulement, jamais dans le dépôt ni dans la base. Chaque changement passe les tests, Brakeman, bundler-audit et importmap audit en CI avant d'être fusionné. Nos comptes chez les fournisseurs utilisent l'authentification à deux facteurs.

Nous sommes établis au Portugal ; les transferts vers les États-Unis se font donc dans le cadre du RGPD : la certification de DigitalOcean au titre du Data Privacy Framework UE-États-Unis (avec ses extensions britannique et suisse) et les clauses contractuelles types de son accord de traitement des données ; les clauses contractuelles types et le Data Privacy Framework pour Resend. Chaque fournisseur est lié par un accord écrit de traitement des données. La politique de confidentialité tient la liste qui fait foi.

Combien de temps nous conservons les données

Le contenu d'un espace de travail (décisions, tâches, notes, passations) reste tant que l'espace existe et est supprimé dans les 30 jours suivant la demande d'un propriétaire ou 90 jours après la fin du service ; les sauvegardes disparaissent en sept jours. Les données personnelles ont des durées publiées, appliquées par une tâche quotidienne :

La politique de confidentialité est la liste qui fait foi. Les propriétaires peuvent demander un export de tout l'espace de travail (déchiffré, envoyé à un propriétaire seulement) ou sa suppression ; une personne peut demander son propre export ou son effacement à privacy@rationalehq.com.

Si quelque chose tourne mal

Nous tenons un plan écrit de réponse aux incidents, sous la responsabilité du gérant de l'entreprise. Il couvre un secret ou un token qui a fui, un ordinateur portable ou un compte fournisseur volé, un accès non autorisé, des données envoyées à la mauvaise personne, des données perdues ou corrompues, et une vulnérabilité exploitée. En cas de doute, nous traitons l'événement comme un incident et l'écrivons dans le registre.

1. Contenir, dans la première heure : renouveler ce qui a fui, révoquer appareils et connexions, désactiver un connecteur, bloquer une adresse, mettre un serveur hors ligne si nécessaire ; copier les journaux avant leur rotation.
2. L'écrire dans le registre des violations, avec les heures en UTC, les faits seulement, conservé au moins cinq ans.
3. Évaluer quelles données, de qui, et si elles étaient chiffrées : le contenu des décisions est chiffré avec des clés hors de la base de données, donc une copie de la base sans les clés n'expose que des identifiants et des états.
4. Notifier : les propriétaires de chaque espace de travail touché sous 48 heures, par e-mail, avec ce qui s'est passé, quelles données, ce que nous avons fait et ce qu'ils doivent faire ; l'autorité portugaise de protection des données sous 72 heures quand le RGPD l'exige, et les personnes concernées sans retard injustifié quand le risque pour elles est élevé ; Atlassian sous 48 heures quand le connecteur Jira est concerné ; les résidents américains selon la loi de leur État.
5. Récupérer depuis les sauvegardes (sept jours de récupération à un instant donné), redéployer, vérifier.
6. Apprendre : cause racine, correctif, mise à jour du plan et du registre des traitements.

Le registre ne contient aucune entrée à la date de cette page. Le plan prévoit un exercice au moins une fois par an, consigné dans le registre.

Conformité et certifications

Rationale est un service d'une entreprise portugaise et fonctionne sous le RGPD pour tout le monde, où que vous soyez. La politique de confidentialité nomme chaque fournisseur, chaque finalité et chaque durée de conservation. Les conditions incluent des Conditions de traitement des données, avec notification d'un incident de sécurité touchant des données personnelles sans retard injustifié et sous 48 heures, et des Conditions de confidentialité pour les États américains. Nous ne vendons pas de données personnelles, n'affichons aucune publicité, n'utilisons aucune analyse d'audience tierce et n'entraînons pas de modèles d'IA sur votre contenu.

Certifications : aucune pour l'instant. Nous ne sommes pas certifiés SOC 2 ni ISO 27001, et aucun audit n'est en cours. SOC 2 est prévu dès que Rationale aura la traction qui le justifie ; cette page dira quand un audit commence et quand un rapport est disponible. D'ici là, cette page, la politique de confidentialité et les conditions sont la preuve, et nous répondons aux questionnaires de sécurité sur demande à security@rationalehq.com.

Ce qui manque encore

Dit clairement, pour que vous n'ayez pas à demander :

• SOC 2 et ISO 27001. Pas de rapport et pas d'audit en cours. Prévu avec la traction.
• SSO avec SAML et provisionnement SCIM. Pas construits. Ils relèvent du plan Business, qui n'est pas en vente tant qu'ils n'existent pas. Aujourd'hui chaque membre se connecte par un lien e-mail, et les propriétaires ajoutent et retirent les membres à la main.
• Export du journal d'audit. Les propriétaires lisent le journal dans les Réglages ; il n'y a pas encore de téléchargement. Prévu pour le plan Business.
• Un second facteur à nous. La connexion se fait par lien e-mail : la protection de votre boîte est celle de votre compte ; Rationale n'ajoute pas de second facteur propre.
• Notarisation Apple du binaire macOS. Les versions sont signées avec minisign et vérifiées par le client lui-même, mais pas encore notarisées par Apple : installez avec la commande ou Homebrew plutôt que par un téléchargement depuis le navigateur.
• Windows. Le client fonctionne sur macOS et Linux ; sous Windows, l'installateur le dit et s'arrête.
• Hébergement hors des États-Unis. Les données vivent aux États-Unis sous les mécanismes de transfert ci-dessus ; il n'y a pas encore de région UE.

Signaler une vulnérabilité

Écrivez à security@rationalehq.com. Nous accusons réception sous un jour ouvré, vous tenons informé pendant la correction et n'engageons aucune action contre une recherche de bonne foi qui respecte les données des autres clients. Notre security.txt dit la même chose, sous une forme lisible par machine.

• Indiquez l'hôte, les étapes pour reproduire et ce que vous avez observé.
• N'accédez pas, ne modifiez pas et ne conservez pas des données qui ne sont pas les vôtres ; arrêtez dès que le problème est démontré.
• Laissez-nous un délai raisonnable pour corriger avant de rendre le problème public.