Test Visuel pour la Fintech et la Banque : Pourquoi le On-Premise Est Non Négociable
Test de régression visuelle : processus automatisé de comparaison de captures d'écran d'une interface avant et après modification, permettant de détecter tout changement visuel non intentionnel — selon le glossaire de l'ISTQB (International Software Testing Qualifications Board), il s'agit d'une forme spécifique de test de régression appliquée à la couche de présentation.
Imaginez la scène. Un client ouvre son application bancaire un lundi matin. L'écran de solde affiche un montant avec une virgule décalée. Au lieu de 12 450,00 €, il lit 124,50 €. Le client panique, appelle le service client, poste sur les réseaux sociaux. Le solde réel n'a pas bougé — c'est un bug CSS qui a décalé le formatage. Mais le mal est fait.
Ce scénario illustre une réalité que chaque responsable QA dans la finance connaît : l'interface utilisateur n'est pas un détail cosmétique. C'est la couche de confiance entre votre institution et vos clients. Et un pixel mal placé peut coûter infiniment plus cher qu'un bug fonctionnel classique.
Pourquoi les interfaces financières sont des surfaces critiques
Il y a une différence fondamentale entre un bug visuel sur un site e-commerce et un bug visuel sur une interface bancaire. Sur un site e-commerce, vous perdez une vente. Sur une interface bancaire, vous déclenchez la peur — peur de perdre de l'argent, peur d'une fraude, peur que la banque ait perdu le contrôle. Et cette peur se propage. Un tweet, un post Reddit, un article de presse — et la confiance construite en années s'effrite en heures.
Les interfaces financières affichent des données intrinsèquement anxiogènes quand elles sont incorrectes : soldes, historiques de transactions, montants de virements, tableaux de bord d'investissement. Un affichage incorrect peut même conduire un client à valider une opération qu'il n'aurait pas validée avec les bonnes informations. Le bug visuel a alors des conséquences fonctionnelles réelles — même si le backend fonctionne parfaitement.
Les équipes testent leurs APIs de manière exhaustive, automatisent les tests fonctionnels, vérifient chaque calcul côté serveur. Mais la couche de présentation reste trop souvent vérifiée manuellement. Cette approche ne passe pas à l'échelle et laisse passer des régressions subtiles : un décalage de 2 pixels dans un tableau, une couleur modifiée sur un indicateur de statut, une police de secours qui remplace la police principale.
Le cadre réglementaire et ses implications pour le test visuel
PCI-DSS 4.0. L'exigence 3 (protection des données stockées), l'exigence 6 (développement sécurisé) et l'exigence 7 (restriction d'accès) s'appliquent directement. Quand votre outil de test visuel capture un tableau de bord affichant des numéros de carte masqués, des montants et des identifiants clients, cette capture est soumise à PCI-DSS. L'envoyer vers un cloud américain crée un problème de conformité.
ACPR. Depuis les recommandations de 2024 sur le cloud, les établissements doivent démontrer le contrôle effectif des données externalisées et disposer de plans de réversibilité. Un outil de test SaaS qui stocke vos captures dans le cloud tombe dans ce périmètre.
DORA. Entré en application en janvier 2025, ce règlement européen impose de tester la résilience des systèmes ICT et renforce les exigences sur les prestataires tiers — ce qui concerne directement les outils SaaS utilisés dans le test.
Ce que ces réglementations disent en substance : vous devez tester vos interfaces, protéger les données qui apparaissent dans ces tests, et maîtriser les outils utilisés. Envoyer des captures contenant des données financières vers un cloud américain rend chacune de ces exigences plus difficile à satisfaire.
Le problème fondamental du cloud pour les captures bancaires
Votre équipe QA utilise un outil SaaS. L'outil capture un écran de gestion de comptes en staging : noms de clients, montants, IBAN partiels, indicateurs de statut. La capture part vers les serveurs du fournisseur.
Où est-elle stockée physiquement ? Qui y a accès ? Est-elle soumise au CLOUD Act américain, qui permet aux autorités américaines d'exiger l'accès aux données stockées par des entreprises américaines, même sur des serveurs européens ?
Et il y a le problème des données de staging. "Nos captures ne contiennent pas de données réelles", affirment les équipes. En pratique, les environnements de staging des banques contiennent souvent des copies partielles de données de production. Un IBAN au format valide, même généré aléatoirement, combiné à un nom et un montant, peut constituer une donnée à caractère personnel au sens du RGPD.
Le seul moyen d'éliminer ce risque structurellement — pas de le mitiger, de l'éliminer — c'est que les captures ne quittent jamais votre infrastructure.
Le on-premise : une obligation, pas une préférence
Le test visuel on-premise signifie que l'ensemble du processus — capture, stockage, comparaison, résultats — se déroule sur des machines que vous contrôlez. Cette approche élimine la question du transfert vers un tiers, supprime le risque CLOUD Act, simplifie la conformité PCI-DSS, et satisfait les exigences de l'ACPR.
Historiquement, le on-premise signifiait des licences coûteuses et des serveurs à provisionner. Cette équation a changé. Il existe aujourd'hui des outils qui fonctionnent en local sans infrastructure lourde — des applications desktop qui s'installent en quelques minutes.
Comment Delta-QA répond aux exigences de la finance
Aucune donnée ne quitte votre machine. Captures prises localement, stockées localement, comparées localement. Pas de serveur Delta-QA, pas d'API cloud, pas de transfert réseau. Quand votre auditeur PCI-DSS demande où vont les captures : nulle part.
Pas de code, pas de SDK, pas de pipeline. Dans la finance, les pipelines CI/CD sont verrouillés et audités. Ajouter un SDK tiers nécessite une revue de sécurité. Delta-QA contourne ce problème : c'est une application desktop. Vous l'installez, vous naviguez, l'outil compare. Aucune modification de votre code.
Un algorithme déterministe, pas une boîte noire IA. L'algorithme structurel en 5 passes analyse le CSS réel. Quand il détecte un changement, il dit précisément quoi : "la taille de police est passée de 14px à 13px". C'est auditable, reproductible, explicable — un avantage significatif dans un contexte réglementaire.
La version Desktop est gratuite et sans limite. Pas de processus d'achat, pas de devis, pas de contrat annuel. Vous téléchargez, vous testez.
Ce que le test visuel détecte dans les interfaces financières
Les régressions les plus critiques dans la finance sont spécifiques : erreurs de formatage numérique (séparateurs de milliers, décimales, symboles de devise), régressions de tableau de bord (graphiques superposés, colonnes disparues), problèmes d'états conditionnels (couleurs de statut inversées, messages d'erreur mal stylés), et régressions d'accessibilité (contraste insuffisant, zones cliquables réduites).
Limites à connaître
Le test visuel ne remplace pas les tests fonctionnels ni les tests de sécurité. Il vérifie l'intégrité visuelle, pas la logique métier.
Delta-QA ne propose pas d'intégration CI/CD cloud native. Si votre workflow exige un test automatique à chaque pull request dans un pipeline cloud, ce n'est pas le bon outil aujourd'hui. C'est un choix de conception qui préserve le modèle on-premise, mais c'est une limite réelle.
FAQ
Le test visuel est-il obligatoire pour la conformité PCI-DSS ?
PCI-DSS n'impose pas explicitement le test visuel. Cependant, les exigences 6.2 et 6.3 impliquent des processus de test couvrant l'ensemble de l'application. Un auditeur qui constate qu'un bug d'affichage a conduit un client à effectuer une mauvaise opération pourrait le considérer comme une défaillance du processus de test. C'est un contrôle préventif fortement recommandé.
Les captures de staging sont-elles des données sensibles ?
Oui, dans la plupart des cas. Si elles contiennent des IBAN au format valide, des noms et des montants, elles sont des données à caractère personnel au sens du RGPD — même si les données sont synthétiques.
Quelle différence entre SaaS et on-premise pour une banque ?
Le lieu de traitement des données. Avec un SaaS, vos captures partent vers les serveurs du fournisseur. Avec un outil on-premise, tout reste sur votre infrastructure. Pour une banque, cette différence a des implications sur PCI-DSS, ACPR, RGPD et CLOUD Act.
Delta-QA peut-il s'intégrer dans un pipeline CI/CD bancaire ?
Delta-QA est un outil desktop local. Il ne s'intègre pas nativement dans un pipeline CI/CD cloud. Pour les banques, cette limitation est souvent un avantage : les pipelines bancaires sont des environnements où l'ajout d'un outil tiers nécessite des semaines de validation. Delta-QA permet de tester immédiatement, en complément des tests du pipeline.
Combien coûte la mise en place pour une équipe bancaire ?
Avec Delta-QA, le coût initial est nul. La version Desktop est gratuite sans limite. L'investissement principal est le temps pour définir les parcours de test. Pour une application avec 20 à 30 écrans critiques, comptez une à deux journées de mise en place.
Le test visuel détecte-t-il les problèmes d'accessibilité ?
Il détecte les régressions visuelles d'accessibilité : perte de contraste, réduction de zones cliquables, disparition d'indicateurs de focus. Il ne remplace pas un audit complet (RGAA, WCAG 2.1), mais il empêche les régressions entre deux audits.
Conclusion
Dans la banque et la fintech, le test visuel est un contrôle nécessaire sur une surface critique. Les réglementations convergent vers une même exigence : maîtrisez vos données et vos outils. Le on-premise n'est pas une préférence technique — dans la finance, c'est une obligation.