Model Card

Une model card est un document standardisé qui accompagne un modèle de machine learning pour décrire ses caractéristiques, ses cas d’usage prévus, ses performances, ses biais connus et ses limitations. C’est l’équivalent d’une « étiquette nutritionnelle » pour l’IA : un résumé structuré qui permet à toute personne (développeur, manager, régulateur, utilisateur final) de comprendre rapidement ce que fait le modèle, comment il a été construit, et dans quelles conditions il est fiable ou non.

Origine: Proposé par Google en 2018 (Mitchell et al., conférence FAccT 2019)
Type: Document de documentation ML (format Markdown, JSON ou PDF)
Objectif: Transparence, gouvernance et documentation responsable des modèles
Sections clés: Model Details, Intended Use, Performance, Bias/Risks/Limitations, Ethical Considerations
Adopté par: Hugging Face, Google DeepMind, Meta, OpenAI, Amazon SageMaker, Microsoft
Standard légal: Pas de norme formelle, mais aligné avec les exigences EU AI Act (août 2026)
Plateforme de référence: Hugging Face Hub (2M+ modèles avec model cards)

Origine et contexte

Le concept de model card a été proposé par Margaret Mitchell (alors chez Google) et ses co-auteurs dans l’article « Model Cards for Model Reporting », présenté à la conférence ACM FAccT (Fairness, Accountability, and Transparency) en 2019. L’idée part d’un constat simple : les modèles de machine learning sont de plus en plus utilisés dans des domaines à fort impact (santé, finance, justice, recrutement), mais leur documentation est quasi inexistante ou inconsistante.

L’article propose un cadre standardisé pour documenter les modèles, en s’inspirant des « datasheets » utilisées en électronique. Les deux exemples originaux concernaient un modèle de détection de sourires dans les images et un modèle de détection de commentaires toxiques (Perspective API de Jigsaw). Ces exemples montraient comment la performance d’un modèle peut varier drastiquement selon les sous-groupes de population, le contexte d’utilisation ou les caractéristiques des données.

Depuis 2018, le paysage de la documentation ML a considérablement évolué. Les model cards sont devenues une pratique standard dans l’industrie, adoptées par les principaux labs d’IA et plateformes de distribution de modèles. Elles s’inscrivent dans un écosystème plus large qui inclut aussi les « Datasheets for Datasets » (proposés par Timnit Gebru et al.) et les System Cards pour les systèmes IA complets.

Contenu d’une model card

Le cadre original de Google propose neuf sections, bien que les organisations puissent adapter cette structure selon leurs besoins. Voici les sections les plus courantes :

Model Details (Détails du modèle)

Cette section fournit les informations de base : nom du modèle, version, architecture, nombre de paramètres, date de publication, auteurs, licence, et liens vers le code source ou le paper de recherche. C’est l’identification du modèle. Elle ne contient pas nécessairement d’informations sensibles que l’organisation ne souhaite pas partager, mais doit communiquer les informations essentielles.

Intended Use (Usage prévu)

C’est l’une des sections les plus importantes. Elle décrit les cas d’usage pour lesquels le modèle a été conçu, les tâches qu’il est censé accomplir, le public cible, et les scénarios où il ne devrait pas être utilisé (« Out of Scope Use »). Par exemple, un modèle de classification d’images médicales pourrait être prévu pour assister des radiologistes formés, mais pas pour un diagnostic autonome sans supervision humaine.

Training Data (Données d’entraînement)

Description des données utilisées pour entraîner le modèle : sources, taille, distribution, langues, filtres appliqués, processus de nettoyage. Cette section est essentielle pour comprendre les biais potentiels : un modèle entraîné principalement sur des données anglophones performera moins bien sur d’autres langues.

Evaluation (Évaluation)

Résultats de performance sur des benchmarks standards et des tests spécifiques. Idéalement, l’évaluation est désagrégée par facteurs pertinents : sous-groupes démographiques, domaines, tâches, conditions d’utilisation. Les métriques utilisées (accuracy, F1, BLEU, etc.) doivent être expliquées et contextualisées. La section Community Evals du Hugging Face Hub, lancée en bêta en février 2026, automatise la collecte de ces résultats directement sur les pages modèles.

Bias, Risks, and Limitations (Biais, risques et limitations)

Probablement la section la plus critique. Elle documente les biais connus du modèle, les risques associés à son utilisation, et ses limitations techniques. Un modèle de NLP peut être biaisé selon le genre, l’ethnie ou l’âge en raison de déséquilibres dans les données d’entraînement. Un modèle de vision peut être moins performant sur certaines carnations de peau. Cette section doit être honnête : mieux vaut documenter un biais connu que de le découvrir en production.

Ethical Considerations (Considérations éthiques)

Réflexions sur l’impact sociétal du modèle, les populations potentiellement affectées, les mesures d’atténuation mises en place, et les questions ouvertes. Certaines model cards incluent aussi l’empreinte carbone du modèle (CO2 émis pendant l’entraînement), une pratique encouragée par Hugging Face.

Model card vs Data card La model card documente le modèle, la data card (ou datasheet) documente le dataset. Les deux sont complémentaires : la model card ne contient pas d’informations détaillées sur les données, elle renvoie vers la data card correspondante. Sur le Hugging Face Hub, les deux formats sont supportés sous le terme générique de « Repository Cards ».

Adoption dans l’industrie

Hugging Face Hub

Le Hugging Face Hub est la plateforme qui a le plus contribué à démocratiser les model cards. Chaque modèle hébergé sur le Hub dispose d’un fichier README.md qui sert de model card, avec une section YAML en haut contenant les métadonnées structurées (licence, tâche, langue, métriques, etc.).

Hugging Face a publié en 2022 un Model Card Guidebook complet, incluant un template annoté, un outil de création graphique (Model Card Creator Tool), et une étude utilisateur. Le template couvre les sections classiques et ajoute un accent particulier sur la section « Bias, Risks and Limitations ». La bibliothèque huggingface_hub en Python permet de créer et valider des model cards programmatiquement via Jinja2.

En pratique, la qualité des model cards sur le Hub varie considérablement. Les modèles publiés par les grands labs (Meta, Mistral, Google) ont généralement des model cards détaillées, tandis que beaucoup de modèles communautaires ont des model cards minimales ou vides. Hugging Face encourage la complétion via des prompts par défaut et des interfaces visuelles.

Google DeepMind

Google DeepMind maintient un site dédié (modelcards.withgoogle.com) présentant des model cards pour ses modèles publics. Ces fiches fournissent des aperçus structurés de la conception et de l’évaluation de chaque modèle. Google a été le pionnier du concept et reste l’un des acteurs les plus rigoureux dans leur mise en oeuvre.

Amazon SageMaker Model Cards

Amazon a intégré les model cards directement dans Amazon SageMaker comme fonctionnalité de gouvernance ML. SageMaker Model Cards permet de documenter les détails critiques d’un modèle (usage prévu, évaluation des risques, métriques, considérations éthiques) et de les associer au Model Registry pour un suivi versionné.

Les model cards SageMaker suivent un schéma JSON prescriptif, supportent l’import automatique des rapports d’évaluation de SageMaker Clarify et Model Monitor, et peuvent être exportées en PDF. Chaque modification (hors statut d’approbation) génère une nouvelle version immuable, garantissant la traçabilité. Les statuts possibles sont : Draft, PendingReview, Approved, Archived. La fonctionnalité cross-account permet de partager les model cards entre environnements (développement, staging, production) via AWS RAM.

Autres acteurs majeurs

Meta et Microsoft ont publié conjointement la model card de Llama 2 dans l’annexe de leur paper de recherche, incluant les détails du modèle, l’usage prévu, le hardware/software, les données d’entraînement, les résultats d’évaluation, les considérations éthiques, et l’empreinte carbone. OpenAI a publié des model cards pour GPT-3 et les modèles suivants, avec des sections dédiées aux biais et aux feedback loops.

Model cards et régulation

Le lien entre model cards et obligations réglementaires se renforce considérablement. L’EU AI Act (Règlement UE 2024/1689), dont les obligations de transparence entreront pleinement en vigueur le 2 août 2026, impose des exigences qui s’alignent naturellement avec le contenu des model cards.

L’Article 13 de l’EU AI Act exige que les systèmes IA à haut risque soient conçus pour être suffisamment transparents, accompagnés d’instructions claires incluant les capacités, limitations, risques potentiels et conditions d’utilisation. L’Article 50 impose des obligations de transparence pour les systèmes d’IA générative : marquage machine-readable des contenus générés, identification des deepfakes, et disclosure de l’utilisation de l’IA.

L’Annexe XI impose une documentation technique pour les fournisseurs de modèles GPAI (General-Purpose AI), et l’Annexe XII exige des informations de transparence pour les fournisseurs en aval qui intègrent ces modèles. Les amendes pour non-conformité peuvent atteindre 15 millions d’euros ou 3% du chiffre d’affaires mondial pour les obligations de transparence, et jusqu’à 35 millions d’euros ou 7% pour les violations les plus graves.

Pas encore un standard formel Malgré l’adoption croissante, il n’existe pas de standard législatif ou réglementaire formel pour le format ou le contenu des model cards. L’EU AI Act impose des obligations de transparence et de documentation, mais ne prescrit pas le format « model card » comme tel. En pratique, les model cards sont devenues le véhicule de facto pour satisfaire ces obligations, mais chaque organisation peut adapter le format à ses besoins.

Comment créer une model card efficace

Créer une bonne model card n’est pas qu’un exercice de documentation. C’est un processus qui implique plusieurs rôles :

Le développeur est essentiel pour les sections techniques : procédure d’entraînement, spécifications techniques, résultats d’évaluation, et la partie « Limitations » des biais et risques. Il fournit les données brutes sur la performance du modèle.

Le sociotechnicien (ou responsable éthique) est nécessaire pour les sections « Bias » et « Risks », et particulièrement utile pour les usages hors périmètre. C’est le regard critique sur les impacts sociétaux du modèle.

Le chef de projet est nécessaire pour les sections Model Details et Uses. Il fournit le contexte business et la vision produit. Il peut aussi gérer la citation, le glossaire et les contacts.

En termes d’outils, plusieurs options existent :

Sur Hugging Face : utilisez le Model Card Creator Tool (interface graphique) ou créez le fichier README.md manuellement avec le template annoté. La classe ModelCard de la bibliothèque huggingface_hub permet de créer des model cards programmatiquement :

from huggingface_hub import ModelCard, ModelCardData

card_data = ModelCardData(
    language="fr",
    license="apache-2.0",
    library_name="transformers",
    model_name="mon-modele-classification"
)
card = ModelCard.from_template(
    card_data,
    model_id="user/mon-modele-classification",
    model_description="Classifieur de sentiments pour le français"
)
card.push_to_hub("user/mon-modele-classification")

Sur AWS SageMaker : créez via la console SageMaker (section Governance > Model Cards) ou le SDK Python. Les rapports d’évaluation de Clarify et Model Monitor sont automatiquement importables.

Outils tiers : des plateformes comme FairNow, Trail ML, ou le Model Card Generator (interface Gradio sur Hugging Face) automatisent la création et le suivi des model cards, avec export en JSON, HTML ou Markdown.

Bonnes pratiques

Voici les principes fondamentaux pour une model card utile :

Être honnête sur les limitations. Une model card qui ne mentionne aucun biais ou limitation n’est pas crédible. Tout modèle a des failles. Les documenter protège à la fois l’utilisateur et le fournisseur.

Écrire pour votre audience. La model card doit communiquer les informations les plus importantes à des audiences techniques et non-techniques. Évitez le jargon excessif, expliquez les termes techniques, utilisez des visualisations pour les métriques de performance.

Désagréger les résultats. Ne donnez pas qu’un score global. Montrez la performance par sous-groupe (genre, âge, langue, domaine). C’est souvent dans les sous-groupes que les biais se révèlent.

Mettre à jour régulièrement. Une model card statique perd sa valeur quand le modèle évolue. Automatisez la mise à jour quand c’est possible, utilisez le versionning (Git sur Hugging Face, immutable versions sur SageMaker).

Intégrer dans le pipeline. La model card ne devrait pas être un document rempli après coup. Intégrez sa création dans votre pipeline CI/CD et vos processus MLOps. C’est un artefact vivant, pas une formalité administrative.

Défis et limites des model cards

Malgré leur adoption croissante, les model cards font face à plusieurs défis structurels.

Absence de standard universel. Chaque organisation a sa propre idée de ce qui constitue une model card « complète ». Cette inconsistance rend difficile la comparaison entre modèles de fournisseurs différents. Le template Hugging Face, le schéma JSON SageMaker et le format Google couvrent des périmètres similaires mais avec des structures et des niveaux de détail différents.

Qualité variable. Sur le Hugging Face Hub, avec plus de 2 millions de modèles, la majorité des model cards sont incomplètes. Beaucoup contiennent uniquement les métadonnées YAML automatiquement générées, sans aucune description humaine des cas d’usage, des biais ou des limitations. Le problème inverse existe aussi : certaines model cards reprennent des formulations génériques (« More information needed ») sans fournir de substance.

Scalabilité. Créer manuellement des model cards détaillées pour chaque modèle n’est pas tenable dans les organisations qui entraînent des centaines de modèles. L’automatisation aide, mais les sections qualitatives (éthique, biais, usages hors périmètre) résistent à l’automatisation complète. Les plateformes de gouvernance IA tentent de résoudre ce problème en extrayant automatiquement les métadonnées techniques et en guidant les humains sur les sections qualitatives.

Vérifiabilité. Une model card est une déclaration du fournisseur, pas un audit indépendant. Rien ne garantit que les informations sont complètes ou exactes. Le système Community Evals de Hugging Face (bêta, février 2026) tente d’adresser ce problème en permettant à la communauté de soumettre des résultats d’évaluation indépendants via pull requests, avec versionning Git pour la traçabilité.

Questions fréquentes

Une model card est-elle obligatoire ?

Pas au sens légal strict : aucune législation n’impose le format « model card » comme tel. Cependant, l’EU AI Act (applicable août 2026) impose des obligations de transparence et de documentation technique pour les systèmes IA à haut risque et les modèles GPAI, dont le contenu s’aligne directement avec celui d’une model card. En pratique, les model cards sont devenues le standard de facto pour satisfaire ces obligations. Sur le Hugging Face Hub, elles sont fortement encouragées et constituent la première chose que les utilisateurs consultent avant de télécharger un modèle.

Quelle est la différence entre model card et system card ?

La model card documente un modèle de machine learning individuel (architecture, données, performances, biais). La system card documente un système IA complet, qui peut intégrer plusieurs modèles, des interfaces utilisateur, des pipelines de traitement et des mécanismes de sécurité. Par exemple, OpenAI publie des system cards pour ChatGPT qui couvrent l’ensemble de la chaîne, pas seulement le modèle GPT sous-jacent.

Qui doit rédiger la model card ?

C’est un effort collaboratif. Les développeurs fournissent les détails techniques (architecture, entraînement, métriques). Les responsables éthiques ou sociotechniciens documentent les biais, risques et impacts sociétaux. Les chefs de projet définissent les cas d’usage et le contexte business. Hugging Face propose un Model Card Creator Tool avec une interface graphique qui facilite cette collaboration en permettant à différents rôles de remplir les sections qui les concernent.

Où trouver des exemples de model cards ?

Les meilleures references sont les model cards des grands labs sur le Hugging Face Hub : Llama de Meta, Mistral de Mistral AI, les modèles BERT de Google. Google maintient aussi un site dédié (modelcards.withgoogle.com). Le Annotated Model Card Template de Hugging Face détaille comment remplir chaque section avec des instructions précises.

Les model cards peuvent-elles être générées automatiquement ?

Partiellement. Les métadonnées techniques (architecture, taille, licence, métriques de benchmark) peuvent être extraites automatiquement du modèle et de son pipeline d’entraînement. Amazon SageMaker import automatiquement les rapports Clarify et Model Monitor. Mais les sections qualitatives (usage prévu, biais connus, considérations éthiques) nécessitent un jugement humain et ne devraient pas être entièrement automatisées. L’automatisation accélère le processus, le jugement humain garantit la pertinence.