Ceci est un scénario illustratif, pas un cas client. Il n’utilise aucune organisation réelle, aucune personne réelle et aucun résultat revendiqué. Son objectif est de montrer comment le pack exécutable Vendor Security de Threada porterait une revue de sécurité de routine de la demande jusqu’à une décision consignée. Chaque surface décrite ci-dessous est une capacité produit réelle ; la situation est inventée à des fins d’illustration.
Les équipes de sécurité consacrent une part étonnamment importante de leur semaine à des revues qui sont pour la plupart routinières et occasionnellement sérieuses. Un nouvel outil SaaS a besoin d’une validation. Un fournisseur veut traiter des données clients. Une exception est demandée par rapport à une politique en vigueur. La plupart suivent une forme connue ; quelques-unes exigent un examen réel. La partie difficile est rarement l’analyse — c’est de garder chaque revue cohérente, fondée sur des preuves et consignée.
Voici comment ce travail s’exécuterait à travers le pack Vendor Security de Threada.
La forme du travail
Vendor Security est un pack de workspace doté d’un archétype case et de trois intentions définies :
- Revue de fournisseur — évaluer un fournisseur nouveau ou en renouvellement par rapport à la politique.
- Revue de traitement des données — évaluer si un fournisseur peut traiter des données spécifiques.
- Exception de sécurité — traiter une demande de dérogation à un contrôle en vigueur.
Un examinateur n’a pas à décider quel formulaire ouvrir. Il énonce l’intention, et le runtime la transforme en un WorkItem structuré dans la file de sécurité.
Une présentation
Imaginez qu’une demande arrive : une équipe veut adopter un nouveau fournisseur d’analytique qui recevrait des données d’usage produit. Dans ce scénario, elle arrive par un canal de réception configuré et devient un WorkItem.
Intention. L’examinateur (ou le demandeur, via un canal) décrit le résultat dont il a besoin — « passer en revue ce fournisseur d’analytique pour l’approbation du traitement des données. » Le runtime extrait le fournisseur, les catégories de données en jeu et un indicateur de risque initial, puis le classe dans la file Vendor Security.
Canvas. Le WorkItem s’ouvre sur un canvas adaptatif. Plutôt qu’un formulaire vierge, le workspace assemble les champs dont ce type de revue a besoin : catégories de données, lieu de traitement, sous-traitants, le profil de politique pertinent. Là où une information manque, il la demande précisément, au lieu de présenter un questionnaire indifférencié.
Preuves. Le tiroir de preuves contient ce sur quoi repose l’évaluation — la documentation soumise par le fournisseur, les revues antérieures du même fournisseur et les citations vers la politique applicable. Si le système ne peut pas fonder une affirmation particulière, il consigne une raison de repli plutôt que d’affirmer une confiance qu’il n’a pas. L’examinateur peut voir, d’un coup d’œil, la fraîcheur de chaque source.
Contrôles. C’est là qu’une revue devient une décision. Approuver le traitement des données pour un nouveau fournisseur est une action lourde de conséquences, elle passe donc par la surface de contrôles gouvernés : une proposition, puis une approbation explicite par rapport à la version de politique active. Si la politique exige un second approbateur pour cette catégorie de données, la barrière l’impose. Rien ne s’exécute silencieusement.
Journal d’exécution. Chaque étape s’accumule dans le journal d’exécution — la réception, les demandes d’informations manquantes, les preuves consultées, l’approbation et qui l’a donnée, et le résultat final consigné. Comme les actions des participants IA apparaissent comme des événements d’acteur distincts, le journal montre clairement quelles étapes le système a gérées et lesquelles une personne a décidées.
Ce qu’il reste à l’équipe
À la fin, l’équipe de sécurité dispose de trois choses qu’elle aurait autrement dû assembler à la main :
- Une revue cohérente. La même intention produit toujours la même forme de workspace, de sorte que les revues ne dérivent pas en rigueur entre une semaine chargée et une semaine calme.
- Une décision fondée. L’approbation est liée à des preuves précises et à une version de politique nommée, et non au souvenir d’un examinateur.
- Un reçu. Toute la revue est consignée — défendable devant un auditeur et lisible pour le prochain examinateur qui reprend un cas similaire.
Les revues de routine avancent rapidement parce que le workspace fait l’assemblage. Les sérieuses font l’objet d’un examen humain complet parce que la surface de contrôles l’exige. Cette répartition — automatiser la routine, orienter les cas réellement difficiles vers les personnes — est tout l’intérêt.
Pourquoi nous publions ceci comme un scénario
Nous pourrions habiller cela en un cas de réussite client avec un pourcentage impressionnant en prime. Nous ne le ferons pas. Tant qu’un client réel et consentant ne partagera pas de résultats réels, tout ce que nous imprimons ici est une illustration, et nous préférons l’étiqueter honnêtement plutôt que de laisser entendre une preuve que nous n’avons pas.
Ce qui est réel, c’est le pack. Vendor Security est un flux de travail installable sur le même runtime gouverné que tout autre pack Threada, avec les intentions et les cinq surfaces décrites ci-dessus. Si vous voulez voir la version exécutable plutôt que la présentation, le catalogue de packs est l’endroit où commencer.