Copilot a généré 40 tests en huit minutes. 31 se compilent. 22 passent sur le CI. La coverage de lignes est passée de 41% à 58%. Le change fail rate en production n'a pas bougé. L'assertion dans la moitié des fichiers est assertNotNull(result). Le SAST dans le même pipeline a 180 findings, dont douze sont de véritables CWE. Personne n'a de ticket pour le triage.
Ce n'est pas un problème de modèle. C'est un problème d'oracle. L'automatisation des tests avec l'IA sans quality gate ressemble à la qualité du code. C'est un build vert basé sur le comportement actuel, y compris sur les erreurs. Le LLM ne sait pas ce qui aurait dû se passer. Il sait ce qui est dans le repo.
Voici une distinction qui manque dans les briefs « nous recherchons un testeur avec IA » : quand louer un seul SDET (body leasing QA automation), et quand la pyramide de tests et le SAST nécessitent une équipe. Nous avons détaillé les tarifs horaires séparément : combien coûte le body leasing IT en 2026. Ici, nous calculons pourquoi la coverage de Copilot est le moyen le plus coûteux d'avoir un dashboard serein.
Une phrase qui ne figure pas sur la diapositive « AI testing »
Un test qui passe ne prouve rien. Ce qui prouve, c'est un test qui peut échouer. Meta sur Instagram et Facebook n'a pas mis l'output du LLM directement dans le main. Elle a mis ce qui a passé le filtre : un build, un pass stable, une augmentation mesurable de la coverage, l'acceptation de l'ingénieur. 25% des classes générées ont augmenté la coverage. Le reste a été rejeté par le quality gate. C'est un produit. Pas un prompt.
1. Anatomie : test vert, oracle mort
Une semaine type de qualité dans une banque, un telco ou une fintech ne ressemble pas à un tutoriel Playwright. Elle ressemble à trois boucles déconnectées :
- Unit. Développeur, JUnit ou pytest, Copilot dans l'IDE. Artefact : un fichier
*Test.javaque personne ne lit parce qu'il « passe ». - E2E. Le QA clique sur le staging ou lance un Selenium enregistré. Flaky sur la CI, donc le job est en
allow_failure: true. - « Sécurité ». Sonar / Checkmarx dans le pipeline. Quality gate configuré pour ne pas bloquer la release. Les findings s'accumulent dans « won’t fix ».
Trois symptômes indiquant que vous avez un générateur, pas une automatisation des tests :
- Oracle cloné depuis le SUT. Le test appelle le même helper que la production et compare le résultat au résultat. Arrondi FX, remise, VAT — le bug est dans le helper, le test le canonise.
- Coverage de lignes sans mutation score. PIT ou Stryker tuerait le mutant en trois secondes. Personne ne l'exécute. Le KPI de l'équipe est le % de lignes, pas le nombre de mutants tués.
- SAST sans SLO. Un CWE critique dans les paiements traîne depuis 120 jours parce que « false positive last time ». Aucun LLM de test ne l'attrapera : le SAST lit un pattern, le test lit un comportement. Ce sont deux alertes distinctes.
C'est pourquoi un brief « testeur qui maîtrise Copilot » sans contexte d'oracle est la manière la plus coûteuse d'obtenir un énième build vert. Les compétences qui construisent réellement l'automatisation des tests se trouvent sur nos pages : testeurs et QA automation, JS/TS (Playwright, Cypress), Java, Python. Le SAST et le Secure SDLC sont complétés par la cybersecurity / DevSecOps. Et la CI où ces jobs tournent réellement : DevOps / SRE.
2. Ce que disent les études, pas les decks « AI writes tests »
Vous n'avez pas besoin d'une autre définition du shift-left. Vous avez besoin d'un seuil à partir duquel un test généré a le droit d'entrer dans le main — et le droit de ne pas y entrer s'il ne fait que compiler.
- 75 / 57 / 25 — et seulement ensuite l'humain. Alshahwan et al., Automated Unit Test Improvement using Large Language Models at Meta (FSE 2024, arXiv:2402.09171) : TestGen-LLM améliore les tests existants écrits par des humains, il n'écrit pas de suite à partir de zéro. Sur Reels et Stories (Instagram), 75% des tests générés se construisent, 57% passent de manière stable, 25% augmentent le coverage. Lors des test-a-thons d'Instagram et Facebook, l'outil a amélioré 11,5% des classes sur lesquelles il a été exécuté. 73% des recommandations ont été acceptées par les ingénieurs de Meta pour la production. Le filtre (compilation, absence de flakiness, delta de coverage) est là pour éviter que l'hallucination n'atteigne le main. Les auteurs appellent cela Assured Offline LLMSE : l'output du modèle est un candidat, pas du code.
- Le coverage augmente lorsque le LLM reçoit une lacune, pas un fichier entier. Pizzorno et Berger, CoverUp: Effective High Coverage Test Generation for Python (arXiv:2403.16218) : boucle coverage → prompt sur le fragment non couvert → test → mesure. Médiane line+branch 80% versus 47% chez CodaMosa ; versus MuTAP 89% à 77% au total. Ce n'est pas de la magie GPT. C'est le feedback de l'instrumentation en boucle, de manière analogue au PSI en continuous training.
- Un ChatGPT pur corrompt les assertions. Yuan et al., No More Manual Tests? Evaluating and Improving ChatGPT for Unit Test Generation (arXiv:2305.04207) : les tests de ChatGPT échouent à la compilation et sur de mauvaises assertions. ChatTester (générateur + refiner itératif) donne 34,3% de tests compilables en plus et 18,7% de plus avec une assertion correcte. Même le « self-repair » du modèle ne retire pas l'oracle à l'humain : le refiner améliore la syntaxe et l'assert, pas la spécification métier.
- Un modèle plus récent ne remplace pas la quality gate. Konstantinou, Degiovanni et Papadakis (arXiv:2601.09695, 2026) répliquent HITS, SymPrompt, TestSpark et CoverUp sur des LLM plus récents : un prompt naïf est parfois meilleur sur le coverage de lignes (+17,7%), de branches (+19,8%) et le mutation score (+20,9%) que les pipelines plus anciens. La conclusion opérationnelle est l'inverse du slide « achetez Copilot » : un modèle plus puissant augmente le volume de candidats. Un volume sans filtre, c'est plus de tests verts à réviser. La révision est le goulot d'étranglement, pas le token.
Conclusion architecturale clé
L'automatisation des tests avec l'IA commence par la quality gate, pas par la licence. Le générateur écrit un candidat. Le CI vérifie : compilation, absence de flakiness, delta de coverage ou mutation score, absence de clone d'oracle du SUT. SAST séparément : un CWE critique bloque le merge. L'humain (SDET) accepte ce que le filtre ne peut pas faire : si l'assertion décrit le contrat ou le bug du jour. Si l'une des étapes est « copier-coller de Copilot et merge », vous n'avez pas de qualité de code. Vous avez de la vitesse.
3. Étude de cas en production : coverage 71%, bug FX en production
Retour d'expérience en ingénierie : de Copilot au mutation score
API de paiement, Java 17 + Spring Boot, E2E avec Playwright, SAST : SonarQube dans GitLab CI. L'équipe a travaillé comme suit :
- unit : développeur + Copilot, JUnit 5, coverage gate 60% de lignes,
- E2E : QA, chemins happy-path enregistrés, job marqué comme optionnel,
- SAST : quality gate désactivé sur la branche de hotfix « pour gagner du temps »,
- métrique de sprint : % de couverture. Pas de change fail rate. Pas le nombre de mutants tués.
Problème : dans le sprint, le coverage du module de facturation est passé de 44% à 71%. Deux semaines plus tard, en production, l'arrondi FX (quelques centimes lors de la conversion de devises) a sous-estimé le montant. Les tests appelaient FxRounding.round(amount) — le même helper que la production — et comparaient avec le résultat du helper. Le bug était dans le helper. La suite de tests le validait. Sonar signalait une logique dupliquée depuis quatre mois. Ticket : won’t fix.
Changement : une passerelle comme chez Meta, mais sur un stack Spring. Un nouveau test avec LLM est intégré lorsque : (1) il compile, (2) il passe trois fois de suite, (3) PIT montre un delta positif de mutation score sur la classe, (4) l'assertion n'appelle pas le SUT comme oracle — l'expected est une constante, une table de cas ou un oracle séparé dans les testdata, (5) le SDET révise la PR. SAST : un CWE dans le package payments bloque le merge, il n'ouvre pas de Slack.
Mesure : le coverage a baissé sur le papier (les tests tautologiques ont été supprimés). Le mutation score sur le billing a augmenté. Le hotfix FX suivant a été détecté en CI, pas chez le client. Temps de révision des PR avec tests : des minutes, pas « nous acceptons parce que c'est vert ». Ce n'est pas Copilot Enterprise. C'est le propriétaire de l'oracle.
Les chiffres du papier de Meta ne se transposent pas 1:1 à votre facturation. C'est la mécanique qui se transpose : 75% « se construit » n'est pas encore de la qualité. 25% avec un delta de couverture et 73% d'acceptation, c'est déjà un processus qui peut être audité devant un comité de risque — de manière analogue à la passerelle PSI dans les services MLOps.
4. Tableau décisionnel : quel test, quelle composition
| Approche | Complexité | Signal qualité | Coût CI / jetons | Surcharge pour l'équipe | Quand appliquer |
|---|---|---|---|---|---|
| Manuel / exploration | Faible | Élevé sur l'UX et les cas limites, nul sur la régression | Faible | Élevé à chaque release | Nouvelle surface, absence de contrat API, PoC |
| E2E enregistré (Selenium IDE, codegen) | Faible | Happy-path ; instable avec CSS | Moyen (minutes par job) | Moyen (réparation des sélecteurs) | Démo, pas une pyramide ; pas comme seule passerelle |
| SDET + pyramide (unit, API, wąskie Playwright) | Moyenne | Régression, contrat, p95 du job | Moyen | Moyen, diminue lorsque la suite est stable | Produit avec CI, équipe stable, SLA sur la release |
| LLM dump (Copilot → commit, gate = coverage) | Faible | Faux : les lignes augmentent, les mutants vivent | Faible–moyen (jetons) | Caché (dette de revue et de prod) | Jamais comme passerelle de merge. Exercice, pas un processus |
| Assured LLMSE (filtr Meta: build, pass, delta, akcept) | Élevée | Delta de coverage / mutation score + revue | Moyen–élevé (boucle + jetons) | Élevé au démarrage, diminue lorsque le filtre est stable | Grand monolithe, suite existante, SDET sur la passerelle |
| SAST avec SLO (CWE w critical path blokuje) | Moyenne | Modèle dans le code, pas le comportement | Faible–moyen | Triage ; sans propriétaire = zéro | Paiements, IAM, données personnelles ; à côté des tests, pas à la place |
L'automatisation QA / SDET n'est pas un « développeur moins cher » et n'est pas un pentest. Fourchette 2026 : spécialiste 110–160 PLN/h, client 160–240 PLN/h, 26–38 mille B2B. Le testeur manuel se situe nettement plus bas. Le pentest et le GRC se trouvent sur une autre landing. Marge 10–25%. Carte, pas un barème de prix — détails dans les tarifs 2026.
5. Antipatterns qui ne figurent pas dans le tutoriel Copilot
- Coverage comme KPI du générateur. L'équipe célèbre 71% de lignes. PIT laisserait 40% de mutants vivants. Meta publie 25% des classes avec une delta de couverture non pas parce que le modèle est faible. Mais parce que le filtre rejette le reste. Votre dashboard sans ce filtre est trompeur.
- Expected calculé avec le même code que la production. Un classique dans la facturation, les impôts, le FX, l'allocation de remises. Le test « documente » un bug. L'oracle est un tableau de cas, une constante de la comptabilité ou un oracle séparé et révisé. Pas
service.calc(x)versusservice.calc(x). - SAST en mode informatif pour toujours. 180 findings, zéro owner, quality gate désactivé pour un hotfix. Les LLM de tests ne remplaceront pas le SAST : ils ne liront pas le CWE-89 dans la string concatenation si l'assertion vérifie HTTP 200. Inversement : le SAST ne détectera pas une erreur d'arrondi d'un centime. Deux alertes. Deux propriétaires ou un SDET avec un DoD pour les deux.
- Brief « QA avec IA » pour le rôle de SDET. Vous obtiendrez quelqu'un qui clique et colle. Vous n'obtiendrez pas une personne qui rejettera 75% de l'output du modèle. Le marché a éclaté de la même manière qu'avec MLOps : le testeur classique a de l'offre, le SDET avec oracle et CI non. Une annonce avec une mauvaise étiquette recueille des CV en 48 h et zéro compétence en mutation score.
- Fausse équipe qualité. Un manuel du vendor A, « quelqu'un de Cypress » de B, SAST « à 10% de la sécurité ». Trois onboardings, zéro Definition of Done commun pour le merge. Nous avons détaillé l'anatomie de cette erreur dans team leasing vs body leasing 2026. Ce n'est pas du staff augmentation. C'est une taxe d'intégration.
6. Playbook: qui recruter et dans quel ordre
Ne commencez pas par la licence Copilot Enterprise. Commencez par vous demander quelle boucle bloque le release : unit, E2E, SAST ou l'absence de propriétaire de l'oracle.
- Une lacune dans la pyramide existante. Vous avez JUnit/pytest, Playwright sur le chemin critique, CI, quelqu'un qui révise les PR. Il manque un propriétaire pour le filtre LLM et le triage SAST. C'est un body leasing classique de testeurs et de SDET : une seule personne, votre stand-up, votre DoD. Premiers profils en quelques jours, pas en un trimestre — nous sourçons à la demande, nous ne vendons pas de banc nominatif pour demain matin.
- Le seul test est un clic. Il n'y a pas de test unitaire, pas de contrat API, Sonar est à l'arrêt depuis six mois. Une seule personne ne pourra pas tout assembler. Composition 3–5 : SDET (pyramide, CI), QA exploratoire (ce que le générateur n'inventera pas), DevOps si les jobs n'existent pas. C'est plus proche du team leasing que d'« acheter Copilot et un junior ».
- Les données de test ne sortent pas du VPC. Fixtures de paiement, PESEL, NDA. Le contractant dans votre IAM, votre environnement, un contrat T&M avec NDA, délégation et IP côté client. Un dump de production sur Colab « pour que Copilot devine mieux les tests » est une fuite. Un prompt avec du code sous NDA vers un modèle cloud public — également.
- Ramp-up. Personne pour une équipe existante : premiers CV en 24–48 h, démarrage après vos entretiens et contrat. Squad à partir de zéro : des semaines, pas un sprint, car vous assemblez les autorisations, les données de test et le DoD pour le merge. Le mensonge « trois SDET seniors dès lundi » est un CV ou un banc que nous n'avons pas — et nous ne ferons pas semblant.
Depuis 2012, Commoditech propose du T&M et du recrutement permanent depuis Varsovie. Plus de 80 spécialistes dans notre réseau, pas de banc inactif. Un brief T&M ou un success fee peut être soumis depuis l'IDE via MCP pour les agents AI, pas seulement via le formulaire. Les montants pour un stack spécifique sont calculés par une personne ; les fourchettes de prix se trouvent dans l'article sur les tarifs, pas dans le JSON de l'agent.
FAQ
Les LLM remplaceront-ils l'automatisation des tests et les testeurs QA ?
Non. Un LLM est un générateur de candidats. Meta TestGen-LLM : 75% des tests se compilent, 57% passent de manière stable, 25% augmentent la coverage. 73% des recommandations sont passées en production, car le filtre (compilation, pass, delta de coverage) et la revue de l'ingénieur ont éliminé le reste. Sans quality gate, vous achetez des assertions vertes sur le comportement actuel, y compris sur les bugs. ChatTester montre que même l'auto-réparation du modèle corrige la syntaxe, pas la spécification.
Quand louer un seul SDET, et quand une équipe QA ?
Une seule personne, si la pyramide est en place (unit + API + E2E étroits en CI), et qu'il manque un propriétaire de quality gate : mutation score, triage SAST, revue des tests de Copilot. Une équipe de 3 à 5 personnes (SDET + QA exploratoire + quelqu'un pour le CI), si le seul test est un clic en staging, et que Sonar a 200 findings en « won’t fix » depuis six mois. Un SDET seul ne rédigera pas l'oracle métier pour le product owner. Un testeur manuel seul ne maintiendra pas un job dans GitLab. Si vous n'avez personne pour réviser la PR d'un contractant, n'achetez pas de body leasing. Achetez un lead plus un rôle ou un squad.
Combien coûte le body leasing SDET / QA automation en Pologne en 2026 ?
QA automation / SDET : spécialiste 110–160 PLN/h, client 160–240 PLN/h, 26–38 mille B2B. Un testeur manuel est nettement moins cher ; un SDET non. Le Pentest et NIS2 sont des tarifs et des landings différents. Marge du fournisseur 10–25% — si quelqu'un promet 8% pour un remplacement en 5 jours, ajoutez-le sur une autre ligne. C'est une carte du marché, pas une offre. Le montant pour un brief est calculé par une personne. Détails dans les tarifs 2026.
En quoi le SAST diffère-t-il des tests générés par LLM ?
Le SAST lit le code sans l'exécuter et recherche des modèles (SQLi, XSS, secrets, CWE). Un LLM écrit un test qui doit échouer en cas de mauvais comportement. Un SAST sans propriétaire est un dashboard de false positive. Un LLM sans filtre est une coverage vanity. Les deux nécessitent un SLO : un CWE critique ne peut pas rester en « informational », un test de Copilot ne peut pas être intégré sans une delta de mutation score. Ce ne sont pas des substituts. Ce sont deux jobs dans un même DoD pour le merge.
Sources
- Alshahwan, N., Chheda, J., Finogenova, A., Gokkaya, B., Harman, M., Harper, I., Marginean, A., Sengupta, S., Wang, E. (2024). Automated Unit Test Improvement using Large Language Models at Meta. FSE 2024. arXiv:2402.09171. arxiv.org/abs/2402.09171
- Pizzorno, J. A., Berger, E. D. (2024). CoverUp: Effective High Coverage Test Generation for Python. arXiv:2403.16218. arxiv.org/abs/2403.16218
- Yuan, Z., Lou, Y., Liu, M., Ding, S., Wang, K., Chen, Y., Peng, X. (2023/2024). No More Manual Tests? Evaluating and Improving ChatGPT for Unit Test Generation. arXiv:2305.04207. arxiv.org/abs/2305.04207
- Konstantinou, M., Degiovanni, R., Papadakis, M. (2026). How well LLM-based test generation techniques perform with newer LLM versions? arXiv:2601.09695. arxiv.org/abs/2601.09695
- DORA / Google Cloud (2024). Accelerate State of DevOps Report.
- Commoditech — tarifs body leasing 2026, team leasing vs body leasing, location de testeurs et SDET.