Nous avons commencé par rendre explicites les mécanismes du moteur de politiques grâce au domain learning. Dans ce contexte, les politiques combinent des conditions portant sur des indicateurs comportementaux tels que l’empreinte de l’appareil, les changements de localisation, la vélocité des dépenses et l’historique des échecs précédents, avec des résultats comme autoriser, bloquer ou déclencher une authentification renforcée. L’interface existante présentait ces règles sous forme de vues de base de données et de tables de configuration. Elle ne correspondait pas à la manière dont les analystes raisonnent sur les schémas de fraude ni à la façon dont ils expliquent leurs décisions aux équipes d’audit interne.

Lors d’ateliers avec les équipes produit, ingénierie et sécurité de Callsign pendant Sandbox Experiments, nous avons cartographié les structures de règles existantes, les scénarios de fraude à couvrir et les points où apparaissaient des conflits ou des lacunes. Cet exercice de cartographie a conduit à une séparation claire entre le modèle de détection de fraude qui attribue des scores aux événements et la couche de politiques qui applique des seuils, des dérogations et des décisions de workflow. Ce travail est devenu un exemple de UX design pour les systèmes d’IA, où l’interface contrôle la manière dont les sorties du modèle se traduisent en actions concrètes dans le monde réel.

À partir de là, nous avons défini une architecture de l’information pour la sécurité d’entreprise qui traite une policy comme l’objet central. Chaque policy regroupe ses conditions, ses actions, son historique et ses liens vers des règles associées. Les analystes peuvent suivre une policy depuis sa définition jusqu’à son évaluation sans perdre le contexte. Les décisions sont enregistrées de manière à faciliter les revues d’audit et les contrôles réglementaires liés à la SCA, au PCI DSS et à la gouvernance interne. Nous avons validé les premières versions de cette structure avec les équipes de Callsign à l’aide de scénarios concis plutôt que de schémas abstraits, puis nous l’avons ajustée en fonction de leurs retours.

Avec l’architecture en place, nous avons repensé les parcours des analystes pour refléter la manière dont les équipes fraude raisonnent réellement sur un cas. L’expérience précédente obligeait les utilisateurs à passer d’écrans de configuration à des documents de référence et à des tableaux de données lorsqu’ils souhaitaient ajuster une seule règle. Nous avons remplacé cela par un flux centré sur la policy. Les analystes identifient un scénario, ouvrent l’ensemble de policies concerné, ajustent les conditions dans leur contexte et voient immédiatement où la modification s’applique dans le workflow.

Le concept d’interaction principal reposait sur un modèle à trois gestes, conçu pour l’interaction design des analystes fraude. Les analystes glissent pour créer ou repositionner des nœuds dans le workflow, cliquent pour ouvrir et modifier les paramètres de règles en ligne, et dessinent une connexion pour relier les nœuds et définir la séquence. Ces gestes sont cohérents dans tout l’outil, ce qui réduit l’effort d’apprentissage pour des utilisateurs issus des domaines du risque ou de la conformité plutôt que du produit.

Nous avons également dû faire des trade offs de périmètre grâce au tension-driven reasoning. Pour la première version, nous avons priorisé la création de policies, la visibilité des conflits et l’explication des impacts plutôt que des fonctionnalités avancées de collaboration ou des vues complètes de l’historique des versions. Cette décision reflétait l’objectif immédiat de rendre les démonstrations auprès des équipes risque et sécurité des grandes banques efficaces et crédibles. Les premiers tests internes avec les analystes de Callsign ont confirmé que les nouveaux parcours réduisaient le temps nécessaire pour exprimer un scénario de fraude courant dans l’outil et rendaient les explications lors des appels clients plus simples.

La configuration seule ne suffisait pas. Callsign avait besoin d’un moyen pour que les analystes et les parties prenantes bancaires comprennent ce que produirait un ensemble donné de policies dans des scénarios réalistes. Nous avons créé un mode d’évaluation dans lequel les utilisateurs définissent un contexte de simulation à l’aide de filtres en langage naturel, tels que le segment client, la zone géographique ou le type de transaction. Le système exécute ensuite ces paramètres via le modèle de détection de fraude et le moteur de politiques, et présente les résultats dans une vue analytique ciblée.

La vue d’évaluation est centrale pour l’expérience utilisateur des outils de gestion des risques, car elle boucle la relation entre la configuration et l’impact. Les analystes peuvent voir à quelle fréquence un scénario conduit à une approbation automatique, à une authentification renforcée ou à un blocage, et vérifier si des cas à haut risque pourraient passer entre les mailles du filet. Pour rendre cela interprétable, nous nous sommes appuyés sur la data visualisation pour les systèmes bancaires, implémentée avec D Three, en utilisant des représentations en graphes et en flux qui mettent en évidence les zones de concentration du trafic et les points où les policies créent des goulots d’étranglement.

Nous avons maintenu une relation très claire entre la configuration et l’évaluation. Les policies sont toujours modifiées dans l’espace de configuration, et l’environnement d’évaluation consomme ces définitions sans permettre aux utilisateurs de les modifier sur place. Cette barrière évite les changements non tracés pendant l’analyse. Nous avons utilisé evidence based UX pour l’IA afin d’affiner le flux d’évaluation, en observant comment les analystes interprétaient les graphiques et où des incompréhensions apparaissaient, puis en simplifiant les libellés et les interactions en conséquence. Le résultat est une boucle contrôlée mais flexible, dans laquelle les analystes peuvent tester, ajuster et justifier des stratégies de policy sans exposer les détails internes du modèle.

Dès les premières semaines, nous avons traité chaque écran comme faisant partie d’un design system plutôt que comme un artefact isolé pendant Concept Convergence. Le système couvre la construction des workflows, la gestion des policies, les vues d’évaluation et les structures de navigation associées. Chaque composant dispose d’états documentés, de règles d’interaction et de notes d’usage. Cette base est devenue un design system pour les produits bancaires qui aide Callsign à maintenir la cohérence des nouvelles fonctionnalités de sécurité et des modules futurs.

Côté ingénierie, nous nous sommes alignés très tôt avec l’équipe front end. Les composants de policy et de workflow ont été modélisés comme des unités React pouvant être assemblées pour créer des écrans plus complexes sans duplication. Par exemple, le même module de résumé de policy apparaît dans les listes de configuration, dans le canvas de workflow et dans les résultats d’évaluation, avec un contrat de comportement cohérent. Les visualisations basées sur D Three sont intégrées dans des conteneurs React dédiés afin que les responsabilités de mise en page et de rendu soient clairement séparées, ce qui facilite l’optimisation des performances pour les jeux de données volumineux.

Nous avons structuré les livrables pour s’adapter à leur processus de développement pendant Implementation Partnership. Les spécifications suivaient la structure de leur travail existant dans Git et Confluence, et nous participions à des sessions régulières avec les ingénieurs pour résoudre les edge cases avant leur mise en œuvre. Après environ huit semaines, le projet a atteint un état stable. Les nouveaux workflows et interfaces de gestion des policies étaient prêts pour des démonstrations en environnement enterprise, et le design system était suffisamment complet pour guider les travaux internes ultérieurs. Les designers de Callsign ont ensuite utilisé ce système comme base pour développer des modules supplémentaires au-delà de la fraude et de l’authentification.