Face à la soudaineté de la crise sanitaire et l'ampleur de son impact sur l'économie, les gouvernements et, à leur suite, les institutions financières ont dû créer et mettre en place des solutions dans l'urgence. Hélas, la précipitation tend à faire ressortir plusieurs défauts structurels de ces organisations. Bank of America en fournit une illustration.
Le point de départ de cette réflexion est une notification [PDF] légale de fuite de données émise par la banque. Celle-ci informe les responsables d'entreprises ayant sollicité un prêt fédéral garanti (PPP) que les informations présentes dans leurs dossiers ont pu être consultées, pendant une courte durée, par des tiers non habilités. La raison ? Des demandes réelles ont par erreur été transmises à un serveur de test de l'administration en charge des traitements, lui-même accessible par les autres établissements de crédit.
En soi, l'incident est probablement de faible gravité, puisque les personnes susceptibles d'avoir intercepté les données en cause sont, en principe, dignes de confiance. Mais il donne à réfléchir sur deux faiblesses intrinsèques aux processus de développement en vigueur dans la plupart des grands groupes, l'une concernant la gestion de la sécurité et l'autre les modalités de test. Et elles s'avèrent potentiellement critiques pour l'évolution de l'informatique bancaire, au-delà des circonstances particulières actuelles.
En effet, la transformation « digitale » a conduit les entreprises à adopter des démarches agiles pour l'exécution de leurs projets, notamment informatiques, de manière à accélérer les déploiements en production et mieux adapter les produits livrés aux attentes des clients. La réactivité ainsi acquise constituait évidemment un atout considérable lorsqu'il a fallu, en raison de la pandémie et dans des conditions elles-mêmes exceptionnelles, mettre en place en quelques jours une nouvelle plate-forme de gestion de crédit.
Malheureusement, il s'avère donc que toutes les bonnes pratiques de l'agilité n'ont pas (encore ?) été intégrées dans ces démarches. La sécurité, d'abord, reste souvent bloquée sur des principes d'une autre époque, fondée sur une logique de contrôle de conformité a posteriori, généralement en fin de projet. Or quand les mises en production deviennent plus fréquentes, cette méthode atteint ses limites et il faut alors impérativement intégrer la sécurité de bout en bout, et au cœur de la chaîne de développement.
L'autre volet de l'équation ressort du même mécanisme, parfois jusqu'à la caricature. Traditionnellement, les phases de test sont repoussées le plus tard possible dans les cycles de projet et cette position les met régulièrement en situation d'arbitrage. Cette habitude conduit à minimiser leur importance… et à produire des catastrophes (TSB, par exemple) qui risquent de devenir la règle. Là aussi, les modalités doivent évoluer et les tests devenir continus et permanents durant tout le processus de création.
Le constat est généralisable : beaucoup d'entreprises qui tentent de se convertir à l'agilité croient qu'il leur suffit de s'emparer de quelques gadgets – les backlogs, les sprints, les stand-up meetings… (en franglais, bien sûr) – pour élaborer plus rapidement de meilleurs produits. La réalité est que non seulement il ne faut pas espérer de miracles mais, en outre, le progrès ne sera viable que si l'ensemble des disciplines impliquées sont transformées, afin de les inscrire dans une approche globale et cohérente.
Le point de départ de cette réflexion est une notification [PDF] légale de fuite de données émise par la banque. Celle-ci informe les responsables d'entreprises ayant sollicité un prêt fédéral garanti (PPP) que les informations présentes dans leurs dossiers ont pu être consultées, pendant une courte durée, par des tiers non habilités. La raison ? Des demandes réelles ont par erreur été transmises à un serveur de test de l'administration en charge des traitements, lui-même accessible par les autres établissements de crédit.
En soi, l'incident est probablement de faible gravité, puisque les personnes susceptibles d'avoir intercepté les données en cause sont, en principe, dignes de confiance. Mais il donne à réfléchir sur deux faiblesses intrinsèques aux processus de développement en vigueur dans la plupart des grands groupes, l'une concernant la gestion de la sécurité et l'autre les modalités de test. Et elles s'avèrent potentiellement critiques pour l'évolution de l'informatique bancaire, au-delà des circonstances particulières actuelles.
En effet, la transformation « digitale » a conduit les entreprises à adopter des démarches agiles pour l'exécution de leurs projets, notamment informatiques, de manière à accélérer les déploiements en production et mieux adapter les produits livrés aux attentes des clients. La réactivité ainsi acquise constituait évidemment un atout considérable lorsqu'il a fallu, en raison de la pandémie et dans des conditions elles-mêmes exceptionnelles, mettre en place en quelques jours une nouvelle plate-forme de gestion de crédit.
Malheureusement, il s'avère donc que toutes les bonnes pratiques de l'agilité n'ont pas (encore ?) été intégrées dans ces démarches. La sécurité, d'abord, reste souvent bloquée sur des principes d'une autre époque, fondée sur une logique de contrôle de conformité a posteriori, généralement en fin de projet. Or quand les mises en production deviennent plus fréquentes, cette méthode atteint ses limites et il faut alors impérativement intégrer la sécurité de bout en bout, et au cœur de la chaîne de développement.
L'autre volet de l'équation ressort du même mécanisme, parfois jusqu'à la caricature. Traditionnellement, les phases de test sont repoussées le plus tard possible dans les cycles de projet et cette position les met régulièrement en situation d'arbitrage. Cette habitude conduit à minimiser leur importance… et à produire des catastrophes (TSB, par exemple) qui risquent de devenir la règle. Là aussi, les modalités doivent évoluer et les tests devenir continus et permanents durant tout le processus de création.
Le constat est généralisable : beaucoup d'entreprises qui tentent de se convertir à l'agilité croient qu'il leur suffit de s'emparer de quelques gadgets – les backlogs, les sprints, les stand-up meetings… (en franglais, bien sûr) – pour élaborer plus rapidement de meilleurs produits. La réalité est que non seulement il ne faut pas espérer de miracles mais, en outre, le progrès ne sera viable que si l'ensemble des disciplines impliquées sont transformées, afin de les inscrire dans une approche globale et cohérente.
Aucun commentaire:
Enregistrer un commentaire
Afin de lutter contre le spam, les commentaires ne sont ouverts qu'aux personnes identifiées et sont soumis à modération (je suis sincèrement désolé pour le désagrément causé…)