Vous cherchez une alternative à Tosca ?

La différence de fond tient à la façon de concevoir un test. Tosca repose sur une approche basée sur les modèles : on modélise l'application sous forme de modules réutilisables, puis on assemble des cas de test à partir de ces modèles. Sa force est la couverture, mais la contrepartie est la profondeur de configuration, avec des centaines d'options, des modules imbriqués et une courbe d'apprentissage si raide qu'expert Tosca est devenu un intitulé de poste. Thunders part de l'intention : on décrit le scénario en langage naturel et le moteur génère le test exécutable, la complexité étant gérée de façon invisible par la plateforme. En clair, avec Tosca l'équipe apprend à utiliser l'outil, avec Thunders l'outil apprend ce que l'équipe veut tester.

Tosca a été conçu pour des cycles de publication trimestriels, avec des projets de mise en œuvre lourds : la Tricentis Academy existe précisément parce que la plateforme exige une formation formelle, et le délai avant le premier test exécutable se compte en semaines ou en mois. Thunders vise le premier test en quelques minutes : pas de projet de déploiement, pas de consultant, pas de parcours de certification, et la plupart des équipes disposent d'une suite fonctionnelle dès le premier jour. Un détail pratique compte aussi côté adoption : le support Mac OS pour la création de tests est limité chez Tosca, là où Thunders, cloud-native, s'utilise depuis n'importe quel poste. Pour une équipe qui veut être productive tout de suite plutôt qu'après une montée en compétence, c'est l'argument central.

Tosca est positionné sur le segment entreprise, avec un système de licences modulaire : des activations distinctes pour des fonctionnalités distinctes. Tricentis ne publie pas de tarif, chaque demande passant par un échange commercial ; les sources tierces évoquent un déploiement de taille moyenne entre 40 000 et plus de 100 000 euros par an, un socle autour de 20 000 euros par an, et des renouvellements en hausse de 15 à 20 %. À la licence s'ajoutent la formation et les consultants nécessaires à l'exploitation. Thunders met en avant une tarification transparente et publiée, sans activation de licence par fonctionnalité, et sans projet de conseil pour démarrer. L'écart de coût vient donc autant du modèle de licence que du coût humain d'exploitation.

L'approche basée sur les modèles de Tosca est réellement puissante une fois les modèles construits, mais puissance et accessibilité tirent dans des directions opposées, et c'est l'accessibilité qui détermine si toute l'équipe utilise vraiment l'outil. Le langage naturel de Thunders supprime l'étape de modélisation : au lieu d'apprendre une syntaxe de modèles, on décrit l'objectif fonctionnel et l'IA le transforme en test exécutable. Cela ouvre la création de tests aux profils non techniques (PM, analystes métier, réussite client) sans interpréter des arbres de modèles ni décoder une syntaxe propriétaire. On échange une structuration lourde mais robuste contre une immédiateté et une accessibilité maximales.

Les deux s'intègrent aux chaînes CI/CD, mais avec une différence d'effort. Tosca s'intègre largement, mais la plupart des intégrations demandent de la configuration et des heures de consulting. Thunders se connecte nativement à GitHub, GitLab, Jenkins, Jira, Linear et Xray dès le premier jour : le pipeline déclenche les tests automatiquement, et les échecs deviennent des tickets avec contexte complet, sans code de liaison personnalisé ni sprint d'intégration. Point structurant souvent négligé : Thunders utilise un contrôle de version standard, compatible Git, là où Tosca s'appuie sur un système propriétaire à gérer en plus.

Les deux réduisent la fragilité, mais différemment. Le Vision AI de Tosca offre une auto-réparation au niveau de l'interface, en reconnaissant les éléments visuellement plutôt que par sélecteur, ce qui est une vraie amélioration par rapport à l'automatisation scriptée. Mais la maintenance à grande échelle continue d'exiger des spécialistes Tosca (mise à jour des modèles, gestion des licences, configuration des environnements) et repose sur un contrôle de version propriétaire qui n'autorise pas la fusion en parallèle comme Git : plus la suite grandit, plus l'équipe pour la faire tourner doit grandir. Thunders maintient au niveau de l'intention, avec des mises à jour automatiques quand l'interface change, et détecte et résout automatiquement les tests instables (flaky) avant qu'ils ne polluent les résultats, un point que Tosca ne traite que de façon limitée. L'argument de Thunders est que la maintenance n'augmente pas linéairement avec la taille de la suite.

Tosca reste taillé pour les grandes organisations avec un paysage applicatif complexe et hétérogène (ERP, SAP, legacy, mainframe), où sa couverture et sa gouvernance à grande échelle font la différence, à condition d'accepter le coût, la formation et une fonction QA centralisée. Thunders s'adresse aux équipes qui livrent quotidiennement et veulent démocratiser le test au-delà de la QA, sur web, mobile natif et API, sans déploiement lourd. En pratique : Tosca si le critère décisif est la largeur de couverture entreprise et l'orchestration à très grande échelle ; Thunders si le critère est la vitesse de mise en œuvre, l'accessibilité à toute l'équipe et le coût total.

Le TCO de Tosca dépasse largement la licence. Le système modulaire fait payer des activations distinctes par fonctionnalité, la Tricentis Academy et la certification représentent un coût de formation, et l'exploitation à grande échelle suppose des spécialistes dédiés, avec des tarifs de consultants souvent élevés et une part significative ajoutée la première année pour l'implémentation. S'ajoute un coût structurel, celui d'un contrôle de version et d'un langage propriétaires qu'il faut gérer et dont on dépend. Thunders met en avant un TCO plus contenu : mise en place en quelques minutes sans conseil, aucune certification, tarification publiée sans activation par fonctionnalité, et compatibilité Git qui évite d'entretenir un outillage propriétaire.

Chez Tosca, l'autonomie réelle passe par la maîtrise de l'approche basée sur les modèles : savoir modéliser l'application, structurer des modules et naviguer dans des arbres de modèles, ce qui explique l'existence d'un métier d'expert Tosca et d'un parcours d'académie. C'est cette exigence qui tend à concentrer l'accès dans une fonction QA centralisée et à exclure PM, analystes métier et équipes de réussite client. Thunders vise l'autonomie de profils non spécialistes dès les premiers jours : décrire un scénario en langage naturel ne requiert ni méthodologie de modélisation, ni syntaxe propriétaire, ni code. La barrière d'entrée technique est donc l'un des principaux points de divergence.

Deux philosophies de résilience. Chez Tosca, l'approche basée sur les modèles centralise la logique : une évolution se répercute en mettant à jour le module concerné, et Vision AI stabilise le test d'interface en reconnaissant les éléments visuellement, mais cela suppose de tenir les modèles à jour et de mobiliser des spécialistes à mesure que la suite grandit. Chez Thunders, l'approche par intention réaligne le test sur l'objectif décrit via l'auto-healing, sans couche de modélisation, et la détection automatique des tests flaky évite l'accumulation de bruit dans les résultats. Là où Tosca demande de maintenir un modèle central fidèle à l'application, Thunders parie sur l'adaptation automatique à partir de l'intention exprimée.