Défaillance informatique du BST – une leçon pour les autres

Les nouvelles du TSB montrant des transactions incorrectes dans les comptes des gens sont la preuve d'un projet logiciel qui a mal tourné en raison d'un travail de mauvaise qualité. Pourquoi cela et comment cela aurait-il pu être évité ? La cause profonde sous-jacente pourrait provenir d’une gamme de possibilités. Dans cet article, j’explore certaines des plus probables et les leçons que nous pouvons en tirer.

Les anciens systèmes sous pression

Au cœur de la plupart des banques et des grandes institutions financières se trouvent des logiciels initialement écrits il y a longtemps et qui se sont révélés très fiables. Nous appelons ces systèmes existants et, comme nous exigeons différentes manières d'accéder à nos données bancaires, le code sous-jacent de ces systèmes existants se retrouve à fonctionner d'une manière que les développeurs d'origine n'avaient jamais imaginée ou prévue, ce qui peut conduire à des bugs peu fréquents.

Maintenir les technologies héritées

La plupart de ces anciens systèmes sont écrits avec des technologies anciennes telles qu'un langage appelé COBOL. La plupart des développeurs COBOL sont désormais à la retraite et très peu de jeunes sont enthousiastes à l'idée d'apprendre des langages aussi morts. Il existe donc une pénurie de développeurs hautement qualifiés pour ces anciens systèmes.

Le risque mène à l’abstraction

La migration des systèmes existants vers des technologies plus récentes est difficile et risquée. La planification et la mise en œuvre peuvent prendre des années. Le remplacement d’un système central peut être tellement perturbateur que la direction évite complètement de le faire. Une tactique pour permettre aux banques d'avancer en offrant de nouvelles fonctions aux utilisateurs consiste à envelopper ces anciens systèmes à l'aide d'une technique appelée Abstraction. Ils sont traités comme une « boîte noire » et nous n'avons pas à nous soucier de leur fonctionnement, nous devons simplement avoir confiance en leurs entrées et sorties. Cette technique retarde la nécessité éventuelle de remplacer ces systèmes.

Architecture et complexité

À mesure que de nouveaux produits bancaires sont créés, de plus en plus de systèmes dépendants « suspendent » l’héritage, créant ainsi une image toujours plus complexe de la façon dont les données circulent entre ces systèmes. Des systèmes trop complexes peuvent être à l’origine de nombreux bugs. Une bonne architecture informatique aidera à combattre ou à contenir cette complexité et les risques associés.

Code évolué

Les systèmes qui existent depuis longtemps ont souvent été bricolés par de nombreux programmeurs au fil des ans. Parfois, il y a peu de transfert de connaissances d’un développeur à l’autre. Le nouveau ne comprend pas ce que le dernier a fait et il est réticent à modifier le code existant, au cas où il le briserait. Au lieu de cela, il écrit un nouveau code pour s'asseoir à côté de l'ancien code. Les deux ensembles de codes font probablement la même chose, mais que se passe-t-il lorsque le prochain développeur arrive, il ne peut pas être sûr sur quel code travailler. C’est l’une des façons dont la complexité peut s’accumuler.

Les tests seuls ne suffisent pas à garantir la qualité

Des études portant sur des milliers de projets informatiques nous prouvent que les tests à eux seuls ne garantissent pas que tous les bogues ont été détectés. En fait, au mieux, les tests trouveront rarement plus de 85% de bugs. Les tests doivent être complétés par d'autres formes de techniques d'amélioration de la qualité qui peuvent identifier les bogues potentiels avant même de commencer les tests. Parmi les plus efficaces figurent l’analyse statique et les examens formels couvrant les exigences, l’architecture, la conception et le code.

Testez qu'il ne fait pas ce qu'il ne devrait pas

Supposons que vous effectuez une transaction sur votre application bancaire, la connexion est perdue et seule la moitié de l'instruction est envoyée à la banque. Comment le système de la banque traite-t-il la moitié d’une instruction ? Si ce système est connecté à un système existant, comment le système existant gère-t-il une instruction incomplète ? Chaque fois que nous modifions un système, nous vérifions toujours que le nouveau système fait ce qu'il est censé faire. Nous devons également nous assurer qu'il ne fait pas ce qu'il ne devrait pas faire, ce type de tests ayant tendance à être négligé.

Horaires compressés

Il ne fait aucun doute que le travail effectué par le BST pour migrer les systèmes aura fait l’objet de tests approfondis. Cependant, avec tous ces projets, l'équipe aura été soumise à une certaine pression de temps pour terminer son travail à une date donnée. Un calendrier compressé est l’une des causes les plus courantes d’échec des projets informatiques.

Compétences techniques

Le codage est un travail créatif qui demande des compétences et de l’expérience. Par exemple, il existe de nombreuses façons de coder le même résultat : un codeur peut réaliser un ensemble de fonctionnalités en seulement une ou deux lignes, un autre peut devoir en écrire cinquante. Dans l’ensemble, un code plus compact/laconique a tendance à être de meilleure qualité. Les compétences des développeurs varient considérablement, comparez un chanteur qui est parfait avec un autre qui ne peut même pas porter une mélodie, ils se disent tous les deux « chanteurs ». Les développeurs peu compétents peuvent introduire plus de bogues que de correctifs ou de fonctionnalités.

Pression commerciale pour de nouvelles exigences

Les dirigeants sont toujours sous pression pour développer leur activité et, dans certains cas, peuvent perdre de vue l'importance de systèmes stables et précis lorsqu'ils sont sous pression pour fournir de nouvelles fonctionnalités et capacités.

Bugs non prévus, donc le risque commercial n'a pas été compris

Contrairement à ce que pensent de nombreuses personnes, les bogues des logiciels peuvent être prédits et mesurés. En utilisant des métriques logicielles standard, il est possible de savoir combien de bogues il reste dans un système avant de le mettre en ligne. Si les responsables sont informés du nombre de défauts restant à détecter, ils pourraient ne pas approuver la décision de mise en service. Il est décevant de constater que très peu de personnes utilisent ces métriques. Ils sont (comme COBOL) démodés mais ils fonctionnent. Ils apportent une certitude considérable à une industrie qui est tombée amoureuse du « fail fast » et du « déploiement rapide » par rapport à des mesures éprouvées.

Conclusion

Il existe de nombreuses raisons possibles pour expliquer les récents problèmes du BST, et j'en suggère quelques-unes ici. La vérité est que le remplacement des systèmes existants est bien plus qu’une simple responsabilité informatique ; dans certains cas, il s’agit d’une question de survie entière de l’entreprise. Les clients des banques peuvent être tolérants si leur application bancaire est indisponible pendant quelques heures, mais ils n'accepteront pas de soldes incorrects ou de transactions fortement retardées. Cela mine la confiance, et sans confiance, les clients des banques iront ailleurs. Colin Hammond est consultant en assurance de projets informatiques et auteur de ScopeMaster, un outil permettant d'apporter de la certitude aux projets informatiques.