Planifier des parcours numériques clients sécurisés

Définition

Un flux de travail orienté clients peut englober un portail, un service web, une expérience mobile, un backend, une API, un prestataire de paiement, un processus de support et une équipe d'administration. La planification doit identifier les rôles utilisateurs et les limites d'accès ; l'authentification et la récupération ; les formulaires, fichiers, messages, tableaux de bord et statuts ; les chemins de paiement, d'abonnement, de facture, de remboursement, de résiliation et de droits d'accès ; la propriété et la conservation des données ; les intégrations tierces ; et la responsabilité opérationnelle. Elle doit aussi déterminer si le mobile ou le web est approprié, si le backend et les API existants sont prêts, et qui sera responsable de la journalisation, du support, des modifications et de la passation. La revue de sécurité et la réalisation logicielle peuvent relever de périmètres distincts.

Public concerné

Ce guide aide les équipes qui planifient :

• Un portail client ou partenaire, un flux de collecte d'informations, un tableau de bord, un parcours de paiement, une transition du web vers le mobile ou le lancement d'une application
• Un accès tenant compte des rôles, la récupération, les fichiers, les informations de statut, le support et les responsabilités d'administration
• Un changement produit impliquant des backends existants, des API, des prestataires tiers, des états de facturation ou des données clients
• Une limite plus claire entre découverte, conception, réalisation, durcissement, revue et responsabilité opérationnelle ultérieure

Ce qu'il aide à clarifier

Les questions de planification aident à révéler :

• Si les utilisateurs, rôles, règles d'accès, la récupération de compte, la propriété et la conservation des données sont compris avant le début de la réalisation
• Quels formulaires, fichiers, messages, tableaux de bord, vues de statut, états de paiement et décisions de droits d'accès franchissent les limites entre systèmes
• Si les intégrations, le backend/les API, la réalisation mobile, le stade de lancement, la journalisation, le support et la responsabilité des modifications sont prêts pour une étape suivante cadrée
• Si l'équipe a besoin d'un sprint de portail, d'une revue des paiements, d'une transition web vers mobile, d'une revue de préparation au lancement, d'un durcissement de site web ou d'une phase préalable de découverte ou de blueprint

Ce qui est inclus

• Une checklist d'achat couvrant parcours, rôles, accès, authentification, récupération, formulaires, fichiers, messages, tableaux de bord, statuts, paiements, abonnements, factures, remboursements, résiliations, droits d'accès, données et intégrations
• Des pistes de planification pour la responsabilité de l'administration, la préparation du backend/des API, le choix mobile ou web, le stade de lancement, la journalisation, le support, la maîtrise des modifications et la passation
• Une comparaison des cas où Secure Client Portal Sprint, Subscription & Payment Infrastructure Security, Secure Web-to-Mobile Launch, App Launch Readiness et Website Performance & Security Hardening peuvent être pertinents
• Un rappel que des flux, rôles, intégrations ou responsabilités flous peuvent appeler une phase de découverte ou de blueprint avant la réalisation

Ce qui n'est pas inclus

• Une promesse de sécurité, d'adéquation réglementaire, d'approbation des paiements, de prévention de la fraude, de chiffre d'affaires, d'approbation par les stores, de réussite du lancement, de disponibilité, de performance ou de fonctionnement ininterrompu
• L'affirmation qu'un sprint de portail est une plateforme SaaS complète, qu'une revue des paiements est une certification PCI ou une opération anti-fraude, ou que la réalisation mobile rend automatiquement un produit prêt pour le lancement
• L'idée que le durcissement remplace la conception applicative, les tests de charge, la réponse aux incidents ou l'exploitation continue
• La supposition que la réalisation logicielle, la revue de sécurité, l'approbation des prestataires et la responsabilité continue forment automatiquement un seul périmètre

Quand le choisir

Utilisez ce guide avant qu'un changement orienté clients ne devienne une liste de fonctionnalités déconnectées. Il est utile lorsqu'une équipe décide s'il faut construire un portail, modifier les accès, introduire des abonnements, étendre un service web au mobile, préparer le lancement d'une application ou améliorer un site web. Si le flux de base, les responsabilités, les intégrations ou les rôles utilisateurs restent flous, une phase de découverte ou de blueprint produit a généralement plus de valeur qu'une mise en œuvre précoce. Une revue cadrée peut ensuite suivre lorsqu'une question précise de sécurité ou d'exploitation est mûre.

Notre approche

Cartographiez le parcours avant de choisir la méthode de réalisation. Partez de l'utilisateur, de son rôle, de la décision d'accès, des données qu'il fournit ou consulte, du système qui porte l'état suivant et de l'équipe responsable lorsque quelque chose change. Suivez les états de paiement et de droits d'accès avec autant de soin que les écrans de l'interface. Identifiez ensuite les dépendances liées aux prestataires et au backend, les besoins de support et de journalisation, les contraintes mobiles, la responsabilité de la mise en ligne et les exigences de passation. Cela révèle si la prochaine décision porte sur la réalisation d'un portail, la logique de paiement, un passage du web au mobile, la préparation au lancement, le durcissement du site web ou une phase de découverte préalable. Cela évite aussi qu'un service cadré soit pris pour une responsabilité illimitée en matière de produit, d'exploitation ou de conformité. Une cartographie écrite des flux peut aussi consigner les chemins normaux et exceptionnels : un nouvel utilisateur, un échec de paiement, une résiliation, un compte perdu, un fichier manquant, une panne chez un prestataire ou une demande de support. Elle donne aux équipes produit, exploitation, ingénierie et support un espace commun pour identifier les responsabilités avant qu'un client ne soit affecté. Cette clarté peut réduire la dérive du périmètre lors des travaux de réalisation ultérieurs. À mesure que la planification avance, revoyez la cartographie chaque fois qu'un prestataire, un modèle de paiement, un rôle, une règle d'accès, une API, un canal de publication ou un processus de support change. Un flux qui semblait simple sur un schéma peut comporter des exceptions importantes en production. Consigner ces exceptions facilite la décision de savoir si le prochain périmètre relève de la conception, de la réalisation, de la revue, du durcissement, des tests ou de la préparation opérationnelle. Cela aide aussi l'acheteur à demander les bons éléments aux prestataires avant de prendre une décision. Enfin, utilisez la cartographie pour décider de ce qui sera mesuré après la livraison et de qui agira face à un constat, un échec de paiement, un signal du support ou une demande de modification. Une passation est plus solide lorsqu'elle nomme un responsable, un point de revue et une limite convenue plutôt que de simplement lister des fonctionnalités.

Foire aux questions

Articles connexes