Harness ? Mr Suricate vous explique.
Un million de nouvelles applications par semaine. C’est le rythme que revendique Lovable, la plateforme suédoise de génération d’apps par IA, dont le CTO Fabian Hedin détaillait la stratégie au JDN le 16 juillet. Un chiffre qu’il avance illustre l’ampleur du phénomène :
« Les projets construits avec Lovable cumulent 720 millions de visites mensuelles, soit 27 fois plus de trafic que le site de Lovable lui-même. »
La majorité de ces apps sont créées par des non-développeurs, et beaucoup partent en production sans la moindre QA structurée.
Au même moment, Veracode a fait passer 80 tâches de développement à plus de 100 modèles d’IA : 45 % du code généré contient au moins une vulnérabilité. Sur Java, le taux d’échec monte à 72 %. Par ailleurs, selon GitClear, un développeur moyen a commité 75 % de code en plus en 2025 qu’en 2022.
Ces deux courbes racontent la même histoire. Le code ne coûte plus rien à produire. La preuve qu’il fonctionne, si. Et cette preuve a désormais un nom : le harness.
Alors, d’où vient le mot Harness ?
Le harness en une phrase : la couche logicielle qui entoure un système ou un modèle d’IA pour l’exécuter, l’observer et vérifier ses résultats de façon fiable, de l’orchestration des appels au contrôle des sorties jusqu’à la production de preuves.
En ingénierie, un test harness est un banc d’essai : le dispositif qui entoure un système pour l’exécuter, l’observer et vérifier ses résultats dans des conditions contrôlées. Le terme était confidentiel, réservé aux équipes d’automatisation. Il est en train de devenir central.
À l’ère des agents IA, le harness désigne toute la couche construite autour des modèles pour rendre leurs résultats fiables : ce qui prépare le contexte, orchestre les appels, contrôle les sorties, corrige les erreurs. Désormais on parle de harness engineering, la discipline où vérification automatisée, évaluation et contrôles de déploiement deviennent le système d’exploitation qui gouverne le code produit par IA. La thèse tient en une formule : le goulot d’étranglement s’est déplacé après le code. Les levées de fonds récentes sur ce créneau de l’après-code, en centaines de millions de dollars, confirment que les investisseurs y croient.
QA Financial enfonce le clou côté secteur financier : la QA entre dans l’âge de l’evidence engineering. En effet, les équipes ne doivent plus seulement prouver qu’elles ont testé. Elles doivent montrer quoi, pourquoi, avec quels contrôles, et si ces contrôles tiennent dans le temps. Régulateurs et auditeurs ne se contentent plus d’un rapport d’exécution.
Fabian Hedin, chez Lovable, le confirme depuis l’autre rive. Quand le JDN lui demande directement quelle part de la qualité de sa plateforme vient des modèles et quelle part vient du harness, de la couche d’orchestration et des appels d’outils, sa réponse est nette :
« Il est très difficile d’arriver au résultat produit par Lovable en utilisant simplement un modèle brut. Cela illustre la valeur que nous ajoutons par-dessus ces modèles de fondation. »
Ceux qui créent le code et ceux qui le vérifient arrivent à la même conclusion.
Pourquoi un modèle brut ne sait pas tester
Un modèle de langage produit du plausible. Un test exige du fiable. La différence se paie tous les jours dans les suites de régression UI.
Le point de douleur numéro un du marché reste la fragilité des sélecteurs. En effet, les études convergent vers 30 à 50 % du temps QA absorbé par la maintenance des tests. Et les équipes constatent que 10 à 15 % de leurs tests end-to-end cassent après un déploiement front significatif. Chaque refonte cosmétique déclenche sa vague de faux positifs, et chaque faux positif érode la confiance dans l’automatisation.
Le marché a tranché sur la direction : l’identification des éléments d’interface en langage naturel, à la place des captures d’écran et des sélecteurs classiques. Le test cible “l’onglet détails en bas de l’écran” et survit aux refontes, aux changements de thème et de résolution. Même les éditeurs historiques du test s’y mettent, preuve que le sujet est devenu incontournable.
Cependant l’identification en langage naturel ne règle qu’une partie du problème. Reste à savoir quoi tester, comment distinguer une vraie régression d’un changement voulu, comment exécuter en production sans polluer les données, comment variabiliser des parcours sur des dizaines d’environnements. C’est tout cela, le harness.
Le harness appliqué à la QA, concrètement
Chez Mr Suricate, le harness recouvre tout ce qui rend un test digne de confiance et qu’aucun modèle brut ne sait faire : identification robuste des éléments, self-healing quand l’application évolue, anti-faux-positif, variabilisation, exécution en production et pas seulement en staging, et la connaissance accumulée des parcours réels de Boulanger, Fnac Darty ou Intersport. Des années de frottement avec de vraies applications, condensées dans une couche logicielle. Chez B&B HOTELS, plusieurs centaines de scénarios s’exécutent en continu pour garantir la qualité des parcours de réservation, avec des product owners autonomes dans la lecture des résultats.
L’enjeu financier est connu de toutes les directions IT : un bug découvert en production coûte 30 à 100 fois plus cher qu’un bug détecté en développement. Et une automatisation correctement harnachée rend 60 à 80 % du temps passé sur les régressions manuelles. Le harness transforme ces deux chiffres, l’un en risque évité, l’autre en capacité récupérée.
C’est là que se joue la défendabilité. N’importe quel concurrent peut appeler les mêmes modèles que nous. Il ne peut pas répliquer cette couche, parce qu’elle ne s’entraîne pas sur du texte : elle se construit sur des millions d’exécutions de tests face à des applications qui changent.
Le générateur ne peut pas être juge et partie
Une objection revient : si l’agent écrit le code, il écrira aussi les tests. C’est déjà vrai, et c’est insuffisant. Un générateur qui vérifie sa propre production reproduit ses propres angles morts. Chez Veracode, le CTO Jens Wessling pointe la cause profonde :
« La montée du vibe coding, où les développeurs s’appuient sur l’IA pour générer du code sans définir explicitement d’exigences de sécurité, représente un changement fondamental dans la manière dont le logiciel est construit » (traduction).
Le code généré passe les tests que le générateur imagine, pas ceux que la réalité impose.
Sur ce point, notre position est claire. Le test indépendant, boîte noire, sur parcours réels et en production, reste un besoin distinct de la génération. Plus le volume de code généré explose, plus cette preuve indépendante devient le goulot d’étranglement de la chaîne logicielle. C’est une bonne nouvelle pour ceux dont c’est le métier depuis le premier jour.
La suite
Mr Suricate continue d’investir dans cette direction. Nos prochains chantiers : exposer notre harness aux agents IA pour qu’ils puissent lancer des scénarios de test et consommer les résultats comme un service, et rendre la plateforme proactive, capable de détecter un changement chez le client et de proposer la mise à jour des scénarios avant qu’on le lui demande.
Le sujet n’est pas clos, il commence. Et si vous voulez voir ce qu’un harness fait sur vos propres parcours, une démo suffit.
Questions fréquentes
C’est la couche logicielle qui entoure une application ou un modèle d’IA pour exécuter des tests, observer les résultats et en garantir la fiabilité. Elle regroupe l’identification des éléments, le self-healing, la détection des faux positifs et la production de preuves exploitables.
Un framework comme Selenium, Playwright ou Appium fournit le moteur d’exécution. Le harness est tout ce qui se construit autour pour rendre les résultats fiables dans la durée : robustesse face aux changements d’interface, distinction entre vraie régression et évolution voulue, exécution en production. Mr Suricate s’appuie sur ces trois moteurs et met sa valeur dans le harness.
Parce qu’un générateur qui vérifie sa propre production reproduit ses propres angles morts. Les tests de Veracode sur plus de 100 modèles le montrent : 45 % du code généré contient une vulnérabilité que le générateur n’a pas vue. La preuve doit venir d’une couche indépendante de la création.
