Comment tester Foundation Models Evaluations ? Tutoriel iOS 2026

Un test unitaire déterministe vérifie un comportement dont le résultat attendu est connu : une fonction reçoit une entrée et doit respecter une règle, une erreur ou une frontière donnée. Il convient, par exemple, pour vérifier que votre application refuse une demande vide, transmet un paramètre correct à une fonction ou traite une erreur de service.

La qualité d’un texte généré pose une autre question. Une réponse peut être différente tout en restant correcte, ou reprendre les mots attendus tout en omettant une information essentielle. Une assertion qui compare deux chaînes au caractère près risque donc de signaler une variation acceptable ou, au contraire, de laisser passer un défaut fonctionnel.

Les évaluations structurent cette vérification autour d’échantillons, de critères, d’évaluateurs et de résultats agrégés. La documentation Apple sur Evaluations présente le cadre comme un moyen de mesurer la qualité de fonctionnalités intelligentes ; la présentation WWDC26 sur le framework apporte le contexte de son usage. L’évaluation ne prouve pas à elle seule qu’une fonctionnalité est prête à publier : elle rend les observations comparables et aide à repérer les cas à examiner.

Premier contrôle : séparer les preuves

Conservez les assertions ordinaires pour les invariants de votre code. Utilisez l’évaluation pour examiner les réponses dont plusieurs formulations peuvent satisfaire le besoin. Réservez la revue humaine aux cas où une note automatique ne suffit pas à justifier une décision produit.

Vous évitez ainsi deux erreurs fréquentes : demander à un score de prouver le bon fonctionnement d’une branche de code, ou demander à une comparaison exacte de chaînes de représenter une réponse acceptable mais formulée autrement.

Pour savoir si une nouvelle invite améliore votre fonctionnalité, comparez les variantes sur les mêmes entrées et selon les mêmes critères. Gardez constants le contexte fourni au modèle, les informations de départ, le format de sortie attendu et la méthode d’évaluation. Si vous modifiez plusieurs éléments simultanément, vous ne saurez pas lequel explique la différence observée.

La documentation Apple présente Evaluations comme un outil pour comparer des stratégies et suivre l’évolution de la qualité. Cela ne transforme pas une observation isolée en conclusion générale sur les performances : une sortie particulière ne suffit pas à établir qu’une invite ou une configuration sera meilleure dans toutes les situations. Examinez les résultats par type de demande, puis ouvrez les échantillons qui expliquent les écarts.

Pour suivre une régression, gardez une version de référence et consignez ce qui a changé : invite, données, évaluateur ou configuration. Si l’ensemble d’échantillons évolue en même temps, les résultats avant et après ne sont plus directement comparables. Une baisse agrégée indique où enquêter ; elle ne vous dit pas automatiquement quelle modification en est la cause.

Une note globale favorable peut masquer un échec concentré sur une catégorie d’entrées. Avant d’accepter un changement, examinez les échantillons concernés et vérifiez si le défaut touche une règle produit importante.

Un jeu d’évaluation utile représente les variations auxquelles votre fonctionnalité doit répondre, et pas seulement les demandes faciles à satisfaire. Pour une fonction qui résume une note, par exemple, prévoyez des textes incomplets, des formulations longues et des informations contradictoires si ces situations existent dans votre produit. Le but n’est pas d’accumuler des exemples, mais de rendre visibles les conditions qui changent la décision attendue.

La guide Apple sur la conception des jeux de données d’évaluation aide à raisonner sur la composition des données. Si vous utilisez un générateur d’échantillons, comme un mécanisme de type SampleGenerator présenté dans le cadre, vérifiez les résultats obtenus avant de les intégrer au jeu de référence. Des exemples synthétiques peuvent élargir les scénarios, mais ils ne deviennent pas représentatifs uniquement parce qu’ils sont nombreux.

Pour chaque échantillon, écrivez ce qu’une réponse acceptable doit accomplir, ce qui constituerait un défaut et les cas où une revue humaine est requise. Évitez les consignes impossibles à noter de façon cohérente, comme « être excellent » ou « sembler naturel », sans critères observables. Si deux personnes interprètent différemment un critère, l’évaluateur risque de produire une mesure instable.

Choisir un évaluateur adapté à l’objectif produit

Un évaluateur doit mesurer ce que vous cherchez réellement à améliorer. Si la fonctionnalité doit extraire une date et un lieu, le critère porte sur l’exactitude des éléments extraits, pas sur l’élégance du paragraphe. Si elle doit rédiger une réponse destinée à un client, la pertinence, l’exhaustivité et le respect des limites du produit peuvent compter davantage qu’une formulation identique à un exemple modèle.

La documentation Apple sur EvaluationTrait décrit le rôle de cette abstraction dans la définition d’évaluations. Utilisez les critères correspondant au comportement visé, puis vérifiez sur des cas concrets que l’évaluateur distingue bien une réussite d’un échec important. Un score automatique est une mesure selon des règles données ; il ne constitue pas une vérité indépendante de ces règles.

Pour vérifier si vos indicateurs sont pertinents, posez-vous ces questions :

• Le critère traduit-il une exigence du produit que vous pouvez expliquer ?
• L’évaluateur repère-t-il un défaut qui compte réellement pour l’utilisateur ?
• Un résultat acceptable peut-il être formulé de plusieurs manières sans être pénalisé ?
• Les cas ambigus sont-ils signalés pour une revue plutôt que classés arbitrairement ?
• Les échantillons couvrent-ils les usages que vous souhaitez prendre en charge, y compris les entrées difficiles ?

Si votre fonctionnalité choisit et appelle des outils, le texte affiché à l’utilisateur n’est qu’une partie du comportement. Une réponse apparemment satisfaisante peut avoir été produite après un mauvais choix d’outil, une omission d’appel ou une séquence inappropriée. Selon le produit, il faut donc vérifier la décision de l’agent, la trace des appels et le résultat final.

La documentation Apple consacrée à l’évaluation du comportement des appels d’outils traite ce cas. Construisez des échantillons qui expriment la situation de départ, l’action attendue, les actions à éviter et le résultat que l’utilisateur doit obtenir. Dans une fonction créative, par exemple, un outil peut fournir les éléments nécessaires à la préparation d’une description audio ou vidéo ; l’évaluation doit alors vérifier à la fois le choix de l’outil pertinent et la réponse issue des données récupérées.

Ne limitez pas le jeu aux parcours où un outil doit obligatoirement être appelé. Ajoutez aussi des cas où le modèle doit s’abstenir, demander une précision ou répondre sans déclencher d’action. Cette distinction est importante lorsque l’appel a un effet sur l’état de l’application ou engage une action que l’utilisateur doit contrôler.

La revue humaine reste nécessaire pour les cas où la trace technique ne révèle pas si l’action était raisonnable dans son contexte, ou lorsque la réponse peut avoir un effet sensible. La mesure automatique peut orienter cette revue, mais ne dispense pas l’équipe de définir les conséquences acceptables pour son produit.

La documentation Apple indique que les évaluations peuvent s’intégrer à Swift Testing et être exécutées dans le contexte des tests du projet. Pour comprendre cette intégration dans votre dépôt, commencez par les exemples et les instructions de la documentation Evaluations, puis distinguez clairement ce que vous vérifiez avec une assertion ordinaire et ce que vous mesurez avec une évaluation.

Les rapports aident à repérer les exemples qui échouent et à comparer les exécutions, tandis que les résultats agrégés donnent une vue d’ensemble selon les données et les critères choisis. Ils ne remplacent ni l’inspection d’un échec individuel ni la décision produit. Ne choisissez pas un seuil par imitation : fixez-le à partir du risque, des exigences et des usages de votre application.

Deuxième contrôle : tracer chaque modification

Avant une comparaison, enregistrez les versions de l’invite et du jeu d’échantillons, la configuration testée et les résultats de l’évaluation. Après un changement, relancez le même ensemble et inspectez les différences échantillon par échantillon. Si une modification porte précisément sur un cas jusque-là mal couvert, ajoutez un exemple pertinent et documentez ce changement ; ne mélangez pas silencieusement une évolution des données avec une comparaison de configuration.

Pour valider votre intégration, suivez cette liste :

• [ ] Les tests déterministes couvrent les règles métier et les limites de votre code.
• [ ] Les échantillons d’évaluation correspondent aux demandes et aux variantes prévues par le produit.
• [ ] Chaque indicateur décrit un défaut ou une qualité que votre équipe sait expliquer.
• [ ] Les appels d’outils et les abstentions sont évalués lorsque le parcours les implique.
• [ ] Les résultats individuels et agrégés sont examinés séparément.
• [ ] Une personne peut retrouver l’échantillon, la configuration et les critères associés à un résultat.
• [ ] Les cas ambigus ou sensibles sont transmis à une revue humaine.

La prise en charge concrète dépend de l’environnement Xcode et du système cible de votre projet. Vérifiez les versions exigées par la page officielle des configurations requises pour Xcode et consultez les notes de version pour confirmer ce que la version installée apporte. Au moment de la vérification indiquée en tête de l’article, Apple a publié Xcode 27.1 le 15 octobre 2026 ; cette date ne signifie pas que toute configuration de projet ou tout système peut exécuter votre cible sans contrôle préalable.

Un environnement de test utile est celui dans lequel vous pouvez reproduire l’exécution, examiner les rapports et comprendre les différences par rapport à votre poste habituel. Avant de déplacer vos évaluations sur un Mac distant ou dans un processus d’intégration continue, vérifiez la compatibilité de Xcode avec le système cible, la possibilité d’exécuter le test concerné et la traçabilité des entrées et des résultats.

Procédez dans cet ordre :

1. Relevez les dépendances du projet. Notez la version de Xcode, le système cible et les conditions nécessaires au lancement des tests. Vérifiez ces exigences dans la documentation officielle, plutôt que de supposer que deux environnements sont interchangeables.
2. Exécutez un projet représentatif. Incluez l’intégration réelle à Foundation Models, le test d’évaluation et les dépendances dont votre application a besoin. Un test isolé qui évite ces éléments ne valide pas le parcours complet.
3. Conservez les mêmes échantillons et critères. Identifiez l’entrée, la variante de configuration et l’évaluateur associés à chaque résultat. Sans ces informations, une différence est difficile à diagnostiquer.
4. Comparez les rapports et les sorties individuelles. Contrôlez les échecs, les erreurs de test et les divergences par rapport à la référence. Ne concluez pas à une amélioration sur la seule base d’un résultat agrégé.
5. Décidez si l’accès distant est justifié. Si les tests doivent s’exécuter régulièrement et que votre environnement local ne peut pas rester disponible, un Mac distant peut être à considérer. Si vous lancez les évaluations ponctuellement sur une machine déjà adaptée, une location n’est pas automatiquement nécessaire.

Dans un environnement distant, la disponibilité d’un Mac ne garantit pas à elle seule que vos tests seront reproductibles : il faut aussi valider le projet, les versions, les accès requis et le chemin d’exécution de Xcode. Cet article ne présente ni configuration distante particulière ni résultat d’essai hébergé ; aucune performance ou compatibilité propre à un service n’est donc promise ici.

Si votre poste actuel vous oblige à suspendre des validations, dépend d’un accès local difficile à partager ou ne reste pas disponible pour les tests récurrents, comparez ce coût opérationnel à un Mac distant. À l’inverse, si vous avez besoin de ports physiques spécifiques ou d’une machine dédiée à une charge intensive et constante, une machine locale peut être plus adaptée. Pour un besoin temporaire ou un environnement de validation accessible à distance, vous pouvez consulter les tarifs de location de Mac de CALMVPS et les offres de Mac distant de CALMVPS, puis vérifier vous-même que le parcours Xcode de votre projet répond à vos critères d’acceptation.

Le contrôle décisif reste le même, que vous exécutiez les évaluations localement ou à distance : des entrées représentatives, des critères défendables, des résultats consultables et une revue des écarts avant publication. Les évaluations de Foundation Models vous aident à suivre la qualité générée ; elles complètent vos tests déterministes, sans les remplacer.