Les vitrines indiquent la direction, les panneaux indiquent le pouls
« Feriez-vous confiance à un scénario de test rédigé par une IA sans relecture humaine ? » Cette question a particulièrement interpellé les participants du forum Info.Lunch : Automatisation et tests bancaires. Le 17 septembre 2026, des responsables de l'assurance qualité de banques et d'établissements de paiement de Suisse alémanique et du Liechtenstein se sont réunis au Viaduct Arch D à Zurich. Grandes banques, banques de détail et banques privées étaient représentées.
Comme annoncé lors de la dernière édition, nous avons cette fois-ci ouvert le forum à des participants extérieurs à Avaloq. Il s'adresse désormais à l'ensemble du secteur suisse de la FinTech et reste fidèle à sa mission première : l'ingénierie de qualité dans le secteur bancaire.
Quatre perspectives sur les tests quotidiens
L'événement s'est articulé autour d'une table ronde animée par un modérateur, abordant quatre thèmes essentiels aux pratiques de test quotidiennes des banques : les incidents de production et la culture de l'erreur, la stratégie de régression, la qualité des logiciels acquis et l'IA dans les tests. Maximilian Matthäus (Infometis) a animé la discussion, à laquelle ont participé :
- Domenic Zimmermann, responsable des essais CoE, groupe LGT
- Petra Bohner, responsable Solutions & Projets, Banque cantonale d'Argovie
- Tom Liebau, chef d'équipe du centre d'excellence des tests, Bank-now
- Tjeerd Olk, Product Owner Quality Enabling, Finnova
Les banques et les éditeurs de logiciels ont des points de vue différents sur l'automatisation des tests : motivations, responsabilités et perceptions des risques diffèrent. Il est d'autant plus frappant de constater à quel point leurs approches, leurs interrogations et leurs priorités sont similaires en pratique. Parallèlement à l'automatisation et aux tests basés sur les risques, le besoin d'une ingénierie qualité proactive se fait sentir.
Incidents de production : trouver une solution avant de chercher des coupables
Toutes les entreprises participantes disposent de procédures claires à suivre en cas d'incident de production. L'accent est mis sur la recherche de solutions ; la recherche de coupables est reléguée au second plan. La classification des incidents permet d'identifier les axes d'optimisation les plus prometteurs. Si une erreur se répète et provient de la même source, il est tout à fait acceptable de la traiter. Cette intervention est menée avec discernement, dans le but de résoudre le problème de manière collaborative et durable.
L’objectif zéro incident demeure. Quiconque souhaite maîtriser les efforts de dépistage prend un risque en toute connaissance de cause.
Notre analyse : un risque ne peut être pris consciemment que s’il est visible. Cela nécessite des réponses claires à trois questions :
- Quels processus métier sont critiques ?
- Où s'accumulent les écarts ?
- Quel est le risque résiduel supporté par le département ?
Les tests fondés sur les risques rendent cette décision compréhensible, y compris pour les auditeurs et les organismes de réglementation.
Stratégie de régression : les cas de test doivent avoir une date d’expiration
Tous les participants connaissent bien la question de l'augmentation du nombre de cas de test au sein de l'ensemble de régression. Plutôt que de discuter du nombre approprié de cas de test au sein de cet ensemble, le groupe se concentre délibérément sur la couverture des tests et les tests basés sur les risques. Rares sont les entreprises qui disposent d'un processus définissant quand des cas de test doivent être retirés de l'ensemble de régression. À mesure que la complexité des applications augmente, l'effort de test s'accroît également. L'essentiel est d'aligner l'ensemble sur les modifications logicielles après chaque mise à jour et de le maintenir à jour.
Notre évaluation : Un ensemble de tests de régression reste pertinent si des critères tout aussi clairs s’appliquent pour son inclusion et sa suppression. Ces critères incluent, par exemple, le risque couvert, le taux de réussite sur les versions récentes ou les chevauchements avec d’autres tests. Il est crucial de mettre à jour l’ensemble de tests de régression après chaque version. Cette tâche est parfois négligée ou considérée comme peu prioritaire.
Logiciels achetés : les parties responsables plutôt que les fautifs
Le panel a délibérément laissé en suspens la question de la responsabilité en cas d'erreur de production dans un logiciel acheté, car il a été jugé que cette question était inappropriée. L'objectif est d'identifier les responsables, et non les coupables. Là encore, il s'agit d'apprendre ensemble et d'obtenir le meilleur résultat possible. Les banques n'effectuent que partiellement des tests d'acceptation pour les logiciels achetés. Cependant, elles retournent les logiciels de mauvaise qualité au fabricant.
Le panel était en désaccord sur un point. Les banques ont imputé plus de la moitié des problèmes signalés au fabricant, tandis que ce dernier en a imputé plus de la moitié au client.
Notre évaluation : Cette différence constitue un bon point de départ. Des critères d’acceptation définis conjointement et une classification des écarts convenue permettent aux deux parties de partager les mêmes éléments factuels avant la mise en production du logiciel.
L'IA dans les tests : des tests avec l'IA aux tests IA
D'après un sondage en direct, c'est ce segment qui a le plus marqué les esprits. La question centrale était de savoir si l'on pouvait faire confiance à un cas de test rédigé par une IA sans vérification humaine. Tjeerd Olk a rétorqué en demandant si un test réalisé par des humains méritait réellement la même confiance. Des erreurs se produisent aussi dans ce cas, a-t-il argumenté, mais nous les acceptons plus facilement.
Dans le même temps, le paysage évolue. Les tests avec l'IA deviennent des tests d'IA, ce qui impose de nouvelles exigences en matière de compétences. Petra Bohner a soulevé la question de la formation de la prochaine génération de testeurs, notamment en cas de manque d'expérience initiale.
Notre point de vue : Nous nous penchons sur cette question depuis un certain temps. En tant que première entreprise suisse, nous proposons une formation certifiante ISTQB en tests d’IA . Les testeurs y apprennent à examiner méthodiquement les systèmes d’IA et à évaluer de manière critique les résultats qu’ils génèrent.
L'échange se poursuit pendant le déjeuner
Après la partie officielle, la discussion s'est poursuivie pendant le déjeuner, avec notamment une démonstration interactive de STAMINA animée par Benjamin Tan. La quasi-totalité du public est restée jusqu'à la fin, malgré un léger retard au service traiteur. Le sondage en direct a confirmé ce qui était déjà évident : le format table ronde a été très apprécié.
Conclusion
Une présentation met en lumière l'évolution d'un sujet. Une table ronde donne le ton et révèle la situation actuelle des banques et des fabricants, au-delà des preuves de concept et des projets pilotes. Ces deux formats se complètent. Cette combinaison fait d'Info.Lunch un lieu de rencontre incontournable pour la communauté des tests dans le secteur bancaire suisse.
Lequel de ces quatre sujets préoccupe le plus votre équipe actuellement ? Vous souhaitez peut-être optimiser votre ensemble de tests de régression, créer des tests d'acceptation pour les logiciels standard ou intégrer l'IA à vos tests. Contactez-nouset nous analyserons ensemble votre situation.
Nous remercions tous les intervenants pour leurs échanges constructifs, ainsi que Tricentis et UiPath pour leur soutien à cet événement. Les deux sponsors ont conservé leur indépendance quant au contenu, tant lors de la préparation que pendant la table ronde.
Prochaine édition : Le prochain Info.Lunch : Forum sur l’automatisation et les tests bancaires aura lieu en mars 2027 (la date exacte sera communiquée ultérieurement). Si vous souhaitez recevoir une invitation, veuillez contacter maximilian.matthaeus@infometis.ch. Les participants des éditions précédentes recevront une nouvelle invitation.
