La Commission européenne avait posé la première pierre à l’édifice de la création d’un Espace unique de paiement Européen (Single European Payment Area ou SEPA) en janvier 2008. Les sociétés se sont vues imposer une date limite claire afin de migrer vers des systèmes de prélèvement et de virement selon le règlement européen SEPA. Ainsi, depuis le 1e février 2014, les établissements bancaires ne devaient plus accepter les opérations de paiements de clients utilisant le système de prélèvements nationaux en vigueur jusqu’au 31 janvier 2013.
Toutefois, face au retard accumulé par de nombreuses entreprises pour se mettre en conformité avec le règlement SEPA avant la date butoir, une extension du délai d’acceptation des paiements NON-SEPA a été décidée le 9 janvier dernier. Avec une date limite repoussée au 6 août 2014, on peut désormais espérer que la majorité des entreprises seront en bonne position pour éviter des déconvenues, telles que des échecs de prélèvements, des pénalités, ou encore de perdre des parts de marché, comme cela a déjà pu être constaté en France.
Mais quelle expérience tirez-vous de la mise en conformité au sein de votre entreprise ? Comment le respect de la date limite imposée a-t-il impacté vos environnements informatiques de développement et de test logiciel ? Comment s’assurer que la mise en conformité avec le règlement SEPA ou d’autres normes ne puisse pas avoir de conséquences négatives pour votre entreprise, comme la re-conception de plates-formes, le déploiement de nouvelles applications mobiles ou le lancement d’un nouveau produit ou service ?
Une étude indépendante1 conduite auprès de responsables des tests et du développement en entreprise a révélé que 44% d’entre eux avaient une vision incomplète des futures performances de leurs applications (ne sachant pas si elles fonctionneront « de temps en temps », « rarement », ou pire encore « jamais »). Selon cette même étude, 47 % des responsables interrogés prévoient d’ajouter régulièrement des fonctionnalités à leurs applications (et 33 % ont été victimes de retards en raison d’une indisponibilité allant de « occasionnelle » à « très fréquente » de leurs systèmes ou environnements).
La réponse à ces risques est la « virtualisation des services » ou simulation de tests logiciels. Ce concept permet d’éviter de dépendre d’un nombre limité d’environnements informatiques, en créant un modèle virtuel de fonctionnement de ces systèmes (mainframe, plate-formes, etc…) afin de tester le comportement des applications avant leur mise en production. Un agent écoute le trafic entre les systèmes de test, traite ces données et les convertit en un modèle, pouvant être configuré afin de se comporter mieux que dans la réalité. Cet agent peut ainsi répondre aux scénarios de tests les plus extrêmes en simulant des montées en charge très élevées.
Virtualisation des services et règlement SEPA
La virtualisation des services peut aider à la mise en conformité avec le règlement SEPA, dans d’autres scénarios de ce type, ainsi que dans des cas plus classiques de déploiement d’applications. En ce qui concerne la norme SEPA, certaines banques ont décidé d’utiliser des solutions SaaS transformant les données de comptes d’anciens formats en données compatibles avec les nouvelles normes. Il s’agit d’une excellente idée, mais comment s’assurer d’une intégration parfaite entre les systèmes établis et des plateformes tierces ? Comment tester les performances de ces systèmes, face à des niveaux variés d’exigence de la part des clients ? En outre, ces plateformes tierces peuvent facturer des coûts supplémentaires pour accéder à des interfaces de tests, dont la disponibilité et les performances pourraient être différentes de celles en production. La virtualisation des services évite les dépenses additionnelles potentielles en fournissant un modèle quasiment réel avec lequel opérer.
À quel point vos applications sont-elles stables ?
Une question revient souvent à propos des tests de performance dans des déploiements importants comme celui d’un système de paiement SEPA : comment se comportera l’application lorsqu’un certain nombre de clients, partenaires ou employés interagiront avec elle massivement à des moments précis ? Les tests de résilience sont également cruciaux : que se passera-t-il si une ou plusieurs composantes de l’application sont indisponibles, arrêtées ou lentes à répondre ?
Les projets de développement de logiciels ont tendance à prendre du retard ; les équipes doivent donc souvent chercher à réduire le temps passé en fin de cycle de développement. Le délai avant la mise en œuvre obligatoire des paiements SEPA suffira-t-il ? Les tests de performance ne peuvent être effectués qu’en fin de cycle, et nécessitent une importante infrastructure, qui ne réplique que rarement les environnements de production au niveau approprié,. En général, les laboratoires ne peuvent pas procéder à des tests de performance tant que l’ensemble des composantes nécessaires ne sont pas disponibles.
L’approche de simulation peut enregistrer des milliers de transactions en temps réel à partir de composantes applicatives et de volumes de clients, pour juste une fraction des coûts normalement nécessaire. Les environnements virtuels permettent aux équipes en charge des performances de disposer d’une gamme bien plus large de données de test. Elles peuvent ainsi reproduire la variabilité de l’application et gérer la performance bien plus tôt dans le cycle de vie de développement, bien avant la fin de l’intégration.
Les données de test : rarement mises en cause, souvent problématiques
Les applications composites possèdent généralement plusieurs magasins de données qui doivent être provisionnés et synchronisés. Des charges de travail plus lourdes impliquent le traitement d’un volume de données plus important pour des tests réalistes. En outre, la règlementation en matière de respect de la vie privée fait désormais de l’utilisation de données de production pour les tests de performance une obligation pour beaucoup d’entreprises. Quelles données utiliserez-vous pour tester les clients utilisant la fonctionnalité de règlement SEPA ? À quel point ces données seront-elles réalistes ? Les modèles virtuels vont permettre à vos équipes de bénéficier d’un accès à l’ensemble des données pertinentes sur des modèles testés.
Une vue complète sur votre application et ses performances
Planifier et prévoir le fonctionnement d’une application avant son déploiement est possible, mais des problèmes subsisteront toujours une fois celui-ci effectué. La virtualisation des services peut être intégrée avec une solution de gestion des performances applicatives (APM) afin de comparer et d’analyser les temps de réponse avant et après la mise en production. Ainsi, il est possible de faire correspondre des métriques de production directement avec des cas de test, et de simuler des comportements en conditions réelles. La capacité des solutions d’APM à extraire des connaissances à partir de données de production au sein et à plusieurs niveaux d’une application est très utile pour les équipes en charge des tests de performance et du développement. Cette approche permet ainsi d’évoluer avec plus de tranquillité grâce à davantage d’informations décisionnelles concrètes.
L’après SEPA
La date limite du 1e février est aujourd’hui dépassée : il est peut-être temps de se demander à quel point votre entreprise peut s’adapter une fois que votre système SEPA sera mis en place. Serez-vous en mesure de déployer rapidement des mises à jour ou des correctifs mineurs, de superviser leur impact sur les performances des applications pertinentes au sein de vos environnements de production ? Quel type d’expérience utilisateur allez-vous proposer, et combien de temps vous faudra-t-il pour résoudre leurs problèmes ? La plupart des grandes sociétés mondiales de services financiers ont adopté et font confiance à la virtualisation des services, et profitent désormais d’une importante réduction des risques au niveau de leurs programmes critiques, en matière de conformité, etc. L’heure est sans doute venue d’envisager une nouvelle approche quant aux processus de développement, de test et de déploiement d’applications.
À propos de l’auteur :
Justin Vaughan-Brown est Directeur de la Stratégie DevOps chez CA Technologies, EMEA. Il est en charge de définir la meilleure approche de mise sur le marché des solutions DevOps de CA Technologies, sur toute la zone EMEA. Il définit les messages, planifie les évènements et concourt à accroître la notoriété de CA Technologies dans ce domaine.