Comment Preludd Payment Services a su mettre en place et adapter sa Méthodologie Agile dans le cadre de la norme PCI DSS ?
Depuis sa création, Preludd conçoit ses solutions hébergées sur le cloud à partir des remontées terrains et des besoins clients pour leur garantir une conformité de sécurité des solutions et une satisfaction optimale.
Nous tenons à faire évoluer régulièrement notre solution pour y intégrer l’exigence des clients, les évolutions propres à la croissance de l’entreprise et de notre outil de production, le tout en respectant la conformité de sécurité.
De plus, nous maintenons notre engagement à travers la mise en place d’une organisation de projet, qui permet tout au long de l’année d’effectuer des nouvelles « livraisons », issues du travail de notre équipe technique.
Certaines de ces nouveautés sont visibles : elles permettent de faire évoluer la gestion de notre portail en facilitant son utilisation quotidienne et en apportant de nouvelles fonctionnalités d’informations. D’autres sont moins perceptibles par le client. Elles visent à améliorer la qualité globale de nos solutions hébergées sur le cloud et de nos services, faire évoluer les outils de l’entreprise, ainsi que faire des ajustements essentiels sur l’architecture de la plateforme dans le but d’augmenter son efficacité et sa qualité.
La norme PCI DSS
Le secteur des paiements par carte est soumis à la norme PCI DSS, ce qui implique le respect de pratiques spécifiques. Le niveau d’exigence est plus ou moins élevé selon les entreprises, le métier et le nombre de paiements cartes traités.
L’acronyme PCI DSS (Payment Card Industry Data Security Standard) désigne les normes de sécurité des données applicables à l’industrie des cartes de paiement. C’est un standard international dont les pratiques visent à lutter contre les incidents de sécurité liés aux données de cartes de paiement, en particulier en prévenant des menaces et de la fraude (par exemple : la collecte des données via des attaques cyber).
En tant que Gateway de paiement, Preludd doit respecter les standards PCI DSS au plus haut niveau en passant un audit annuel pour bénéficier de l’agrément et ainsi assurer la protection des données des titulaires de carte. La conformité à cette norme garantit la certification de la mise en œuvre correcte des points de contrôles, et de leur efficacité contre les menaces et les risques de cybersécurité.
Vu la haute sensibilité des données cartes, la mise en place des procédures de protection et d’accès aux données est très stricte. Des investissements humains et logiciels importants sont nécessaires, engendrant une rigueur contraignante mais indispensable à l’organisation.
La méthode Agile
La méthode Agile est une méthodologie de gestion de projet en entreprise. En réalité, il existe plusieurs méthodes qui ont toutes un point commun : elles découlent du Manifeste Agile. Édité par deux experts en développement logiciel dans les années 2000, ce manifeste vient d’un besoin d’amélioration de la gestion des développements logiciels. Son application a donc pour but d’améliorer leur process et réduire leur taux d’échec.
Pour cela, ils placent le client au cœur du projet. C’est une différente façon d’aborder le système de développement logiciel.
Toutes les méthodes inscrites dans la philosophie de ce manifeste sont appelées méthodes agiles.
Chez Preludd, le cycle de vie logiciel s’appuie sur une de ces méthodologies Agiles, appelée « Scrum ». Cette approche, réputée rapide et flexible pour le développement de nouvelles solutions, se caractérise par des étapes qui détaillent et priorisent le produit jusqu’à sa réalisation.
Vous l’aurez sûrement compris, les normes PCI DSS ont influencé considérablement l’approche Agile que nous avons souhaité mettre en place pour le développement de nos solutions et nos services.
Adapter la Méthodologie Agile Scrum aux normes PCI DSS
L’enjeu fut d’adapter la méthodologie Agile pour qu’elle puisse correspondre aux exigences PCI : détailler le plus possible chaque processus du développement, assurer un suivi fin et sécurisé de ces systèmes, tout en gardant le client au centre de ce process.
Mais alors, comment avons-nous conserver notre agilité tout en développant une plateforme conforme à la certification PCI DSS ?
C’est ce que nous allons vous expliquer dans cet article.
Les cycles courts de développement : Les « Sprints »
Le cycle de nos livraisons fonctionne par le biais d’itérations, aussi appelées sprints. Chez Preludd, les sprints correspondent à la durée totale de la conception et à la qualification de(s) évolution(s), soit environ un mois.
À la fin d’un sprint, tous les développements doivent être potentiellement livrables et nous tenons à cette exigence ! Dès qu’une fonctionnalité est développée, elle est livrée sur nos différents environnements et finie en production pour être accessible par le réseau d’utilisateurs. La plateforme évolue donc une fois par mois.
Les réunions agiles : Les « cérémonies »
Tout au long du cycle de la livraison, des « cérémonies » ont lieu sous forme de réunions pour encadrer et ajuster les différentes étapes du projet.
Chaque cérémonie a un but précis et implique les parties prenantes : le product owner, le scrum master, les développeurs, l’équipe commerciale et marketing. PCI DSS a imposé la séparation des responsabilités, ainsi les personnes ont un rôle bien défini avec des responsabilités spécifiques. Ces moments privilégiés sont aussi l’opportunité d’être à l’écoute des collaborateurs, d’échanger et partager autour d’un projet. C’est également l’occasion de laisser la parole à chaque acteur impliqué et de réajuster les développements du cycle en cours, si nécessaire.
L’objectif commun est de faire l’analyse du projet et d’avancer en respectant la méthodologie Scrum et les exigences PCI DSS.
Un exemple de cérémonie : Le Backlog Grooming
Le Backlog Grooming est une cérémonie qui peut s’apparenter à « un grand nettoyage de printemps » des demandes clients.
Chaque besoin/demande client est exprimé sous forme de phrase narrative, raison pour laquelle ils sont appelés user story (par exemple : je veux pouvoir me connecter en tant qu’un autre utilisateur au portail pour pouvoir le guider dans son utilisation).
Chaque user story est décrite puis qualifiée en fonction de sa complexité de réalisation et de sa business value :
- La complexité de réalisation représente l’évaluation de la complexité d’une tâche et des ressources nécessaires à son application. Elle ne correspond pas forcément au temps total de production (tous collaborateurs confondus).
- La business value est l’intérêt business des entreprises, sur une échelle de 0 à 100 (chez Preludd).
Lors du Backlog Grooming, les users stories vont être priorisées en fonction de la plus grande business value (de chaque user story) et de leur complexité de réalisation. Lors d’un sprint, Preludd est capable de gérer une totalité de complexité de 70. Cela évolue au fur et à mesure que l’équipe grandit et augmente son expertise.
Le but n’est pas qu’à chaque nouveau sprint les points de complexités augmentent, mais que le prochain sprint soit défini au plus proche de la réalité. Il faut viser juste pour que la frustration soit moindre au sein des équipes et pour répondre aux attentes des clients.
Une autre cérémonie majeure : Le sprint planning
Lors du Sprint Planning, chaque user story est redécoupée en sous-tâches, qui seront ensuite affectées à l’équipe technique selon les temps de disponibilité et les compétences de chacun. Ainsi, le product manager analyse de façon globale les développements à effectuer et à suivre sur le sprint à venir.
L’impact sécuritaire est défini lors du Sprint Planning.
Le CAB – Une exigence PCI-DSS
Après le Sprint Planning, Preludd a prévu un CAB (Comité d’approbation des Changements) afin d’ajuster la méthodologie Scrum aux exigences PCI DSS, permettant ainsi l’introduction d’un échange constructif au sein de ce comité.
Ce comité implique les parties prenantes telles que le Directeur Technique, le Directeur des Opérations, la Directrice Commerciale, la Directrice Produits et Solutions, le Product Owner et le Product Manager. Ils vont pouvoir donner leur accord sur le sprint prévu et s’assurer que chaque évolution et tâches programmées respectent la norme PCI DSS. La mise en place d’un CAB est nécessaire pour assurer le suivi des développements, la traçabilité des livraisons et l’évaluation de l’impact sécuritaire est revue ou commentée.
Une autre cérémonie : Les Stand-up Meeting
Également appelés Daily Scrum Meetings, cette cérémonie a lieu tous les matins, dès le jour 1 du sprint. Pendant 30 minutes maximum, les développeurs prennent la parole et échangent entre eux en prenant en compte les informations de la veille et ce qu’ils ont prévu durant la journée. C’est l’occasion d’exprimer leurs difficultés techniques et de demander le retour d’expérience d’un autre développeur. Celui-ci pourra, dans un second temps, lui apporter son aide si besoin.
En résumé, le Stand-up Meeting est une session d’échange d’informations courte et efficace entre les développeurs. Ils sont appelés « Stand Up » car ils se font habituellement debout pour être dynamiques et éviter que ce temps se transforme en réunion sans fin. Le respect du temps est primordial.
Les Peer Review
Nous avons intégré dans notre gestion du processus la réévaluation des développements, et au besoin, des retours en arrière (refactoring). Avec une équipe plus expérimentée, les risques de devoir effectuer des ajustements diminuent.
Dans un souci de qualité optimale, lors des Peer Review, chaque développement est vérifié par un développeur qui ne s’est pas occupé du développement en question. Avec son regard neutre et externe, c’est la qualité du code et les erreurs éventuelles qui sont vérifiées. C’est une spécificité Preludd.
L’impact sécuritaire est vérifié lors des Peer Reviews.
La phase d’évaluation et de correction des développements
Preludd fonctionne en CICD (Continuous Integration Continuous Development) pour tester tout au long du sprint les développements et par conséquent détecter les problèmes fonctionnels avant la fin du sprint.
Le principal avantage réside dans la capacité de pouvoir repérer tôt les ajustements nécessaires dans le système de développement. Le développeur, ayant encore une connaissance fraîche de son code, sera en mesure de faire plus aisément une analyse de son travail immédiatement que plusieurs semaines après. Ceci permet des gains de productivité très importants.
Au début de la mise en place de la méthodologie Scrum, il se peut que le processus de correction/réévaluation soit répété plusieurs fois de suite. Plus il y a de cycles de livraison, plus les développements sont qualitatifs et moins il y a besoin de corrections (c’est comme le sport). En revanche, il faut tenir compte du délai imposé de 4 semaines : il y a une obligation de résultat et non de moyens.
Une fois les développements réalisés, réévalués et corrigés par l’équipe de développeurs, le Product Manager et le Product Owner effectuent des tests fonctionnels pour s’assurer que les développements correspondent aux besoins clients (users stories) et qu’ils ne présentent aucun bug lors de leur utilisation dans l’environnement du client.
La Mise en Production et la fin du Sprint
Si tout est fonctionnel, le CAB se réunit de nouveau pour approuver la conformité PCI DSS de la livraison. Une fois que le comité donne son approbation, les développements partent en déploiement sur l’environnement de production de Preludd.
Les clients ont accès aux nouvelles fonctionnalités et applications, bénéficiant ainsi des évolutions intégrées dans le mois en cours.
Les deux dernières cérémonies du sprint : Le Sprint Review & le Sprint Rétrospective
À chaque fin de sprint c’est-à-dire une fois que le déploiement sur l’environnement de production Preludd est fait, deux cérémonies ont lieu.
Le Sprint Review, qui permet de faire le point uniquement sur le sprint qui est terminé, suivi du Sprint Rétrospective, qui lui permet de faire le bilan sur l’ambiance de tous les sprints passés.
C’est fini ! Le sprint actuel prend fin… mais il annonce le début d’un nouveau sprint ! Et ainsi, l’histoire se répète 🔁
Vous vous êtes maintenant plus familiarisés avec l’agilité et la manière dont Preludd a dû s’adapter pour réussir.
Depuis l’introduction de la méthode Agile alignée aux exigences PCI DSS, nos équipes techniques et produit ont constaté une hausse de leur vélocité Agile. Nous sommes devenus plus efficaces dans notre capacité à produire et innover. L’intégration de l’agilité chez Preludd montre des signes positifs et concrets, qui se traduisent par des retombées perceptibles sur le marché.
L’étape suivante dans le développement de Preludd tend vers l’introduction d’une méthodologie Agile dit SAfe.
Rendez-vous dans quelques mois pour en savoir davantage…
Nous espérons que l’article vous a plu ! 😊
