Quelle sécurité pour un MVP ?

Quel niveau de sécurité pour un Produit Minimum Viable (MVP) ? La question à laquelle tente de répondre Sandy Carielli, analyste pour Forrester, est éminemment stratégique pour les institutions financières et leurs programmes d'innovation. La réponse tient en un délicat équilibre entre les exigences de réactivité et de protection des clients.

Parce que le principe fondamental du MVP consiste à élaborer une première ébauche de solution aussi dépouillée que possible, dont le seul but est de tester et valider dans les meilleurs délais et à moindre coût une hypothèse déterminante pour le projet d'ensemble auprès de la cible d'utilisateurs visée, surgit naturellement le débat autour de la quantité d'efforts et de ressources à consacrer à la sécurité : pas suffisamment et les cobayes encourront des risques intolérables, trop et le budget et les lenteurs exploseront.

La balance penche hélas fréquemment de ce dernier côté dans les grands groupes bancaires. Paranoïaques vis-à-vis des dangers – notamment pour leur réputation – de cyberattaques, de fuites ou vols de données sensibles, mais aussi de manquements, réels ou supposés, aux exigences réglementaires, ils préfèrent généralement soumettre la moindre expérimentation exposée à la clientèle (et parfois même interne) à la totalité des contraintes imposées aux services opérationnels, déployés en production.

Ces excès de prudence sont, en grande partie, à l'origine des dérives observées dans la mise en œuvre de MVP chez ces acteurs. L'application des politiques de sécurité est en effet (légitimement) une tâche extrêmement lourde, dont le poids s'avère démesuré par rapport aux objectifs fixés. Les conséquences se répartissent entre le découragement des équipes chargées des explorations initiales, des déperditions massives d'argent et d'énergie sur ces phases amont et l'échec pur et simple des projets innovants.

Dans ce contexte, Sandy confirme qu'il faut absolument éviter de ralentir les processus outre mesure, mais qu'un certain nombre de précautions restent indispensables. Une évidence, tout d'abord : aucun compromis ne peut être admis sur l'intégrité du MVP lui-même. Les données personnelles qu'il manipule, ses mécanismes d'accès, ses interactions avec d'autres systèmes… doivent bénéficier d'une protection optimale, sous peine de perdre la confiance des usagers et toute possibilité d'évaluer leur intérêt.

Plus ambiguë, sa deuxième recommandation considère les choix effectués (ou non effectués) qui sont susceptibles de perdurer jusqu'au produit final. Il s'agirait, par exemple, d'appréhender dès le début les problématiques de respect de la vie privée plutôt que de différer les décisions tant que le sujet ne fait pas partie du prototype courant. Malheureusement, c'est exactement ce genre d'obligation qui, en se transformant en étude de risque exhaustive anticipée, peut devenir un handicap majeur.

L'essence du MVP est de focaliser toute l'attention d'une première réalisation sur une idée principale, dont on souhaite vérifier très vite si elle rencontre un écho favorable chez les testeurs. Il faut impérativement en exclure tout ce qui ne contribue pas directement à ce résultat. L'analyse de faisabilité lors de l'idéation donne l'occasion d'adopter quelques principes de bon sens, puis chaque étape de réalisation intègrera les nouvelles règles de sécurité strictement requises. Enfin, un accompagnement ad hoc peut être proposé afin d'éviter toute négligence au fil des progrès. Mais chaque chose en son temps…