Sécurité
Ce qui empêche une erreur d'arriver
Un système sûr n'est pas un système écrit par quelqu'un qui ne se trompe jamais. C'est un système où les erreurs les plus graves sont rendues impossibles.
La transparence d'abord
Govynn n'est pas construit par un développeur de métier
Autant le dire ici plutôt que de laisser croire le contraire.
De mon point de vue, savoir qui a construit n'est pas la bonne question. La bonne question est : qu'est-ce qui, dans ce système, empêche une erreur d'arriver — indépendamment de celui qui l'a écrit ?
Voici les réponses. Elles sont vérifiables.
Les verrous
Sept contraintes qui ne dépendent pas de ma vigilance
Une bonne pratique se relâche. Une contrainte technique, non. Chacun des points ci-dessous est verrouillé dans l'architecture, pas confié à la discipline de quelqu'un.
L'envoi automatique est désactivé par conception
Govynn sait produire une réponse et l'envoyer seul. Ce mode existe dans le code, verrouillé sur « inactif ». Ce n'est pas un réglage qu'on pourrait basculer par erreur : rien ne part sans l'avocat.
Les requêtes ne sont jamais assemblées à la main
La logique sensible vit dans des fonctions côté base de données, appelées avec des paramètres. La classe d'erreur la plus connue — l'injection — n'a pas de porte d'entrée.
Aucun secret ne vit dans l'interface
L'application lit et écrit dans la base ; elle ne parle jamais directement aux modèles d'intelligence artificielle. Les appels et les clés restent côté serveur. Il n'y a rien à voler côté navigateur.
Le journal ne peut pas être réécrit
La table d'audit est en écriture seule, verrouillée au niveau de la base. Une ligne écrite ne peut plus être modifiée. Ce n'est pas une politique interne, c'est une contrainte technique.
Un document ne peut pas donner d'ordre au système
Le contenu d'une pièce jointe est traité comme une donnée à lire, jamais comme une consigne à suivre. Un document reçu ne peut pas modifier le comportement de Govynn.
Les liens de téléchargement sont éphémères
Ils expirent en moins d'une minute et ne peuvent pas être devinés. Un identifiant inconnu ne révèle même pas si une pièce existe.
Aucun contenu client n'est journalisé
Les journaux techniques portent des identifiants, des durées, des compteurs et des classes d'erreur. Jamais un corps de message, jamais le contenu d'une pièce.
Aucune de ces sept lignes ne dépend de mon attention un jour de fatigue.
La limite
Ce que l'architecture ne couvre pas
La rigueur trouve les erreurs. La connaissance trouve les failles. Ce ne sont pas les mêmes choses.
Une erreur se voit : le système fait quelque chose de visiblement faux, on le reproduit, on le corrige. Une faille ne se manifeste pas. Elle attend quelqu'un qui la cherche. Et on ne teste jamais ce qu'on n'imagine pas.
C'est la limite honnête de ce qui précède. Les sept verrous ferment des portes connues ; ils ne prouvent pas qu'il n'en existe aucune autre.
Govynn fera l'objet d'un audit de sécurité indépendant avant le raccordement du premier cabinet.Pas après. Avant.
Un audit de sécurité vérifie qu'on ne peut pas entrer par effraction. Il ne se substitue pas au cadre de protection des données, qui relève d'un autre travail. RGPD et AI Act
À me poser
Les questions à poser
Vous n'avez pas à me croire sur parole. Voici les questions que je vous invite à poser — à moi, et à tout autre outil que vous envisagez.
01Le mode d'envoi automatique existe-t-il ? Est-il désactivé par réglage, ou par conception ?
02Le journal des actions peut-il être modifié après coup ?
03Où sont traitées les données, et par qui ?
04Le contenu de mes documents alimente-t-il des décisions automatiques ?
05Un audit de sécurité indépendant a-t-il été réalisé ? Par qui, et quand ?
Une réponse claire à ces cinq questions vaut mieux qu'une page de promesses.
Une question
Une question sur la sécurité ?
Les questions techniques sont les bienvenues, y compris les plus exigeantes. Elles orientent ce qui sera construit.