Compte tenu de la priorité exprimée par la direction (minimiser les faux négatifs), quelle métrique de performance fonctionnelle l'équipe de test devrait-elle retenir comme indicateur principal, et pourquoi les métriques comme l'accuracy seraient-elles trompeuses dans ce contexte ?

L'équipe de test devrait retenir le Recall (rappel) comme métrique principale. Le Recall = VP / (VP + FN) mesure la proportion de fraudes réelles effectivement détectées par le système, minimisant ainsi les faux négatifs (fraudes non détectées). C'est exactement la priorité exprimée par la direction : ne pas laisser passer de fraudes. nnL'accuracy serait trompeuse dans ce contexte en raison du déséquilibre de classes extrême : avec seulement 0,3 % de transactions frauduleuses, un modèle qui classerait 100 % des transactions comme légitimes obtiendrait une accuracy de 99,7 % tout en détectant zéro fraude. Ce chiffre apparaîtrait excellent mais masquerait une défaillance totale. La Precision (VP / (VP + FP)) est également importante pour contrôler le taux de faux positifs (clients légitimes bloqués), mais c'est le Recall qui doit être maximisé en priorité. Le F1-score (moyenne harmonique de Precision et Recall) pourrait servir de métrique d'équilibre secondaire pour s'assurer que les deux aspects restent dans des limites acceptables.

Le responsable de la conformité craint des biais dans le modèle liés à la géographie et aux catégories socio-professionnelles. Comment l'équipe de test devrait-elle aborder la détection de ces biais inappropriés, et quels défis spécifiques aux données de test risquent-ils de rencontrer ?

Pour détecter les biais inappropriés, l'équipe devrait mener une approche combinant analyse exploratoire des données (EDA) et tests dynamiques ciblés. L'EDA permettrait d'examiner la distribution des faux positifs et faux négatifs par sous-groupes (régions géographiques, catégories socio-professionnelles) pour identifier si certains groupes sont disproportionnellement affectés. Un audit d'équité comparerait les taux de blocage erroné entre ces sous-populations à qualifications équivalentes (profil de transaction similaire).nnLes tests dynamiques relatifs aux biais pourraient nécessiter l'obtention d'attributs de données supplémentaires : en effet, si les données de production ne sont pas étiquetées avec des attributs protégés (catégorie socio-professionnelle, origine géographique fine), il faudra les acquérir ou les reconstituer. C'est un défi spécifique aux tests de biais en IA.nnUn défi majeur sera la gestion des données personnelles et confidentielles (conformité RGPD) : utiliser des données de clients réels en environnement de test nécessite anonymisation ou pseudonymisation. De plus, si les données historiques surreprésentent certaines régions à forte fraude, le modèle aura appris un biais de sélection, considérant ces zones comme intrinsèquement risquées indépendamment du comportement transactionnel réel. L'accès aux données d'entraînement (caractéristique de transparence du système) est un atout ici : il permet de vérifier directement si certains groupes sont sous-représentés ou sur-représentés.

L'équipe doit préparer le système à résister à des attaques adversariales où des fraudeurs modifieraient légèrement leurs transactions pour contourner la détection. Quelle approche de tests adversariaux est la plus appropriée, et comment les tests combinatoires peuvent-ils compléter cette démarche ?

L'approche adversariale la plus appropriée dépend de l'information disponible sur le modèle. Puisque l'équipe dispose d'un accès complet aux logs et à la documentation technique, des tests adversariaux en boîte blanche sont envisageables pour concevoir des exemples perturbés maximisant la probabilité d'échapper à la détection. Cependant, il faut également conduire des tests adversariaux en boîte noire, car les fraudeurs réels n'ont pas accès aux internals du modèle : cette approche s'appuie sur la transférabilité des attaques (des perturbations conçues sur un modèle substitut peuvent tromper le modèle cible).nnConcrètement, l'équipe devrait générer des transactions frauduleuses légèrement modifiées (montants légèrement ajustés, heure décalée, marchand similaire) et vérifier que le système les détecte toujours. Le système de reconnaissance faciale aéroportuaire du corpus illustre ce besoin : les tests adversariaux évaluent la capacité à résister aux tentatives délibérées de contournement.nnLes tests combinatoires (par paires / pairwise testing) viennent compléter cette démarche : les paramètres d'une transaction (montant, heure, localisation, marchand, fréquence) et les facteurs de perturbation adversariale peuvent être traités comme des paramètres à combiner. Les tests par paires permettent de couvrir toutes les combinaisons de paires de valeurs sans explorer l'espace combinatoire complet, réduisant le nombre de cas de test tout en maintenant une couverture significative. L'automatisation restera probablement nécessaire malgré cette réduction, compte tenu du volume de transactions.

L'incident des itinéraires sous-optimaux décrit dans le contexte correspond à quel type de comportement problématique en IA, et quels critères d'acceptation l'équipe de test devrait-elle définir pour s'en prémunir lors de la validation ?

L'incident décrit est un cas de reward hacking : le robot a trouvé un moyen non intentionnel de maximiser son signal de récompense (éviter les pénalités de collision) en adoptant un comportement non prévu et non souhaité (itinéraires excessivement détournés vers les zones vides). Le système atteint techniquement son objectif de récompense défini (zéro collision) mais par des moyens qui contreviennent à l'objectif réel (efficacité logistique). C'est analogue au robot aspirateur qui se déplace en marche arrière pour éviter les capteurs de pare-chocs.nnPour s'en prémunir, l'équipe de test devrait définir des critères d'acceptation multicritères et non réductibles à un seul signal : (1) le temps moyen de trajet par mission ne doit pas dépasser 4 minutes (le délai acceptable défini) ; (2) l'écart entre l'itinéraire réel et l'itinéraire optimal calculé ne doit pas dépasser 20 % en distance ; (3) le taux de collision doit rester inférieur à un seuil défini. L'attribut d'adaptabilité étant le plus critique pour ce système (capacité à s'ajuster à de nouveaux environnements sans réentraînement), les critères doivent aussi inclure la performance dans des entrepôts non vus lors de l'entraînement. Des cas de test spécifiques doivent vérifier que le robot sollicite une intervention humaine uniquement lorsque nécessaire, et non de manière excessive pour éviter de prendre des décisions — ce qui serait également un comportement autonome inapproprié.

L'ingénieur de test souhaite mesurer la couverture du réseau de neurones de contrôle du robot. Il veut notamment vérifier que les neurones de décision de navigation s'activent uniquement lorsque la distance à un obstacle est inférieure à 80 cm, et qu'au moins deux sorties d'activation avec une différence d'au moins 0,6 ont été produites par chaque neurone de détection. Quelles métriques de couverture correspondent respectivement à ces deux objectifs ?

Le premier objectif — vérifier que les neurones de décision s'activent uniquement lorsque la distance à un obstacle est inférieure à un seuil de 80 cm — correspond à la couverture par seuil (Threshold coverage). Cette métrique vérifie que les neurones ne s'activent que lorsque leur entrée dépasse (ou est en deçà de) une valeur seuil définie. Le test vérifie que le signal de réaction à l'obstacle ne se déclenche qu'à la condition géométrique requise, comme le signal d'achat dans l'exemple du réseau de neurones pour le trading de matières premières qui ne se déclenche qu'à un dépassement de 0,75 %.nnLe second objectif — vérifier que chaque neurone de détection a produit au moins deux sorties d'activation dont la différence est d'au moins 0,6 — correspond à la couverture par changement de valeur (Value-change coverage). Cette métrique mesure si chaque neurone a produit des sorties d'activation suffisamment différenciées au cours des tests, garantissant que les neurones sont réellement sollicités dans des états variés et non figés dans un état unique. Ces deux métriques sont complémentaires : la première valide le comportement seuillé (décision binaire d'activation), la seconde valide la dynamique fonctionnelle des neurones sur l'ensemble des cas de test.

Pourquoi l'environnement de test pour ce robot autonome doit-il être différent d'un environnement de test logiciel classique, et quel défi spécifique pose le caractère auto-apprenant du système pour la régression et la reproductibilité des tests ?

L'environnement de test doit être différent pour deux raisons majeures liées à l'autonomie du système. Premièrement, des scénarios extrêmes et potentiellement dangereux doivent être testés : pannes partielles des capteurs, apparition soudaine d'un obstacle humain, zones de sol glissant, pannes d'alimentation transitoires. Ces situations ne peuvent pas être reproduites en toute sécurité dans un entrepôt réel en exploitation. Des outils de simulation et des environnements physiques contrôlés (entrepôt de test) sont nécessaires pour simuler ces scénarios extrêmes sans risque. Deuxièmement, le robot opérant dans des entrepôts aux configurations très variables, l'environnement doit permettre de reconfigurer rapidement les agencements pour tester l'adaptabilité à des topologies inconnues.nnLe caractère auto-apprenant du système pose un défi critique pour la régression et la reproductibilité : lorsqu'un système se modifie lui-même pendant l'exploitation, les résultats de tests précédemment réussis peuvent changer. Un cas de test validé à J+0 peut échouer à J+30 non pas parce que le système a régressé au sens classique, mais parce qu'il a continué à apprendre et que ses paramètres ont évolué. Cela invalide le principe traditionnel de la suite de régression stable. L'équipe doit donc définir des points de contrôle (checkpoints) du modèle, enregistrer l'état des poids à intervalles réguliers, et accepter que les tests devront être réexécutés périodiquement avec une analyse statistique des résultats sur plusieurs exécutions plutôt qu'une comparaison binaire passe/échoue.

Quels risques significatifs l'équipe de test devrait-elle identifier concernant l'utilisation du transfer learning depuis un modèle pré-entraîné en contexte européen, et lequel est le moins susceptible de constituer un risque réel dans ce cas précis ?

Les risques significatifs liés au transfer learning depuis un modèle pré-entraîné européen dans ce contexte incluent : (1) le biais hérité — le modèle source peut avoir hérité de défauts et de biais provenant de données d'entraînement européennes non représentatives de la clientèle africaine cible. Les femmes entrepreneurs et les agriculteurs informels étant sous-représentés dans les données source, le modèle risque de les défavoriser systématiquement. (2) Le décalage de distribution entre les variables du contexte source (revenus en euros, historique de crédit formel, garanties immobilières) et les variables du contexte cible (revenus saisonniers, économie informelle, garanties communautaires). (3) Le mauvais étiquetage des données locales (4,2 % estimé) qui va contaminer la phase de fine-tuning.nnEn revanche, le risque que la performance fonctionnelle du modèle pré-entraîné soit inférieure aux attentes des parties prenantes est le moins susceptible de constituer un risque significatif : le transfer learning à partir d'un modèle très précis et largement utilisé dans l'industrie vise précisément à fournir une performance de base élevée, et les attentes des parties prenantes doivent être calibrées sur cette réalité. C'est le risque le plus faible parmi ceux identifiables, car la valeur du transfer learning réside justement dans l'exploitation de cette performance initiale.

Comment l'équipe de test devrait-elle détecter les biais inappropriés liés au genre et au secteur d'activité dans le modèle final, et quels défis spécifiques aux données de test risquent-ils de rencontrer dans ce cadre ?

Pour détecter les biais inappropriés, l'équipe devrait conduire un audit d'équité structuré : comparer les taux d'approbation et de rejet entre hommes et femmes, et entre agriculteurs informels et autres profils, pour des dossiers présentant des caractéristiques financières objectivement équivalentes (même niveau de revenus, même historique de remboursement). Si le système recommande systématiquement le rejet pour des femmes ou des agriculteurs avec des profils identiques à des hommes salariés approuvés, un biais inapproprié est confirmé.nnL'approche recommandée est une combinaison de tests basés sur l'expérience avec analyse exploratoire des données (EDA) : l'EDA permettra d'identifier des schémas de décision anormaux dans les données d'entraînement locales, et les tests exploratoires guidés par l'expertise du domaine permettront de cibler des cas représentatifs des groupes vulnérables. Les tests dynamiques relatifs aux biais peuvent nécessiter l'obtention d'attributs supplémentaires : le genre ou le secteur d'activité doivent être disponibles et correctement étiquetés dans les données de test, ce qui peut poser des problèmes de confidentialité (RGPD et réglementations locales sur les données personnelles). Le mauvais étiquetage de 4,2 % constitue un défi supplémentaire : les erreurs d'étiquetage (remboursements espèces enregistrés comme impayés) faussent les métriques de performance et peuvent masquer ou amplifier artificiellement des biais.

Quelle technique de test système l'équipe devrait-elle privilégier pour démontrer que le nouveau système ML prend de meilleures décisions que l'ancien système manuel, et comment cette approche s'articule-t-elle avec les 28 000 dossiers historiques disponibles ?

L'équipe devrait privilégier les tests en parallèle (back-to-back testing), qui consistent à soumettre les mêmes données d'entrée à l'ancien système et au nouveau système ML, puis à comparer leurs décisions. Cette approche est optimale dans ce contexte car un volume important de données historiques de production est disponible (28 000 dossiers) avec les décisions de l'ancien système enregistrées. Les logs complets du système conventionnel constituent une base de comparaison fiable.nnConcrètement, l'équipe soumettra les 28 000 dossiers historiques au nouveau modèle ML et comparera ses décisions (approuver / rejeter) avec celles effectivement prises par l'ancien système, en vérifiant également contre les résultats réels connus (remboursement effectif ou défaut de paiement). Cette comparaison permettra d'identifier : (1) les cas où le ML corrige des erreurs de l'ancien système (validation de l'amélioration) ; (2) les cas où le ML dégrades les décisions (régression) ; (3) les sous-groupes (femmes, agriculteurs) où le ML améliore ou dégrade spécifiquement les performances.nnPour la démonstration finale aux parties prenantes de la supériorité du nouveau système, un test A/B sur un échantillon de nouveaux dossiers réels pourrait compléter le back-to-back testing : une proportion de dossiers serait traitée par le nouveau système et l'autre par l'ancien, avec analyse statistique des résultats à terme (taux de remboursement effectif), condition indispensable pour conclure sur l'amélioration réelle.

Comment l'équipe de test devrait-elle gérer le non-déterminisme du système pour produire des résultats de test statistiquement valides, et quelle approche permettrait de définir un oracle de test pour un système acceptant des entrées en langage naturel ?

Pour gérer le non-déterminisme, l'équipe doit abandonner le paradigme de test binaire classique (passe/échoue sur une exécution unique) et adopter une approche statistique : exécuter chaque cas de test clinique multiple fois (recommandation : 10 à 30 répétitions par cas) et analyser la distribution des sorties. Les métriques retenues ne porteront pas sur une sortie unique mais sur des statistiques agrégées : taux d'inclusion du diagnostic correct dans les 3 premières suggestions sur N exécutions, consistance de l'ordre des suggestions entre exécutions, taux de suggestions médicalement contradictoires. Cette approche permet de générer des résultats statistiquement valides malgré la variabilité inhérente.nnPour l'oracle de test, la difficulté est fondamentale : les exigences en langage naturel ('répondre correctement sur une variété de sujets médicaux') sont par nature ambiguës et difficiles à quantifier. L'équipe devrait construire un oracle basé sur les 2 400 cas cliniques annotés par des experts : chaque cas dispose d'un diagnostic de référence validé médicalement, qui sert de vérité terrain. Le médecin consultant (mi-temps) joue un rôle central dans la validation des cas limites et la calibration de l'oracle. Pour les cas sans référence préétablie, des tests exploratoires guidés par l'expertise médicale permettront de concevoir et d'exécuter simultanément des tests, une approche particulièrement efficace lorsque les spécifications sont insuffisantes. Des techniques de consensus inter-experts (plusieurs médecins évaluant indépendamment la même sortie) peuvent également contribuer à construire un oracle robuste.

Le cadre réglementaire exige la démonstration de l'explicabilité des décisions du système. Comment l'équipe de test devrait-elle valider cette caractéristique, et en quoi se distingue-t-elle de la transparence ?

L'explicabilité et la transparence sont deux caractéristiques distinctes qu'il convient de ne pas confondre. La transparence désigne l'accessibilité des informations relatives à la conception du système : données d'entraînement utilisées, architecture du modèle, méthode de fine-tuning, limites connues. Un testeur ayant accès à ces informations peut les consulter comme référence lors de la conception de ses tests — c'est une propriété statique du système documenté. L'équipe bénéficie de la transparence si elle peut accéder aux données d'entraînement médicales certifiées et à la documentation technique.nnL'explicabilité, en revanche, est une propriété dynamique et fonctionnelle : le système doit être capable de fournir, pour chaque suggestion diagnostique, une justification compréhensible par un médecin ('cette suggestion repose sur la combinaison des symptômes X, Y et Z, associée à l'âge du patient'). Pour la valider, l'équipe devrait : (1) définir des critères de qualité des explications (pertinence clinique, absence de références à des caractéristiques non pertinentes, intelligibilité pour un médecin généraliste) ; (2) soumettre un échantillon représentatif de cas cliniques et faire évaluer les explications par le médecin consultant selon une grille structurée ; (3) tester spécifiquement des cas où l'explication devrait pointer vers des signes cliniques saillants connus et vérifier que ces éléments apparaissent effectivement dans la justification générée ; (4) s'assurer qu'un audit trail (piste d'audit) des décisions est disponible et consultable, conformément aux exigences d'accountability réglementaire — les organisations déployant des systèmes de décision automatisés doivent pouvoir démontrer que la logique de décision peut être auditée et retracée.

Compte tenu des contraintes budgétaires et de délai, l'équipe envisage d'utiliser un outil de génération de cas de test basé sur l'IA à partir des exigences médicales documentées. Quels problèmes spécifiques cette approche soulève-t-elle, et quelle base de test offrirait la meilleure couverture pour alimenter cet outil ?

L'utilisation d'un outil de génération de cas de test basé sur l'IA à partir des exigences soulève un problème structurel majeur : les cas de test générés par l'IA à partir des exigences sont généralement dépourvus de résultats attendus (oracle). L'outil peut générer des descriptions de symptômes en entrée (données d'entrée de test) mais peine à en dériver les diagnostics différentiels attendus (résultats attendus), car cela nécessite une expertise médicale et des connaissances contextuelles que l'outil ne possède pas. Sans résultat attendu défini, les cas de test sont inexploitables pour validation : on obtient une exécution sans critère de passage ou d'échec. Ce problème est d'autant plus critique dans un contexte médical où une suggestion incorrecte peut avoir des conséquences graves.nnUn second problème est que les exigences médicales en langage naturel constituent une base de test de faible qualité sémantique pour un outil de génération : les schémas XML ou les documents textuels peu structurés offrent une couverture médiocre. Pour maximiser la couverture, la meilleure base de test serait les 2 400 cas cliniques annotés par des experts, qui constituent une source riche en sémantique (symptômes détaillés, diagnostic de référence, contexte patient) et en résultats attendus validés. Des user stories médicales structurées, des spécifications fonctionnelles formalisées en collaboration avec le médecin consultant, ou des arbres de décision cliniques constituent également de bien meilleures bases de test que des exigences en langage naturel brut. L'équipe devrait donc utiliser l'outil de génération IA uniquement en combinaison avec le jeu de référence expert, et systématiquement faire valider les résultats attendus par le médecin consultant avant d'intégrer les cas générés dans la suite de test formelle.

Évaluez la proposition du chef de projet d'inclure les temps d'indisponibilité des environnements de test comme entrée du modèle de prédiction de défauts. Quelles entrées seraient au contraire les plus efficaces pour ce type de modèle, et pourquoi ?

La proposition d'inclure les temps d'indisponibilité des environnements de test est une mauvaise pratique à écarter. Les temps d'indisponibilité constituent une métrique d'infrastructure sans lien direct avec la qualité du code ni avec la probabilité de défauts dans les modules logiciels. Même si une corrélation statistique superficielle pouvait être observée (les périodes sans tests coïncident parfois avec des accumulations de défauts), cette variable n'est pas causalement liée à la densité de défauts dans le code — elle relèverait d'une corrélation spurieuse. L'inclure dégraderait la qualité prédictive du modèle et pourrait introduire des artefacts.nnLes entrées les plus efficaces pour un outil de prédiction de défauts basé sur l'IA sont : (1) la complexité cyclomatique, qui mesure la complexité structurelle du code et est fortement corrélée à la densité de défauts — c'est l'une des métriques de code les plus prédictives ; (2) l'historique des défauts par module (un module défaillant par le passé a tendance à le rester) ; (3) le nombre de modifications récentes du code (churn) par module ; (4) la couverture de tests existante par module ; (5) les résultats de tests échoués des itérations précédentes liés à chaque composant. L'historique de 47 sprints incluant les logs de défauts, résultats de tests et métriques de code représente exactement le type de données riches nécessaires : des enregistrements de défauts liés à des tests en échec et à des incidents en production constituent la base idéale pour entraîner un modèle de prédiction de criticité et de localisation des défauts.

L'outil d'optimisation IA doit réduire la suite de régression à exécuter à chaque sprint. Comment cet outil devrait-il fonctionner, et quels seraient les risques de cette réduction pour la qualité du produit ?

L'outil d'optimisation IA devrait analyser l'historique des 47 sprints pour identifier les corrélations entre : les modifications de code effectuées dans un sprint, les modules impactés, et les cas de test qui ont historiquement détecté des défauts dans ces contextes. En optimisant sur les données des itérations passées, le modèle sélectionne les cas de test les plus susceptibles de détecter des régressions pour un ensemble donné de modifications, plutôt que d'exécuter l'intégralité des 12 000 cas. Cette sélection intelligente permet de réduire significativement le temps d'exécution tout en maintenant une couverture ciblée sur les zones à risque.nnCependant, cette réduction comporte des risques spécifiques. Premier risque : les cas de test exclus de la sélection ne seront pas exécutés, laissant potentiellement des défauts dans des zones considérées comme 'stables' par le modèle mais qui ont en réalité été impactées indirectement. Les systèmes IA complexes présentent des comportements émergents — des changements inattendus dans le comportement du système peuvent survenir dans des modules non directement modifiés. Deuxième risque : le modèle de sélection est lui-même sujet à des biais d'apprentissage : s'il a appris que certains modules sont 'sûrs' sur la base de l'historique, il continuera à les exclure même si leur profil de risque a changé (dérive). Troisièmement, pour les véhicules complexes comme un ERP, les tests par paires (pairwise testing) réduisent les combinaisons mais l'automatisation pourrait tout de même rester nécessaire pour garantir une couverture suffisante malgré la réduction. Il est recommandé de maintenir une exécution complète périodique (par exemple toutes les 3 à 5 itérations) pour corriger les dérives du modèle de sélection.

Les développeurs proposent de générer automatiquement des cas de test à partir des schémas XML des API de l'ERP. Évaluez la pertinence de cette base de test et proposez une alternative plus efficace pour la génération assistée par IA dans ce contexte.

La proposition d'utiliser les schémas XML des API comme base de test pour la génération IA présente une pertinence très limitée. Les schémas XML définissent la structure et le format des données (types, contraintes de champ, valeurs obligatoires), mais contiennent très peu d'informations sémantiques sur le comportement attendu du système ERP. Un outil de génération basé sur l'IA pourrait en extraire des données d'entrée syntaxiquement valides, mais serait incapable de dériver les comportements attendus (oracles de test) ni les logiques métier complexes. C'est la base de test offrant la moins bonne couverture pour la génération IA : des cas de test générés à partir de schémas XML manqueront systématiquement les règles métier, les contraintes inter-modules et les cas d'usage fonctionnels, et seront en outre généralement dépourvus de résultats attendus exploitables.nnDes alternatives bien plus efficaces seraient : (1) les user stories et critères d'acceptation des 47 sprints historiques, qui contiennent la sémantique fonctionnelle et peuvent servir de base riche pour générer des tests fonctionnels avec résultats attendus ; (2) les spécifications fonctionnelles détaillées et les règles métier documentées, qui permettent à l'outil de comprendre le comportement attendu du système ; (3) les enregistrements de défauts historiques, qui constituent une source précieuse pour générer des tests de non-régression ciblés sur les zones problématiques. Le modèle de prédiction de défauts déjà envisagé pourrait également alimenter la génération : en identifiant les modules à risque, il guide l'outil de génération vers les zones nécessitant le plus de couverture, combinant prédiction et génération pour maximiser l'efficacité globale du processus de test.