Qu’est-ce que notre logiciel CCPA ?
L’an dernier, mon associé et moi avons décidé de proposer une solution logicielle de conformité pour gérer les demandes d’exercice de droits via un formulaire web et un Toll-Free Number, afin de permettre aux entreprises de respecter les exigences de la loi californienne sur la protection de la vie privée des consommateurs (California Consumer Privacy Act, CCPA). Depuis, nous avons ajouté des fonctionnalités de niveau entreprise comme le chiffrement intégral des données au repos, l’authentification multifacteur pour renforcer la sécurité et des rappels d’échéance des demandes d’exercice de droits pour tous nos utilisateurs. Mon associé est avocat de formation ; je suis ingénieur et j’ai participé au développement de la solution logicielle derrière la hotline 866-I-OPT-OUT (866-467-8688).
Si vous êtes curieux de découvrir le fonctionnement interne de notre solution SaaS, lisez la suite !
Nous avons construit CCPATollfree.com en trois parties. D’abord, un tableau de bord enregistre la configuration et les paramètres de gestion du compte de nos utilisateurs dans une base de données Postgres. Ensuite, nous utilisons certains de ces paramètres pour alimenter une expérience Twilio Programmable Voice, ainsi qu’une intégration de formulaire web qui renvoie les demandes d’exercice de droits vers notre base de données. Enfin, nous utilisons des tâches en arrière-plan pour envoyer des rapports à nos utilisateurs et calculer la consommation d’appels de chaque compte. Plongeons dans ces trois parties.
Configuration et gestion du compte
Le tableau de bord vous permet de créer des Service Codes, que vous pouvez voir comme des référentiels distincts où les consommateurs enregistrent leurs préférences en matière de confidentialité. Ils servent à segmenter logiquement les demandes d’exercice de droits. Par exemple, il est courant que des clients grands comptes possèdent plusieurs marques et publient le même numéro de téléphone avec des Service Codes différents sur différents sites web. En plus de segmenter les demandes, vous pouvez personnaliser le message d’accueil associé à chaque Service Code, de sorte que l’expérience téléphonique varie d’un Service Code à l’autre. Toute cette configuration est publiée et stockée en temps réel dans une base de données Postgres. Nous stockons les messages d’accueil dans un bucket Amazon S3 et les rendons disponibles en temps réel lorsque les consommateurs appellent votre Toll-Free Number.
Chaque onglet du tableau de bord correspond à une ressource de notre backend, à laquelle sont associées certaines actions. Le backend est une application Ruby on Rails. Pour chacun de nos clients, il est essentiel que les données stockées dans une base de données partagée ne fuient jamais d’un compte client à l’autre. Chaque contrôleur de ces ressources ne peut renvoyer que les données appartenant au compte de l’utilisateur connecté. C’est ce que nous appelons la segmentation horizontale des données : elle empêche que des enregistrements appartenant à un autre compte soient un jour affichés. Un autre type de segmentation est la segmentation verticale : seules les colonnes strictement nécessaires à l’interface utilisateur sont mises à sa disposition. Pour garantir ce comportement, nous testons chaque endpoint afin de nous assurer qu’aucune donnée n’échappe à la segmentation horizontale ou verticale. Pour les clients grands comptes qui exigent le plus haut niveau de garantie, nous proposons des instances de notre application en cloud privé, reliées à une base de données dédiée plutôt que partagée.
Expérience Twilio et formulaire web
Twilio propose un produit appelé Programmable Voice. Dans l’architecture de Twilio, la capacité d’appels entrants est illimitée : nous pouvons accepter un nombre illimité d’appels entrants simultanés par seconde. C’est un élément essentiel de notre architecture, qui nous permet d’utiliser un numéro partagé entre des centaines de clients différents, quelle que soit leur taille. Twilio assure la téléphonie de clients comme Uber sur des numéros partagés : nous pensons donc que cela nous suffira pour un bon moment !
Twilio Programmable Voice envoie une requête HTTP à chaque interaction d’un consommateur. L’expérience commence lorsqu’un consommateur appelle notre numéro : 1-866-467-8688 ou 1-866-I-OPT-OUT. La requête parvient à notre backend, qui répond avec du XML indiquant à Twilio comment se comporter. Par exemple, lorsque l’appelant saisit le Service Code 1#, notre backend utilise les données de configuration du tableau de bord pour diriger Twilio vers l’étape suivante : l’écoute du message d’accueil du Service Code 1.
Lorsque vous intégrez notre service à votre site web, vous avez accès à notre formulaire web, qui envoie les demandes d’exercice de droits vers votre tableau de bord, aux côtés de celles reçues via votre Toll-Free Number. Vous avez remarqué que le formulaire web intègre un RECAPTCHA ? Il s’agit d’un outil gratuit de Google qui sécurise les formulaires web. Il génère un jeton sur le backend de Google, que nous recevons dans notre formulaire web et transmettons à notre backend. Nous vérifions ensuite la validité de ce jeton auprès du service RECAPTCHA de Google. En réalité, nous protégeons chaque endpoint. Nous utilisons une gem Ruby appelée Devise pour nous assurer que tous les utilisateurs sont authentifiés avant de leur donner accès aux données. Nous utilisons une technologie de signature avec contrôle d’horodatage pour éviter les attaques par rejeu sur les webhooks. Nous mettons également les origines sur liste blanche, afin qu’aucun tiers ne puisse proposer un formulaire web envoyant des demandes vers votre tableau de bord. C’est pourquoi vous devez nous envoyer un e-mail pour que nous configurions votre domaine afin qu’il communique avec notre application en HTTPS.
Tâches en arrière-plan
Le dernier élément essentiel de notre architecture, ce sont les tâches en arrière-plan. Nous les utilisons par exemple pour calculer de façon asynchrone la consommation téléphonique de chaque compte, que nous transmettons ensuite quotidiennement à Stripe. Nous préparons également les e-mails de reporting, envoyés selon les préférences choisies dans le tableau de bord. Ces tâches s’exécutent sur notre infrastructure hébergée sur Heroku et sont elles aussi segmentées par compte, pour que les données ne fuient jamais d’un compte à l’autre. Nous n’envoyons que des données agrégées par e-mail : les e-mails ne contiennent donc jamais d’informations sensibles.
Un autre aspect important de nos traitements asynchrones est la capacité à rejouer les flux de données en cas de panne réseau ou de défaillance de calcul. Pour suivre la consommation des comptes (par exemple le nombre d’appels), nous ouvrons une transaction en base de données, passons la consommation au statut « traitée », puis envoyons chaque jour le total agrégé à Stripe. Si l’opération réussit, nous validons la transaction. En cas de problème, nous rétablissons la consommation au statut « non traitée ». Si une erreur survient après l’appel à Stripe et avant la fin de la transaction, nous pouvons gérer les problèmes prévus par le théorème CAP en recalculant le nombre quotidien d’appels de chaque compte.
Nous surveillons les tâches en arrière-plan avec Papertrail et New Relic et recevons des alertes dès qu’un problème survient. En fait, le même niveau d’alerte existe pour chaque composant de notre système. Nous sommes alertés en cas de problème avec Twilio, le backend, le formulaire web, notre serveur e-mail ou les paiements Stripe, afin de pouvoir intervenir dès qu’un incident se produit. Cela fait partie de notre engagement à offrir un support de niveau entreprise à nos clients.
CCPA Toll Free enrichit ses fonctionnalités en suivant le même modèle de sécurité et de surveillance que nous nous sommes fixé dès le départ. Notre feuille de route comprend de nombreux partenariats, intégrations et autres développements. N’hésitez pas à écrire à support@optacy.com pour vos questions et demandes de fonctionnalités.