1. Convertir chaque allégation de benchmark en proposition testable
Une allégation de benchmark doit identifier le système, la tâche, la population, l’intervention, le comparateur, la métrique et la pertinence décisionnelle. L’affirmation selon laquelle un modèle est plus précis qu’un concurrent est incomplète tant que l’acheteur ne sait pas quel checkpoint de modèle, quelle politique de prompt, quelle configuration d’outils, quel jeu de données, quelles exclusions, quelle règle de scoring et quel intervalle de confiance ont produit le résultat. L’affirmation selon laquelle une application est plus rapide ou moins chère est incomplète tant que la concurrence, le matériel, la mise en cache, les nouvelles tentatives, la revue humaine et la gestion des défaillances ne sont pas inclus.
Le registre de due diligence doit conserver la formulation exacte présentée aux clients, aux investisseurs et au comité de transaction. Chaque allégation doit être liée au code source, aux poids ou à la version API, aux données d’évaluation, aux journaux d’exécution, au matériel, aux dépendances logicielles, à l’implémentation de la métrique, aux notebooks des analystes et aux approbations. Les preuves doivent conserver les horodatages et les hachages lorsque cela est réalisable. Un chiffre de présentation qui ne peut pas être rattaché à une exécution reproductible doit être classé comme non résolu.
Les allégations doivent également avoir un usage transactionnel. Un résultat peut étayer la différenciation produit, la fidélisation client, le pouvoir de fixation des prix, la marge brute, la préparation réglementaire ou un paiement conditionnel. La force de test requise dépend de cet usage. Une comparaison marketing peut nécessiter une correction sans changer la valeur. Une capacité revendiquée qui soutient l’essentiel de la prévision peut nécessiter une évaluation aveugle indépendante et un recours contractuel avant signature.
2. Construire un graphe de preuves de benchmark
Le graphe de preuves relie le score déclaré aux artefacts et aux décisions qui l’ont produit. Les nœuds représentent le modèle, le jeu de données, la tâche, le prompt, l’outil, le matériel, la version logicielle, la métrique, l’exclusion, l’évaluateur humain, l’exécution et l’allégation publiée. Les arêtes enregistrent les dépendances et les transformations. Le graphe doit permettre à un évaluateur de revenir d’un chiffre figurant sur une diapositive du conseil d’administration aux sorties brutes, puis d’avancer vers l’hypothèse commerciale qu’il étaye.
Chaque nœud doit avoir un état de preuve : préservé et vérifié, préservé mais non vérifié, déclaration de la direction, document de tiers, indisponible ou remplacé. Un hachage établit l’identité du fichier, mais n’établit pas que le fichier est complet, approprié ou exempt de contamination. Les évaluateurs doivent donc consigner à la fois la provenance et l’adéquation à l’usage.
Le graphe expose les substitutions silencieuses. Une allégation publique peut citer un benchmark tandis que le notebook d’évaluation utilise un découpage modifié. Le produit peut appeler un modèle plus récent que celui décrit lors de la due diligence. Un graphique de latence peut omettre les requêtes échouées. Un rapprochement assisté par machine peut signaler des identifiants, des dates, des nombres d’échantillons et des versions discordants pour examen par des experts. Le graphe obtenu devient la surface de contrôle pour la reproduction, les exceptions et le traitement de la transaction.

Une allégation pertinente pour la transaction doit être traçable depuis les artefacts sources, en passant par l’évaluation, jusqu’à l’hypothèse commerciale.
Tableau 1. Enregistrement minimal d’une allégation de benchmark
| Champ | Éléments de preuve requis | Test principal | Responsable de la décision |
|---|---|---|---|
| système | modèle, checkpoint, API, outils et configuration | le système testé peut-il être reconstruit ? | responsable technique |
| données | source, licence, population, découpage et hachages | la population d’évaluation est-elle appropriée et non contaminée ? | responsable des données |
| protocole | prompts, échantillonnage, matériel, logiciels et nouvelles tentatives | les conditions étaient-elles fixées et comparables ? | responsable de l’évaluation |
| métrique | mise en œuvre, agrégation et incertitude | le score mesure-t-il le résultat revendiqué ? | responsable de la méthodologie |
| résultat | sorties brutes, échecs, exclusions et journaux | le chiffre publié peut-il être recalculé ? | réviseur indépendant |
| usage commercial | lien avec les prévisions, les contrats, les marges ou la valeur | Comment l'allégation entre-t-elle dans le dossier de l'opération ? | Responsable de l'opération |
| autorité | Préparateur, réviseur, date et approbation | Qui a accepté l'allégation et ses limites ? | Président de la due diligence |
Le registre distingue l'identité, la méthode, le résultat et l'usage dans la transaction.
3. Définir la décision avant de choisir le test
La conception de l'évaluation doit commencer par la décision de transaction. Un acquéreur qui cherche à déterminer si un produit respecte un seuil contractuel de précision a besoin d'une population de clients représentative, de la métrique contractuelle et du traitement convenu des échecs. Un acquéreur qui évalue la marge brute a besoin du débit, du matériel, du coût d'inférence, de la revue humaine et de la charge de support. Un conseil d'administration qui évalue la différenciation technique a besoin de comparables pertinents et de preuves que l'avantage persiste au-delà d'une démonstration sélectionnée.
Un seul benchmark répond rarement à toutes ces questions. Les tests de capacités mesurent la performance sur des tâches définies. Les tests de robustesse font varier les entrées et les conditions d'exploitation. Les tests de sûreté examinent les comportements nuisibles ou contraires aux politiques. Les tests économiques relient la qualité à la latence, au calcul, à la main-d'œuvre et aux niveaux de service. Les tests produit intègrent l'interface, la récupération, les outils, le flux de travail et l'escalade humaine. Le plan de due diligence doit indiquer à quelle question chaque test répond et à quelle question il ne peut pas répondre.
L'équipe doit s'accorder sur le seuil de matérialité avant de voir les résultats reproduits. Le seuil de matérialité peut concerner la concentration du chiffre d'affaires, les pénalités contractuelles, la marge prévisionnelle, l'usage réglementé, le préjudice client, les besoins en capital ou la valorisation. Une règle de décision préenregistrée réduit la tentation de redéfinir le succès après un résultat gênant. Elle aide aussi le vendeur à fournir les bons artefacts et protège l'acquéreur contre le temps consacré à des scores ayant peu d'incidence sur la transaction.
4. Figer le système revendiqué et l'environnement d'évaluation
La reproduction exige un objet identifié. L'équipe de due diligence doit figer le point de contrôle du modèle ou la version API, le prompt système, le corpus de récupération, les définitions d'outils, les couches de sûreté, les paramètres d'échantillonnage, les paquets logiciels, le profil matériel et le code d'évaluation. Les conteneurs, les verrouillages de dépendances, les hachages et les manifestes d'exécution peuvent appuyer le gel. Lorsqu'un API tiers empêche la préservation complète, l'équipe doit consigner le fournisseur, le point de terminaison, l'identifiant du modèle, la date, la région et les métadonnées de réponse observées.
Le système figé doit refléter l'allégation faisant l'objet de la due diligence. Un vendeur peut présenter un point de contrôle de recherche alors que les clients utilisent un stack produit optimisé. Les deux peuvent mériter d'être testés, mais les résultats doivent rester distincts. Le fine-tuning, la récupération, le post-traitement et la revue humaine peuvent créer de la valeur qui ne réside pas dans le modèle de base. L'acquéreur doit éviter d'attribuer la performance du produit aux capacités du modèle propriétaire lorsque l'avantage provient d'un composant externe remplaçable.
Les contrôles d'accès sont importants. L'environnement de reproduction peut contenir du code confidentiel, des données clients et des pondérations de modèle. L'équipe cloisonnée doit journaliser les utilisateurs, les transferts de données, les exécutions et les exports. Les preuves de reproduction doivent survivre à la signature tout en respectant les licences, la confidentialité, les secrets d'affaires et la sécurité. Les conseils juridiques et les spécialistes de la sécurité doivent définir les accès autorisés, la conservation et la destruction.
5. Reconstituer le lignage du jeu de données et la population visée
La traçabilité du jeu de données doit décrire l'origine des exemples, la manière dont ils ont été collectés, filtrés, étiquetés, dédupliqués et répartis, ainsi que les versions qui ont servi à l'entraînement, à l'ajustement et à l'évaluation. L'acheteur a besoin d'identifiants au niveau des éléments ou de substituts justifiables pour tester le chevauchement. Les déclarations agrégées sur des données propriétaires n'offrent qu'une assurance limitée lorsque la valorisation dépend d'un avantage lié aux données.
La population d'évaluation doit correspondre à l'allégation commerciale. Un flux de travail médical, une décision de crédit, un outil d'inspection industrielle ou de rédaction juridique peut être confronté à une composition des cas, une langue, une zone géographique, une prévalence et un comportement des utilisateurs différents de ceux d'un benchmark public. Les performances peuvent changer lorsque des cas rares mais coûteux reçoivent un poids plus important. L'équipe de due diligence devrait comparer les distributions du benchmark à l'utilisation réelle ou contractuelle et documenter l'écart de couverture.
Les licences et le consentement nécessitent un examen distinct. Un jeu de données peut être statistiquement utile tout en créant une exposition contractuelle, de confidentialité, de propriété intellectuelle ou réglementaire. Le dossier du benchmark devrait relier la provenance, l'utilisation autorisée, les restrictions de conservation et de transfert. Des conseillers qualifiés devraient évaluer les obligations applicables. La reproduction technique ne peut remédier à un droit que la cible ne possède pas.
6. Tester le chevauchement direct entre l'entraînement et le test
Un chevauchement direct se produit lorsque des éléments d'évaluation, des réponses ou des quasi-doublons apparaissent dans le matériel d'entraînement ou d'ajustement. Il peut gonfler la généralisation apparente parce que le modèle a rencontré le test. La détection peut combiner des hachages exacts, une correspondance de texte canonicalisé, un chevauchement de n-grammes, une similarité sémantique, des empreintes d'images et des métadonnées. La méthode devrait tenir compte des modifications de formatage, des traductions, des paraphrases et des exemples dérivés.
Une correspondance doit être interprétée. Des connaissances largement publiées peuvent apparaître légitimement dans différentes sources, tandis qu'une paire question-réponse distinctive de benchmark suscite une préoccupation plus forte. L'équipe devrait consigner la force de la correspondance, son sens, sa chronologie et si l'élément a pu influencer l'entraînement. Lorsque le vendeur ne peut pas exposer les données d'entraînement, les alternatives incluent des attestations, des enregistrements de génération de données, des recherches sur l'inférence d'appartenance, des éléments canaris et de nouveaux tests séquestrés.
La réponse appropriée dépend de la prévalence et de la sensibilité de l'allégation. L'évaluateur peut recalculer les performances après avoir retiré les chevauchements suspectés, comparer les strates affectées et non affectées, et tester un nouvel ensemble équivalent. Le résultat devrait présenter une fourchette plutôt que de comprimer l'incertitude dans une étiquette binaire « contaminé » ou « propre ». Une baisse significative d'un résultat soutenant le prix nécessite une escalade.
7. Détecter la contamination sémantique et la familiarité avec le benchmark
La contamination peut aller au-delà des copies exactes. Des tutoriels, dépôts de solutions, discussions sur les benchmarks, variantes synthétiques et données d'entraînement générées par modèle peuvent encoder la tâche ou la structure de la réponse. Les modèles peuvent aussi apprendre des formats et des stratégies spécifiques au benchmark sans mémoriser des éléments individuels. Des recherches sémantiques, l'historique des dépôts, les dates d'exploration web et l'analyse d'exposition peuvent aider à identifier des voies plausibles.
L'équipe de due diligence devrait comparer les performances sur des éléments publics existants avec des éléments nouvellement créés, séquestrés et structurellement équivalents. Un écart important peut indiquer une exposition, un changement de distribution, des différences de construction des tests ou plusieurs effets combinés. Il s'agit d'une preuve nécessitant une enquête plutôt que d'une preuve d'une cause particulière. Une administration en aveugle et des contrôles d'accès stricts renforcent l'inférence.
La familiarité avec le benchmark affecte aussi les systèmes agentiques. Les outils, prompts ou logiques de routage peuvent contenir des noms de benchmarks, des schémas de réponses ou des raccourcis spécifiques à la tâche. Le gel du système devrait donc inclure le code de l'orchestrateur et les bibliothèques de prompts. Un modèle de base aux performances modestes peut sembler fort lorsqu'un harnais construit manuellement est adapté au test. Ce harnais peut rester précieux, mais son transfert vers les flux de travail clients doit être démontré.

Des preuves plus solides combinent la correspondance d'artefacts, l'analyse temporelle et une nouvelle évaluation séquestrée.
Tableau 2. Matrice de tests de fuite
| Voie de fuite | Test | Preuves plus solides | Limite |
|---|---|---|---|
| chevauchement exact d’éléments | hachages et appariement canonisé | enregistrements datés du corpus et appariements au niveau des éléments | omet les transformations |
| quasi-doublons | similarité lexicale et sémantique | groupes d’appariements examinés | la similarité ne prouve pas l’utilisation pour l’entraînement |
| exposition des réponses | recherche de solutions et de dépôts | enregistrement daté d’accès ou d’ingestion | les connaissances publiques peuvent être légitimes |
| adaptation des prompts | inspecter les prompts et le code du dispositif d’évaluation | comparaison avec un protocole générique figé | l’optimisation produit peut créer une valeur réelle |
| contamination temporelle | comparer les dates de publication et d’entraînement | journaux et instantanés immuables | les dates peuvent être incomplètes |
| familiarité étendue | éléments aveugles hérités versus éléments aveugles nouveaux | ensemble équivalent de tâches tenu à l’écart | les nouveaux ensembles peuvent différer par leur difficulté |
Les résultats doivent être interprétés en tenant compte du calendrier, de l’accès et de la conception du benchmark.
8. Tester la sélection des benchmarks et les alternatives omises
Le biais de sélection peut apparaître avant toute exécution. Une cible peut présenter des benchmarks sur lesquels elle obtient de bons résultats, choisir des sous-tâches favorables ou omettre des alternatives reconnues. L’équipe de due diligence devrait reconstituer l’univers des benchmarks candidats à partir des allégations produit, des exigences clients, des attentes réglementaires, des pratiques universitaires et des informations publiées par les concurrents. La direction devrait expliquer les critères d’inclusion et d’exclusion.
La pertinence importe davantage que le volume. L’utilisation de dizaines de classements publics peut donner une fausse impression de couverture tout en laissant l’usage commercial de l’acheteur non testé. L’équipe doit associer chaque benchmark sélectionné à la population visée, au coût des erreurs et à la décision. Elle doit aussi examiner les résultats générés en interne et non publiés, car des expérimentations abandonnées ou défavorables peuvent révéler des effets de sélection.
Un portefeuille de benchmarks peut inclure des tests de comparabilité publics, des tests privés de type client, des tests de résistance, des tests économiques et des tests de sûreté. Les pondérations doivent refléter l’exposition de la transaction et rester fixées avant que les résultats soient connus. Si un vendeur choisit un portefeuille différent, l’acheteur doit conserver les deux visions et rapprocher les différences.
9. Reproduire le calcul des métriques à partir des sorties brutes
Le score déclaré doit être recalculé à partir des prédictions brutes, des étiquettes et du code des métriques. Les examinateurs doivent tester les dénominateurs, le calcul des moyennes, les pondérations de classes, les ex aequo, les abstentions, les expirations de délai, les sorties invalides et les enregistrements en double. Les moyennes macro et micro peuvent raconter des histoires différentes. La précision peut masquer un déséquilibre entre classes. Un score composite peut cacher une défaillance importante dans une dimension.
L’incertitude doit figurer à côté de l’estimation ponctuelle. La taille de l’échantillon, la dépendance, les exécutions répétées, la variation entre annotateurs et la génération stochastique influent sur la précision. Les travaux du NIST sur les modèles statistiques pour l’évaluation automatisée des benchmarks soulignent la nécessité de définir la cible de mesure et les hypothèses qui étayent les conclusions. Le rapport de due diligence doit indiquer des intervalles de confiance ou d’autres mesures d’incertitude adaptées et éviter une fausse précision.
Les métriques doivent être reliées aux conséquences. Une amélioration d’un point peut avoir peu de valeur pour le client, tandis qu’une légère détérioration dans une classe d’erreurs à coût élevé peut avoir une grande importance. Les seuils doivent être justifiés par les contrats, l’économie des flux de travail, l’appétence au risque et les besoins des utilisateurs. Un rang dans un classement suffit rarement à établir une signification économique.
10. Recréer les prompts, les outils et l’intervention humaine
Les systèmes génératifs et agentiques peuvent être très sensibles aux prompts, à l’accès aux outils, à la récupération, à l’échantillonnage et aux instructions de l’évaluateur. Le protocole revendiqué doit conserver les prompts système et utilisateur, les exemples few-shot, les schémas d’outils, la logique de nouvelle tentative, la température, les graines lorsque celles-ci sont prises en charge, les limites de contexte et les conditions d’arrêt. Les modifications manuelles non documentées ou les complétions sélectionnées sur le volet doivent être traitées comme des interventions.
L’assistance humaine doit être visible. Le personnel peut sélectionner des entrées, réparer des sorties, choisir parmi des candidats, étiqueter des réponses limites ou passer outre des échecs. Le travail humain peut faire partie intentionnellement d’un service de valeur. Son temps, ses compétences, son coût, sa cohérence et son évolutivité doivent entrer dans le benchmark et dans le modèle commercial. Un produit décrit comme automatisé ne devrait pas bénéficier d’une économie automatisée lorsque sa qualité démontrée dépend d’un travail expert non enregistré.
Le plan de reproduction doit d’abord exécuter la configuration divulguée. Les analyses de sensibilité peuvent ensuite faire varier les prompts et les contrôles pour tester la robustesse. Une méthode qui ne réussit que sous une instruction finement ajustée peut convenir à un flux de travail stable, mais elle fournit des preuves plus faibles d’une capacité générale.
11. Maîtriser le matériel, la concurrence et l’optimisation du système
Les affirmations sur la latence, le débit et le coût dépendent du matériel, de la précision, de la taille des lots, de la longueur des séquences, de la mise en cache, du réseau, de la région, de la concurrence et du taux d’utilisation. Une cible peut produire un résultat de laboratoire impressionnant sur des accélérateurs rares à faible charge, tandis que la prévision suppose une infrastructure standard et un trafic soutenu. L’environnement de due diligence doit capturer la télémétrie matérielle et système en même temps que la qualité.
Les démarrages à chaud et à froid, les succès de cache, les nouvelles tentatives et les requêtes échouées doivent être rapportés séparément. La latence par centile est généralement plus informative qu’une moyenne pour les engagements de service. Le débit doit inclure la contre-pression et la mise en file d’attente. Le coût par tâche réussie doit intégrer l’inférence, la récupération, les outils, le stockage, l’observabilité, la revue humaine et l’infrastructure allouée, et pas seulement le coût par token.
L’optimisation peut être propriétaire et durable. La quantification, la compilation, le routage et l’ordonnancement peuvent créer un avantage réel. L’acheteur doit vérifier si l’optimisation se transfère avec les actifs acquis, dépend d’une licence tierce ou nécessite des spécialistes qui pourraient ne pas rester. L’affirmation relative au benchmark et la capacité de réalisation de la transaction doivent donc être reliées.
12. Exécuter un protocole de reproduction préenregistré
Le protocole doit être approuvé avant que l’équipe indépendante ne voie les résultats finaux. Il précise le système revendiqué, la population de test, l’échantillon, les métriques, la méthode statistique, l’environnement, les interventions autorisées, les règles d’exception et les seuils de décision. Il identifie qui peut accéder aux étiquettes, qui exécute les exécutions et qui approuve les écarts. Le préenregistrement réduit les modifications a posteriori et étaye une piste d’audit défendable.
L’exécution peut se dérouler selon la réception, les contrôles d’intégrité, l’exécution à blanc, l’exécution verrouillée, le recalcul indépendant, l’analyse de sensibilité et la revue des exceptions. L’exécution à blanc valide le mécanisme sur les éléments non notés. L’exécution verrouillée utilise des artefacts contrôlés et produit des journaux immuables. Toute réexécution doit conserver la sortie d’origine et un motif.
L’équipe doit distinguer la reproductibilité de la réplication. La reproduction peut consister à obtenir le résultat avec les artefacts et la méthode du vendeur. La réplication peut tester la revendication sous-jacente à l’aide de données ou de méthodes construites indépendamment. Un programme de due diligence robuste peut nécessiter les deux, en particulier lorsque le benchmark public est exposé ou que la population commerciale diffère.

Les règles de décision et les modifications autorisées sont fixées avant l’exécution notée.
Tableau 3. Jalons du protocole de reproduction
| Point de contrôle | Livrable requis | Réponse en cas d’échec | Autorité |
|---|---|---|---|
| réception de la revendication | revendication exacte et usage commercial | lever l’ambiguïté avant les tests | Responsable de l'opération |
| gel des artefacts | manifeste, versions, empreintes de hachage et journal d’accès | consigner les artefacts manquants ou modifiables | responsable technique |
| préenregistrement | échantillon, métrique, incertitude et seuil | reporter l'exécution notée | responsable de la méthodologie |
| exécution verrouillée | sorties brutes complètes, télémétrie et échecs | mettre l'exécution en quarantaine et enquêter | responsable de l’évaluation |
| recalcul | score indépendant et sensibilité | réconcilier une différence de code ou de données | réviseur indépendant |
| Décision | traitement de la valeur, du contrat et de l'intégration | escalader un écart significatif | Président de la due diligence |
Chaque point de contrôle produit des éléments de preuve pour la décision de transaction suivante.
13. Recourir à une évaluation en aveugle et séquestrée lorsque l'exposition est importante
Les tests en aveugle limitent l'accès de la partie évaluée aux étiquettes, aux sorties attendues ou aux éléments finaux. Les tests séquestrés maintiennent les données dans un environnement contrôlé et peuvent empêcher leur inclusion dans l'entraînement futur. Le programme d'évaluation technologique AI du NIST utilise des données en aveugle et un environnement séquestré pour réduire le risque de contamination et améliorer la comparabilité. Les équipes de transaction peuvent adapter ce principe aux déclarations significatives.
Le vendeur peut fournir un conteneur ou un point de terminaison contrôlé tandis qu'une équipe indépendante détient le jeu de test. Les entrées doivent refléter la population convenue, et le processus doit capturer les sorties, les refus, les erreurs, les temps d'exécution et l'utilisation des ressources. Les contrôles de sécurité doivent empêcher l'exfiltration de données via les journaux, les outils ou les mises à jour de modèle. Le protocole doit également empêcher une fuite d'informations par l'évaluateur via des retours informels pendant l'exécution.
Des données récentes ne créent pas automatiquement un test équitable. La qualité, la difficulté et l'étiquetage des éléments doivent être revus. Lorsque cela est possible, un sous-ensemble de calibration peut être examiné conjointement avant le verrouillage de l'ensemble noté. Les litiges doivent suivre un processus d'arbitrage prédéfini qui préserve les décisions en aveugle et évite un réétiquetage sélectif.
14. Tester la robustesse dans des conditions d'exploitation pertinentes
Un score unique décrit un point dans un espace opérationnel plus vaste. Les tests de robustesse font varier la langue, la géographie, l'expertise des utilisateurs, la qualité des entrées, la longueur des documents, la prévalence des classes, le comportement adversarial, la pression temporelle, la défaillance des outils et la charge système. Ces variations doivent refléter l'exposition des clients et des régulateurs plutôt que des perturbations arbitraires.
L'équipe doit distinguer la dégradation gracieuse des effets de falaise. Un modèle peut décliner modérément à mesure que les documents deviennent plus bruités, puis échouer brusquement au-delà d'un seuil de contexte ou de récupération. Un processus peut rester précis alors que la latence et le coût dépassent les niveaux de service. Ces points de transition peuvent guider la planification des capacités, les conditions contractuelles et la feuille de route d'intégration.
Les affirmations de robustesse nécessitent incertitude et couverture. Tester toutes les conditions est impossible. Le rapport doit préciser le périmètre échantillonné, les combinaisons non testées et la surveillance nécessaire après la clôture. L'acheteur peut protéger la valeur par un déploiement par étapes, des retenues de prix, des engagements de support ou une contrepartie conditionnelle lorsque des conditions importantes restent non testées.
15. Comparer à des alternatives crédibles
La différenciation exige un comparateur que l'acheteur ou le client pourrait réellement utiliser. Cela peut inclure un produit actuel, un modèle ouvert, un API commercial, un fournisseur spécialisé, un processus humain ou une méthode statistique plus simple. Le comparateur doit bénéficier d'une optimisation raisonnable et des mêmes données, métrique, limite matérielle et exigence de service. Une référence délibérément faible surestime l'avantage.
Le test doit également séparer la valeur du modèle de la valeur du système. Une cible peut produire des résultats supérieurs grâce à des données propriétaires, une intégration au processus métier, des boucles de rétroaction, la distribution ou des opérations expertes, même lorsque le modèle sous-jacent est remplaçable. À l'inverse, un score de modèle de premier plan peut créer une valeur métier limitée si le produit manque de droits sur les données, d'adoption par les clients ou d'économie unitaire.
La disponibilité des comparateurs peut évoluer rapidement. Le dossier de transaction doit inclure des déclencheurs de mise à jour entre la signature et la clôture, ainsi qu'après la clôture. Une amélioration importante d'une alternative accessible peut modifier le prix prévisionnel, les besoins en capital ou la valeur de la technologie propriétaire. Le contrat et le processus d'approbation doivent définir la manière dont ces changements sont évalués.
16. Concilier signification statistique et signification économique
Un résultat statistiquement distinguable peut être économiquement non significatif, et un risque économiquement sérieux peut rester statistiquement incertain dans un petit échantillon. L'équipe de due diligence doit définir le plus petit effet qui modifie la valeur client, le coût, la sécurité, la performance contractuelle ou la valorisation. La conception de l'échantillon doit viser à mettre en évidence cet effet lorsque cela est réalisable.
L'analyse décisionnelle peut combiner estimations d'effet, incertitude et conséquences. Les erreurs fréquentes à faible coût peuvent être gérées par les opérations, tandis que les défaillances rares et graves peuvent nécessiter des tests de résistance et des contrôles ciblés. L'équipe doit éviter de convertir toutes les dimensions en un score opaque. La qualité, la sécurité, la latence, le coût et l'effort humain doivent rester visibles avant toute pondération.
Lorsque les preuves restent faibles, les modalités de la transaction peuvent refléter directement l'incertitude. Des fourchettes de prix, des compléments de prix, des garanties, des covenants, un investissement par étapes et des conditions de clôture peuvent répartir le risque de manière plus transparente qu'un ajustement de probabilité non étayé. Le conseil d'administration doit voir comment le mécanisme retenu répond à l'écart de preuves observé.
17. Faire le lien entre la qualité en laboratoire et la performance en production
La production introduit un mix de trafic, des entrées imparfaites, l'adaptation des utilisateurs, une dérive de la récupération, des pannes d'outils, des contrôles de sécurité, la surveillance, l'escalade humaine et l'évolution des modèles. L'équipe de due diligence doit établir un pont entre la qualité de référence et la réussite des tâches de bout en bout. Chaque étape doit identifier les preuves, la perte, le coût et le responsable.
Les tests en mode miroir peuvent rejouer ou reproduire des cas de production représentatifs sans permettre au système candidat de contrôler le résultat réel. Un pilote limité peut tester le processus en conditions réelles et le comportement des utilisateurs dans le cadre de garde-fous convenus. Les rétro-tests historiques peuvent accroître l'échelle, mais ils risquent de manquer les distributions changeantes et les effets de rétroaction. Les preuves les plus solides combinent généralement plusieurs méthodes.
Le pont doit concilier les métriques au niveau du modèle avec les mesures clients et financières : tâches réussies, temps de cycle, reprises, escalade, rétention, prix, crédits de service, calcul et main-d'œuvre. Un modèle peut améliorer la précision tout en réduisant la marge brute en raison d'une inférence ou d'une revue coûteuse. Un score global plus faible peut créer davantage de valeur lorsqu'il est fiable, rapide et économique dans le processus cible.

La qualité du benchmark déclaré est réduite par des effets de distribution, de flux de travail et d'exploitation avant même d'atteindre les résultats clients et de trésorerie.
Tableau 4. Passerelle de preuves de l'écart de production
| Couche | Justificatif | Écart typique | Conséquence sur la transaction |
|---|---|---|---|
| benchmark déclaré | publication, présentation et historique d'exécution | ambiguïté de sélection et de protocole | confiance dans l'allégation |
| reproduction contrôlée | artefacts figés et exécution verrouillée | différence de calcul ou d'environnement | valeur technique |
| données représentatives | jeu de test à l’aveugle représentatif des clients | évolution de la population et de la prévalence | adéquation du produit |
| flux de travail | outils, récupération, intervention humaine et gestion des défaillances | intégration et reprises | capacité de prestation |
| niveau de service | latence, disponibilité, sécurité et support | résilience opérationnelle | performance contractuelle |
| aspects économiques | calcul, main-d’œuvre, prix et rétention | marge et conversion en trésorerie | valorisation et financement |
Chaque couche convertit la performance technique en une conséquence opérationnelle et financière.
18. Refondre l’économie de l’inférence et du support
L'économie unitaire doit être mesurée par résultat client réussi. La structure de coûts peut inclure les appels de modèle, le temps d'accélérateur, la récupération, le stockage, le réseau, les outils tiers, l'observabilité, la sécurité, les nouvelles tentatives, la revue humaine, le support et le coût de plateforme alloué. Les minimums contractuels et la capacité réservée peuvent générer des coûts même lorsque l'utilisation est faible.
La qualité et le coût interagissent. Un modèle plus petit peut réduire les dépenses d'inférence mais augmenter les erreurs et la revue. Un modèle plus grand peut améliorer la qualité au premier passage tout en augmentant la latence et la concentration fournisseur. Le routage peut créer de la valeur lorsqu'il envoie chaque tâche au système le moins coûteux qui atteint le seuil requis. Le benchmark devrait donc présenter une frontière qualité-coût plutôt qu'un score unique pour une configuration donnée.
Les prévisions devraient utiliser les distributions observées et les contraintes de capacité. Les remises sur volume, les prix du matériel et les gains d'efficacité des modèles peuvent s'améliorer, tandis que la composition de la clientèle, la longueur du contexte et les attentes de service peuvent augmenter les coûts. Les scénarios devraient préserver les deux directions. Les gains d'efficacité futurs non vérifiés devraient rester une estimation de la direction jusqu'à ce qu'ils soient étayés par des contrats ou démontrés par l'ingénierie.
19. Examiner la gouvernance et les incitations du benchmark
L'acheteur devrait comprendre qui a conçu, exécuté, examiné et approuvé chaque évaluation. Les chercheurs, fondateurs, équipes commerciales et conseillers peuvent être incités à présenter des résultats favorables. L'indépendance est renforcée par la séparation des rôles, des règles préenregistrées, la conservation des sorties brutes et l'examen par des personnes qui n'ont pas créé l'allégation.
Les changements après une exécution défavorable méritent une attention particulière. Certains changements corrigent de véritables erreurs ; d'autres restreignent la population, remplacent une métrique ou excluent des échecs. Le journal devrait conserver le résultat d'origine, la raison, l'approbateur et l'effet. Des réexécutions répétées non documentées ou des sorties brutes manquantes affaiblissent la confiance même lorsqu'un score ultérieur est plausible.
Le conseil d'administration devrait recevoir les limites importantes dans un langage clair. Une annexe technique ne peut pas compenser un titre qui suggère une performance plus large que ce que les preuves soutiennent. La gouvernance devrait également définir qui peut faire des déclarations publiques, clients ou relatives à la transaction et comment ces déclarations restent alignées sur les résultats validés.
20. Évaluer les preuves apportées par les benchmarks et certifications tiers
Les évaluations, audits et certifications indépendants peuvent renforcer les preuves lorsque leur périmètre, leurs méthodes, leur compétence et leur indépendance correspondent à l'allégation. L'équipe de due diligence devrait obtenir le rapport réel, la version testée, la période, les exclusions et les conclusions. Un logo ou un certificat peut couvrir la gestion de la sécurité de l'information tout en disant peu de choses sur la qualité du modèle.
L'équipe devrait examiner l'accès aux preuves brutes, l'échantillonnage, la reproductibilité, les conflits, le libellé relatif à l'usage autorisé et si l'évaluateur a testé le produit ou accepté les déclarations de la direction. Les normes peuvent soutenir des contrôles cohérents mais n'établissent pas qu'une prévision commerciale est réalisable. L'assurance devrait être rattachée à l'allégation de la transaction plutôt que traitée comme un badge général.
Lorsque la cible s'appuie sur un organisateur de benchmark, l'acheteur devrait examiner les règles, les limites de soumission, la confidentialité des tests, la divulgation du matériel et les mécanismes d'audit. MLCommons et d'autres organismes de benchmark publient des règles pour des programmes spécifiques. La version et la catégorie applicables importent. Le rapport de due diligence devrait éviter de combiner des scores générés selon des règles différentes.
21. Évaluer la pertinence réglementaire et contractuelle
Les obligations d'évaluation de AI varient selon le rôle, la juridiction et l'usage. Les orientations de la Commission européenne sur les AI à usage général expliquent les attentes en matière de documentation et d'évaluation au titre du règlement AI, y compris des obligations supplémentaires pour les modèles présentant un risque systémique. Les orientations du gouvernement britannique décrivent l'assurance relative à AI comme un ensemble de mécanismes soutenant l'évaluation et la communication des risques. Les régulateurs sectoriels et les contrats clients peuvent imposer des exigences supplémentaires.
L'équipe chargée de la transaction devrait cartographier les rôles de fournisseur, déployeur, importateur et distributeur ; les usages prévus ; la pertinence en matière de risque élevé ou de sécurité ; et la portée géographique. Les résultats techniques devraient être liés à la documentation requise, à la surveillance, à la réponse aux incidents et à la supervision humaine. Un conseil qualifié devrait interpréter le droit applicable et les dates d'application.
Les contrats peuvent définir des tests d'acceptation, des niveaux de service, des droits d'audit, des contrôles des changements de modèle, des restrictions de données, des garanties et des recours. L'acheteur devrait comparer les tests de due diligence avec ces engagements. Un benchmark qui exclut les cas exacts couverts par une garantie client peut créer une exposition cachée même lorsque le score moyen est solide.
22. Tester la sécurité et les performances adverses
Un produit AI peut bien performer sur des cas ordinaires tout en restant vulnérable à l’injection de prompt, à l’empoisonnement des données, à l’extraction de modèle, à l’usage abusif d’outils, à des sorties non sécurisées ou à un déni de service. Les tests de sécurité doivent refléter l’architecture et le modèle de menace. Les orientations du National Cyber Security Centre britannique sur le développement sécurisé de AI et les ressources de gestion des risques de AI du NIST fournissent des points d’ancrage utiles pour les contrôles.
L’environnement de benchmark doit préserver les frontières du système. Un test de qualité de modèle en bac à sable n’établit pas la sécurité de la récupération, des plugins, des agents, des identifiants ou de l’infrastructure de déploiement. Les résultats de red team et de tests adversariaux doivent préciser le périmètre, l’accès, les critères de réussite, les mesures d’atténuation et le risque résiduel. La démonstration d’une attaque ne mesure pas toute l’exposition.
Les conséquences de la transaction peuvent inclure un coût de remédiation, un déploiement retardé, des notifications aux clients, des contraintes d’assurance, un manquement contractuel et des échanges avec les autorités de régulation. L’acheteur doit relier les constats importants au plan de closing, aux garanties, au séquestre, au budget d’investissement et au pouvoir opérationnel. Les preuves de sécurité doivent rester protégées et être partagées selon le principe du besoin d’en connaître.
23. Inspecter le code d’évaluation comme un logiciel critique pour la transaction
Le code d’évaluation peut modifier les résultats via l’analyse syntaxique, l’appariement des réponses, le traitement des délais d’expiration, la randomisation, le chargement des données et l’agrégation. Il doit faire l’objet d’une revue de code, de tests et d’un contrôle de version comparables à ceux des autres calculs critiques pour la transaction. Le réviseur doit exécuter des cas positifs et négatifs connus dans l’outil de notation et confirmer que les échecs sont correctement représentés.
Les dépendances peuvent introduire des dérives. Une mise à jour de bibliothèque peut modifier la tokenisation, le comportement numérique ou les paramètres par défaut. Le manifeste d’environnement doit inclure les versions des paquets et les détails de la plateforme. Les graines améliorent la traçabilité lorsque les systèmes prennent en charge le déterminisme, tandis que des exécutions répétées peuvent encore être nécessaires pour les sorties stochastiques.
Le code d’évaluation généré peut accélérer la création de tests mais doit être inspecté et validé. L’assistance machine peut détecter des éléments dupliqués, des libellés incohérents et des motifs de scores anormaux. Elle ne peut pas établir qu’une métrique représente la valeur pour le client. La responsabilité méthodologique reste du ressort de réviseurs qualifiés.
24. Rapprocher les preuves clients des preuves de benchmark
L’usage client, les renouvellements, les réclamations et les résultats réalisés constituent une couche de preuves différente. L’équipe doit comparer les strates de benchmark aux cohortes clients, aux flux de travail et aux dossiers de support. Une forte rétention client peut valider la valeur du produit malgré un score public modeste. Un benchmark de premier plan peut coexister avec une adoption limitée ou une charge élevée de travaux de services.
Les références et études de cas doivent être vérifiées. L’acheteur doit examiner les contrats, factures, journaux d’utilisation et mesures de résultats convenues, sous réserve des autorisations. Les entretiens clients doivent distinguer la capacité du produit de l’implication du fondateur, de l’ingénierie sur mesure et des concessions tarifaires. Une utilisation concentrée par quelques clients avertis peut ne pas se transposer à un marché plus large.
Le rapprochement doit identifier quelle métrique de benchmark prédit le renouvellement, l’expansion, le prix ou le coût. Une corrélation sur un petit échantillon historique ne constitue qu’une preuve limitée. La prévision doit préserver l’incertitude et surveiller la relation après la clôture. Lorsque les données de résultats clients contredisent le benchmark, l’équipe doit examiner la mesure, la population et le flux de travail avant de retenir une seule interprétation.
25. Identifier la dérive du benchmark entre la signature et la clôture
Les systèmes AI, les concurrents et les benchmarks publics peuvent changer pendant une transaction. La cible peut publier un nouveau modèle, changer de fournisseur tiers ou modifier la pile produits. Un jeu de test public peut devenir davantage exposé. L’accord doit définir les modifications autorisées dans le cours normal des activités, les obligations de notification, la conservation des preuves et les déclencheurs de nouveaux tests.
L’acheteur doit conserver la configuration signée et surveiller la configuration de production. Un meilleur score d’une nouvelle version n’élimine pas les risques de transition, de licence, de coût ou de fiabilité. Un score inférieur peut refléter un contrôle de sécurité ou un point de fonctionnement moins coûteux qui améliore la valeur totale. Les changements doivent être évalués sous l’angle de la qualité, du coût, de la sécurité, de la conformité et de l’impact client.
Les conditions de clôture peuvent porter sur des livrables, des accès ou des mesures de remédiation spécifiques plutôt que sur une promesse générale selon laquelle la technologie reste satisfaisante. Le caractère significatif et les recours exigent une rédaction juridique. Le cadre de due diligence fournit les preuves et les seuils nécessaires à ce travail.
26. Traduire l’écart de reproductibilité en valorisation
L’écart de reproductibilité est la différence entre le dossier économique revendiqué et le dossier étayé par des preuves contrôlées. Il peut résulter d’une qualité inférieure, d’un coût plus élevé, d’un déploiement plus lent, d’un usage adressable plus restreint, de mesures de remédiation supplémentaires ou d’une durabilité moindre. Le pont de valorisation devrait identifier chaque mécanisme plutôt que d’appliquer une décote arbitraire.
Le chiffre d’affaires peut évoluer en fonction de la conversion, de la rétention, du prix et de la population de clients éligibles. La marge peut évoluer en fonction de l’inférence, de la revue, du support et de l’infrastructure. Les besoins en capital peuvent évoluer en fonction de la remédiation, de l’acquisition de données et du déploiement. Le calendrier affecte la valeur actuelle et le financement. Les plages de scénarios doivent éviter de compter deux fois un même écart de preuve sur plusieurs lignes.
L’acheteur peut préserver la valeur d’option stratégique séparément de la valeur souscrite. Une capacité prometteuse peut justifier la poursuite d’un investissement sans pour autant soutenir le même prix d’achat qu’un résultat de production reproduit. Le conseil d’administration devrait voir les deux catégories et les jalons susceptibles de convertir la valeur d’option en valeur souscrite.
27. Répartir le risque au moyen des conditions de la transaction
Les clauses peuvent répondre à des éléments de preuve qui ne peuvent pas être résolus avant la signature. La contrepartie conditionnelle peut lier le paiement à des résultats clients, de performance ou de marge mesurés de manière indépendante. Les garanties peuvent porter sur l’exactitude des dossiers de référence divulgués, l’exhaustivité des artefacts ou l’absence d’intervention manuelle non divulguée. Les covenants peuvent préserver les systèmes et exiger un accès pour les tests.
Les indicateurs destinés à un usage contractuel doivent être précis. L’accord devrait identifier le système, la population, l’administrateur de test, l’environnement, le calcul, l’incertitude, les exceptions, le contrôle des changements et le processus de règlement des litiges. Un rang dans un classement public est souvent trop variable pour un earn-out. Les résultats opérationnels tels que l’utilisation payante, le renouvellement ou la marge brute peuvent être plus durables, même s’ils introduisent d’autres dépendances.
Les recours doivent être proportionnés et exécutoires. Les conseils juridiques, fiscaux et comptables devraient évaluer le traitement. L’équipe technique devrait fournir des faits et des méthodes reproductibles sans rédiger au-delà de son domaine d’expertise.
28. Protéger le dossier de financement
Les prêteurs et les comités de crédit peuvent se fonder sur des prévisions de chiffre d’affaires, de marge, de flux de trésorerie et de dépenses d’investissement influencées par les affirmations AI. Le modèle de financement devrait utiliser le dossier étayé par des preuves et tester une reproduction retardée ou échouée, une perte de clients, des mesures de remédiation, des variations de prix des fournisseurs et des besoins de calcul supplémentaires. La capacité d’endettement devrait rester distincte du potentiel stratégique.
Les engagements d’information peuvent exiger la publication de rapports sur des modifications importantes du modèle, des défaillances de service, des événements réglementaires et la concentration de la clientèle. Les dispositifs de sûretés et les covenants compensent rarement une thèse produit qui n’a pas été étayée. L’acheteur devrait évaluer la liquidité sur la période nécessaire pour valider et remédier au système.
Un benchmark solide peut renforcer la confiance mais ne génère pas de trésorerie à lui seul. Le dossier de crédit devrait rapprocher les résultats des tests du chiffre d’affaires contractuel, des encaissements, de la marge brute, du besoin en fonds de roulement et des investissements. Cela protège à la fois la transaction et l’entreprise acquise contre un plan opérationnel qui suppose une conversion immédiate du laboratoire au marché.
29. Exemple pratique : une acquisition hypothétique d’un workflow AI
Supposons qu’un acheteur hypothétique évalue une société de workflow documentaire AI. La direction indique un score de 92 sur un ensemble de tâches public, une latence médiane de deux secondes et une marge brute de 78 %. Les prévisions supposent une expansion auprès des entreprises fondée sur un leadership en matière de qualité. Ces chiffres sont des hypothèses illustratives et ne décrivent ni une société ni une transaction.
Le graphe de preuves identifie une bibliothèque de prompts non divulguée, une partition de test modifiée et l'exclusion des cas ayant dépassé le délai. Une reproduction contrôlée donne un score illustratif de 87. Un nouvel ensemble aveugle représentatif de documents clients atteint 81, avec des performances plus faibles sur les entrées longues et multilingues. La prise en compte des nouvelles tentatives, de la revue humaine et de l'inférence allouée réduit la marge brute illustrative à 66 % au volume prévisionnel.
L'acquéreur ne considère pas le résultat comme une remise unique. Il reconstruit les revenus éligibles, la rétention, la capacité de support, les capacités de calcul et la remédiation. Dans un scénario illustratif, la valeur autonome étayée par les preuves est inférieure de 18 % au scénario initial. Les parties pourraient répondre par le prix, une contrepartie conditionnelle liée aux résultats de production payants, un covenant de remédiation et un support technique conservé. Le traitement effectif dépendrait des preuves, de la négociation et de conseils professionnels.

Le traitement de la transaction se renforce à mesure que l'importance commerciale et la faiblesse des preuves augmentent.
Tableau 5. Réponse de la transaction aux preuves de référence
| Constat | Mécanisme de valeur | Réponse possible en due diligence | Réponse transactionnelle possible |
|---|---|---|---|
| score non reproductible | différenciation ou demande plus faibles | réexécution verrouillée et nouvel ensemble aveugle | pont de prix ou valeur conditionnelle |
| contamination | généralisation exagérée | supprimer les chevauchements et créer un nouvel ensemble | garantie, covenant ou retenue |
| dégradation de la production | adoption plus faible ou performance contractuelle dégradée | test en parallèle et tests par cohorte | paiement lié à un jalon ou mesures correctives |
| coût plus élevé | marge brute et trésorerie plus faibles | frontière qualité-coût et test de charge | ajustement de valorisation ou réserve de financement |
| artefacts manquants | capacité incertaine et transfert | récupération de preuves et condition d’accès | condition de closing ou répartition des risques |
| dépendance fragile vis-à-vis de tiers | durabilité et contrôle plus faibles | test de licence, de substitution et de transition | obligation de consentement, de covenant ou de soutien |
La réponse doit traiter le mécanisme par lequel l’écart affecte la valeur.
30. Transférer les éléments de preuve dans le plan d’intégration
Le registre des benchmarks doit survivre à la clôture. Les responsables de l’intégration ont besoin du système figé, des écarts non résolus, des actions correctives, des suites de tests représentatives des clients, du modèle de coûts, des seuils de surveillance et de l’autorité pour les modifications de modèle. La répétition du test de due diligence après les changements assure la continuité entre la valorisation et les opérations.
Les cent premiers jours peuvent prioriser les écarts de preuve significatifs et les dépendances. Les travaux peuvent inclure la sécurisation des droits sur les données, le renforcement de l’infrastructure d’évaluation, la réduction de la revue humaine, la négociation des conditions des fournisseurs, l’amélioration des performances en contexte long ou la mise en place d’une mesure des résultats clients. Chaque action doit être liée au dossier de transaction et au budget.
L’acheteur doit éviter de transformer un benchmark de due diligence en objectif produit permanent sans réexamen. Les marchés, les systèmes et les besoins des clients évoluent. L’actif durable est un processus d’évaluation gouverné capable de mettre à jour les tests tout en préservant la traçabilité et l’historique des décisions.
31. Surveiller la dérive post-clôture sans réécrire la base de référence
Le reporting post-clôture doit comparer les performances réelles au dossier de preuves signé. L’équipe peut actualiser les prévisions tout en conservant le benchmark d’origine, les hypothèses et le traitement de la transaction. Cela évite qu’un rebasage favorable masque si la thèse d’investissement a été réalisée.
La surveillance peut inclure les changements de distribution des données, la qualité par cohorte, les événements de sécurité, la latence, le coût, la revue humaine, les résultats clients et les modifications de modèle ou de fournisseur. Les seuils doivent déclencher une investigation et des décisions responsables. Les alertes statistiques nécessitent une interprétation opérationnelle ; de faibles fluctuations peuvent être du bruit, tandis que des moyennes stables peuvent masquer une détérioration par cohorte.
Les différences observées doivent améliorer la due diligence future. L’acheteur peut consigner quels tests préalables à la signature ont prédit la production, quels écarts ont eu un impact financier et quels contrôles ont réduit l’incertitude. Les informations sensibles doivent rester gouvernées et anonymisées le cas échéant.
32. Adapter la méthode aux secteurs réglementés et à forts enjeux
Les services financiers, la santé, l’énergie, les infrastructures et les usages du secteur public peuvent nécessiter des populations propres au secteur, des coûts d’erreur, une explicabilité, une supervision humaine, une résilience et une documentation. Un benchmark général doit être complété par des tests reflétant les décisions et les utilisateurs concernés. Des spécialistes qualifiés doivent définir les exigences réglementaires et professionnelles.
Dans le crédit ou l’assurance, la prévalence des classes, l’équité, les résultats défavorables et les modifications de modèle peuvent compter. Dans la santé, la pertinence clinique, la variation entre sites et les facteurs humains peuvent prédominer. Dans les systèmes industriels, la dérive des capteurs, les conditions environnementales et un repli sûr peuvent compter davantage qu’un score de précision public. Dans les flux de travail juridiques ou de conformité, la validité des citations, la confidentialité et la charge de revue peuvent déterminer la valeur.
Le cadre commun demeure : identifier l'allégation, préserver les artefacts, définir la population, reproduire le résultat, tester les conditions de production et relier les éléments de preuve au traitement de la transaction. L'adaptation sectorielle modifie les tests et les conséquences, pas la nécessité de la traçabilité.
33. Protéger la confidentialité, la vie privée et la propriété intellectuelle
La due diligence de benchmark peut exposer les poids de modèle, le code, les données clients, les secrets commerciaux et les informations de sécurité. Le protocole de clean team doit définir les utilisateurs autorisés, les environnements, les transferts, les sorties, la conservation et la destruction. Des données synthétiques ou désidentifiées peuvent réduire l'exposition, tout en pouvant modifier la population et devant être validées.
La cible doit démontrer ses droits sur les jeux de données, les étiquettes, le contenu de benchmark et les outils d'évaluation. Les licences ouvertes peuvent contenir des conditions d'attribution, de redistribution ou d'utilisation. Les contrats clients peuvent restreindre les tests secondaires ou le transfert en cas de changement de contrôle. Le conseil juridique doit évaluer les droits et recours spécifiques.
L'acheteur doit également protéger sa propre conception de test et ses seuils stratégiques. La divulgation d'un ensemble séquestré peut détruire de la valeur future. L'exécution contrôlée, les journaux d'audit et l'accès cloisonné aident à préserver l'intégrité sans empêcher un examen approprié par le vendeur ni la résolution des litiges.
34. Encadrer l'assistance machine dans le processus de due diligence
L'assistance machine peut inventorier les artefacts, comparer les versions, détecter les chevauchements possibles, regrouper les erreurs, générer des variantes de test, exécuter les harnais et préparer l'analyse de sensibilité. Chaque sortie doit conserver les liens vers les sources, les versions de code et les décisions des évaluateurs. L'automatisation est surtout utile lorsqu'elle améliore la couverture et la traçabilité.
Le système de due diligence lui-même peut introduire des erreurs. Les éléments de test générés peuvent être ambigus, les étiquettes synthétiques peuvent être erronées, la correspondance sémantique peut surestimer la contamination et la notation automatisée peut mal interpréter des sorties valides. Des ensembles de validation, une revue humaine et des journaux d'exceptions sont nécessaires. Les décisions importantes ne doivent pas dépendre d'un agrégat opaque produit par un outil non testé.
Les contrôles d'accès et de confidentialité s'appliquent aux modèles d'assistance. L'envoi de code cible ou de dossiers clients à un service externe peut enfreindre des obligations. L'équipe doit utiliser des environnements approuvés et consigner les fournisseurs, les paramètres de conservation et les flux de données. Les réviseurs sécurité et juridiques doivent approuver les usages sensibles.
35. Construire le dossier de décision du conseil autour des lacunes de preuve
Le dossier du conseil doit présenter le résultat annoncé, le résultat reproduit, le pont vers la production, l'incertitude, le lien commercial et les limites non résolues. Il doit identifier dans quelle mesure le chiffre d'affaires prévisionnel, la marge et la valeur dépendent de chaque allégation importante. Une carte thermique concise peut relier la faiblesse des preuves et l'exposition financière à la décision proposée.
Les questions doivent notamment porter sur les points suivants : le système testé est-il transférable, les données correspondent-elles à l'usage contractuel, la contamination a-t-elle été circonscrite, des alternatives ont-elles été testées, l'économie unitaire inclut-elle l'ensemble du travail, et le dossier de financement résiste-t-il à un scénario défavorable. Les réponses doivent renvoyer à des artefacts préservés plutôt qu'à des assurances non étayées.
L'approbation doit indiquer quelles allégations soutiennent le prix, lesquelles restent facultatives, quelles clauses répartissent le risque, ce qui doit se produire avant la clôture et qui est responsable de la validation post-clôture. Toute nouvelle information doit déclencher une nouvelle approbation lorsqu'elle franchit les seuils convenus.
36. Mettre en œuvre un protocole reproductible de due diligence de benchmark
Un protocole reproductible comporte six étapes : réception des allégations, graphe de preuves, gel des artefacts, tests préenregistrés, pont commercial et décision de transaction. Chaque étape a un responsable désigné, une date limite de preuve, un processus d'exception et un livrable. L'équipe de transaction peut adapter la profondeur selon l'importance relative tout en conservant la même structure de contrôle.
Les mesures de processus peuvent inclure des affirmations retracées jusqu'aux éléments probants bruts, des artefacts manquants à la réception, des constats de fuite, des écarts de scores reproduits, des facteurs d'écart de production, des exceptions après verrouillage, le temps écoulé et des hypothèses de valeur modifiées. Ces mesures indiquent la qualité et la charge de travail de la due diligence. Elles ne prouvent pas qu'un test a causé le résultat d'une transaction.
L'adoption peut commencer par les quelques affirmations qui génèrent le plus de valeur. Un acheteur peut figer le système revendiqué, reproduire un test déterminant, exécuter un ensemble aveugle représentatif et reconstruire l'économie unitaire avant d'investir dans une plateforme étendue. La capacité institutionnelle se développe grâce à des protocoles conservés, des suites de tests, des évaluateurs et des retours post-clôture. Le résultat est un parcours plus rapide de l'affirmation technique à une décision de prix, de contrat et d'intégration dont on peut rendre compte.
Le protocole doit également définir une règle d'arrêt. Des tests supplémentaires ont de la valeur lorsqu'ils peuvent modifier le prix, l'allocation des risques, le financement, l'état de préparation à la clôture ou le budget d'intégration. Les tests peuvent s'arrêter lorsque la décision déterminante est étayée dans la limite de l'incertitude convenue, ou lorsque l'incertitude restante est allouée plus efficacement au moyen de clauses et de contrôles post-clôture. Le responsable de la due diligence doit documenter ce jugement, les éléments de preuve encore manquants et la personne qui accepte l'exposition résiduelle. Cela évite que des travaux techniques sans limite retardent une transaction sans améliorer la décision.
La répétabilité dépend aussi du maintien d'une bibliothèque de benchmarks contrôlée. Les ensembles de tests doivent être associés à des responsables, des usages prévus, des classifications d'accès, un historique d'exposition, des dates d'actualisation et des règles de retrait. Les éléments publics peuvent rester utiles pour la comparabilité, tandis que des ensembles nouveaux et représentatifs de clients fournissent des preuves plus solides de transférabilité. La bibliothèque doit consigner quels systèmes ont vu chaque élément afin que les équipes futures ne confondent pas un test exposé avec un test aveugle. Cette discipline opérationnelle protège la valeur des actifs d'évaluation au fil des transactions.
Conclusion
La due diligence des benchmarks AI doit considérer un score déclaré comme le début d'un processus de preuve. Une affirmation exploitable pour décider rattache un système identifié, une population appropriée, un protocole contrôlé, une métrique recalculable et une incertitude à une hypothèse commerciale. Les fuites, la sélection, les conditions d'exécution et l'économie de production doivent rester visibles.
La reproduction contrôlée peut établir si le résultat déclaré résiste à la méthode divulguée. Des tests aveugles nouveaux et une évaluation proche de la production peuvent fournir des preuves plus solides de généralisation et de valeur pour le client. Ni l'un ni l'autre n'élimine l'incertitude au-delà des conditions échantillonnées. Le conseil doit voir l'écart restant et le mécanisme par lequel il affecte le chiffre d'affaires, la marge, le capital, le calendrier et le risque.
Un graphe de preuves de benchmarks, un protocole préenregistré et un pont vers la production donnent aux équipes de transaction une méthode reproductible. Ils permettent aussi aux parties d'allouer le risque non résolu au moyen du prix, de la valeur conditionnelle, des garanties, des conditions, du financement et des actions d'intégration. L'assistance machine peut améliorer la couverture et la rapidité dans ce processus gouverné.
L'objectif est un dossier d'acquisition qui peut être reconstitué de l'affirmation jusqu'à la trésorerie. Cette discipline favorise une valorisation, un financement et une responsabilité post-clôture plus crédibles dans les transactions où la performance AI constitue une part importante de la valeur.
Références
- National Institute of Standards and Technology. Cadre de gestion des risques AI. https://www.nist.gov/itl/ai-risk-management-framework
- National Institute of Standards and Technology. Cadre de gestion des risques liés à l'intelligence artificielle : profil pour l'intelligence artificielle générative, NIST AI 600-1. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
- National Institute of Standards and Technology. Guide pratique AI RMF. https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook
- National Institute of Standards and Technology. Aperçu de l'évaluation de la technologie AI. https://pages.nist.gov/ai-technology-evaluation/
- National Institute of Standards and Technology. Vers les meilleures pratiques pour les évaluations automatisées de benchmarks. https://www.nist.gov/news-events/news/2026/01/towards-best-practices-automated-benchmark-evaluations
- National Institute of Standards and Technology. Élargir la boîte à outils d'évaluation AI avec des modèles statistiques, NIST AI 800-3. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.800-3.pdf
- National Institute of Standards and Technology. Évaluer les risques et les impacts de AI, document d'accompagnement du programme ARIA. https://ai-challenges.nist.gov/aria/docs/ARIA_Program_Companion_Document_Dec20.pdf
- Gouvernement du Royaume-Uni. Introduction à l’assurance de l’AI. https://www.gov.uk/government/publications/introduction-to-ai-assurance/introduction-to-ai-assurance
- Gouvernement du Royaume-Uni. Portefeuille de techniques d’assurance de l’AI. https://www.gov.uk/guidance/portfolio-of-ai-assurance-techniques
- Gouvernement du Royaume-Uni. Boîte à outils pour une AI responsable. https://www.gov.uk/government/collections/responsible-ai-toolkit
- Centre national de cybersécurité du Royaume-Uni. Lignes directrices pour le développement sécurisé de systèmes AI. https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development
- Commission européenne. Obligations relatives à l’AI à usage général au titre de la loi sur l’AI. https://digital-strategy.ec.europa.eu/en/factpages/general-purpose-ai-obligations-under-ai-act
- Commission européenne. Lignes directrices sur les obligations des fournisseurs d’AI à usage général. https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers
- Commission européenne. Lignes directrices sur le champ des obligations des fournisseurs de modèles AI à usage général. https://digital-strategy.ec.europa.eu/en/library/guidelines-scope-obligations-providers-general-purpose-ai-models-under-ai-act
- Commission européenne. Code de pratique pour l’AI à usage général. https://digital-strategy.ec.europa.eu/en/policies/contents-code-gpai
- Union européenne. Règlement (UE) 2024/1689 établissant des règles harmonisées en matière d’intelligence artificielle. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Banque centrale de UAE. Note d'orientation sur la protection des consommateurs et l'adoption et l'utilisation responsables de l'intelligence artificielle. https://rulebook.centralbank.ae/en/rulebook/guidance-note-consumer-protection-and-responsible-adoption-and-use-artificial-intelligence
- Organisation de coopération et de développement économiques. Principes de l'OCDE AI. https://oecd.ai/en/ai-principles
- Organisation internationale de normalisation. ISO/IEC 42001 — Système de management de l'intelligence artificielle. https://www.iso.org/standard/81230.html
- Organisation internationale de normalisation. ISO/IEC 23894 — Lignes directrices sur la gestion des risques liés à l'intelligence artificielle. https://www.iso.org/standard/77304.html
- MLCommons. Politiques et résultats MLPerf. https://mlcommons.org/benchmarks/
- Autorité de la concurrence et des marchés. Lignes directrices pour l'évaluation des fusions. https://www.gov.uk/government/publications/merger-assessment-guidelines
- Département de la Justice des États-Unis et Commission fédérale du commerce. Lignes directrices sur les fusions de 2023. https://www.justice.gov/atr/2023-merger-guidelines
- Fondation IFRS. IFRS 3 Regroupements d'entreprises. https://www.ifrs.org/issued-standards/list-of-standards/ifrs-3-business-combinations/
- Public Company Accounting Oversight Board. AS 2501 : Audit des estimations comptables, y compris les évaluations à la juste valeur. https://pcaobus.org/oversight/standards/auditing-standards/details/AS2501

