Les évaluations IA tierces sont désormais un critère d'achat — lis-les comme un acheteur

OpenAI vient de publier un playbook partagé pour des évaluations tierces dignes de confiance — un cadre structuré qui définit comment les évaluations de modèles frontier doivent être conçues, conduites et rapportées. Pour les chercheurs, c'est de la méthodologie. Pour les CTOs, c'est autre chose : un aperçu du standard que tes équipes procurement et infosec vont devoir appliquer d'ici un ou deux trimestres. Ce que la plupart des analyses ratent, c'est que ce document donne aux acheteurs une checklist — et la vraie question est de savoir si tu sais t'en servir.

Ce qui a changé dans la façon de cadrer les évaluations

Les recommandations d'OpenAI organisent les évaluations tierces en trois axes distincts : les évaluations de capacités (qu'est-ce que le modèle sait réellement faire ?), les évaluations de garde-fous (quels comportements a-t-il été entraîné ou instruit à supprimer ?), et les évaluations de validité (les benchmarks mesurent-ils ce qu'ils prétendent mesurer ?). Chaque axe, selon le document, requiert une expertise différente de l'évaluateur, un accès différent aux internals du modèle, et des standards de reporting différents.

Le document établit aussi une distinction nette entre les évaluations conduites avec la coopération du fournisseur de modèle et celles menées de façon adversariale ou indépendante. Les évaluations coopératives bénéficient d'un accès plus complet, mais elles risquent d'orienter les résultats vers le récit préféré du fournisseur. Les évaluations indépendantes préservent l'objectivité, mais travaillent souvent uniquement sur les sorties du modèle — passant à côté des artefacts d'instruction-tuning ou des valeurs par défaut du system prompt, qui comptent énormément en déploiement production.

C'est le cadrage que tes fournisseurs vont bientôt adopter dans leur documentation sécurité. Le timing n'est pas un hasard : les obligations d'évaluation de conformité de l'EU AI Act pour les systèmes à haut risque entrent pleinement en vigueur cette année, et plusieurs grands référentiels d'achat enterprise — dont les directives IA pour les contractants fédéraux américains — convergent vers des exigences d'évaluation tierce comme preuve acceptable de diligence raisonnable.

Pourquoi ça change le calcul sur la confiance accordée aux déclarations de sécurité fournisseur

Jusqu'à récemment, un fournisseur de modèle frontier pouvait te remettre une model card, citer quelques benchmarks académiques, et en rester là. Cette époque se ferme. Ce que signale le playbook d'OpenAI — même involontairement — c'est que l'industrie converge vers un vocabulaire commun pour définir ce qu'est une évaluation crédible. Ce vocabulaire sera utilisé contre toi lors d'un audit fournisseur si tu ne le maîtrises pas.

Le problème plus difficile, c'est que la plupart des rapports d'évaluation dans la nature échouent sur au moins un des trois axes. Les déclarations de capacités sont fréquemment optimisées pour les benchmarks — entraînées sur des données qui chevauchent l'ensemble de test d'une façon que le rapport ne divulgue pas. Les déclarations de garde-fous sont presque toujours des évaluations coopératives : le fournisseur a sélectionné les prompts, défini les catégories de nuisance, et dans certains cas mené lui-même l'évaluation avec une signature tierce nominale en page de couverture. La validité est l'axe que quasiment tous les rapports fournisseurs ignorent complètement, parce qu'elle oblige l'évaluateur à défendre pourquoi son benchmark prédit le comportement en situation réelle — argument défendable, mais difficile.

Pour ton stack, ça compte surtout quand tu déploies un modèle dans un contexte où un échec a des conséquences réglementaires, réputationnelles ou contractuelles : automatisation côté client, traitement de documents juridiques, outils de présélection RH, récupération d'informations médicales. Dans ces contextes, une déclaration de capacités sans section de validité n'est pas une preuve — c'est du marketing.

→ Réserve un audit d'architecture Domani AI si tu es en plein procurement sur un modèle frontier et que tu as besoin d'un regard extérieur pour savoir si la documentation d'évaluation tient la route.

Le chantier du lundi matin : un arbre de décision pour lire un rapport d'évaluation

Quand un fournisseur te remet un rapport d'évaluation — ou quand tu examines un modèle pour un déploiement interne — fais-le passer par ces filtres avant qu'il influence une décision de build or buy.

Filtre 1 : Qui a conduit l'évaluation, et à quoi avait-il accès ?

• Si l'évaluateur a été payé directement par le fournisseur de modèle et n'avait pas de protocole pré-enregistré : traite les déclarations de capacités comme indicatives, pas comme définitives.
• Si l'évaluateur avait accès aux poids ou au fine-tuning : les déclarations de garde-fous sont plus fiables que les audits sur sorties seules, mais vérifie la divulgation des conflits d'intérêts.
• Si l'évaluateur était totalement indépendant sans accès fournisseur : la validité du choix de benchmark compte plus que le score lui-même.

Filtre 2 : Les déclarations de capacités, de garde-fous et de validité sont-elles séparées ou regroupées ?

• Les rapports agrégés qui utilisent un score unique pour couvrir les trois axes sont presque toujours des documents marketing. Démêle-les manuellement si nécessaire : trouve où les déclarations de capacités se terminent et où les déclarations de sécurité commencent.
• L'absence d'une section de validité est un signal d'alerte. Pose la question au fournisseur : pourquoi ce benchmark prédit-il ton cas d'usage en production ?

Filtre 3 : Quel est le périmètre de l'évaluation des garde-fous ?

• Demande explicitement : les catégories de nuisance ont-elles été définies par l'évaluateur ou par le fournisseur ?
• Demande : quelle méthodologie de prompting adversarial a été utilisée, et était-elle cohérente avec ton contexte de déploiement (accès API, system prompt, tool use) ?
• Si l'évaluation des garde-fous a été conduite sur le modèle de base alors que tu déploies une variante fine-tunée ou avec system prompt : l'évaluation ne s'applique pas à ton déploiement. Demande-en une nouvelle ou délimite ta responsabilité en conséquence.

Filtre 4 : Le rapport peut-il être reproduit ?

• Le benchmark est-il public ? Les prompts sont-ils divulgués ? Si aucun des deux : le rapport ne peut pas être vérifié indépendamment, et tu dois intégrer cette incertitude dans ton évaluation des risques.

Cette semaine : récupère la documentation d'évaluation de chaque modèle frontier actuellement en procurement ou déjà dans ton stack. Lance les filtres 1 et 3 en premier — ils détectent la majorité des défauts de validité avec le moins de temps investi. Signale tout ce qui échoue au filtre 3 pour une revue juridique et conformité immédiate avant le prochain incrément de déploiement.

Ce que ça coûte, et ce que ça t'évite

Lire un rapport d'évaluation de façon critique ajoute 2 à 4 heures par fournisseur à ton cycle procurement. Commander une revue d'architecture indépendante sur un contexte de déploiement spécifique — l'étape suivante quand un rapport échoue aux filtres 2 ou 3 — prend 3 à 6 semaines et coûte de l'argent réel. Ce n'est pas une demande anodine sur un trimestre sous pression de livraison.

Le coût contrefactuel est plus difficile à voir avant qu'il arrive. Une déclaration de garde-fous qui ne tient pas sous ton system prompt réel est une exposition au risque, pas un problème fournisseur. Les sanctions réglementaires au titre de l'EU AI Act pour les défaillances de systèmes à haut risque peuvent atteindre 3 % du chiffre d'affaires annuel mondial — et "l'évaluation du fournisseur indiquait que c'était sûr" n'a, dans aucune directive publiée, été acceptée comme défense de conformité. Le chantier du lundi matin n'est pas une quête de perfection ; c'est savoir quelles déclarations dans ton stack actuel sont structurantes et lesquelles sont de la mise en scène, avant que quelqu'un d'autre le découvre à ta place.