Fournisseurs d'IA et ISO 42001 : le contrôle A.10.3

Le sujet a un double ancrage dans ISO/IEC 42001. Une exigence de clause d’abord : le dernier alinéa de la clause 8.1 impose de maîtriser les processus, produits et services fournis par l’extérieur qui comptent pour le système de management. Un contrôle de l’Annexe A ensuite, A.10.3, dont l’objet est plus étroit : la cohérence entre l’usage de ce que vous achetez et votre approche responsable de l’IA. Le premier s’applique toujours ; le second se retient ou s’écarte, avec justification, dans la déclaration d’applicabilité.

Répartir n’est pas transférer

Le domaine A.10 repose sur une distinction que les contrats brouillent souvent. La responsabilité opérationnelle se délègue : héberger le modèle, filtrer les contenus, conserver les journaux. La redevabilité ne se délègue pas : c’est l’organisation qui répond du système devant ses clients, les personnes concernées et les autorités.

On peut sous-traiter l’exécution. On ne sous-traite jamais le fait d’en répondre.

Il faut aussi distinguer trois natures d’engagement d’un fournisseur, qui ne se valent pas :

le contractuel, opposable : contrat, accord de traitement des données, engagements de service ;
le documentaire, attesté par un tiers ou publié : rapport d’audit, certificat, fiche descriptive du système ;
le déclaratif, révisable à tout moment : page d’aide, billet de blog, argumentaire commercial.

Une exigence qu’on veut voir tenir dans la durée ne peut reposer que sur les deux premiers.

Ce qui change selon ce que vous achetez

La même exigence produit des dispositifs très différents selon la configuration. Le tableau résume où passe la frontière de maîtrise.

Configuration	Ce que le fournisseur maîtrise	Ce que vous gardez	Point de vigilance
API d’un fournisseur de modèle	Modèle, données d’entraînement, infrastructure, versions, garde-fous	Invites, données transmises, décision finale, version appelée	Usage et conservation de vos données ; changements de version
Modèle proposé par un grand fournisseur cloud	Hébergement, politique de mise à jour, contrôle des abus	Version épinglée, politique de mise à jour du déploiement	Mises à jour automatiques de la version par défaut
Assistant intégré à une suite bureautique	Modèle et garde-fous	Les droits d’accès aux documents de l’organisation	L’assistant rend trouvable tout ce que l’utilisateur peut atteindre : le risque vient des partages trop larges
Modèle à poids ouverts hébergé en interne	Presque rien : c’est vous qui opérez	Infrastructure, versions, filtres, sécurité	Provenance des poids, licence, formats de fichiers capables d’exécuter du code au chargement
Logiciel métier qui a ajouté de l’IA	La couche d’IA, souvent elle-même sous-traitée	La décision d’activer la fonction, l’information des utilisateurs	Activation par défaut, modèle sous-jacent changé sans préavis
Fournisseur de données	Provenance et droits, en principe	L’usage et la redevabilité	Droits d’usage pour l’entraînement, garanties de provenance
Prestataire de développement ou d’exploitation	L’exécution technique	La redevabilité, la documentation, la propriété des livrables	Réversibilité, transfert de la documentation

La configuration change aussi la déclaration d’applicabilité, mais moins qu’on ne l’imagine. Le critère n’est pas d’entraîner un modèle : c’est de concevoir ou non un système. Une organisation qui se borne à consommer un service tel quel peut justifier d’écarter les contrôles qui encadrent la conception et le développement (A.6.1.2, A.6.1.3, A.6.2.3), en rattachant cette exclusion à son appréciation des risques et à l’absence d’exigence externe applicable qui l’imposerait. Restent pertinents ceux qui valent pour tout système mis en service : exigences attendues, vérification et validation, déploiement, exploitation et surveillance, documentation technique remise à chaque public concerné, journaux (A.6.2.2, A.6.2.4 à A.6.2.8). Cette documentation ne s’écarte pas au motif qu’on achète : l’Annexe B (B.10.3) recommande au contraire d’obtenir du fournisseur ce qu’il faut pour la produire. Héberger un modèle à poids ouverts ne fait pas de vous son concepteur ; cela vous transfère en revanche son exploitation — infrastructure, versions, filtres, sécurité —, que vous assurez au titre de ces mêmes contrôles. La conception et le développement redeviennent pertinents dès que vous adaptez ou réentraînez le modèle, comme dès que vous bâtissez votre propre application autour d’une API.

Les questions à poser

La page du domaine A.10 donne les cinq questions propres à l’IA. Une due diligence complète va plus loin, et classe chaque réponse selon qu’elle est publique, obtenable sous accord de confidentialité ou non obtenable.

L’engagement de ne pas utiliser vos données pour entraîner le modèle est-il contractuel, ou seulement déclaratif ?
Quelle est la durée de conservation des entrées et des sorties, et existe-t-il une option de non-conservation ?
Quels sous-traitants interviennent, et avec quel préavis en cas de changement ?
Pouvez-vous épingler une version datée ? Quel préavis avant une dépréciation ou un changement de version par défaut ?
Quelle documentation des limites du système est fournie : usage prévu, taux d’erreur, conditions dans lesquelles il se dégrade ?
Quelles certifications et quels rapports d’audit, avec quel périmètre, quelles dates, quel organisme ?
Où les données sont-elles stockées et traitées ?
Quel délai et quelle procédure de notification en cas d’incident ?
Quels journaux le fournisseur conserve-t-il, et pouvez-vous les obtenir ?

Ce qui n’est pas obtenable — la composition des données d’entraînement d’un modèle fermé, typiquement — ne se passe pas sous silence. Il s’écrit comme une incertitude dans l’appréciation des risques, avec les mesures qui la compensent.

La certification du fournisseur ne vaut pas la vôtre

Un fournisseur certifié ISO/IEC 42001 démontre qu’il exploite un système de management conforme, dans un périmètre donné, à une date donnée. Il ne démontre ni que votre usage est maîtrisé, ni que le service que vous consommez entre dans son périmètre.

Une certification se lit donc comme une pièce d’entrée de la due diligence, jamais comme sa conclusion : on en vérifie le périmètre, les dates de validité et l’organisme qui l’a délivrée — et l’accréditation de celui-ci, comme l’explique la page sur le choix d’un organisme.

Proportionner l’effort

Le contrôle n’impose aucune méthode de classement. Les recommandations de l’Annexe B (B.10.3) invitent toutefois à moduler le choix des fournisseurs, les exigences qu’on leur fixe et l’intensité du suivi selon le type de fournisseur, ce qu’il livre et le risque qui en découle ; elles recommandent aussi de documenter la façon dont les systèmes ou composants fournis s’intègrent aux vôtres. Pour proportionner l’effort, une grille en trois niveaux suffit le plus souvent, sur des critères comme l’effet sur les personnes, la sensibilité des données, la dépendance et la facilité à changer de fournisseur.

Niveau	Situation type	Traitement proposé
Critique	Le service influence une décision qui affecte des personnes — recrutement, crédit, santé —, traite des données sensibles ou soutient une fonction critique	Due diligence approfondie, contrat renforcé, surveillance continue, réexamen annuel
Important	Usage de production sans effet direct fort sur des personnes	Due diligence standard, réexamen tous les deux ans
Faible	Usage interne, données non sensibles, changement de fournisseur facile	Due diligence allégée, réexamen lors d’un changement

Quel que soit le niveau, certains événements appellent un réexamen anticipé : changement de version majeur, incident, changement de sous-traitant, modification unilatérale des conditions, évolution réglementaire.

Les changements silencieux

C’est le risque propre aux fournisseurs d’IA. Rien ne change chez vous, et le système en production n’est plus celui que vous avez évalué : nouvelle version, alias de modèle qui pointe désormais ailleurs, modification des filtres ou de la politique d’usage, dépréciation, retrait.

Les parades, par ordre de solidité :

Épingler une version datée plutôt qu’un alias générique, quand le fournisseur le permet.
Rejouer un jeu d’évaluation stable avant d’accepter un changement de version.
Déployer progressivement, sur une fraction de l’usage.
Suivre les préavis et s’abonner aux notifications de dépréciation.
Prévoir un repli, vers une version antérieure ou un autre fournisseur.

Sur le plan normatif, un tel changement relève d’abord de la clause 8.1 : l’organisation garde la maîtrise de ce qui lui vient de l’extérieur, et, face à un changement qu’elle n’avait pas planifié, elle en examine les conséquences et agit pour en limiter les effets défavorables. Annoncé avant la bascule et jugé significatif, il fait reprendre l’appréciation des risques (8.2) et l’évaluation d’impact (8.4) avant le basculement. Découvert après coup, il relève de 8.1 et, s’il est jugé significatif, de 8.2 ; ses effets sur les personnes sont repris à la prochaine évaluation planifiée, et les examiner sans attendre reste la conduite prudente. La clause 6.3 n’intervient que si l’organisation décide, en réponse, de modifier son système de management lui-même, son processus de sélection des fournisseurs par exemple. Le guide sur la dérive en production détaille la surveillance qui permet de le détecter.

Ce qu’il faut obtenir par contrat

Chaque clause répond à un objectif, et c’est l’objectif qui se défend en audit :

l’usage des données : pas d’entraînement sans accord exprès ;
la conservation et la suppression, y compris en fin de contrat ;
la localisation des traitements ;
les préavis de dépréciation et de changement de version par défaut ;
la notification des changements de sous-traitants ;
la notification des incidents, avec un délai ;
un droit d’audit, ou à défaut la remise d’attestations ;
la réversibilité : export des données et plan de sortie ;
la documentation transmise, sur l’usage prévu et les limites du système.

Ce qui n’a pas pu être obtenu s’écrit, et se traite comme un risque. Ces éléments ne remplacent pas l’analyse d’un juriste. Pour les entités financières, le règlement DORA impose en outre un contenu contractuel minimal avec les prestataires de services numériques.

Ce que le contrôle ne demande pas

Aucune certification du fournisseur, aucun audit sur site, aucun modèle de contrat. Il ne demande pas non plus d’obtenir l’impossible : un fournisseur qui refuse une clause n’interdit pas son usage, à condition que l’écart soit identifié, documenté et assumé. C’est le silence qui n’est pas recevable.