La conformité au cœur du développement logiciel

Les banques sont aujourd'hui prises dans un tourbillon infernal : pour répondre aux attentes de leurs clients, il leur faut accélérer en permanence la mise en place de nouveaux services, sur le web et sur mobile, alors qu'elles sont soumises, en parallèle, à une croissance ininterrompue de contraintes réglementaires et de sécurité.
L'exigence extrême de rapidité dans le développement de nouveaux logiciels (ou dans la réalisation des évolutions de ceux qui existent) a conduit de nombreuses entreprises à adopter progressivement des approches agiles, dont une des principales caractéristiques est de requérir une étroite proximité entre les équipes techniques et le "métier" demandeur de l'application à réaliser, pendant toute la durée du projet.
Selon un article de la revue American Banker, Bank of America, qui a déjà introduit certaines de ces pratiques dans ses processus, s'est aperçue que ce rapprochement ne suffisait plus à garantir la réactivité nécessaire. Pour aller encore plus vite, elle a également du impliquer les équipes de conformité au plus près des projets logiciels, en les faisant participer directement aux phases de test, immédiatement après la finalisation de chaque lot de fonctions (le "sprint" en langue agile).
Concrètement, pendant que les "utilisateurs" vérifient que le produit livré correspond effectivement à leurs attentes et est exempt d'anomalies, les "testeurs de la conformité" vont – pour prendre l'exemple d'une application mobile destinée aux clients – s'assurer qu'un accord explicite est demandé pour un accès à des données privées, que la géolocalisation n'est pas activée en permanence ou encore que les informations sensibles manipulées sont correctement protégées (la conformité incluant la sécurité)…
Dans la même logique que celle qui justifie les cycles rapides de développement et de test fonctionnel des méthodes agiles, l'introduction des contrôles de conformité au plus tôt dans le processus permet de limiter l'impact des anomalies. En effet, si ces dernières sont découvertes trop tardivement, elles deviennent beaucoup plus coûteuses à corriger et elles peuvent même induire un risque majeur de réputation pour l'entreprise (dans le cas où elles ne sont pas détectées avant d'arriver entre les mains des utilisateurs).
Par ailleurs, s'il faut en croire l'expérience d'une autre banque, ce type d'approche apporte un second bénéfice pour la réactivité des projets, peut-être plus important que le premier. Traditionnellement, les équipes en charge de la conformité rendent leurs conclusions sur la base d'une information "théorique", sans toujours avoir une perception claire de ce que les responsables du projet développent, et en appliquant, par conséquent, un principe de précaution souvent handicapant. A l'inverse, lorsque les mêmes acteurs sont immergés dans la réalisation, leurs décisions deviennent beaucoup plus objectives et pragmatiques.
Fondamentalement, plus les services financiers deviennent une activité logicielle (s'écartant du modèle historique d'une informatique en simple support du métier), plus l'ensemble de l'organisation va devoir se rapprocher des centres de développement et s'impliquer profondément dans les projets. La conformité et la sécurité, généralement considérées comme des freins à l'agilité et à la créativité, sont évidemment les premières concernées par cette transformation inéluctable.