Construire ou acheter son automatisation de tests : quelle option coûte le moins cher à maintenir ?

Construire ou acheter son automatisation de tests est une décision de modèle opérationnel sur le long terme. La vraie comparaison va au-delà de l'effort de mise en place face au coût de licence : elle porte sur la charge de maintenance année après année, les preuves que chaque modèle produit quand quelque chose casse, l'adéquation avec le stack existant et la question de savoir qui assume la fiabilité quand les choses dérivent. Cet article vous donne un cadre pour recueillir ces preuves. Il montre aussi, critère par critère, comment une option d'achat, Thunders, répond à chaque question, pour vous offrir une référence concrète à laquelle confronter n'importe quelle plateforme.

‍

Ce qu'implique réellement une automatisation QA construite en interne

Construire son propre framework d'automatisation QA, c'est assumer toute la pile : conception du framework, écriture des tests, configuration des environnements, gestion des données de test, intégration CI/CD, reporting et documentation. Chacune de ces couches demande une attention continue. Le coût de mise en place d'un framework se paie une fois. Le coût de son exploitation, lui, ne s'arrête jamais.

Dès que l'application testée évolue, qu'il s'agisse de nouveaux éléments d'interface, de workflows refondus ou d'API mises à jour, le framework doit suivre. Ce travail revient au même rythme que les livraisons de l'application.

La taxe de maintenance des scripts maison

Le travail de maintenance se répartit en catégories prévisibles. Les mises à jour de locators sont les plus visibles : un sélecteur change et les tests échouent jusqu'à ce que quelqu'un les répare. Un workflow modifié oblige à réécrire la logique de test, pas seulement à la rapiécer. Les tests instables (flaky tests) exigent une investigation pour séparer les vrais défauts de l'instabilité d'environnement, des problèmes de timing ou des effets de bord liés aux données de test.

C'est précisément cette boucle de réparation des locators que les agents de test IA ont été conçus pour supprimer. Dans Thunders, une étape de test est enregistrée sous la forme de l'action utilisateur qu'elle vérifie (« ajouter le produit au panier et vérifier le total ») plutôt que sous la forme d'un sélecteur CSS ou XPath. Un bouton renommé ou un élément déplacé ne fait donc pas échouer l'exécution : l'agent résout l'intention sur la page telle qu'elle est.

Au-delà des tests eux-mêmes, le travail d'intégration CI/CD s'accumule : scripts de pipeline, provisionnement des environnements, configuration de la parallélisation et intégrations de reporting demandent tous de l'attention dès que l'infrastructure ou le processus de déploiement change. Former un nouvel ingénieur au framework prend du temps, surtout quand les conventions ne sont pas documentées ou n'existent que dans la tête d'une seule personne.

Le tableau ci-dessous distingue les principales catégories de coûts, les questions à poser avant de les estimer et les preuves à recueillir pour comparer cette base à une plateforme.

Recueillez ces preuves dans votre propre historique. Les moyennes du secteur varient trop selon la taille de l'équipe et le type d'application pour remplacer la charge réelle de votre équipe. Si vous testez une plateforme, suivez ces six mêmes catégories pendant l'essai pour comparer à périmètre égal.

Quand construire est le bon choix

Construire est le bon choix dans un ensemble précis de situations :

• L'application utilise des protocoles spécialisés, des interfaces matérielles atypiques ou des environnements de déploiement que les plateformes disponibles ne prennent pas en charge.
• Des exigences strictes de résidence des données, de sécurité ou de conformité réglementaire excluent l'exécution des tests par un tiers.
• L'équipe dispose d'une expertise profonde et durable sur le framework qu'elle maintient, et le coût opérationnel est compris et budgété.
• Un comportement indispensable, comme un contrôle précis du timing, un protocole de communication propriétaire ou une intégration avec l'outillage interne, ne peut être reproduit sur aucune plateforme disponible.

Dans ces cas, un framework maison n'est pas un héritage du passé. C'est la seule option viable. L'équipe assume la fiabilité, la documentation, les mises à niveau, les preuves de réparation et le coût de chaque changement, et ce compromis est acceptable quand aucune autre voie ne permet d'obtenir l'adéquation spécialisée nécessaire.

Vérifiez toutefois la deuxième condition avant de vous engager. La résidence des données et la sécurité n'excluent plus d'office une plateforme. Thunders, par exemple, peut être déployé dans un cloud dédié mono-tenant, en auto-hébergement ou entièrement on-premise avec vos propres clés de modèles IA, et est conforme ISO 27001, SOC 2 et RGPD. Les exécutions mobiles sur de vrais appareils iOS et Android peuvent rester aux États-Unis ou dans l'Union européenne. Si cela couvre votre contrainte, elle cesse d'être une raison de construire et devient une question d'évaluation.

Quand un modèle hybride est le bon choix

Certaines équipes ne font pas face à un choix binaire. Les différentes parties de la suite de tests n'ont ni le même profil de risque, ni le même rythme de changement, ni les mêmes exigences de contrôle.

Un modèle hybride conserve des tests codés pour les parcours qui exigent un contrôle spécialisé, une mesure de performance, une validation de sécurité ou une conformité réglementaire. Il confie à une plateforme l'ensemble plus large des workflows utilisateurs, ceux qui changent souvent et génèrent l'essentiel du travail de réparation. Une répartition typique : une suite liée à un protocole propriétaire reste en code, tandis que les parcours web côté client passent sur Thunders, qui s'exécute comme une étape du même pipeline CI/CD (GitHub, GitLab, Jenkins). Les deux couches conditionnent ainsi la même release.

Les risques sont réels. Deux systèmes de maintenance peuvent diverger : le reporting se fragmente, les frontières de responsabilité se brouillent, et faire tourner deux couches peut coûter plus cher que d'en choisir une seule. Un modèle hybride n'a de sens que si l'équipe sait définir une règle claire sur la place de chaque test, la consolidation des preuves et le responsable de chaque périmètre. Sans cette clarté, l'hybride ajoute de la complexité opérationnelle sans réduire le travail.

‍

Ce que change l'achat d'une plateforme d'automatisation QA

Une plateforme d'automatisation QA change le modèle opérationnel. Au lieu de construire et de posséder l'infrastructure qui exécute les tests, les équipes configurent leurs tests dans un environnement géré par l'éditeur et s'appuient sur lui pour l'exécution, les intégrations et les mises à jour. L'entretien du framework diminue, mais acheter ne supprime pas la maintenance. Une partie peut être déplacée chez l'éditeur, et l'achat introduit une dépendance à celui-ci, des coûts de migration si la plateforme ne convient pas au workflow, et le risque que la plateforme s'éloigne des besoins de l'équipe avec le temps.

La part de maintenance qui disparaît vraiment dépend de ce que la plateforme enregistre comme « un test ». Les outils d'enregistrement et de rejeu produisent toujours des sélecteurs en coulisses : ils déplacent surtout le problème des locators. Les plateformes à base d'agents comme Thunders enregistrent l'intention de chaque étape et laissent un agent IA la résoudre sur l'interface réelle au moment de l'exécution. C'est un autre modèle de maintenance, et c'est celui à éprouver le plus sérieusement pendant un essai.

Acheter mérite une évaluation sérieuse quand :

• L'application repose sur un workflow web standard qui change souvent.
• L'équipe n'a pas la capacité de maintenir l'infrastructure du framework en plus de livrer des fonctionnalités.
• Des personnes extérieures à l'ingénierie QA (product managers, développeurs, business analysts) doivent écrire ou relire des tests, ce que permettent les plateformes en langage naturel comme Thunders.
• L'auditabilité, les intégrations prises en charge et l'outillage de gouvernance sont des priorités d'évaluation.
• L'équipe peut vérifier, par un essai sur un workflow représentatif, que la plateforme réduit le travail de réparation au lieu de le déplacer.

Acheter est peu adapté quand l'application présente des contraintes spécialisées que la plateforme ne sait pas traiter, quand la dépendance à l'éditeur entre en conflit avec la politique de sécurité ou d'achats, ou quand les preuves et la piste d'audit de la plateforme ne satisfont pas aux exigences de gouvernance de l'équipe.

Lock-in éditeur : le risque à régler avant de signer

Le principal risque à long terme de l'achat, c'est le lock-in. Si vos tests n'existent que dans la plateforme d'un éditeur, partir signifie reconstruire la suite à partir de zéro, et ce coût de sortie grossit discrètement à chaque test ajouté. Il donne aussi à l'éditeur un levier à chaque renouvellement, et c'est souvent la raison pour laquelle les achats, le juridique ou un audit de risque fournisseur bloquent purement et simplement une plateforme.

Posez une question directe à chaque éditeur avant de vous engager : pouvons-nous partir avec tous nos tests, sous forme de code exécutable sans vous ? N'acceptez qu'une réponse démontrée. Un CSV de noms de tests ou un rapport PDF n'est pas une porte de sortie.

Thunders répond oui. La plateforme exporte tous vos scénarios de test sous forme de projet Playwright TypeScript standard, qui s'exécute avec npm ci et npx playwright test, sur vos propres machines et dans votre propre CI, sans aucune dépendance à Thunders. Chaque étape Thunders devient une étape Playwright nommée, avec votre instruction d'origine en langage naturel conservée en commentaire au-dessus du code. Les tests réutilisés deviennent des modules partagés, chaque environnement a son propre fichier, et les secrets ne sont jamais copiés : ils sont listés, vides, pour que vous les renseigniez. Un rapport d'export indique quelles étapes ont été exportées en code complet et lesquelles demandent un travail manuel. Les clients cloud demandent l'export à leur contact Thunders ; les clients auto-hébergés le lancent eux-mêmes.

Soyez lucide sur ce qu'un export peut transporter ou non. Du code brut ne sait pas faire ce que Thunders fait avec l'IA au moment de l'exécution : les vérifications en langage naturel, les sélecteurs auto-réparants, les données de test générées et les personas d'accessibilité sont exportés sous forme de TODO commentés, et les tests mobiles natifs sont listés plutôt que convertis, car Playwright n'exécute pas d'applications mobiles. C'est la forme honnête du risque de lock-in avec une plateforme IA : vous gardez vos tests, et vous reprenez la maintenance que la plateforme assurait pour vous.

Tests auto-adaptatifs : évaluez les preuves, pas l'étiquette

Le self-healing est le terme employé par les éditeurs pour désigner l'adaptation automatique aux changements d'interface ou de workflow. L'étiquette recouvre des comportements très variés, du simple sélecteur de repli jusqu'aux agents IA qui réinterprètent une étape à partir de son intention.

L'étiquette seule ne suffit pas pour évaluer. Ce qui compte, c'est ce qui se passe quand un test casse :

• Qu'est-ce qui a changé exactement ? (Élément, sélecteur, structure visuelle, parcours du workflow ?)
• Pourquoi ce changement ? Était-il intentionnel ou s'agit-il d'une régression ?
• Quelles preuves ont été capturées pour justifier la réparation automatique ?
• Un relecteur peut-il voir, approuver, rejeter ou annuler le changement ?
• Existe-t-il un historique des versions et un modèle de permissions qui encadre qui peut accepter les réparations ?

Un système qui modifie un test en silence et renvoie un résultat vert sans conserver de preuves rend plus difficile de savoir si l'intention d'origine du test est toujours vérifiée.

Pour donner un point de référence, voici comment Thunders procède. L'auto-réparation s'appuie sur l'intention de l'étape, pas sur un locator unique. Avant une exécution, Thunders AI signale les étapes fragiles et propose des améliorations ; après une exécution, la plateforme suggère des mises à jour d'étapes quand le produit a évolué. Chaque suggestion peut être appliquée ou rejetée par un relecteur. Quand Thunders répare une étape pendant une exécution, le rapport d'exécution affiche chaque étape réparée et ce qui a été modifié pour qu'elle passe, et le résumé de l'exécution en fait le décompte : rien n'est réparé en silence. Les versions d'un scénario de test peuvent être restaurées, et les équipes peuvent modifier leurs tests sur une Branch séparée, relire les changements étape par étape, puis les fusionner dans main. Les administrateurs définissent l'accès de chaque utilisateur par projet, avec un rôle en lecture seule pour les personnes qui doivent voir les tests sans les modifier. Quand une exécution échoue, Thunders AI l'analyse, identifie l'étape fautive, distingue les vrais bugs produit des problèmes de test et rédige un rapport de bug prêt à être créé dans Jira ou Linear.

Appliquez le même niveau d'exigence à chaque éditeur, Thunders compris. Exigez une démonstration sur un workflow représentatif, pas dans un environnement de démo soigneusement préparé, et interrogez précisément les modes de défaillance : que se passe-t-il quand une réparation est fausse, et comment un test mal réparé est-il détecté puis corrigé ?

Garder le stack existant en vue

La plupart des équipes qui évaluent une plateforme ne partent pas de zéro. Elles disposent de tests codés, de pipelines CI/CD et d'un outillage de reporting qu'elles ne peuvent pas abandonner du jour au lendemain.

Évaluez chaque plateforme selon ces critères : les possibilités d'import des suites de tests existantes, l'accès API et CLI pour l'intégration CI/CD, les options d'export si la relation s'arrête, et la coexistence avec les tests codés dans un pipeline commun. Pour les équipes qui ont déjà une suite codée, la documentation Selenium reste la référence pour comprendre ce qui migre et ce qui ne migre pas.

Concrètement, Thunders génère des tests à partir de prompts en langage naturel, d'URL, de tickets Jira, d'issues Linear, de documentation produit et de maquettes Figma. La plateforme s'exécute dans les pipelines CI/CD existants avec suivi des exécutions en direct, se connecte à Jira, Xray, Linear, GitHub, GitLab et Jenkins, et expose un serveur MCP pour créer et lancer des tests depuis des assistants IA comme Claude, ChatGPT ou Cursor. Si la relation s'arrête, Thunders exporte tous vos scénarios de test en code Playwright (voir la section sur le lock-in éditeur plus haut).

Qu'une plateforme remplace les tests codés, les complète ou fonctionne à leurs côtés dépend du workflow et du modèle de risque. Cette décision revient à l'équipe, pas à l'éditeur.

‍

Construire ou acheter son automatisation de tests : un cadre de décision pratique

Le tableau ci-dessous est un point de départ, pas un verdict. Chaque équipe pondérera ces critères à sa façon. Complétez-le avec vos propres preuves avant de conclure.

Un modèle de coût total de possession (TCO) doit intégrer le temps d'ingénierie interne consacré à la maintenance et à la réparation du framework, les coûts CI/CD et d'infrastructure, les licences de la plateforme, l'intégration des équipes, le support, les coûts de changement et la charge de gouvernance. Calculez-le sur trois à cinq ans, pas sur un seul, avec les données réelles de votre équipe. Les benchmarks publiés varient trop selon la taille de l'équipe et la complexité de l'application pour remplacer de vraies données.

Exemples de parcours de décision

Construire : l'application utilise un protocole binaire propriétaire qu'aucune plateforme disponible ne prend en charge. Deux ingénieurs seniors ont construit le framework et le maintiennent. Le coût opérationnel est compris, budgété et compensé par le contrôle et la couverture spécialisée qu'apporte la suite maison.

Acheter : l'équipe maintient un produit SaaS d'entreprise standard. Les changements d'interface sont livrés toutes les deux semaines, et les ingénieurs passent une part importante de chaque sprint à réparer des locators et à traquer des tests instables. Ils testent Thunders sur deux parcours représentatifs, le paiement et l'onboarding. Le responsable QA et un product manager décrivent les scénarios en langage naturel, les tests s'exécutent dans le pipeline CI existant, et l'équipe compare les incidents de réparation et le taux de relance à ceux du trimestre précédent avant de s'engager.

Hybride : une application financière régulée comporte un flux transactionnel central qui doit être testé sur une version d'API précise, avec des preuves auditables pendant trois ans. Ce parcours reste codé. Les workflows utilisateurs qui l'entourent, qui changent souvent et concentrent l'essentiel des réparations de locators, passent sur une plateforme. Comme les données de test ne peuvent pas quitter l'environnement de la banque, l'équipe ne retient que des plateformes déployables en auto-hébergement, comme Thunders. Les règles de responsabilité et la consolidation des preuves sont documentées avant la mise en place de la répartition.

Questions à poser lors de l'évaluation d'une plateforme

• Comment la plateforme gère-t-elle un changement d'interface ou de workflow, et quelles preuves conserve-t-elle pour chaque changement automatique ?
• Les relecteurs peuvent-ils voir, approuver, rejeter et auditer les réparations automatiques, et quel est le modèle de permissions ?
• Quels intégrations, chemins d'import, API, options d'export et déclencheurs CI/CD sont pris en charge, et avec quelles limites ?
• Comment sont gérés les versions de tests, les preuves, les permissions, les échecs et les retours en arrière ?
• Pouvons-nous exporter tous nos tests en code exécutable (Playwright, par exemple) qui fonctionne sans la plateforme, et qu'est-ce qui ne s'exporte pas ?
• La plateforme s'intègre-t-elle au stack et au processus de release actuels de l'équipe sans dupliquer la maintenance ?
• Quelles affirmations sur les capacités, les performances, les résultats clients, les prix ou le ROI peuvent être vérifiées de façon indépendante, par la documentation ou un essai contrôlé ?

Ces questions valent pour toutes les plateformes. Toute réponse qui ne peut pas être démontrée sur votre propre workflow représentatif doit rester non vérifiée jusqu'à preuve du contraire.

‍

Pourquoi Thunders est une option solide si vous achetez

Si vos preuves penchent vers l'achat ou l'hybride, la question suivante est de savoir quelle plateforme supprime le plus de maintenance au lieu de la déplacer. Thunders est une plateforme d'automatisation de tests par IA dans laquelle des agents IA écrivent, exécutent et maintiennent des tests end-to-end à partir de descriptions en langage naturel, sur des applications web, mobiles (iOS et Android natifs sur de vrais appareils), API et desktop. Elle a été conçue autour des catégories de coûts décrites dans cet article, et la correspondance est directe.

Côté gouvernance, Thunders est conforme ISO 27001, SOC 2 et RGPD, propose un déploiement en cloud dédié, en auto-hébergement ou on-premise avec vos propres clés de modèles IA, et exporte les tests vers Playwright sur demande. Cela couvre l'essentiel des contraintes qui pousseraient autrement une équipe à construire.

Les résultats sont documentés. Agorapulse a intégré toute son équipe produit en deux heures et est passé de 0 % à 80 % de couverture de tests en six semaines. Clarrio a réduit le temps d'écriture d'un test end-to-end de 40 minutes à moins de 10, a doublé sa fréquence de release et n'a connu aucun incident en production depuis l'adoption de Thunders. LegalPlace, sans aucune expérience préalable de l'automatisation, était opérationnel en quelques jours et a ramené la validation des releases de plusieurs sprints à un seul. Des équipes de Sopra Steria, PwC et Infopro Digital testent également avec Thunders.

Là où Thunders n'est pas la réponse : les protocoles propriétaires, les tests hardware-in-the-loop et les tests qui dépendent d'un timing précis ou d'une mesure de performance. Gardez-les en code et laissez Thunders couvrir la surface utilisateur, celle qui change souvent, tout autour.

‍

Conclusion

Construire ou acheter son automatisation de tests : il n'existe pas de réponse universelle. Le bon modèle opérationnel est celui qui correspond au rythme de changement de votre équipe, à vos exigences spécialisées, à vos standards de gouvernance, à votre tolérance au risque et à votre capacité à assumer les preuves sur toute la durée de vie de la suite.

Un principe vaut pour les trois voies : mesurez la charge de maintenance sur toute la durée d'exploitation, pas seulement pendant la mise en place. Un framework peu coûteux à construire peut coûter bien plus cher à maintenir à jour à mesure que l'application évolue. Une plateforme rapide à configurer peut créer des dépendances et des coûts de changement onéreux le jour où vous voulez en sortir.

Si vous voulez notre réponse directe à la question du titre : pour un produit web standard livré chaque semaine ou plus souvent, acheter coûte généralement moins cher à maintenir, parce que le coût dominant est la réparation, et que la réparation est justement ce que les agents IA fondés sur l'intention retirent à l'équipe. Construire reste gagnant sur un terrain réellement spécialisé.

Évaluez sur un workflow représentatif, pas sur une démo éditeur, et recueillez des preuves dans votre propre historique avant de vous engager. Si vos preuves penchent vers l'achat ou l'hybride, faites tourner l'un de vos vrais parcours sur Thunders et mesurez le travail de réparation par rapport à votre référence. Réservez une session avec un expert Thunders.