Model card IA : de Hugging Face à la preuve AI Act

Une model card IA est un document court et structuré qui accompagne un modèle d’IA entraîné : à quoi il sert, comment il a été entraîné et testé, où il échoue. Des chercheurs de Google en ont proposé le format en 2018-2019 ; Hugging Face en a fait le README.md de chaque dépôt de modèle. Depuis le 2 août 2025, l’AI Act demande aux fournisseurs de modèles une documentation qui lui ressemble, plus longue et exigible ; à partir du 2 décembre 2027, les fournisseurs de systèmes à haut risque devront un dossier technique qu’elle ne fait qu’amorcer. Ce guide lit la model card comme le ferait un auditeur ou une autorité de surveillance du marché : ce qu’elle contient, ce qui lui manque, quelle loi peut l’exiger, comment en faire une preuve.

L’essentiel

• Une model card est un format volontaire en neuf sections (Mitchell et al., 2019), pas un document juridique.
• Le modèle Hugging Face fait figure de standard, mais couvre environ la moitié de l’annexe XI et du Model Documentation Form.
• Depuis le 2 août 2025, les fournisseurs de modèles à usage général documentent leur modèle (annexe XI), informent l’aval (annexe XII) et publient un résumé des contenus d’entraînement ; l’annexe IV (haut risque) suit en décembre 2027.
• La transparence recule : 41 sur 100 au Foundation Model Transparency Index de décembre 2025, 17 points sous 2024 ; sur Hugging Face, impact environnemental, limites et évaluation sont les moins remplies.
• Une model card devient une preuve une fois versionnée, signée par trois rôles, écrite dans les termes du régulateur et reliée au système.

Qu’est-ce qu’une model card ?

Le terme vient d’un article de recherche, « Model Cards for Model Reporting », déposé sur arXiv en octobre 2018 et présenté à la conférence FAT\* d’Atlanta en janvier 2019 par des chercheurs de Google, dont Margaret Mitchell et Timnit Gebru. Leur définition : une model card est un document court qui accompagne un modèle d’apprentissage automatique entraîné et rend compte de ses performances mesurées dans des conditions variées, notamment selon des groupes culturels, démographiques ou phénotypiques. Deux exemples travaillés : un classifieur de sourires entraîné sur CelebA et le modèle de toxicité de l’API Perspective. Trois publics : développeurs, décideurs publics, personnes concernées. Hugging Face l’a fait entrer dans la pratique. Sur le Hub, la model card est le fichier README.md du dépôt : du Markdown, précédé d’un bloc YAML qui déclare licence, langue, jeux de données, modèle de base (base_model), tâche (pipeline_tag), bibliothèque (library_name), résultats d’évaluation structurés et émissions de CO2. Le modèle annoté et le Model Card Guidebook (Ozoani, Gerchick et Mitchell, 2022) ajoutent un point souvent oublié : remplir une fiche sérieuse mobilise trois rôles, le développeur, le « sociotechnicien » (juriste, éthicien, défenseur des droits) et l’organisateur du projet. Pour les bases, voir ce qu’est un modèle d’IA.

Model card, system card, data card : trois artefacts, trois objets

La confusion la plus fréquente porte sur l’objet décrit. Une model card décrit des poids entraînés. Une system card décrit le produit déployé autour de ces poids : prompts système, garde-fous, outils connectés, évaluations de sécurité. OpenAI a popularisé le genre avec la System Card de GPT-4 en mars 2023 ; Anthropic en publie pour ses modèles Claude. Détail révélateur : en août 2025, OpenAI a publié une model card, et non une system card, pour ses modèles à poids ouverts gpt-oss-120b et gpt-oss-20b, parce que ce qui circule, ce sont les poids. Le troisième artefact, la data card ou datasheet, décrit le jeu de données (« Datasheets for Datasets », Gebru et al., 2018). La règle : un artefact par objet.

Les neuf sections d’une model card et la question à laquelle chacune répond

Les neuf sections de Mitchell et al. forment encore l’ossature de la plupart des fiches. Chacune répond à une question qu’un auditeur poserait de toute façon ; à droite, la faiblesse la plus fréquente. <table header-row= »true »> <tr> <td>Section</td> <td>Question à laquelle elle répond</td> <td>Faiblesse typique</td> </tr> <tr> <td>Model Details (détails du modèle)</td> <td>Qui l’a construit, quelle version, date, type, licence, contact ?</td> <td>Version et date absentes, contact générique</td> </tr> <tr> <td>Intended Use (usage prévu)</td> <td>Quels usages, quels utilisateurs, quels usages hors périmètre ?</td> <td>Rédigé comme du marketing, sans usages exclus</td> </tr> <tr> <td>Factors (facteurs)</td> <td>Quels groupes, instruments ou environnements font varier la performance ?</td> <td>Jamais désagrégés</td> </tr> <tr> <td>Metrics (métriques)</td> <td>Quelles mesures, quels seuils de décision, quelle variabilité ?</td> <td>Métriques sans seuils ni intervalles</td> </tr> <tr> <td>Evaluation Data (données d’évaluation)</td> <td>Quels jeux de données, pourquoi ceux-là, quel prétraitement ?</td> <td>Identiques aux données d’entraînement</td> </tr> <tr> <td>Training Data (données d’entraînement)</td> <td>Sur quoi le modèle a-t-il appris, ou pourquoi ne peut-on pas le dire ?</td> <td>« Propriétaires », sans catégories de provenance</td> </tr> <tr> <td>Quantitative Analyses (analyses quantitatives)</td> <td>Quels résultats par facteur et par intersection de facteurs ?</td> <td>Un score global, aucune intersection</td> </tr> <tr> <td>Ethical Considerations (considérations éthiques)</td> <td>Données sensibles, risques pour la vie humaine, mesures d’atténuation ?</td> <td>Une clause de non-responsabilité</td> </tr> <tr> <td>Caveats and Recommendations (réserves et recommandations)</td> <td>Qu’est-ce que l’évaluation n’a pas couvert ?</td> <td>Vide, ou copiée d’un autre modèle</td> </tr> </table> Le modèle Hugging Face réorganise ces neuf rubriques sans en changer la logique : Model Details, Uses (direct, en aval, hors périmètre), Bias, Risks and Limitations avec Recommendations, Training Details, Evaluation (données de test, facteurs, métriques, résultats), Environmental Impact, Technical Specifications, Citation, Glossary, Authors, Contact, How to Get Started. Le guidebook fixe aussi trois définitions : un biais est un écart de performance au détriment de certaines sous-populations ; un risque, un problème socialement significatif que le modèle pourrait causer ; une limite, un mode d’échec probable auquel les recommandations répondent. Trois mots que les rédacteurs confondent et qu’un auditeur distingue.

Ce qu’une model card n’est pas : volontaire, auto-déclarée, inégale

Aucune loi n’impose le format. Personne ne vérifie ce qui y est écrit. L’auteur choisit ce qu’il mesure, sur quelles données, et ce qu’il tait. Une model card est donc une auto-déclaration ; deux mesures récentes montrent ce que cela donne à grande échelle. La première vient de Stanford. Le Foundation Model Transparency Index 2025, troisième édition, décembre 2025, note 13 entreprises sur 100 indicateurs : moyenne de 41 sur 100, 17 points de moins qu’en 2024 ; IBM à 95, xAI et Midjourney à 14. La transparence des grands modèles recule. La seconde porte sur la masse. En février 2024, Liang et al. ont analysé 32 111 model cards sur Hugging Face : la section entraînement est la plus régulièrement remplie ; impact environnemental, limites et évaluation sont les moins remplies, précisément celles qu’un régulateur lit en premier. Autre signal : l’ajout d’une fiche détaillée à 42 modèles populaires s’est révélé modérément corrélé à la hausse de leurs téléchargements hebdomadaires ; rien n’oblige pourtant à produire cette fiche. Pour une équipe de gouvernance, deux conséquences. Une model card reçue d’un fournisseur est une affirmation, pas un constat : ses scores ne valent preuve qu’une fois reproduits, comme l’explique notre article sur le benchmark IA. Celle que vous publiez est une déclaration dont vous répondrez : elle décrit un modèle à une date donnée, et la dérive du modèle la rend fausse sans prévenir.

Là où la model card rencontre l’AI Act

Le règlement (UE) 2024/1689 n’emploie jamais l’expression model card, mais décrit deux fois un document qui en reprend la structure en l’allongeant : l’annexe XI pour les modèles à usage général, l’annexe IV pour les systèmes à haut risque.

Modèles d’IA à usage général : article 53, annexe XI et le Model Documentation Form

L’article 53, paragraphe 1 s’applique depuis le 2 août 2025 à tout fournisseur de modèle d’IA à usage général : (a) une documentation technique reprenant au moins l’annexe XI, tenue à jour, remise sur demande au Bureau de l’IA et aux autorités nationales ; (b) une documentation pour les fournisseurs en aval reprenant au moins l’annexe XII, pour qu’ils comprennent capacités et limites ; (c) une politique de respect du droit d’auteur ; (d) un résumé public des contenus d’entraînement, sur le modèle publié par le Bureau de l’IA le 24 juillet 2025. Le paragraphe 2 dispense de (a) et (b) les modèles libres et open source à paramètres publics, sauf risque systémique. La section 1 de l’annexe XI se lit comme une model card augmentée : tâches et systèmes d’intégration visés, politiques d’utilisation acceptable, mise sur le marché et distribution, architecture, paramètres, modalités, licence, moyens d’intégration, méthodologie d’entraînement justifiée, données (type, provenance, curation, volume, détection des biais), calcul en opérations à virgule flottante, temps d’entraînement, énergie. La section 2, pour les modèles à risque systémique, ajoute évaluations, tests contradictoires, red teaming et architecture du système. Le code de bonne pratique, texte final du 10 juillet 2025, approuvé par la Commission et le Comité IA le 1er août 2025, traduit ces annexes en un formulaire, le Model Documentation Form. Mesure 1.1 : documenter chaque champ à la mise sur le marché, le mettre à jour, conserver les versions précédentes dix ans. Mesure 1.2 : un point de contact, les champs utiles aux fournisseurs en aval sous 14 jours, au Bureau de l’IA ce qu’il demande. Mesure 1.3 : contrôle qualité, intégrité, protection contre l’altération. Le formulaire est une model card dotée d’une troisième colonne : trois cases par champ indiquent le destinataire (Bureau de l’IA, autorités nationales compétentes, fournisseurs en aval). Ses champs : raison sociale, date de mise sur le marché de l’Union, empreinte (hash) ou point d’accès prouvant l’authenticité, dépendances (modèle de base), nombre de paramètres à deux chiffres significatifs pour le Bureau de l’IA et par fourchette (de 1 à 500 millions à plus de 1 000 milliards) pour les autres, tailles maximales d’entrée et de sortie, politique d’utilisation acceptable, usages prévus en 200 mots environ, types de systèmes d’IA admis ou exclus, processus d’entraînement en 400 mots environ avec la justification des choix, provenance des données par catégorie, mesures de détection des sources inappropriées, dont les contenus pédocriminels (CSAM) et les images intimes non consenties (NCII), mesures contre les biais identifiables, temps d’entraînement en durée réelle et en jours-matériel, calcul en FLOPs, énergie en mégawattheures, calcul d’inférence mesuré sur banc d’essai. Les informations remises aux autorités relèvent du secret des affaires de l’article 78. Régime complet dans notre article sur l’IA à usage général.

Systèmes d’IA à haut risque : annexe IV, article 13 et la fiche du déployeur

Pour un système à haut risque, l’article 11 exige une documentation technique établie avant la mise sur le marché, dont l’annexe IV fixe les neuf points : description générale (destination, fournisseur, versions, interactions, matériel, notice d’utilisation) ; développement (méthodes, modèles pré-entraînés de tiers, spécifications, architecture, données avec provenance, étiquetage et nettoyage, supervision humaine, modifications prédéterminées, validation et tests avec métriques d’exactitude, de solidité et d’impact discriminatoire, cybersécurité) ; surveillance et contrôle (performance pour des groupes spécifiques, résultats non intentionnels prévisibles, données d’entrée) ; justification des métriques ; gestion des risques de l’article 9 ; modifications du cycle de vie ; normes harmonisées ; déclaration UE de conformité ; plan de surveillance après commercialisation de l’article 72. L’article 18 impose dix ans de conservation. L’article 13, paragraphe 3 décrit la notice d’utilisation, c’est-à-dire la model card tournée vers le déployeur : identité du fournisseur, destination, exactitude avec ses métriques, solidité, cybersécurité, risques de mauvaise utilisation connus et prévisibles, performance pour des groupes spécifiques, spécifications des données d’entrée, modifications prédéterminées, mesures de supervision humaine, besoins en calcul et en matériel, durée de vie attendue et maintenance, mécanismes de journalisation. Le calendrier a changé avec l’omnibus numérique sur l’IA, règlement (UE) 2026/1744, publié au Journal officiel le 24 juillet 2026, en vigueur le 27 juillet 2026 : annexe III (systèmes autonomes) à partir du 2 décembre 2027, annexe I (systèmes intégrés) à partir du 2 août 2028. Les PME et désormais les petites entreprises à moyenne capitalisation peuvent utiliser le formulaire simplifié de la Commission : mêmes neuf rubriques, moins de texte. Les déployeurs suivent la notice (article 26) et, pour les cas d’usage de l’annexe III dans le secteur public et certains cas privés, mènent l’analyse d’impact sur les droits fondamentaux de l’article 27, qui part de cette fiche. Voir aussi systèmes d’IA à haut risque, évaluation de la conformité et documentation d’un système d’IA.

Audit des écarts : le modèle Hugging Face face aux listes de champs légales

Ce tableau est notre lecture, non une correspondance officielle : chaque section du modèle Hugging Face face à ce que demandent l’annexe IV, l’annexe XI ou le Model Documentation Form. <table header-row= »true »> <tr> <td>Section du modèle Hugging Face</td> <td>Ce que demandent l’annexe IV, l’annexe XI ou le formulaire</td> <td>Écart</td> </tr> <tr> <td>Model Details</td> <td>Informations générales : raison sociale, date de mise sur le marché de l’Union, empreinte d’authenticité, dépendances</td> <td>Manquant</td> </tr> <tr> <td>Uses</td> <td>Usage : lien vers la politique d’utilisation acceptable, types de systèmes d’IA admis ou exclus, en 200 à 300 mots</td> <td>Partiellement manquant</td> </tr> <tr> <td>Bias, Risks and Limitations</td> <td>Mesures de détection des sources inappropriées et des biais identifiables</td> <td>Manquant : le modèle consigne des résultats, le formulaire demande les méthodes</td> </tr> <tr> <td>Training Details</td> <td>Processus d’entraînement et données : justification des choix, catégories de provenance, nombre de points de données, curation, mesures CSAM et NCII</td> <td>Manquant</td> </tr> <tr> <td>Evaluation</td> <td>Annexe XI section 2 et annexe IV point 2(g) : stratégies d’évaluation, tests contradictoires, métriques d’impact discriminatoire, seuils</td> <td>Partiellement présent</td> </tr> <tr> <td>Environmental Impact</td> <td>Énergie : le champ CO2 s’en approche, le formulaire veut des MWh à deux chiffres significatifs et la méthodologie</td> <td>Partiellement présent</td> </tr> <tr> <td>Technical Specifications</td> <td>Propriétés du modèle et ressources de calcul : paramètres, tailles maximales d’entrée et de sortie, FLOPs, jours-matériel</td> <td>Partiellement présent</td> </tr> <tr> <td>(rien)</td> <td>Annexe IV points 2(e) à 2(h) et 3 à 9 : supervision humaine, modifications prédéterminées, cybersécurité, gestion des risques, cycle de vie, normes, déclaration de conformité, plan de surveillance</td> <td>Manquant</td> </tr> <tr> <td>(rien)</td> <td>Article 13(3)(e) et (f) : durée de vie attendue, maintenance, journalisation</td> <td>Manquant</td> </tr> </table> Lisez ce tableau dans les deux sens. Ce que le modèle Hugging Face contient et que la loi ne demande pas, citation, glossaire, How to Get Started, auteurs, est précisément ce qui rend une model card lisible par un ingénieur qui la découvre. Gardez-le. Ajoutez les champs légaux en dessous, sous les intitulés des annexes, plutôt que de la remplacer par un formulaire que personne n’ouvrira.

Au-delà de l’UE : où la model card est attendue

L’AI Act n’est pas le seul texte à attendre une model card.

• États-Unis, FDA : le projet de guide du 7 janvier 2025 sur les fonctions logicielles de dispositifs médicaux fondées sur l’IA propose en annexe E un exemple de model card pour utilisateurs et professionnels de santé, et en annexe F un résumé 510(k) avec fiche remplie. La FDA n’exige ni la fiche ni un format, mais note qu’elle peut renforcer la confiance des utilisateurs. Toujours un projet à la date de rédaction.
• Californie, SB 53 : le Transparency in Frontier Artificial Intelligence Act, signé le 29 septembre 2025, applicable depuis le 1er janvier 2026, impose aux développeurs de modèles de frontière (plus de 10\^26 opérations d’entraînement) un rapport de transparence avant ou lors du déploiement : date de sortie, langues et modalités, usages prévus, restrictions, contact ; au-delà de 500 millions de dollars de chiffre d’affaires, des résumés d’évaluation des risques catastrophiques ; jusqu’à 1 million de dollars par infraction, devant le procureur général. Voir la loi californienne sur la transparence de l’IA et frontier model.
• New York, RAISE Act : signé le 19 décembre 2025, amendé le 27 mars 2026, applicable au 1er janvier 2027 : protocoles de sécurité publiés, incidents signalés sous 72 heures, sanctions jusqu’à 1 million de dollars, puis 3 millions. Notre guide du signalement des incidents d’IA compare les délais.
• NIST AI RMF : le Playbook cite model cards et system cards parmi les pratiques de documentation suggérées, toutes volontaires ; voir NIST AI RMF.
• Europe hors AI Act : la liste de contrôle d’audit commandée par le Comité européen de la protection des données à Gemma Galdon Clavell (janvier 2023) s’ouvre par une section « Model Card » renvoyant au RGPD ; l’AI Impact Assessment v2.0 du ministère néerlandais de l’Infrastructure (décembre 2024) demande s’il existe une model card ou une documentation équivalente.
• Normes : ISO/IEC 42001 consacre des mesures à la documentation technique du système d’IA, à l’information des utilisateurs, à la provenance des données et à la vérification et validation ; l’auditeur demande où vit la documentation et comment elle est tenue à jour. Voir ISO 42001.
• Chaîne d’approvisionnement : CycloneDX 1.5 (juin 2023) a ajouté une nomenclature ML-BOM avec un composant de type modèle dont les champs reprennent ceux d’une model card ; elle peut donc voyager dans un SBOM.

En France, les fiches pratiques IA de la CNIL (2024-2025) lisent la documentation des données d’entraînement comme une obligation du RGPD : base légale, provenance, minimisation, information des personnes. Une model card dont la section données est vide ne satisfera ni la CNIL, ni les autorités de surveillance du marché désignées par la France au titre de l’AI Act, ni le Bureau de l’IA à Bruxelles, superviseur des modèles à usage général. Les trois liront la même section.

Rédiger une model card qui résiste à un audit : six étapes

Six étapes transforment une fiche descriptive en pièce de dossier. Chacune se termine par l’enregistrement qu’elle produit.

1. Une model card par version du modèle. Figée dès la mise en circulation, avec un journal des modifications (données, entraînement, évaluation, usage prévu) : point 6 de l’annexe IV, mesure 1.1 du code de bonne pratique, versions précédentes conservées dix ans. Enregistrement produit : l’historique des versions.
2. Les champs légaux d’abord, dans le vocabulaire du régulateur. Raison sociale, dates de sortie et de mise sur le marché de l’Union, dépendances, licence, politique d’utilisation acceptable, usages prévus et hors périmètre, types de systèmes d’IA. Reprendre les intitulés des annexes épargne à l’autorité une table de correspondance. Enregistrement produit : la fiche d’identité du modèle.
3. Évaluer de façon désagrégée et rapporter ce que veut l’article 13. Exactitude avec métriques et seuils, solidité, cybersécurité, performance pour des groupes spécifiques. Un score agrégé sans intervalle de confiance ne prouve rien (voir benchmark IA). Enregistrement produit : le rapport d’évaluation daté, avec ses jeux de test.
4. Documenter les données par catégorie de provenance. Exploration du web, jeux tiers, données d’utilisateurs, jeux publics, données synthétiques, avec le nombre de points de données, la curation et les mesures de détection des sources inappropriées et des biais. Le cadre de gouvernance des données fournit la structure. Enregistrement produit : le registre des données d’entraînement.
5. Trois rôles signent. Développeur, sociotechnicien et organisateur du projet valident la fiche ; un responsable nommé en répond ; la revue a lieu à chaque version et au moins une fois par an. Enregistrement produit : la feuille d’approbation, avec noms et dates.
6. Relier la model card à la fiche du système. Inventaire des systèmes d’IA, registre des risques, notice d’utilisation, journal des incidents, contrat fournisseur. Pour un modèle acheté, exigez les champs de l’annexe XII et inscrivez au contrat le délai de 14 jours et une mise à jour trimestrielle ; un guide pratique pour juristes propose une telle clause : fiches couvrant architecture, provenance des données, benchmarks, tests de biais et résultats de surveillance, actualisées au moins chaque trimestre. La due diligence des fournisseurs d’IA donne la liste de questions. Enregistrement produit : le lien contractuel et documentaire entre modèle et système.

Six étapes, six enregistrements : ensemble, le dossier qu’une autorité peut demander dès aujourd’hui au titre de l’article 53 et, à partir de décembre 2027, au titre de l’annexe IV. Sa présentation le jour venu relève de l’audit IA.

Les model cards dans la fiche du système d’IA

Une model card parle d’un modèle. Un régulateur pose ses questions sur un système : celui qui trie des candidatures, note des dossiers de crédit ou lit des radiographies. Le registre fait le lien entre les deux. Chaque fiche de système d’IA liste ses composants modèles ; chaque composant porte les champs et la version de sa model card ; une modification de la fiche rouvre l’analyse de risques et la notice d’utilisation, car le modèle évalué n’est plus le même. Un modèle partagé par trois systèmes a une seule model card et trois évaluations de contexte. AI Sigil conserve la model card à côté des contrôles du cadre réglementaire appliqué au système, de sorte que la réponse à « montrez-moi la documentation de ce modèle » est un rapport, pas une recherche dans trois outils. Le registre des systèmes d’IA décrit cette structure ; l’inventaire des systèmes d’IA explique par où commencer.

Questions fréquentes

Qu’est-ce qu’une model card, en termes simples ? C’est la fiche d’identité d’un modèle d’IA entraîné : qui l’a construit, pour quoi faire, avec quelles données, quels résultats mesurés, où il échoue. Neuf sections, proposées par des chercheurs de Google en 2018-2019 ; Hugging Face en a fait le README.md de chaque dépôt de modèle. Elle s’adresse aux ingénieurs comme aux juristes, aux auditeurs et aux personnes concernées. Une model card est-elle obligatoire ? Aucun texte n’impose le format. Son contenu, lui, est devenu exigible : article 53 de l’AI Act depuis le 2 août 2025 pour les modèles à usage général (annexe XI) ; dossier technique de l’annexe IV à partir du 2 décembre 2027 pour les systèmes à haut risque ; rapports de transparence de la loi californienne SB 53 depuis le 1er janvier 2026. Une fiche bien tenue alimente les trois. Quelle est la différence entre une model card et une system card ? L’objet décrit. La model card documente des poids entraînés ; la system card, le produit déployé autour de ces poids : prompts système, garde-fous, outils connectés, évaluations de sécurité de l’ensemble. OpenAI a popularisé la system card avec GPT-4 en mars 2023, puis publié une model card pour ses modèles gpt-oss en août 2025 : ce qui était diffusé, c’étaient les poids. Une model card Hugging Face suffit-elle pour l’AI Act ? Non. Selon notre lecture, elle couvre à peu près la moitié des champs de l’annexe XI et du Model Documentation Form : manquent raison sociale, date de mise sur le marché de l’Union, empreinte d’authenticité, dépendances, provenance par catégorie, détection des sources inappropriées, énergie en MWh. Et aucun des points de gouvernance de l’annexe IV : supervision humaine, cybersécurité, gestion des risques, surveillance après commercialisation. Un point de départ, pas un livrable. Qui doit rédiger la model card ? Trois rôles, selon le guidebook de Hugging Face : le développeur, qui connaît architecture, données et résultats ; le sociotechnicien (juriste, éthicien, défenseur des droits), qui écrit usages exclus, risques et considérations éthiques ; l’organisateur du projet, garant de la cohérence du dossier. Au-dessus des trois, un responsable nommé en répond devant l’auditeur et signe chaque version. À quelle fréquence mettre à jour une model card ? À chaque nouvelle version du modèle : nouvelles données, nouvel entraînement, nouvelle évaluation ou nouvel usage prévu justifient une nouvelle fiche, l’ancienne restant figée. Le code de bonne pratique impose de garder les versions précédentes dix ans ; l’article 18 fixe la même durée pour la documentation technique des systèmes à haut risque. Entre deux versions, une revue annuelle vérifie que les limites décrites tiennent toujours.

Conclusion

La model card est aujourd’hui le vocabulaire le plus répandu pour décrire un modèle d’IA. Conçue pour la transparence, pas pour la conformité, elle le reste : volontaire, auto-déclarée, inégale. L’AI Act en a inscrit une version plus longue dans la loi pour les fournisseurs de modèles à usage général depuis août 2025, et fera de même pour les systèmes à haut risque en décembre 2027 ; les États américains demandent des rapports de transparence bâtis sur le même squelette. Le travail d’une équipe de gouvernance n’est pas de remplacer la fiche, mais de la compléter avec les champs légaux, de la versionner, de la faire signer et de la relier au système qu’elle sert. AI Sigil conserve la model card de chaque modèle à côté de sa fiche de système d’IA, de ses risques et de ses contrôles, afin que la documentation demandée par un régulateur existe déjà.