Document de conformitéISO 27001 A.5.1

Politique de sécurité de l'information

Ce que Stilops veut atteindre en sécurité de l'information, qui décide de quoi et quelles règles s'appliquent — y compris ce que la politique doit admettre.

Ceci est une traduction automatique du document néerlandais. En cas de divergence, le texte néerlandais fait foi. Lire le texte néerlandais

Version31-10-2026LangueFrançaisPDFFichier texte

Contrôle iso27001:A.5.1 dans le registre de conformité ; soutient également la clause 5 (leadership), iso27001:A.6.7 (travail à distance) et iso27001:A.8.24 (cryptographie).

Établie par le propriétaire le 2-10-2026. Le propriétaire a en même temps accepté les risques résiduels que le registre des risques traite comme « acceptés », dont le fait qu'une seule personne soit propriétaire et administrateur et l'absence de test d'intrusion externe.

Ceci est la politique que demande ISO 27001 A.5.1 : un document unique indiquant ce que Stilops veut atteindre en matière de sécurité de l'information, qui décide de quoi, et quelles règles s'appliquent. Il est volontairement court et décrit ce qui se passe réellement. Une politique plus belle que la pratique n'est pas une politique, mais un vœu.


1. Objet et champ d'application

Stilops fournit des agents IA qui exécutent du travail pour le compte d'une organisation. Les clients nous confient à cet effet leurs données d'entreprise, et parfois des données à caractère personnel de leurs propres relations. L'essence du produit n'est pas seulement que le travail soit effectué, mais qu'il soit possible de retracer a posteriori ce qui s'est passé et qui l'a approuvé.

Cette politique s'applique à l'ensemble de la plateforme : le portail clients, l'environnement d'administration, le site public, l'exécution des tâches des agents, et l'infrastructure sur laquelle tout cela fonctionne. Elle s'applique à toute personne qui y travaille — à l'heure actuelle le propriétaire — et aux agents qui travaillent eux-mêmes dans la base de code.

2. Objectifs

  1. Confidentialité. Les données d'une organisation ne sont pas accessibles à une autre organisation, et les secrets des systèmes connectés sont stockés de manière chiffrée et ne sont pas montrés à un agent. Lorsqu'un agent a techniquement besoin d'un secret, il ne le reçoit que pour la durée de cette tâche ; les exceptions figurent sous « Cryptographie et gestion des clés » et au §5.
  2. Intégrité et traçabilité. Ce qu'un agent a proposé, qui l'a approuvé et quel en a été le résultat est consigné et n'est pas modifié a posteriori.
  3. Disponibilité. Le service fonctionne, et une panne est réparable sans perte de la piste d'audit.
  4. Autorité humaine. Aucun effet sans qu'un humain l'ait approuvé.

Le quatrième n'est pas chez Stilops une mesure de sécurité mais le point de départ du produit. Les trois autres existent pour rendre ce quatrième crédible.

3. Qui décide de quoi

SujetQui
Établir et modifier la politiqueLe propriétaire
Évaluation de la sécurité, renseignement sur les menaces, analyse des incidentsLe rôle de RSSI
Tout ce qui touche à une obligation légale ou devient une déclaration publiqueLe propriétaire, toujours — ceci n'est pas délégable et ne peut pas être désactivé par mandat
Exécution technique, modifications du logicielLes rôles de développement, via le contrôle qualité établi
Attribution de pouvoirs à un agentLe propriétaire

Le fait que le propriétaire soit le seul humain de ce tableau est un fait et non une lacune à dissimuler — mais c'est bien le plus grand risque individuel du registre des risques, et il y figure en tant que tel.

4. Règles applicables

Accès. L'accès est nominatif et par rôle. Les mots de passe sont stockés sous forme de hachage fort et salé. L'authentification à deux facteurs est disponible pour chaque utilisateur, et obligatoire comme étape supplémentaire pour les actions ayant des conséquences — notamment la confirmation publique d'une déclaration de conformité. Une limite de débit s'applique à la connexion et aux formulaires.

Poste de travail et travail à distance. Stilops n'a pas de bureau ; toute l'administration s'effectue à distance, depuis le poste de travail du propriétaire. Les règles suivantes s'appliquent à cet égard : le disque de l'appareil est chiffré et l'écran se verrouille automatiquement après une courte inactivité ; le système d'exploitation et le navigateur reçoivent les mises à jour de sécurité dès leur publication ; les comptes auprès des fournisseurs de code, d'hébergement, de DNS et de paiement sont protégés par l'authentification à deux facteurs ; l'accès aux serveurs se fait uniquement par clés SSH, et non par mots de passe ; les données de production ne sont pas copiées sur le poste de travail, sauf une copie temporaire pour une restauration ou une enquête, qui est ensuite supprimée. En cas de perte ou de vol de l'appareil, les sessions sont terminées dans les 24 heures et les clés qui s'y trouvaient sont renouvelées, et il est évalué s'il s'agit d'une violation de données conformément à la procédure de gestion des incidents et des violations de données.

Secrets. Les secrets des systèmes connectés et de l'infrastructure sont stockés de manière chiffrée (AES-256-GCM) avec une clé par environnement, et ne sont déchiffrés qu'au moment où une tâche en a besoin. Ils n'apparaissent jamais dans l'instruction adressée au modèle de langage. L'inclusion accidentelle d'un secret dans un commit n'est que partiellement empêchée : un test du contrôle qualité recherche dans le code des secrets présentant un préfixe fixe (tels que les clés GitHub, Anthropic et Stripe et les clés privées), et les mêmes motifs sont appliqués à ce que les agents soumettent comme modification. Un secret sans préfixe reconnaissable, tel qu'un jeton Hetzner ou un mot de passe, échappe à ce contrôle. Un utilisateur qui saisit un secret dans un message de chat voit ce message intercepté avant que le modèle ne le voie.

Exécution des tâches des agents. Une tâche d'agent s'exécute de manière confinée sous un compte propre et restreint issu d'un pool fixe. S'il y a plus de tâches simultanées que la taille du pool, une tâche s'exécute provisoirement sous le compte d'agent partagé, où une autre tâche simultanée peut lire sa configuration déchiffrée. Cela sera corrigé. Un agent d'un client n'obtient jamais accès aux données d'une autre organisation, n'a pas de boîte aux lettres et n'envoie pas d'e-mail.

Modifications du logiciel. Chaque modification passe par un contrôle automatisé établi : style, vérification des types, l'ensemble complet des tests, un contrôle des secrets inclus dans les commits et un contrôle des vulnérabilités connues dans les dépendances. Une modification d'un contrôle ou d'un pouvoir doit en outre être volontairement cassée afin de prouver que le test correspondant passe au rouge — un contrôle qui n'a pas été cassé ne protège rien tant que le contraire n'a pas été démontré.

Modifications et conformité. Chaque modification est également évaluée, avant sa fusion, quant à ce qu'elle signifie pour la conformité : touche-t-elle à quelque chose que promet un document de conformité, les contrôles ou les conditions ? Un logiciel détermine quels sujets une modification touche ; un agent d'évaluation distinct, en lecture seule, apprécie alors si la modification peut passer telle quelle, si un document de conformité doit être modifié en même temps (ce que Stilops met à jour lui-même dans la même modification, après quoi le propriétaire établit le nouveau texte), si le propriétaire doit décider, ou si la modification est bloquée. Une modification des conditions, de la déclaration de confidentialité, du contrat de sous-traitance ou de la liste des sous-traitants ultérieurs, un risque qui doit être accepté et une mesure qui s'affaiblit, relèvent toujours du propriétaire ; un test qui n'aboutit pas à un avis également. En outre, chaque trimestre, Stilops confronte tous les documents de conformité au code et fait de chaque écart un constat.

Consignation. Les actions des administrateurs et des utilisateurs de l'organisation sont consignées en mode append-only. Une action consignée n'est ni modifiée ni supprimée.

Cryptographie et gestion des clés. Le trafic transite par TLS. Les données au repos constituant un secret sont chiffrées avec AES-256-GCM, avec deux exceptions connues : le jeton de lecture de courte durée de la connexion Search Console (valable une heure au plus) est volontairement stocké sans chiffrement, et la clé API Anthropic pour les exécutions des clients se trouve, pendant une telle exécution, jusqu'à deux minutes, sous forme de fichier sur le disque. La clé est stockée par environnement en dehors du code source et de la base de données et n'est lisible que par le service lui-même, sur les machines où les agents s'exécutent sous un compte distinct (un paramétrage distinct pour ce compte). Là où cette séparation n'est pas paramétrée, comme sur les environnements de développement et de production locaux, les agents s'exécutent sous le même utilisateur que le service et peuvent lire à la fois la clé et les valeurs chiffrées.

Ce qu'un agent peut lire, y compris là où la séparation est bien paramétrée : la clé API Anthropic pendant une exécution client ; le jeton Cloudflare ordinaire ; tant que le tunnel local pour les secrets des connexions n'est pas activé, le fichier de configuration déchiffré d'une tâche ; et, lorsque le pool est plein, également le fichier de configuration d'une autre tâche simultanée, avec les secrets de connexion d'un client. Là où ce tunnel est activé, ces secrets n'aboutissent pas dans un fichier lisible. La base de données contenant les données de toutes les organisations est elle aussi lisible par le compte d'agent, car les serveurs qu'utilisent les agents en ont besoin. Un agent d'un client n'y accède pas : il n'a alors pas de shell, un contrôle fixe avant chaque action limite sa lecture à son propre répertoire de travail et à ses pièces jointes, et les outils qu'il reçoit filtrent selon son organisation. Cette séparation se situe dans l'application, et non dans le système d'exploitation : si ce contrôle disparaît, rien n'arrête le compte. Il s'agit de risques résiduels, et le premier figure dans le registre des risques (R13).

Les clés d'accès externes sont renouvelées dans la mesure où le fournisseur le permet. Le jeton Cloudflare est renouvelé par Stilops lui-même. Pour Hetzner, GitHub, Anthropic, Stripe et MXroute, Stilops crée un rappel sous forme de constat et le propriétaire renouvelle lui-même la clé. Pour les autres connexions (S3, OneDrive, VirusTotal, LinkedIn, PageSpeed, Bing, le compte de service Google et les mots de passe SMTP et IMAP), aucun rappel n'est prévu ; seule s'applique la rotation manuelle des clés figurant dans la planification opérationnelle. Pour Hetzner s'y ajoute une surveillance qui signale chaque action du journal d'actions de Hetzner qui ne provient pas de Stilops lui-même ; pour les autres fournisseurs, cette surveillance n'existe pas.

Un changement de clé après une fuite (présumée) invalide les confirmations publiques de conformité existantes : celles-ci doivent alors être données à nouveau, car quiconque possédait l'ancienne clé a pu les falsifier. Lors d'un changement ordinaire, Stilops signe à nouveau, avec la nouvelle clé, chaque confirmation qui était valide avec l'ancienne clé. Les sessions et les liens d'invitation et de réinitialisation expirent à chaque changement.

Incidents. Ce qui constitue un incident, la manière dont il est signalé et dans quel délai quoi est notifié à qui figurent dans la procédure de gestion des incidents et des violations de données. La décision de notifier est humaine.

Fournisseurs. Toute partie qui traite des données à caractère personnel figure avec son nom, la finalité, le pays et l'état de l'accord de sous-traitance dans la liste des sous-traitants ultérieurs — y compris lorsque cet accord fait défaut.

5. Ce que cette politique doit honnêtement admettre

  • Il n'y a pas de séparation des tâches. Une seule personne établit la politique, approuve et administre. La compensation est que la piste d'audit est complète et append-only, et que les actions les plus lourdes exigent une étape de vérification supplémentaire. C'est une compensation, pas une solution.
  • La restauration est testée, mais pas encore complètement. Le déchiffrement et le contrôle des sauvegardes ont été testés ; un exercice de restauration complet chaque trimestre est mis en place et la première exécution reste à faire. Les détails figurent dans le plan de continuité, que les clients peuvent consulter dans le portail.
  • Les secrets ne sont pas illisibles pour chaque agent. Voir « Cryptographie et gestion des clés » : la clé API Anthropic pendant une exécution client, le jeton Cloudflare ordinaire, et sur les machines sans compte d'agent séparé également la clé elle-même. Leur sécurisation est un arbitrage en suspens.
  • La séparation entre organisations dans la base de données est une séparation dans l'application. La base de données contenant les données de toutes les organisations est lisible par le compte d'agent, car les serveurs qu'utilisent les agents en ont besoin. Que l'agent d'un client n'y accède pas est assuré par un contrôle fixe dans l'application, non par le système d'exploitation : si ce contrôle disparaît, rien n'arrête le compte.
  • Il n'y a pas de test d'intrusion externe.

Ces points figurent comme point ouvert dans le registre de conformité. Ils figurent ici parce qu'une politique de sécurité qui ne mentionne que les points forts induit le lecteur en erreur quant à ce sur quoi il peut compter.

6. Conformité et révision

Le registre de conformité à l'adresse stilops.com/nalevingsregister est la mesure continue de cette politique : par norme et par contrôle, où en sont les choses, avec preuves à l'appui. Les écarts entrent sous forme de constat et sont acheminés vers la personne compétente.

Cette politique est révisée lorsque l'organisation dépasse une seule personne, lorsqu'une nouvelle catégorie de données ou un nouveau fournisseur s'ajoute, après un incident ayant un impact, et au plus tard chaque année.

Des questions sur ce document ? Écrivez à [email protected].