Comment intégrer Foundation Models Evaluations à une CI Mac distante ? Guide 2026

Le rapport d’évaluation varie d’une exécution à l’autre et la chaîne CI ne sait pas quoi en faire ?
La voie la plus sûre consiste à garder la construction et les tests déterministes comme portes de base, puis à exécuter Foundation Models Evaluations comme une tâche distincte, avec données, critères et résultats conservés.

Cet article s’adresse aux développeurs Apple qui évaluent une fonction de génération, de classification ou d’appel d’outils.
Il concerne aussi les ingénieurs CI qui doivent exécuter des tests Swift sur un Mac distant et retrouver leurs preuves.
Les responsables d’une fonction d’IA y trouveront une méthode pour comparer des consignes et des changements d’implémentation avant de fixer une porte de validation.

Dernière mise à jour : 26 octobre 2026. Les informations sur le cadre d’évaluation et les rapports sont vérifiées à partir de la documentation Apple Evaluations, de la présentation WWDC26 consacrée aux évaluations et des exigences système de Xcode. Les conditions propres au projet et au nœud distant doivent être confirmées sur l’environnement réellement utilisé.

Le rôle des évaluations dans la CI doit rester distinct des tests de base

Foundation Models Evaluations sert à examiner la qualité d’une fonction s’appuyant sur un modèle ; ce n’est pas un substitut à la compilation, aux tests déterministes ou à une revue humaine. Apple présente Evaluations comme un cadre permettant de définir des critères et d’examiner les résultats. La démonstration WWDC26 montre un flux associé à Swift Testing, mais cela ne garantit pas que toute évaluation fonctionnera dans n’importe quelle configuration de CI, sur chaque simulateur ou sur tout Mac distant. Il faut vérifier le comportement selon les consignes de la documentation du cadre et de la présentation Apple citée plus haut.

La distinction est importante parce que ces mécanismes ne répondent pas à la même question. Un test déterministe vérifie une condition définie par le projet, par exemple qu’une fonction retourne une valeur attendue pour une entrée contrôlée. Une évaluation de modèle examine plutôt si une sortie est suffisamment utile, fidèle à une consigne ou adaptée à un usage donné. Même lorsque le résultat paraît bon, une seule exécution ne démontre ni la qualité générale de la fonction ni sa stabilité.

Dans la CI, les responsabilités peuvent donc être réparties de façon claire :

• La construction et les tests déterministes vérifient que le code compile et que les comportements contractuels connus restent conformes.
• La tâche d’évaluation mesure des dimensions de qualité sur un jeu de données suivi et produit des éléments à examiner.
• La revue humaine tranche les cas où les critères sont ambigus, les conséquences d’une erreur élevées ou les changements de comportement difficiles à résumer par un indicateur.

Les décisions de blocage, d’alerte ou de revue manuelle ne découlent pas d’un seuil universel. Elles dépendent des conséquences d’une sortie erronée, de la qualité du jeu d’évaluation et de la capacité de l’équipe à distinguer une variation ponctuelle d’une régression.

Définir des échantillons et des critères qui permettent une comparaison

Une évaluation réutilisable sépare la fonction testée, les entrées, les attentes et le jugement porté sur la sortie. Si ces éléments sont mélangés dans un test monolithique, une modification de consigne peut changer silencieusement la population évaluée ou la règle utilisée pour noter le résultat. Cette confusion rend les comparaisons peu fiables.

Constituez un jeu d’exemples représentatif des usages prévus et des erreurs que le produit doit éviter. Pour une fonction de génération, les entrées devraient couvrir des demandes ordinaires, des demandes incomplètes et des cas où la consigne doit empêcher une réponse non souhaitée. Pour une classification, décrivez les catégories attendues et les cas ambigus. Pour un appel d’outil, évaluez la pertinence de l’appel et la qualité des arguments, sans confondre la décision du modèle avec l’exécution réelle de l’outil.

La quantité d’exemples ne garantit pas à elle seule la pertinence. Un petit ensemble peut servir au contrôle rapide d’une modification, mais il ne permet pas nécessairement de tirer une conclusion sur l’ensemble des usages. La documentation Apple sur la conception d’évaluations efficaces fournit les principes à appliquer pour organiser une évaluation ; la sélection des exemples doit ensuite être adaptée aux erreurs et aux usages observés dans le produit.

Distinguez les indicateurs calculables de ceux qui demandent un jugement qualitatif. Un indicateur automatisable doit avoir une définition stable et un lien direct avec un risque ou un objectif produit : par exemple, la présence d’une information requise, le respect d’un format ou la capacité à éviter une catégorie de sortie interdite. Une appréciation qualitative peut porter sur la clarté, la pertinence ou la qualité d’une réponse, mais elle doit être accompagnée de critères concrets afin que les personnes chargées de la revue ne notent pas selon des attentes différentes.

Versionnez séparément le code, le jeu d’entrées, les consignes et les critères. Pour chaque exécution, il doit être possible d’identifier la révision logicielle et les données auxquelles le rapport correspond. Cela évite de comparer une nouvelle consigne sur un ensemble modifié à un ancien résultat sans le signaler. Cela évite aussi d’attribuer à une modification de code un écart qui vient en réalité d’un changement de données ou de règle de notation.

Si l’équipe utilise un modèle comme évaluateur, définissez précisément le rôle qui lui est confié et contrôlez ses limites. La documentation Apple sur la conception des évaluateurs de modèles concerne cette conception ; elle ne transforme pas l’évaluation automatisée en vérité de référence. Les cas sensibles, les sorties contestées et les évolutions qui affectent un usage important doivent rester accessibles à une revue humaine.

La comparaison doit expliquer les écarts avant de conclure

Après une modification, ne réduisez pas l’analyse à « réussite » ou « échec ». Une évaluation peut varier pour des raisons liées à l’entrée, à la consigne, à l’implémentation ou aux conditions d’exécution. Pour isoler la cause, comparez la même population d’échantillons, les mêmes critères et les résultats individuels, puis examinez ce qui a changé dans le code et la consigne.

Pour une modification de consigne, faites passer l’ancienne et la nouvelle version sur les mêmes entrées, dans des conditions aussi comparables que possible. Regardez les réponses qui ont changé, les critères satisfaits ou manqués, et les exemples qui justifient une revue. Une moyenne identique peut recouvrir une amélioration sur certains cas et une dégradation sur d’autres ; la moyenne seule ne montre pas ce partage.

La variabilité doit être documentée plutôt que dissimulée derrière un seuil arbitraire. Si une sortie change alors que le code et les entrées sont identiques, relevez les conditions d’exécution observables et déterminez si cette variation est attendue ou si elle empêche une décision fiable. Les démonstrations et exemples d’Apple expliquent le fonctionnement montré dans leur contexte ; ils ne constituent pas une conclusion générale sur les performances d’un projet.

Une équipe qui utilise un évaluateur automatisé devrait également comparer son jugement avec des exemples examinés par des personnes compétentes. Si l’évaluateur classe mal des cas importants, une règle de blocage fondée sur ses notes reproduira cette faiblesse. La revue humaine ne doit donc pas être réservée aux seuls échecs techniques : elle peut être le mécanisme de décision normal pour les sorties dont l’ambiguïté ou l’impact sont élevés.

La porte de validation dépend de la qualité des preuves

Avant de faire d’une évaluation un blocage, vérifiez le parcours complet sur le même état du projet dans l’environnement de référence et sur le Mac de CI. Le rapport doit pouvoir être ouvert, les résultats doivent être rattachés aux entrées et aux critères, et un échec doit laisser assez d’éléments pour être examiné. En l’absence de ces conditions, le signal n’est pas suffisamment vérifiable pour bloquer automatiquement une modification.

Utilisez les conditions suivantes pour choisir le traitement :

• Si la compilation ou un test déterministe échoue, bloquez la suite selon la politique habituelle du projet ; l’évaluation du modèle ne peut pas annuler cet échec.
• Si les données, les critères et le rapport sont versionnés et relisibles, et si l’équipe a validé une règle sur des cas pertinents, l’évaluation peut contribuer à une porte de blocage adaptée au risque.
• Si le parcours fonctionne mais que la variabilité ou le jugement restent insuffisamment caractérisés, publiez le résultat comme signal et demandez une revue, plutôt que d’appliquer un seuil non éprouvé.
• Si les résultats ne sont pas conservés ou ne peuvent pas être reliés à leurs entrées, réparez d’abord la chaîne de preuves ; un statut vert isolé n’est pas une validation exploitable.
• Si le modèle ou les conditions d’accès ne sont pas disponibles dans l’environnement visé, n’interprétez pas l’absence d’exécution comme une réussite ; définissez un parcours de repli explicite et signalez que l’évaluation n’a pas eu lieu.

Le tableau ci-dessous distingue les usages possibles ; ce sont des choix d’architecture, non des garanties qu’Apple impose à toutes les équipes.

Pour les équipes qui ne disposent pas d’un environnement macOS reproductible, un Mac distant peut fournir un nœud d’exécution adapté au projet, à condition que les prérequis du modèle et de la chaîne soient satisfaits. Avant de choisir cette voie, comparez l’environnement local, un nœud distant et l’acquisition d’une machine : l’environnement local évite certains délais d’accès, l’achat convient davantage à un besoin durable et maîtrisé sur site, tandis qu’un nœud distant évite de réserver du matériel local mais dépend du réseau, des permissions et de la conservation des rapports. Les options de Mac distant de VNCMac peuvent être examinées si une exécution temporaire ou un environnement de test est nécessaire ; elles ne remplacent pas la vérification des exigences Apple ni un essai sur le projet réel. Pour situer cette solution dans l’offre de VNCMac, consultez également la présentation des services Mac distants.

L’essentiel est de ne pas opposer l’évaluation aux tests classiques. Une chaîne solide fait d’abord respecter les invariants du logiciel, puis utilise Foundation Models Evaluations pour produire des indices structurés sur la qualité de la fonction. Si vous ne disposez pas encore d’un Mac reproductible pour tester votre parcours Xcode, commencez par évaluer les exigences du projet et la conservation des rapports, puis examinez une exécution temporaire avec VNCMac. Si le besoin devient durable, ou exige des interfaces physiques et une maîtrise locale permanente, comparez plutôt cette solution à un Mac acheté et administré par l’équipe.