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 sur les remontées terrains et les besoins de nos clients pour garantir une conformité des solutions aux attentes du marché et une satisfaction optimale de nos clients et partenaires.
Nous avons à cœur de faire évoluer notre solution régulièrement pour y intégrer petit à petit les demandes clients et les évolutions propres à la croissance de l’entreprise et de notre outil de production.
Aussi, nous respectons notre engagement avec la mise en place d’une organisation qui nous permet, chaque mois, d’effectuer des nouvelles « livraisons », fruit du travail mensuel de notre équipe technique.
Certaines de ces nouveautés sont visibles, elles permettent de faire évoluer notre portail, notamment en facilitant son utilisation quotidienne et d’apporter de nouvelles fonctionnalités. D’autres nouveautés sont moins visibles par le client et ont pour objectif d’améliorer la qualité globale de nos solutions, de faire évoluer les outils, de faire un travail de fond sur l’architecture de la plateforme afin de la rendre toujours plus efficace et qualitative.
La norme PCI DSS
Le secteur des paiements carte est régi par le standard PCI DSS, avec l’édition de normes à respecter. Selon le métier et le nombre de paiements cartes traités, le niveau d’exigence est plus ou moins élevé.
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 qui a pour objectif de combattre les incidents de sécurité concernant les données de cartes de paiement, notamment pour prévenir la fraude.
En tant que Gateway de paiement, Preludd doit respecter les standards PCI DSS au plus haut niveau et passer un audit annuel pour bénéficier de l’agrément. La conformité à cette norme permet de vérifier que les points de contrôles sont bien mis en œuvre et qu’ils sont efficaces pour la protection des données de cartes bancaires.
Vu la haute sensibilité des données cartes, la mise en place des procédures de protection des données et d’accès aux données est très stricte. Elle nécessite des investissements à la fois humains et logiciels importants et apporte une rigidité contraignante, mais nécessaire, à l’organisation.
La méthode Agile
La méthode AGILE est une méthodologie de gestion de projet. Il existe en réalité plusieurs méthodes qui ont toutes un point commun : elles découlent du Manifeste Agile. Ce manifeste, édité par deux experts en développement logiciel dans les années 2000, vient d’un besoin d’amélioration de la gestion des développements logiciels. Le but de ce manifeste est donc 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 développement logiciel. Depuis, les méthodes qui s’inscrivent 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éthodologie Agile, 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.
Adapter la Méthodologie Agile Scrum aux normes PCI DSS
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 étape du développement, en assurer un suivi fin et sécurisé, tout en gardant le client au centre du processus.
Mais alors, comment avons-nous pu conserver notre agilité tout en développant une plateforme conforme 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 1 mois.
À la fin d’un sprint, tous les développements doivent être potentiellement livrables : et c’est ce que nous faisons ! 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 les 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 chaque personne a 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 aussi l’occasion de laisser la parole à chaque acteur impliqué et de réajuster, si nécessaire, les développements du cycle en cours.
L’objectif commun est de faire avancer le projet 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. C’est pour cette raison qu’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.
- Complexité de réalisation: c’est l’évaluation de la complexité d’une tâche, et pas forcément du temps total de production (tous collaborateurs confondus), les ressources nécessaires à sa réalisation.
- Business Value: c’est l’intérêt business qui est qualifié, 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 devient de plus en plus experte : alors elle est capable de gérer de plus grands points de complexités.
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 qu’il y ait le moins de frustration possible dans les équipes et pour les 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 a une visualisation globale des 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
Pour ajuster la Méthodologie Scrum aux exigences PCI-DSS, Preludd a mis en place, après la cérémonie du Sprint Planning, un CAB (Comité d’approbation des Changements).
Ce comité comprend les parties prenantes comme, 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 sont revues ou commentés.
Une autre cérémonie : Les Stand-up Meeting
Aussi appelé Daily Scrum Meetings. C’est une cérémonie qui a lieu tous les matins, dès le jour 1 du sprint, d’une durée maximum de 30 minutes. Durant cette cérémonie, les développeurs prennent la parole et s’expriment sur ce qu’ils ont fait la journée précédente et ce qu’ils vont faire dans la journée. C’est aussi 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. Le Stand-up Meeting est simplement une cession d’échanges entre les développeurs.
Ils sont appelés « Stand Up » car ils se font habituellement debout pour être plus dynamiques et éviter que ce temps se transforme en réunion sans fin. Ici, le respect du temps est primordial.
Les Peer Review
Dans notre processus nous avons prévu des moments de réévaluations des développements et, si besoin, de retour en arrière. Plus l’équipe est expérimentée, moins il y a de retours en arrière (refactoring).
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. Ceci 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 donc, de détecter les problèmes fonctionnels avant la fin du sprint.
L’intérêt majeur est de pouvoir détecter le plus en amont possible s’il faut réajuster des choses. Le développeur, ayant encore tout son code en tête, il sera plus facile pour lui de revenir sur son travail à chaud, 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. Mais 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 sont en charge d’effectuer 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 CAB 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 bénéficient des évolutions effectuées dans le mois.
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 permet de faire le point uniquement sur le sprint qui est terminé. Ensuite, le Sprint Rétrospective permet de faire le bilan sur l’ambiance de tous les sprints passés.
Et voilà ! Le sprint est terminé mais …. Il marque le début d’un nouveau sprint ! Et l’histoire redémarre 😊
Vous vous êtes maintenant plus familiarisés au fait de l’agilité et de comment Preludd a dû s’adapter pour réussir.
Depuis la mise en place de la méthode agile adaptée à l’exigence PCI DSS, nous avons constaté une augmentation de la vélocité Agile de nos équipes techniques et produit. Nous arrivons clairement à produire et donc à innover de plus en plus efficacement. La mise en place de l’agilité chez Preludd montre des signes positifs et concrets. Cela a des répercussions visibles sur le marché.
L’étape suivante dans le développement de Preludd tend vers la mise en place d’une méthodologie Agile dit SAfe.
Rendez-vous dans quelques mois pour en découvrir plus…
Nous espérons que l’article vous a plu ! 😊
