QA & Testing, valider l’IA, de l’application au modèle

Nous raisonnons en pyramide de tests : beaucoup d'unitaires rapides, une couche intermédiaire de tests d'intégration et de contrats, et un sommet réduit de tests end-to-end, coûteux et fragiles, donc à doser. L'erreur classique est la pyramide inversée (tout en E2E UI), qui produit des suites lentes et instables. Les tests d'interface sont conçus avec des patterns maintenables (Page Object, Screenplay) pour résister aux évolutions du front, et exécutés en parallèle et cross-browser (BrowserStack, SauceLabs) pour tenir le temps de cycle.

La fiabilité passe par une guerre déclarée aux tests *flaky* : un test intermittent détruit la confiance dans toute la suite et finit ignoré. Nous les détectons, les quarantenons et traitons leur cause (attentes implicites, dépendances d'ordre, données partagées) plutôt que de les relancer en boucle. La gestion des données de test (jeux maîtrisés, isolés, réinitialisables) et la virtualisation de services (WireMock, Mountebank, Hoverfly) rendent les tests indépendants des systèmes tiers et donc reproductibles.

Le contract testing (Pact) sécurise les architectures distribuées : producteurs et consommateurs valident leur contrat indépendamment, sans avoir à monter tout le système. Côté API, des outils comme REST Assured, Karate ou Postman/Newman couvrent fonctionnel et schéma. La qualité de code (SonarQube) et l'accessibilité (WCAG/RGAA, axe) entrent dans les portes. Toute cette suite est intégrée à la CI/CD comme des gates bloquants : on ne promeut pas un build qui casse la qualité, et des smoke tests post-release valident la prod réelle.

Le socle est un harnais d'évaluation et des golden sets, des jeux de référence représentatifs, avec vérité terrain, couvrant les cas nominaux, les cas limites et les cas adverses. Sans golden set, aucune affirmation de qualité n'est défendable. Sur ces jeux, nous mesurons des métriques adaptées à la tâche, en connaissant leurs limites : l'exact match et les métriques lexicales (BLEU, ROUGE) ne capturent pas la sémantique d'une réponse générative ; nous leur préférons, pour le génératif, l'évaluation de la fidélité aux sources (faithfulness/groundedness), de la pertinence de la réponse et de la complétude, souvent via du *LLM-as-judge*, calibré et audité contre du jugement humain, car un juge LLM non vérifié introduit ses propres biais.

L'hallucination devient une grandeur mesurée (taux sur golden set, détection de non-ancrage), avec un budget explicite par cas d'usage plutôt qu'une promesse de zéro. Les biais et l'équité sont testés sur des sous-populations ; la robustesse, par des perturbations et des entrées adverses. Pour le RAG, nous découplons l'évaluation de la récupération (recall@k, précision) de celle de la génération : un mauvais score global doit pouvoir être imputé à la bonne couche.

Le point critique en production est la non-régression sur changement de modèle ou de prompt : une mise à jour de fournisseur peut dégrader silencieusement un cas d'usage. Nous intégrons l'éval à la CI/CD comme une porte (la porte de qualité du modèle opérationnel, conjointe avec la Cyber) et surveillons le drift de qualité en continu, avec dashboards et alertes. L'humain reste dans la boucle pour les cas sensibles et l'arbitrage des seuils.

Tout part d'un modèle de charge fondé sur le trafic réel : profils d'utilisateurs, mix de transactions, montée en charge, pics. Nous distinguons les types d'essais selon la question posée, test de charge (comportement à la charge attendue), de stress (point de rupture), d'endurance/soak (fuites et dégradation dans la durée), et de pic (élasticité). Un test qui n'imite pas la réalité produit des chiffres rassurants et faux.

La mesure se fait sur les percentiles, pas sur la moyenne : c'est le p95/p99 de latence qui décrit l'expérience réelle, la moyenne masquant les queues qui font fuir les utilisateurs. Nous appliquons les lois de base de la théorie des files (relation débit-concurrence-latence, loi de Little) pour interpréter les résultats au lieu de les constater. L'analyse de goulet corrèle les métriques de charge avec l'APM et l'observabilité (CPU, mémoire, I/O, pools de connexions, GC, requêtes lentes) pour passer du symptôme (« c'est lent ») à la cause (« saturation du pool de connexions à N utilisateurs concurrents »).

Cette boucle alimente le capacity planning : dimensionnement, seuils d'autoscaling, et SLI/SLO de performance reliés à des budgets d'erreur. Les essais sont scénarisés *as code* et intégrés à la CI/CD pour détecter les régressions de performance avant la prod, et non en incident. Côté front, nous suivons les Core Web Vitals et l'Apdex pour la dimension expérience.