Questions à poser pour choisir un fournisseur IA et maîtriser les risques

Table des matières :

1. Partir des usages réels et des données, pas des slogans
2. Où vont les données: hébergement, juridiction applicable et rétention
3. Sécurité opérationnelle: chiffrement, contrôle d’accès, audits et incidents
4. Maîtrise du modèle: qualité, mises à jour, biais et traçabilité
5. Contrat et exploitation: niveaux de service, réversibilité et coûts réels
6. Transformer ces questions en décision: une démarche en trois livrables

Partir des usages réels et des données, pas des slogans

Choisir un fournisseur IA commence par une clarification opérationnelle: quel usage, quelle donnée, quel niveau de criticité, et quel horizon de dépendance. Un « fournisseur IA » désigne ici un prestataire qui fournit un modèle (par exemple un modèle de langage), une interface (application, API) et une infrastructure d’exécution pour produire des réponses. Sans cadrage, on compare des offres incomparables et l’on découvre trop tard que la meilleure démonstration n’était pas la meilleure option de production.

L’« inférence » est la phase où le modèle produit une réponse à partir d’une entrée, tandis que l’« entraînement » est la phase où l’on ajuste les paramètres du modèle à partir de données. Cette distinction doit apparaître noir sur blanc dans vos échanges: beaucoup de risques portent sur l’entraînement (réutilisation de données, fuites par mémorisation), mais les risques d’inférence (exposition de prompts, journaux, métadonnées, résultats sensibles) sont souvent plus fréquents au quotidien.

Pour structurer la décision, vous pouvez reprendre une définition classique du risque et la rendre actionnable. La norme ISO 31000 (2018) rappelle que « le risque est l’effet de l’incertitude sur les objectifs » (ISO 31000:2018, traduction française). Vos objectifs ne sont pas seulement la conformité: ils incluent la continuité d’activité, la qualité des réponses, la maîtrise des coûts, et la capacité à changer de solution.

Un bon cadrage consiste aussi à expliciter le “niveau d’autonomie” autorisé. Par exemple:

• IA assistive: l’IA propose, un humain valide (ex. réponse à un client, rédaction de note interne).
• IA semi-automatisée: l’IA exécute mais sous garde-fous (ex. génération de brouillons de tickets, synthèses, extraction structurée).
• IA automatisée: l’IA déclenche une action (ex. modification d’un dossier, envoi d’un email, décision de tri).
  Dans ce dernier cas, l’exigence de traçabilité, de tests et de supervision doit être nettement plus élevée.

Mini-scénario (fréquent en France): une équipe support (centre de services, DSI interne, ou prestataire) veut réduire le temps de traitement des tickets. Si l’usage réel est “suggérer une réponse” à partir d’une base de connaissances, les exigences clés seront la qualité sur votre documentation, la confidentialité (tickets contenant parfois des données personnelles) et l’intégration (SSO, ITSM). Si l’usage dérive en “répondre automatiquement au client”, la criticité et les preuves attendues changent fortement (supervision, journalisation, tests réguliers, gestion des incidents).

Questions à poser dès la phase de cadrage (à documenter dans un cahier des charges ou un appel d’offres):

• Quels cas d’usage sont visés (assistance utilisateur, recherche documentaire, génération de code, analyse de tickets) et lesquels sont exclus?
• Quelles catégories de données entrent dans le système (données à caractère personnel, secret des affaires, données de santé, données de mineurs, informations classifiées internes)?
• Quels impacts métiers en cas d’erreur (réponse inexacte, fuite, indisponibilité) et quelles obligations de traçabilité?
• Quel est le niveau d’automatisation autorisé (proposition, exécution, déclenchement), et quelles étapes imposent une validation humaine?
• Quels indicateurs feront dire, dès le départ, que le projet est un succès (qualité mesurée, gain de temps, réduction des erreurs, satisfaction utilisateur)?

Où vont les données: hébergement, juridiction applicable et rétention

L’« hébergement » est le fait de stocker et traiter des données sur une infrastructure située dans un ou plusieurs centres de données. À la première lecture, beaucoup réduisent l’hébergement à une région cloud; en pratique, vous devez aussi considérer les flux, les sauvegardes, les journaux et les outils de support. Demandez une cartographie de bout en bout: entrée utilisateur, traitement, stockage temporaire, archivage, supervision.

Pour rendre cette cartographie exploitable, demandez qu’elle distingue clairement:

• Données de contenu: prompts, pièces jointes, documents indexés (RAG), réponses.
• Données techniques: identifiants, adresses IP, user-agent, métriques de latence, IDs de requête.
• Données de sécurité: logs d’authentification, alertes, traces d’administration.
• Données de support: tickets d’incident, captures, échantillons éventuellement partagés.

La « juridiction applicable » est l’ensemble des règles de droit et des autorités compétentes susceptibles de s’appliquer au fournisseur et à ses sous-traitants, notamment en matière d’accès aux données. Ce point ne se résume pas au pays du centre de données: il inclut aussi le pays d’immatriculation de la maison mère, les chaînes de sous-traitance et les obligations légales qui peuvent s’imposer au prestataire. L’objectif n’est pas de chercher une immunité, mais de mesurer l’exposition et d’aligner vos données les plus sensibles sur le niveau de risque acceptable.

Dans un contexte France/UE, la question se traduit souvent de manière très opérationnelle: quelles données peuvent quitter l’EEE, à quelles conditions (contrats, mesures techniques, chiffrement, contrôle des clés), et quels composants (anti-abus, détection de fraude, support) peuvent introduire des flux inattendus. Sans faire de “sur-droit”, c’est un sujet de gouvernance: vous devez pouvoir expliquer et justifier où vont les données et pourquoi.

La « rétention » est la durée pendant laquelle vos données et métadonnées (prompts, sorties, identifiants techniques, adresses IP, journaux) sont conservées. Le RGPD fixe un repère clair: les données doivent être « conservées sous une forme permettant l’identification des personnes concernées pendant une durée n’excédant pas celle nécessaire au regard des finalités » (Règlement (UE) 2016/679, art. 5(1)(e), 27/04/2016). Vous n’obtiendrez pas une conformité « garantie » par un fournisseur, mais vous pouvez exiger des paramètres de rétention cohérents avec vos finalités.

Table simple (à adapter) pour éviter les malentendus lors des échanges fournisseur:

Élément	Exemples	Risque typique	Question clé
Prompts & pièces jointes	extrait de contrat, CV, ticket support	fuite / réutilisation / accès support	utilisés pour améliorer le modèle? rétention configurable?
Réponses du modèle	synthèse, recommandation, brouillon	divulgation involontaire	journalisation des sorties? masquage?
Logs d’accès	userID, IP, horodatage	ré-identification / corrélation	durée de conservation? export SIEM?
Données RAG (index vectoriel)	embeddings de documents internes	extraction indirecte d’informations	chiffrement? suppression? séparation par client?

Questions concrètes à poser sur les données:

• Les prompts, pièces jointes et réponses sont-ils utilisés pour entraîner ou améliorer les modèles? Si oui, dans quelles conditions d’opt-in, d’anonymisation, et avec quelles exclusions?
• Quelles durées de conservation s’appliquent à: contenus, journaux, traces de sécurité, sauvegardes? Peut-on choisir et prouver les durées (export de configuration, attestation, rapports)?
• Où les données transitent-elles (région, pays), y compris pour le support, la détection d’abus, l’anti-fraude et la télémétrie?
• Quels sous-traitants interviennent (hébergeur, supervision, anti-spam, OCR, traduction) et comment sont-ils listés et mis à jour?
• En cas de demande de support, quelles informations un opérateur peut-il voir (prompts, réponses, métadonnées)? Peut-on imposer un mode “support sans contenu” sauf escalade formalisée?

Sécurité opérationnelle: chiffrement, contrôle d’accès, audits et incidents

La sécurité ne se résume pas à un logo de certification. Un bon fournisseur est capable d’expliquer, avec des éléments vérifiables, comment il réduit la probabilité d’un incident et comment il en limite l’impact. Exigez des mesures de sécurité « en profondeur »: segmentation réseau, chiffrement, gestion des secrets, surveillance, durcissement, et processus de gestion des vulnérabilités.

Le « chiffrement » est la transformation d’une information en un format illisible sans clé, afin de protéger la confidentialité en transit et au repos. Dans l’IA, le sujet critique devient vite la gestion des clés. Demandez si l’offre supporte le BYOK (Bring Your Own Key), c’est-à-dire l’utilisation de clés gérées par votre organisation, et si le fournisseur supporte une séparation des rôles entre administrateurs, opérateurs et support. Sur des usages sensibles, ce point pèse souvent plus que la performance brute.

En pratique, vous pouvez rendre la discussion “testable” en demandant un schéma clair:

• chiffrement en transit (TLS) entre vos utilisateurs, votre SI, et le fournisseur;
• chiffrement au repos (stockage, sauvegardes, index RAG);
• gestion des clés: qui peut y accéder, comment elles sont renouvelées, comment on révoque;
• journalisation des accès aux clés et aux secrets.

Un « audit » est une évaluation indépendante ou interne des contrôles et processus, produisant des preuves. Sans vous enfermer dans une liste figée, demandez quels rapports sont disponibles (par exemple ISO/IEC 27001, SOC 2 Type II) et quel est leur périmètre exact.

Deux angles souvent sous-estimés sur les services IA:

• La sécurité des “connecteurs” (RAG, plugins, accès à SharePoint, Jira, messagerie): une IA très sécurisée n’empêche pas une fuite si le connecteur a des droits trop larges.
• Les “frontières” d’environnement: dev/test/prod, espaces projet, tenants; une erreur de configuration peut exposer des documents d’une équipe à une autre.

Questions de sécurité à poser, orientées preuves:

• Quels mécanismes d’authentification sont supportés (SAML, OpenID Connect), et peut-on imposer MFA, des politiques de mot de passe, et des restrictions par adresse IP?
• Comment sont isolés vos environnements (tenant dédié ou mutualisé), et quelles protections existent contre l’exfiltration via l’interface (limites, filtrage, prévention de fuite de données)?
• Quels engagements sur la gestion des vulnérabilités (délais de correction, programmes de divulgation, tests d’intrusion) et sur la journalisation (contenu des logs, accès, export vers votre SIEM)?
• Quel est le processus en cas d’incident: notification, délais, informations partagées, rapport post-mortem, preuve de containment, et exercice de crise?
• Avez-vous un mécanisme d’audit d’administration (qui a changé un paramètre, ajouté un connecteur, modifié une politique de rétention), exportable et horodaté?

Références utiles pour cadrer vos exigences, sans surinterpréter: le NIST publie un cadre de gestion des risques IA (AI RMF 1.0, 01/2023) qui insiste sur la gouvernance et la mesure des risques tout au long du cycle de vie (documentation officielle: NIST AI Risk Management Framework). Côté européen, l’ENISA propose des recommandations sur la cybersécurité des systèmes d’IA et les menaces associées (voir notamment ses publications 2023-2024 sur l’IA et la cybersécurité: ENISA publications).

Maîtrise du modèle: qualité, mises à jour, biais et traçabilité

La « maîtrise du modèle » est la capacité à comprendre, configurer et surveiller le comportement du modèle dans le temps, sans dépendre exclusivement des décisions du fournisseur. Elle inclut le choix des versions, la gestion des paramètres, l’évaluation, et la capacité à détecter une dérive de performance. C’est un point central pour les organisations qui veulent industrialiser, car les modèles évoluent vite et un changement de version peut modifier des réponses de manière invisible.

Pour une mise en production, vous avez intérêt à demander des mécanismes de versionnage et de « gel » (locking) des modèles, au moins pour des périodes maîtrisées. Sans cela, vous pouvez respecter vos tests en préproduction et constater en production une hausse des hallucinations ou une baisse de qualité sur un type de documents. Mesurez la performance avec des métriques adaptées: taux de réponses factuellement incorrectes sur un jeu de tests, taux de refus, temps de réponse (p95), coût par 1 000 jetons, et taux d’escalade vers un humain.

Pour éviter un pilotage “au ressenti”, définissez un jeu de tests représentatif (même modeste) avec des cas réels anonymisés. Exemple de grille de mesures (à adapter):

• Exactitude factuelle: sur 100 questions, combien de réponses contiennent au moins une erreur vérifiable?
• Complétude: la réponse couvre-t-elle les points indispensables (checklist)?
• Robustesse: la réponse reste-t-elle correcte si l’utilisateur reformule?
• Sécurité: l’IA refuse-t-elle correctement une demande interdite (exfiltration, données sensibles)?
• Stabilité: le score varie-t-il fortement entre deux versions du modèle?

La « traçabilité » est la capacité à reconstituer qui a fait quoi, quand, avec quelle configuration et quelles données. En IA générative, cela passe souvent par la conservation contrôlée des prompts, de la version du modèle, des paramètres (température, top-p), et des sources utilisées dans le cas d’une approche RAG (retrieval augmented generation, que l’on peut traduire par génération augmentée par recherche documentaire). Sans traçabilité, vous ne pouvez ni auditer une décision, ni corriger un comportement, ni produire une justification crédible.

Point d’attention: en RAG, la traçabilité n’est pas seulement “quel modèle”, mais aussi quels documents ont été retrouvés (ou non). Un fournisseur mature doit pouvoir exposer, au minimum sur demande:

• la liste des documents (ou IDs) utilisés pour produire la réponse;
• le score de pertinence / la stratégie de recherche (top-k, seuil, reranking si applicable);
• la date de dernière indexation (utile quand la doc change souvent).

Questions à poser sur le modèle et la qualité:

• Avez-vous une documentation de type « model card » ou « system card » décrivant entraînement, limites, usages interdits, et risques connus? Quelles garanties de mise à jour de cette documentation?
• Peut-on verrouiller une version de modèle? Comment sont annoncées les évolutions (préavis, notes de version, environnement de test)?
• Quels outils fournissez-vous pour évaluer la qualité sur nos cas d’usage (jeux de tests, red teaming, détection d’hallucinations, filtres de sûreté configurables)?
• Comment gérez-vous les biais et la sécurité de contenu (réglages, seuils, journalisation des refus), et quelles sont les responsabilités respectives client et fournisseur?
• En cas de dégradation, quels leviers sont disponibles sans changer de fournisseur (réglages, modèles alternatifs, routing, cache, règles de refus, templates de prompts)?

Pour les traitements de données personnelles avec une automatisation à impact, la CNIL publie des repères méthodologiques sur l’IA et la protection des données, utiles pour structurer des questions de minimisation, de base légale et d’analyse d’impact (accès aux ressources CNIL: CNIL – ressources IA). L’idée n’est pas de transformer un fournisseur en garant juridique, mais d’obtenir des informations techniques permettant à votre DPO et à votre RSSI de faire une analyse de risque documentée.

Contrat et exploitation: niveaux de service, réversibilité et coûts réels

Un contrat IA robuste décrit des engagements exploitables, pas seulement des intentions. Le « niveau de service » (SLA) est un engagement chiffré sur la disponibilité et parfois sur les délais de réponse, assorti de mécanismes de mesure et de compensations. Vérifiez comment la disponibilité est calculée (périmètre, fenêtres de maintenance, exclusions) et si les incidents d’un sous-traitant sont inclus.

Au-delà de la disponibilité, demandez des éléments opérationnels souvent décisifs en production:

• SLO/SLA de latence (ex. p95) si l’usage est interactif;
• capacité et quotas (pics, limites par minute, politique de burst);
• support (horaires, délais de première réponse, escalade, langue, canal);
• statut public (page status, historique des incidents, post-mortems).

La « réversibilité » est la capacité à sortir du service en récupérant données, configurations et éléments nécessaires à la continuité, dans des délais et un coût maîtrisés. Réversibilité ne veut pas dire simplement exporter un CSV. Pour une solution IA, cela couvre au minimum: export des historiques nécessaires, des paramètres de sécurité, des jeux de tests, des prompts systèmes, des connecteurs RAG, et la documentation d’intégration. Un bon signal est l’existence de procédures de sortie testées, avec une option d’accompagnement.

Checklist “réversibilité” (courte, mais très discriminante) à faire confirmer avant signature:

• exporter la configuration (modèles, versions, politiques de sécurité, rétention);
• exporter les journaux (au moins métadonnées) et les métriques;
• récupérer les données RAG (sources, index ou mécanisme de reconstruction documenté);
• obtenir une attestation de suppression (périmètre, délais, sauvegardes);
• documenter l’équivalent fonctionnel minimal chez un autre fournisseur (dépendances techniques).

Le coût réel se cache souvent dans des postes non évidents: taux d’échec et de relance d’appels API, surcoût des contextes longs, coûts de réseau sortant, stockage de vecteurs pour la recherche documentaire, et support premium. Pour éviter les surprises, demandez un modèle de coût complet avec hypothèses (nombre d’utilisateurs, volumétrie de documents, jetons moyens par requête, p95 de latence). Comparez ensuite à votre budget et à vos contraintes opérationnelles.

Astuce simple: exigez un chiffrage sous forme de trois scénarios (bas / nominal / pic), avec un tableau de variables. Cela force le fournisseur (et vous) à rendre explicites les hypothèses (longueur moyenne des prompts, taux d’upload de pièces jointes, nombre de documents indexés, fréquence de ré-indexation).

Questions à poser côté contrat et exploitation:

• Quels SLA proposez-vous (disponibilité, p95/p99, support 24/7, délais de prise en charge)? Comment sont-ils mesurés et reportés?
• Quelles clauses encadrent l’usage des données (non-réutilisation, sous-traitants, localisation), et comment sont gérées les demandes d’accès légales (processus, transparence, notifications lorsque possible)?
• Quelle est la procédure de réversibilité (délais, formats d’export, suppression et attestation de suppression, assistance)? Avez-vous déjà réalisé des sorties chez des clients de taille comparable?
• Comment sont gérés les changements de prix, les limites de quotas, et les conditions de fin de vie d’un modèle ou d’une API?
• En cas d’arrêt d’un modèle/endpoint, quel est le préavis, et existe-t-il une solution de repli (modèle remplaçant, période de transition)?

Transformer ces questions en décision: une démarche en trois livrables

Un bon moyen d’avancer vite sans perdre la maîtrise est de produire trois livrables légers mais opposables: une fiche d’usage, une fiche de données, et une fiche d’exigences. La fiche d’usage décrit le flux utilisateur, les systèmes intégrés, et les impacts d’une erreur. La fiche de données liste les catégories, la sensibilité, les durées de conservation attendues et les interdictions. La fiche d’exigences convertit cela en questions et preuves attendues.

Pour que ces livrables soient directement utilisables en comité de validation (DSI/RSSI/DPO/métier), ajoutez deux éléments simples:

• un niveau de criticité par usage (faible/moyen/élevé) avec justification;
• une liste de “données interdites” (ex. secrets industriels, données de santé, etc.) et comment elles sont détectées/empêchées (charte, DLP, filtrage, formation).

Ensuite, organisez un pilote instrumenté plutôt qu’une simple démonstration. Un pilote instrumenté est un test en conditions proches de la production, avec journalisation, jeux de tests, mesures de latence et coûts, et un processus d’escalade. Exemples de critères de sortie de pilote: 95 % des requêtes répondent en moins de X secondes, taux d’erreur API inférieur à Y %, aucune donnée interdite dans les journaux, capacité à exporter les logs vers votre supervision, et stabilité de la qualité sur un jeu de tests fixe.

Ajout utile pour éviter les “pilotes éternels”: formalisez un plan de contrôle post-déploiement, même minimal, avec une cadence. Exemple:

• revue mensuelle d’un échantillon de conversations (anonymisées) pour détecter dérives et fuites;
• re-test trimestriel sur le jeu de tests figé;
• alerte sur hausse du coût moyen par requête (dérive de prompts, contextes trop longs);
• procédure de rollback si une mise à jour de modèle dégrade la qualité.

Enfin, préparez la sortie dès l’entrée. Cela paraît contre-intuitif, mais c’est ce qui réduit la dépendance et accélère la décision. Demandez au fournisseur de valider, avant signature, un scénario de réversibilité: quelles données vous récupérez, en quels formats, et en combien de temps. Si le fournisseur ne sait pas répondre, vous avez déjà une information sur la maturité de l’offre.

Action concrète à lancer cette semaine (effort: moyen, 1 à 2 demi-journées)

Rassemblez DSI, RSSI, DPO et métier autour d’un atelier unique, et produisez une grille de 25 questions maximum, réparties en 5 thèmes: données, sécurité, modèle, exploitation, réversibilité. Exigez pour chaque question un type de preuve (document, capture de configuration, rapport d’audit, démonstration en pilote). Vous obtenez ainsi un cadre reproductible pour comparer des fournisseurs IA, documenter vos arbitrages et sécuriser une mise en production progressive.