La fiche modèle que personne ne lit
Anthropic publie une fiche modèle pour chaque version de Claude. OpenAI publie une fiche système pour chaque version de GPT. Google DeepMind publie des rapports techniques pour Gemini. Meta publie des fiches modèle pour Llama. Mistral publie les siennes pour ses modèles. Ce sont les documents source — rédigés par les personnes qui ont construit les modèles — qui décrivent exactement ce que le modèle peut faire, ce qu’il ne peut pas faire, où il échoue, et dans quelles conditions ses sorties ne devraient pas être considérées comme fiables.
Presque personne ne les lit.
La page marketing reçoit des millions de visites. La fiche modèle en reçoit des milliers. Le billet de blog annonçant le modèle est partagé dans chaque newsletter IA et chaque fil LinkedIn. La fiche modèle — le document qui dit réellement si ce modèle est adapté à votre cas d’usage — reste tranquillement sur un site de documentation, non lue, non citée, non utilisée.
C’est un problème. Plus précisément, c’est le genre de problème qui coûte de l’argent aux entreprises, produit de mauvais déploiements et érode la confiance dans les outils IA — tout cela parce que le document le plus important livré avec chaque modèle est traité comme une annexe technique au lieu d’un manuel opérationnel.
Ce que contient réellement une fiche modèle
Le terme « model card » vient d’un article de 2019 par Margaret Mitchell, Simone Wu, Andrew Zaldivar, Parker Barnes, Lucy Vasserman, Ben Hutchinson, Elena Spitzer, Inioluwa Deborah Raji et Timnit Gebru. L’article proposait un cadre de documentation standardisé pour les modèles d’apprentissage automatique — analogue à une étiquette nutritionnelle pour les aliments ou à une fiche de données de sécurité pour les produits chimiques.
Le cadre original spécifiait : détails du modèle, usage prévu, facteurs (facteurs démographiques ou contextuels pertinents), métriques, données d’évaluation, données d’entraînement, analyses quantitatives, considérations éthiques, et mises en garde et recommandations.
En pratique, les fiches modèle des grands laboratoires IA ont évolué au-delà de ce modèle, mais l’objectif fondamental demeure : une documentation honnête des capacités, limites et cas d’usage appropriés d’un modèle, rédigée par les personnes qui connaissent le mieux le modèle.
Les fiches modèle de Claude d’Anthropic, par exemple, contiennent :
Des évaluations de capacités avec des benchmarks spécifiques. Pas « Claude est bon en raisonnement » mais « Claude atteint X % sur le benchmark MMLU, Y % sur HumanEval, Z % sur MATH ». Ces chiffres sont comparables entre modèles. Ils disent, précisément, comment le modèle performe sur des tests standardisés de connaissance, de capacité de codage et de raisonnement mathématique.
Des limites connues documentées explicitement. La fiche modèle indique où le modèle échoue. Où il hallucine. Où ses sorties ne devraient pas être considérées comme fiables sans vérification humaine. Cette information n’est pas enfouie dans des clauses de non-responsabilité — elle est mise en avant comme un guide opérationnel.
Des évaluations de sécurité. Comment le modèle a été testé pour les sorties nuisibles, les biais et le potentiel d’utilisation détournée. Quelles atténuations ont été appliquées. Quels risques résiduels subsistent. C’est l’évaluation la plus honnête du profil de sécurité d’un modèle disponible où que ce soit — plus honnête qu’un billet de blog marketing, plus spécifique que le résumé d’un journaliste.
Les cas d’usage prévus et le potentiel d’utilisation détournée. Pour quoi le modèle a été conçu, pour quoi il n’a pas été conçu, et quelles utilisations les développeurs déconseillent spécifiquement. Pour une PME évaluant si ce modèle convient à une tâche spécifique, cette section est la guidance la plus précieuse qui existe.
Les fiches système d’OpenAI fournissent des informations équivalentes dans un format différent, avec une profondeur particulière sur leur méthodologie d’évaluation de sécurité — résultats de red-teaming, pipelines d’évaluation automatisée et catégories spécifiques de risques testées.
Ces documents ne sont pas des supports marketing. Ce sont des divulgations techniques. C’est ce qui se rapproche le plus d’une auto-évaluation honnête dans l’industrie de l’IA. Et ils sont ignorés.
Pourquoi personne ne les lit
Trois raisons, toutes structurelles.
Les documents sont écrits pour des chercheurs, pas pour des opérationnels. Les fiches modèle utilisent le langage de la recherche en apprentissage automatique : noms de benchmarks, méthodologies d’évaluation, mesures statistiques. Un directeur des achats évaluant s’il faut déployer Claude pour la classification des demandes clients ne sait pas ce que signifie MMLU, n’a pas de référence pour interpréter un score HumanEval, et ne sait pas comment traduire une évaluation de sécurité en évaluation des risques opérationnels. L’information est précieuse. La couche de traduction manque.
Le marketing est plus facile à consommer. Un billet de blog annonçant un nouveau modèle fait 1 500 mots de prose accessible avec des affirmations claires : « plus rapide », « plus précis », « meilleur en codage ». La fiche modèle fait 15 000 mots de documentation technique avec des réserves, des limites et des déclarations conditionnelles. Le billet de blog confirme ce que vous voulez entendre. La fiche modèle dit ce que vous avez besoin d’entendre. Ce sont deux publics différents, et le marketing gagne toujours la compétition pour l’attention.
Le poste de personne n’inclut la lecture des fiches modèle. Dans une entreprise de 200 personnes évaluant un déploiement IA, personne n’est responsable de lire la fiche modèle. Le CTO a peut-être le background technique mais pas le temps. Le chef de projet a le temps mais pas le background technique. Le consultant externe a une recommandation de modèle prête avant que la fiche modèle n’ait été téléchargée. La fiche modèle tombe dans un trou de responsabilité — trop technique pour le décideur métier, trop opérationnelle pour l’équipe recherche, trop détaillée pour le calendrier du consultant.
Ce qu’une fiche modèle dit que rien d’autre ne dit
Démontrons avec un exemple précis. Je vais parcourir trois catégories d’informations tirées des fiches modèle qui affectent directement si une PME européenne devrait déployer un modèle spécifique pour un cas d’usage spécifique.
Catégorie 1 : Variance de performance linguistique
Les fiches modèle rapportent des benchmarks de performance multilingue. Ces benchmarks révèlent des écarts de performance entre langues que les supports marketing ne mentionnent jamais.
Un modèle qui obtient 89 % en question-réponse en anglais peut obtenir 72 % en allemand et 58 % en portugais. La page marketing dit « supporte plus de 95 langues ». La fiche modèle montre le gradient de performance réel — et pour une PME européenne opérant sur plusieurs marchés, la différence entre 89 % et 58 % est la différence entre un outil utile et un risque.
Quand un client portugais soumet une requête et que la précision de compréhension du modèle est inférieure de 31 points à celle d’une requête en anglais, la qualité de la sortie se dégrade. Le client reçoit une réponse moins précise. Si la réponse implique une recommandation, une classification ou une décision, l’écart de précision devient un écart de qualité, un écart d’équité, et potentiellement un écart juridique au titre de l’article 22 du RGPD.
La fiche modèle le dit. Le billet de blog ne le dit pas.
Catégorie 2 : Taux d’hallucination par domaine
Les fiches modèle rapportent de plus en plus les taux d’hallucination — la fréquence à laquelle le modèle génère des informations qui semblent plausibles mais sont factuellement incorrectes. Ces taux varient drastiquement selon le domaine.
Un modèle peut halluciner à 2 % sur des questions de culture générale et à 12 % sur des questions techniques spécifiques au domaine. Pour une PME déployant le modèle pour répondre aux questions clients sur une gamme de produits spécialisée, le taux d’hallucination pertinent est celui spécifique au domaine, pas le chiffre en gros titre.
Plus important, les fiches modèle décrivent les types d’hallucinations auxquelles le modèle est enclin. Certains modèles hallucinent des détails spécifiques (dates, chiffres, noms) tout en ayant la bonne direction générale. D’autres hallucinent des chaînes causales entières — produisant des explications qui semblent faire autorité et sont complètement inventées. Le type d’hallucination détermine le type de supervision humaine nécessaire.
Un modèle qui se trompe parfois sur les dates a besoin d’une couche de vérification factuelle. Un modèle qui fabrique des explications a besoin d’un expert métier comme réviseur. La réponse opérationnelle est différente. La fiche modèle dit laquelle est nécessaire.
Catégorie 3 : Résultats des évaluations de sécurité
Les fiches modèle des laboratoires IA responsables incluent les résultats de red-teaming — les résultats de tentatives systématiques de faire produire au modèle des sorties nuisibles, biaisées ou inappropriées.
Pour une PME européenne, les considérations de sécurité pertinentes sont spécifiques : si le modèle génère des sorties biaisées pouvant affecter les décisions d’emploi (pertinent au titre de l’article 22 du RGPD et de l’article 6 de la Loi sur l’IA de l’UE), s’il produit du contenu discriminatoire dans les applications destinées aux clients, et s’il fuit des données d’entraînement contenant des informations personnelles.
La fiche modèle aborde ces questions avec des résultats de tests spécifiques. Pas « nous avons testé les biais » mais « nous avons testé les biais démographiques sur X catégories en utilisant la méthodologie Y, et nous avons observé le schéma Z de biais résiduel dans les conditions suivantes ».
Cette information est essentielle pour l’évaluation de la conformité requise par la Loi sur l’IA de l’UE pour les systèmes IA à haut risque. L’article 9 exige un système de gestion des risques incluant l’identification et l’analyse des risques connus et prévisibles. La fiche modèle est la source principale pour les risques connus. L’ignorer n’est pas seulement opérationnellement imprudent — c’est potentiellement juridiquement insuffisant.
Comment lire une fiche modèle
Pour une PME évaluant un déploiement IA, voici l’approche opérationnelle pour lire une fiche modèle. Cela prend environ deux heures, soit moins que la réunion moyenne de comité de pilotage et cela produit des informations plus utiles.
Étape 1 : Lisez la section « usage prévu » en premier. L’usage prévu correspond-il à votre cas d’usage ? Si la fiche modèle dit que le modèle est « conçu pour l’assistance conversationnelle et la génération de contenu » et que vous voulez l’utiliser pour l’évaluation automatisée du crédit, il y a un décalage. Le décalage ne signifie pas que le modèle ne peut pas le faire. Il signifie que les développeurs ne l’ont pas testé pour cet usage, ce qui signifie que la responsabilité des tests vous revient.
Étape 2 : Vérifiez les benchmarks multilingues. Trouvez les chiffres de performance pour chaque langue que votre déploiement utilisera. Si l’écart de performance entre votre langue principale et les langues secondaires dépasse 10 points de pourcentage, prévoyez une couche d’assurance qualité dans les langues moins performantes.
Étape 3 : Lisez la section « limites » en entier. C’est la section la plus précieuse. Les développeurs vous disent où leur modèle échoue. Ils le savent, parce qu’ils l’ont testé. Ignorer cette section est l’équivalent IA d’ignorer le rapport de l’ingénieur structure avant de construire sur un terrain. L’information est là. Les conséquences de l’ignorer sont prévisibles.
Étape 4 : Examinez l’évaluation de sécurité. Identifiez les catégories de sorties nuisibles qui ont été testées et les risques résiduels qui subsistent. Cartographiez-les par rapport à votre cas d’usage. Si votre déploiement implique des populations vulnérables (clients demandant des produits financiers, candidats à l’emploi, patients), l’évaluation de sécurité n’est pas une lecture complémentaire. C’est une exigence de conformité.
Étape 5 : Comparez entre modèles. Les fiches modèle sont comparables. Les mêmes benchmarks, les mêmes catégories, les mêmes méthodologies d’évaluation apparaissent dans les fiches modèle de différents laboratoires. Lisez trois fiches modèle de modèles concurrents et les différences de performance — y compris les moins évidentes enfouies dans les annexes — deviennent claires.
Catégorie 4 : Documentation de l’usage approprié et des détournements
Les fiches modèle incluent de plus en plus des listes explicites de cas d’usage prévus et de scénarios de détournement documentés. Ces listes ne sont pas hypothétiques. Elles sont tirées du comportement observé des utilisateurs pendant les tests et le déploiement.
Pour une PME déployant un modèle de langage pour des applications destinées aux clients, la documentation des détournements est opérationnellement critique. La fiche modèle peut spécifier : « Ce modèle n’est pas conçu pour le diagnostic médical, le conseil juridique ou les recommandations financières. » Si votre déploiement utilise le modèle pour générer des recommandations de produits financiers, la fiche modèle vient de vous dire — par écrit, de la part des personnes qui ont construit le modèle — que votre cas d’usage est hors du périmètre prévu.
Cela ne signifie pas que le modèle ne peut pas accomplir la tâche. Il peut l’accomplir de manière adéquate. Mais la documentation des détournements de la fiche modèle signifie que les développeurs du modèle n’ont pas testé ni validé le modèle pour cette application spécifique. Les évaluations de sécurité ne couvrent pas votre cas d’usage. Les benchmarks de performance ne sont pas calibrés pour votre domaine. La responsabilité, en cas de sortie nuisible, vous revient entièrement — parce que la fiche modèle a explicitement indiqué que votre usage n’était pas prévu.
Pour la conformité à la Loi sur l’IA de l’UE, cette documentation est directement pertinente. L’article 13 exige de la transparence sur la finalité prévue d’un système IA. Si la fiche modèle dit que le modèle n’est pas prévu pour votre cas d’usage, et que vous le déployez pour ce cas d’usage, vous avez créé un écart de conformité qu’aucune documentation a posteriori ne peut combler.
La fiche modèle vous l’a dit. Vous avez choisi de ne pas la lire. La conséquence est prévisible.
Le principe de la source primaire
Je lis les rapports de la BCE, pas ce que les journalistes disent des rapports de la BCE. Je lis les jeux de données d’Eurostat, pas ce que les commentateurs disent des jeux de données d’Eurostat. Je lis les articles de la Loi sur l’IA de l’UE, pas ce que les cabinets de conseil disent de la Loi sur l’IA de l’UE.
La fiche modèle est la source primaire pour ce qu’un modèle IA peut et ne peut pas faire. Tout le reste — le billet de blog, le rapport d’analyste, la recommandation du consultant, le commentaire à chaud sur LinkedIn — est du commentaire. Le commentaire a ses usages. Mais le commentaire introduit du biais, de la compression et un agenda. La source primaire n’en introduit pas.
La fiche modèle n’est pas parfaite. Elle est rédigée par le laboratoire qui a construit le modèle, et les laboratoires ont des incitations à présenter leurs modèles favorablement. Mais la fiche modèle est contrainte par la reproductibilité — les benchmarks peuvent être vérifiés indépendamment, les limites peuvent être testées indépendamment, et les évaluations de sécurité peuvent être répliquées indépendamment. Le marketing n’est contraint par aucune de ces choses.
Quand j’évalue un modèle IA pour un déploiement Bluewaves, la fiche modèle est le premier document que je lis et le dernier que je consulte. Pas le premier parce que c’est facile — parce que c’est honnête. Pas le dernier parce que c’est exhaustif — parce que les décisions que nous prenons sur le déploiement sont ancrées dans ce que les développeurs savent réellement de leur modèle, pas dans ce que leur équipe marketing veut nous faire croire.
L’implication opérationnelle
Pour chaque déploiement IA dans votre entreprise, une personne devrait lire la fiche modèle. Complètement. Pas en diagonale. Pas le résumé. Le document complet.
Cette personne devrait traduire les évaluations techniques de la fiche modèle en trois documents opérationnels :
Une évaluation des capacités qui indique, en langage clair, ce que le modèle peut et ne peut pas faire pour votre cas d’usage spécifique, sur la base des benchmarks et des limites de la fiche modèle.
Un registre des risques qui cartographie les évaluations de sécurité et les limites connues de la fiche modèle par rapport à votre contexte de déploiement spécifique, identifiant quels risques sont pertinents, quelles atténuations sont nécessaires et quels risques résiduels doivent être acceptés.
Un plan de suivi qui spécifie comment vous vérifierez, en production, que la performance réelle du modèle correspond à la performance documentée dans la fiche modèle — parce que les modèles peuvent se dégrader, les cas d’usage peuvent dériver, et le seul contrôle sur les affirmations de la fiche modèle est votre propre observation.
Ces trois documents prennent à une personne environ quatre heures. Ils ne coûtent rien. Ils préviennent les échecs de déploiement IA les plus courants et les plus coûteux : déployer un modèle pour un cas d’usage pour lequel il n’a jamais été conçu, déployer dans une langue où la performance est significativement inférieure, et déployer sans système de suivi qui détecte la dégradation avant les utilisateurs.
La fiche modèle est gratuite. La lire est gratuit. Agir en conséquence est gratuit.
Le coût de ne pas la lire, c’est le déploiement qui échoue et l’équipe qui perd confiance dans les outils IA parce que personne n’a lu le document qui aurait prédit l’échec.
Lisez la fiche modèle.
La source primaire est disponible. La source primaire est gratuite. La source primaire contient des informations qu’aucune source secondaire — aucun billet de blog, aucun rapport d’analyste, aucune recommandation de consultant — ne peut reproduire.
La fiche modèle est rédigée par les personnes qui ont construit le modèle. Elles savent des choses sur son comportement que personne d’autre ne sait. Elles ont documenté ces choses — honnêtement, précisément, avec des benchmarks et des réserves — dans un document qui est publiquement disponible et systématiquement ignoré.
L’écart entre la page marketing et la fiche modèle est l’écart entre ce que vous voulez entendre et ce que vous devez savoir. La fiche modèle est ce que vous devez savoir.
Lisez-la.