Sécurité
Cette page s’adresse à qui doit répondre de l’usage de Stratt dans une collectivité : direction des systèmes d’information, délégué à la protection des données, responsable des achats. Elle dit ce qui est protégé et ce qui vous revient.
Elle ne décrit pas comment ces protections sont construites. Ce n’est pas une réserve de principe : publier le détail de nos mécanismes sur un site ouvert serait en remettre le plan à qui voudrait les contourner. Les éléments qu’un audit ou un marché exige se communiquent par le support, dans le cadre prévu pour cela.
Le périmètre d’un compte est son organisation
Les données d’une organisation ne sont pas visibles depuis une autre. C’est la propriété première de Stratt, et elle ne dépend d’aucun réglage de votre part : elle n’est pas une option qu’on active, c’est la façon dont le produit est construit.
Concrètement, pour un compte :
- il ne voit que les organisations auxquelles il appartient, et doit désigner explicitement, à chaque demande, dans laquelle il travaille ;
- une demande portant une organisation dont il n’est pas membre est refusée ;
- une donnée appartenant à une autre organisation est, pour lui, introuvable — pas « interdite », introuvable. La différence a son importance : un refus explicite apprendrait à qui tâtonne que la donnée existe, ce qui est déjà une information.
Un même agent peut appartenir à plusieurs organisations — un service mutualisé, un établissement public rattaché. Ses périmètres restent séparés : rien ne circule de l’un à l’autre, et ni une recherche, ni un export, ni une statistique ne les additionne.
Un droit refusé dans l’interface l’est aussi par l’API
La règle de la maison : tout filtrage de droits se fait aussi côté serveur. Ce que l’interface masque, grise ou cadenasse n’est qu’un confort d’affichage ; l’autorité est ailleurs, dans le service qui répond.
C’est une règle qu’il faut énoncer parce qu’elle n’est pas automatique : dans beaucoup d’outils, un écran masqué reste atteignable en saisissant son adresse, et une donnée retirée d’un tableau continue de voyager dans la réponse qui l’alimente. Ici, le contrôle a lieu à chaque demande, du côté qui détient les données — et c’est là, non dans l’interface, qu’il se vérifie et se corrige.
Il en découle une recommandation, qui vaut quel que soit l’outil : réservez les comptes d’administration aux personnes qui en ont l’usage. Le cloisonnement entre organisations ne dépend pas de vos réglages ; la répartition des droits à l’intérieur de la vôtre, elle, vous appartient entièrement.
Deux conséquences pratiques :
- Le retrait d’un rôle prend effet sans attendre une reconnexion. Les droits d’un compte sont relus à chacune de ses demandes, et non figés à l’ouverture de session. Un changement de rôle en remplace le précédent, et un membre retiré de l’organisation perd ses rôles avec son accès — voir la page Membres.
- Un refus vous dit lequel des deux manque. Un droit et une brique fonctionnelle sont deux choses distinctes : la première s’attribue en interne par votre administrateur, la seconde relève de ce dont votre organisation dispose. Les deux refus sont distingués, pour que vos agents sachent à qui s’adresser au lieu d’ouvrir un ticket au hasard.
Les documents et les liens de téléchargement
Les rapports, fiches et exports que Stratt produit s’ouvrent par un lien de courte durée et à usage unique.
C’est volontairement inconfortable, et voici pourquoi : un lien de téléchargement ordinaire reste valable, se recopie, part dans un courriel, atterrit dans un journal technique ou dans l’historique d’un navigateur partagé. Ici, le lien qui a servi ne sert plus.
Un de ces liens ne se transmet pas. Il ne sert qu’une fois ; le transférer produira, chez le destinataire, une page expliquant que le lien n’ouvre plus le document — jamais le document. Transmettez le fichier, si vous avez le droit de le faire, ou demandez au destinataire d’ouvrir le document depuis son propre compte.
Un effet de bord à connaître pour ne pas le prendre pour une panne : rafraîchir la page d’un rapport ouvert ne le rouvre pas. Il faut le redemander depuis l’application. C’est le prix de la propriété précédente.
Les liens de partage vers l’extérieur
Stratt permet d’ouvrir une fraction de son contenu à quelqu’un qui n’a pas de compte : une synthèse des achats pour un élu, l’assistant de classification pour un agent d’un autre service.
Ces liens sont limités par construction : lecture seule, contenu restreint à ce que l’écran d’émission annonce, aucun accès à l’application. Mais ils ont une propriété qu’il faut regarder en face :
Un lien de partage se comporte comme un mot de passe. Qui le possède voit ce qu’il ouvre, sans compte, et sans qu’aucun nom soit attaché à cette consultation. Un lien transféré est un accès transféré.
Ce qu’il faut en faire est détaillé sur la page Partage public. En résumé : un lien par destinataire, la durée la plus courte qui couvre l’usage, aucune diffusion à un public large, et la consigne de ne pas rediffuser transmise avec le lien.
La traçabilité
Stratt tient un journal d’audit par organisation : qui a fait quoi, sur quelle ressource, et quand. Il se consulte depuis l’application et s’exporte au format CSV, ce qui permet de le verser à un dossier ou de le conserver selon votre propre politique.
Sa consultation exige la permission d’administration : ce n’est pas une donnée que tout agent peut parcourir. Deux remarques à l’usage d’un délégué à la protection des données :
- le journal porte sur les actions faites depuis un compte. Une consultation faite par un lien de partage, qui n’est associé à aucun compte, n’y figure pas nominativement ;
- l’export est une copie : une fois sorti de Stratt, il relève entièrement de vos propres règles de conservation et de diffusion.
Ce que votre organisation doit tenir
Aucune des protections décrites plus haut ne compense un accès laissé ouvert. Ce qui suit n’est pas une liste de recommandations décoratives : c’est la part du travail que Stratt ne peut pas faire à votre place.
Nommer et faire expirer les clés d’API
Une clé d’API est un accès permanent, sans mot de passe et sans écran de connexion. Donnez-lui un nom qui dit à quoi elle sert, pas à qui elle appartient : c’est ce nom qui vous permettra, dans six mois, de la retirer sans casser une intégration que vous aurez oubliée.
Posez-lui une échéance chaque fois que l’usage en a une — une reprise de données, une campagne, un prestataire sous contrat. Une clé sans terme survit à la raison qui l’a fait naître.
Et passez la liste en revue : la date de dernier usage y figure. Une clé qui n’a jamais servi, ou qui n’a pas servi depuis des mois, est à supprimer. Voir Clés d’API.
Retirer les comptes qui partent
Au départ d’un agent, retirer son compte de l’organisation referme son périmètre dès sa demande suivante. C’est la première chose à faire, avant même la restitution du matériel.
Attention au point qui se laisse oublier : une clé d’API créée par cet agent ne disparaît pas avec son compte. Les clés appartiennent à l’organisation. Avant de retirer quelqu’un, regardez les clés et les liens de partage de son périmètre, et faites le ménage.
Ne pas rediffuser un lien de document
Un lien de téléchargement ou de partage n’a pas vocation à être transmis, recopié dans un compte rendu, ou collé dans une conversation de groupe. C’est la consigne la plus simple à énoncer et la plus souvent enfreinte, parce qu’elle paraît anodine : celui qui transfère un lien croit transférer un document.
Formulez-la explicitement à vos agents et à vos destinataires externes. Un lien reçu sans consigne est un lien qui sera rediffusé.
Tenir la liste de ceux qui administrent
La permission d’administration ouvre les rôles, le journal d’audit et les réglages de l’organisation. Elle doit être rare, nominative, et revue : trois administrateurs dans une collectivité de trente agents, pas quinze. Voir Comptes et rôles.
Faire des revues, à date fixe
Une fois par trimestre, un quart d’heure : les comptes de l’organisation, ceux qui administrent, les clés d’API et leur dernier usage, les liens de partage encore valables. Ce qui n’est pas revu à date fixe n’est jamais revu.
Limites connues
Ce qui suit n’est pas une faiblesse cachée mais une limite assumée, et il vaut mieux la connaître avant d’en dépendre :
- Un lien de partage du tableau de bord élu ne se révoque pas avant son échéance, et n’apparaît sur aucune liste. Sa durée de validité, choisie à l’émission, est votre seul levier — prenez la plus courte.
- Un lien public de l’assistant créé sans expiration n’expire pas. Il reste valable tant que personne ne le révoque.
- Les clés d’API n’ont pas de rotation automatique, et une clé perdue ne se récupère pas : on en crée une nouvelle, on bascule, puis on supprime l’ancienne.
- Les consultations faites par un lien de partage ne sont pas nominatives. Si votre politique exige de savoir qui a vu quoi, un lien de partage n’est pas le bon véhicule : ouvrez un compte.
Une question qui n’a pas sa réponse ici
Les éléments qu’un marché public, un audit ou une analyse d’impact réclament — hébergement, sous-traitance, conservation, chiffrement, continuité — se communiquent par le support, qui les transmet dans le cadre prévu. Ils n’ont pas leur place sur une page publique, et une réponse approximative trouvée ici ne vous servirait pas dans un dossier.