Modèles à usage général : ce qui doit descendre la chaîne

Un modèle d’IA à usage général est un modèle entraîné pour accomplir une grande variété de tâches, que d’autres entreprises intègrent ensuite dans leurs propres systèmes, ce qui répartit les obligations de conformité sur toute une chaîne d’acteurs. Le règlement européen sur l’IA le traite à part : depuis le 2 août 2025, ses fournisseurs ont des obligations de documentation propres.

Les obligations se répartissent entre celui qui produit le modèle, celui qui l’intègre et celui qui l’utilise, et chacun dépend des informations transmises par le précédent. C’est cette dépendance qui pose problème en pratique.

Un intégrateur ne peut pas documenter les limites d’un modèle qu’il n’a pas entraîné. Il ne peut pas décrire les données d’entraînement, ni les capacités et incapacités mesurées, ni les risques identifiés. Ces éléments doivent lui être fournis.

La conséquence opérationnelle est directe : une partie de votre dossier de conformité ne se rédige pas, elle se réclame. Et elle se réclame au moment du contrat, pas au moment du contrôle. Le calendrier des obligations qui deviennent exigibles est détaillé dans sanctions de l’AI Act : ce qui devient exigible.

Le fournisseur d’un modèle à usage général doit vous permettre d’obtenir trois pièces : une documentation technique, un résumé des données d’entraînement et une politique en matière de droits d’auteur, qui conditionnent votre propre dossier. Elles ne s’obtiennent pas toutes de la même façon, et aucune ne s’archive toute seule.

La documentation technique décrit les capacités, les limites connues et les usages pour lesquels le modèle n’est pas prévu. Elle n’est pas nécessairement publique : le règlement impose au fournisseur de la tenir à la disposition des intégrateurs, et de l’autorité sur demande, d’où l’intérêt de la réclamer explicitement. C’est la pièce qui vous permet de justifier que l’usage envisagé est dans le périmètre annoncé.

Le résumé des données d’entraînement porte sur les catégories de sources utilisées ; c’est la pièce que le fournisseur doit rendre publique. Il ne vous sera pas utile tous les jours, et il devient indispensable si la provenance d’une réponse est contestée.

La politique en matière de droits d’auteur importe surtout si le système produit du contenu diffusé publiquement.

Le réflexe à prendre : archiver ces pièces à la date de la mise en service, avec leur version. Un document publié aujourd’hui peut avoir changé quand on en aura besoin.

Réclamer la documentation d’un modèle à usage général suit une méthode simple en cinq étapes, à dérouler avant la signature du contrat et non après la mise en service. Chaque étape produit une pièce datée qui rejoint le dossier du système.

1. Identifier la version exacte du modèle utilisé. Un nom commercial ne suffit pas : il faut l’identifiant de version appelé par votre code, car c’est lui que la documentation doit couvrir.
2. Lister les pièces attendues. Documentation technique, résumé des données d’entraînement, politique en matière de droits d’auteur, plus la localisation du traitement si vous envoyez des données sensibles.
3. Vérifier que chaque pièce correspond à cette version. Une documentation générique sur une famille de modèles ne décrit pas les limites de la version que vous appelez.
4. Archiver les pièces dans le dossier du système, avec la date de téléchargement et l’adresse d’origine.
5. Planifier une revue à chaque changement de version, en reprenant les étapes 1 à 4. Une migration de modèle est aussi une migration de documentation.

Pour un modèle à poids ouverts, la démarche est la même, mais l’interlocuteur change : c’est la fiche publiée avec les poids qui tient lieu de documentation, et elle est souvent plus pauvre. Ce que des poids téléchargés ne fournissent pas est détaillé dans Llama 3.1 405B : ce que télécharger des poids ne fournit pas.

Dans un contrat avec un fournisseur de modèle, un engagement de transmission de la documentation à jour et un préavis en cas de retrait d’une version valent plus que toute clause de responsabilité. Ce sont les deux points qui ont un effet réel sur votre exploitation.

La transmission de documentation évite de reconstituer un dossier deux ans plus tard sur un modèle dont la page a changé. La formulation est simple : le fournisseur s’engage à fournir, sur demande, la documentation correspondant à la version utilisée.

Le préavis de retrait est le point le plus concret. Une version retirée sans délai suffisant force une migration en urgence, avec revérification complète des réglages. C’est le scénario décrit dans le jour où le modèle a changé sans prévenir.

J’ajoute une troisième clause quand c’est possible : la localisation du traitement, qui détermine ce qu’on a le droit d’envoyer.

La qualité de la documentation d’un modèle devient un critère de sélection du fournisseur au même titre que la qualité du modèle, parce qu’elle conditionne votre capacité à répondre à un contrôle. Ce critère est facile à évaluer et rarement évalué.

Le test tient en une heure. On cherche la documentation technique du modèle envisagé, on regarde si elle décrit les limites connues, si elle est datée, si elle est versionnée, et si l’historique des versions précédentes reste accessible.

Un fournisseur dont la documentation est complète et archivée facilite considérablement le travail. Un fournisseur dont la page produit change sans historique le rend pénible, et parfois impossible.

Ce critère s’ajoute aux quatre autres, dépréciation, localisation, tarification, disponibilité, qui décident réellement d’un choix hors capacités, comme détaillé dans quand la fenêtre cesse d’être un argument. La même logique vaut pour arbitrer entre un modèle fermé et un modèle ouvert, sujet traité dans modèles ouverts et souveraineté : une décision d’architecture.

Les erreurs qui fragilisent le dossier d’un intégrateur de modèle à usage général tiennent presque toutes à une confusion entre ce que le fournisseur documente et ce que l’intégrateur doit documenter. Elles se repèrent avant le contrôle si l’on sait où regarder.

• Citer un lien au lieu d’archiver un document. Le lien pointe vers la version du jour, pas vers celle qui était en vigueur à la mise en service.
• Recopier la documentation du fournisseur dans son propre dossier. Elle décrit le modèle, pas votre système ; un contrôleur cherche la finalité et la décision servie.
• Négocier la responsabilité et oublier le préavis de retrait. La première clause sert rarement, la seconde sert à chaque fin de vie d’une version.
• Ne rien revoir lors d’un changement de version. Le nom du produit reste le même, la documentation et les limites changent.
• Confondre usage général et usage autorisé. Un modèle capable de tout n’est pas prévu pour tout ; la liste des usages non prévus est la partie à lire en premier.

Un regard extérieur sur ces points est l’objet d’un audit de système d’IA, qui vérifie le dossier sur pièces plutôt que sur déclarations.

Même avec un fournisseur exemplaire, la documentation reçue porte sur le modèle, alors que la vôtre doit porter sur le système, et personne ne peut l’écrire à votre place. C’est la part irréductible.

Un modèle n’a pas de finalité : c’est le système qui en a une. Un modèle n’a pas de données : c’est vous qui lui donnez les vôtres. Un modèle ne sert aucune décision : c’est votre processus qui en sert une.

Ces trois éléments constituent le cœur du dossier, et ils tiennent en une page. Le format et le contenu sont détaillés dans l’AI Act en vigueur : ce que l’ingénieur doit livrer.

La bonne nouvelle est que cette page a une valeur qui dépasse la conformité : elle oblige à formuler la finalité, ce qui révèle régulièrement qu’un système en poursuit deux à la fois.