Cloud computing et réglementation bancaire

Par Isabelle Renard, avocat au barreau de Paris, docteur ingénieur

Une question mal posée

À la question relative aux risques associés au cloud computing dans l’environnement bancaire, de nombreux articles, commentaires, et séminaires ont été consacrés. Il n’en est rien sorti de concret. Exemple parmi d’autres, le document élaboré par le secrétariat général de l’autorité de contrôle prudentiel intitulé « Les risques associés au cloud computing » (ACP Banque de France – Analyses et synthèses – n°16 Juillet 2013), constate que les établissements de crédits et organismes d’assurance interrogés confirment que « le cloud computing présente des risques supérieurs à l’infogérance classique », énumérant pêle-mêle la confidentialité des données, la disponibilité des données et traitements, la réversibilité, et le contrôle. Bien sûr, et so what ? Une fois qu’on a dit ça, que fait-on ?

Il n’y a pas « un » cloud computing, mais plutôt différentes modalités d’externalisation

La question est, au départ, mal posée. Car il n’y a pas « un » cloud computing, mais au contraire beaucoup de types de cloud computing et le seul fait d’opposer « cloud » et « infogérance classique » montre bien d’où vient le problème.

Le « cloud » est une appellation marketing qui rejoint, au panthéon des expressions subliminales valorisantes de notre temps, la « transformation numérique » ou le « Big Data », qui sont devenus des concepts fourre-tout dépourvus de sens précis.

L’externalisation de tout ou partie d’un système d’information se définit toujours selon trois axes, cloud ou pas cloud : un axe technique, un axe économique et un axe juridique. Ce sont les possibilités offertes sur ces trois axes qui ont varié avec le temps, donnant l’impression que l’on serait passé d’une externalisation de grand papa à un « cloud », le plus souvent américain, aussi dangereux que séduisant.

Mais ce ne sont que des mots. Sur chaque axe, il y a des curseurs.

Sur l’axe technique, les curseurs se déplacent à mesure de l’évolution des techniques. Les infrastructures techniques de l’externalisation dite « classique » sont aujourd’hui les mêmes que celles du cloud : puissances de calcul importantes, bandes passantes élevées, machines virtuelles. La différence tient essentiellement à ce que du côté classique de l’échelle les serveurs sont localisés dans des endroits précis, alors que du côté cloud ils se promènent dans des localisations mouvantes. Corrélativement, du côté des SLA, on passe d’une liste claire de niveaux de services faisant l’objet d’une obligation de résultat à des SLA non négociables et, le plus souvent, imprécis.

Sur l’axe économique, ce qui a fait la fortune de l’appellation « cloud » est son association avec le service « on demand » et le paiement à l’usage. C’est certes une avancée majeure car cela permet à des petites et moyennes entreprises ou collectivités de bénéficier d’infrastructures et d’applications puissantes qui seraient sinon hors de leur portée. Mais cela n’est pas un critère différenciant, car les infogérants « classiques » peuvent tout aussi bien proposer ce type de modèle économique. Et d’ailleurs ils le font.

Sur l’axe juridique enfin, il y a une véritable rupture entre le modèle classique et celui des cloud US et c’est dans doute la plus structurante.

Dans l’externalisation classique les contrats se négocient selon un schéma éprouvé qui part du besoin client, se traduit par l’expression d’un cahier des charges, appelle une réponse du prestataire et se conclut par la rencontre du besoin du client et de l’offre du prestataire autour d’une convention de service et des conditions financières et juridiques représentant un compromis négocié.

De l’autre côté du curseur, les grands fournisseurs de cloud américains ont imposé une logique radicalement inverse, qui est celle du contrat d’adhésion. Les conditions juridiques et les SLA ne sont pas négociables. Ils sont de plus particulièrement obscurs, se composant d’un empilement de documents disponibles sur le Web et s’enchevêtrant au fil des liens hypertexte sans qu’on puisse, au bout du compte, avoir une idée claire de l’engagement du prestataire. Ce type de construction contractuelle s’accompagne de clauses non négociables visant à :

Exonérer le prestataire de toute responsabilité en cas de dysfonctionnement ;
Ne donner aucune garantie sur la localisation des données ;
Poser le principe de la non auditabilité des sites ;
Décliner toute responsabilité en cas d’accès aux données par une autorité locale ;
Ne donner aucune garantie en matière de réversibilité ou de continuité d’activité ;
Ignorer toute forme de gouvernance conjointe ;
Instaurer un système unilatéral de modification des conditions contractuelles.

Ces dispositions sont la contrepartie normale de l’attractivité financière de ce type de services comparé aux infogérants classiques. C’est l’industrialisation des services à grande échelle dans des localisations à moindre coût d’implantation et de main d’œuvre, associés à une absence quasi-totale d’interaction client, qui permet de tirer les prix vers le bas.

Mais cela ne caractérise que les offres de cloud « public » les plus minimalistes, la plupart du temps d’origine US. À côté de cela, il existe sur le marché de nombreuses offres qui se situent à différents niveaux de curseur sur ces trois axes. La perversité de la façon dont la question du risque du cloud computing est posée est qu’elle ne définit pas de façon précise ce que l’on entend par « cloud computing » et que du coup, chacun répond à la question sur la base d’un référentiel flou et d’idées toutes faites.

Il faut renverser le paradigme

Il faut arrêter de tourner autour de la question du « risque » du cloud computing, car elle ne mène nulle part. Il faut revenir à la démarche éprouvée consistant à réconcilier l’expression de besoin du client et l’offre disponible, dans le cadre d’un raisonnement structuré qui n’a aucune raison de disparaître.

L’expression de besoin du client, en matière d’externalisation de système d’information s’articule autour d’indicateurs parfaitement connus : la disponibilité, la sécurité, la localisation des données, etc. Selon le secteur d’activité du client et l’activité externalisée, cette expression de besoin aura un caractère plus ou moins impératif sur tout ou partie des indicateurs.

Quant à l’offre, elle est d’une grande diversité et la question n’est pas de savoir si on peut y répondre ou non par une offre de cloud computing, mais bien plutôt quelle est la meilleure offre sur le marché qui permette de répondre au besoin, et avec quel écart.

De façon peu surprenante, on en déduira certainement que dans le secteur bancaire les offres les moins chères des fournisseurs US n’y répondent qu’avec un écart sidéral et c’est cela qui fait dire et écrire à l’envi que le cloud computing présente « des risques ». Mais cette affirmation, dans sa généralité, est fausse. Il existe des offres en cloud qui répondent aux exigences du secteur bancaire, avec des écarts plus ou moins grand, que l’on peut mesurer à partir d’un cahier des charges précis des exigences propres à ce secteur.

Le cahier des charges des prestations externalisées dans le secteur bancaire : une nouvelle réglementation depuis novembre 2014

Le cahier des charges des prestations externalisées dans le secteur bancaire a changé, puisque le règlement CRBF 97-02, après quelque 20 ans de bons et loyaux services, a cédé la place à l’arrêté du 3 novembre 2014 « relatif au contrôle interne des entreprises du secteur de la banque, des services de paiement et des services d’investissement soumises au contrôle de l’autorité de contrôle prudentiel et de résolution », achevant la transposition de la directive 2013/36/UE du 26 juin 2013 dite « CRD IV », notamment sur le sujet des prestations externalisées.

Les activités externalisées sont définies comme celles « pour lesquelles l’entreprise assujettie confie à un tiers, de manière durable et à titre habituel, la réalisation de prestations de services ou d’autres tâches opérationnelles essentielles ou importantes ».

Les « tâches opérationnelles essentielles ou importantes » sont, notamment, celles qui participent directement aux opérations de banques et opérations connexes. L’externalisation de tout ou partie du système d’information supportant les opérations de banque en fait donc à l’évidence partie.

Il s’en suit un certain nombre d’exigences qui doivent être intégrées dans le cahier des charges de l’externalisation du système d’information supportant les opérations de banque et notamment :

L’existence d’un système de contrôle des activités externalisées ;
La capacité à identifier et gérer les risques liés à l’externalisation ;
La conclusion d’un contrat écrit entre le client et le prestataire, et la possibilité pour le client d’accepter expressément toute modification substantielle du service ;
La capacité du client à prendre des mesures en cas de dysfonctionnement du système ;
La capacité à assurer la continuité de l’activité et l’existence d’un plan de secours ;
L’existence d’un engagement du prestataire sur le niveau de qualité du service ;
La capacité à assurer la protection des informations confidentielles ;
La capacité à auditer les prestations sur place et à donner accès aux informations par l’autorité de contrôle prudentiel.

Adéquation du cahier des charges à l’offre

On l’aura compris à la lecture du cahier des charges brièvement esquissé ci-dessus pour l’externalisation par une banque du système d’information supportant des opérations de paiement : les cloud US « premier prix » répondent « non » à quasiment toutes les exigences.

Il ne sert à rien d’essayer de faire rentrer au chausse pied un éléphant dans un trou de souris en expliquant que l’opération est « risquée ». Si l’on raisonne en termes d’écart entre l’exigence et la réponse à l’exigence, on se bornera à dire que, pour ces offres qui sont à l’échelle extrême du curseur « cloud », l’écart n’est pas mesurable et donc le risque n’est pas mesurable. Ce qui ne veut pas dire qu’il n’existe pas d’autres offres de services externalisé en « cloud computing » qui puissent y répondre, avec un écart – et donc un risque – mesurable.

En conclusion

Il faut, en conclusion, sortir de la pensée unique : « le cloud computing, ce n’est pas cher mais c’est risqué », pour repasser à une logique classique d’adéquation entre les exigences du cahier des charges, qui pour le secteur bancaire sont précises et élevées, avec les offres. Il est vrai que les offres de cloud public très attractives financièrement, souvent seules associées – à tort, à l’étiquette « cloud », se révéleront inadéquates.

Ce qui ne veut pas dire qu’elles soient techniquement mauvaises. Au contraire, non seulement elles ne sont pas chères mais, au dire des experts et avec le recul de l’expérience, elles apparaissent techniquement très fiables.

Leurs limites tiennent plutôt à deux points qui sont actuellement inhérents à la construction de ces offres : d’une part leur manque de transparence et l’absence quasi-totale d’engagement juridique qu’elles véhiculent, d’autre part une nécessité d’industrialisation pour tirer les prix vers le bas, rendant quasi impossible la maîtrise de la localisation des traitements, l’auditabilité des sites et la mise en œuvre d’une gouvernance effective, qui sont des exigences essentielles pour le secteur bancaire.