Liste de contrôle des fournisseurs d’IA pour les fondateurs et responsables conformité

Une liste de contrôle des fournisseurs d’IA doit établir si un service précis, dans une configuration précise, convient à l’usage prévu. Avant approbation, documentez l’usage, les flux de données, la chaîne de fournisseurs, les rôles juridiques, les contrôles de sécurité, les tests de performance, le contrat, la supervision humaine et le plan de sortie. Attribuez à chaque point ouvert un responsable et une décision : corriger avant lancement, limiter le pilote, faire remonter ou refuser.

Cette liste est un modèle pratique pour les fondateurs et responsables conformité SaaS, pas un questionnaire réglementaire ni une certification. Proportionnez les preuves au dommage possible. Un outil de rédaction utilisant des contenus publics exige moins d’examen qu’un système classant des candidats ou un agent capable de modifier des comptes clients. La réputation du fournisseur ne démontre pas la sécurité de votre déploiement.

Quand réaliser l’examen

Commencez avant de transmettre de vraies informations clients, de connecter des systèmes de production ou de prendre des engagements contractuels envers des clients. Recommencez lorsqu’un fournisseur existant ajoute de l’IA, que la finalité change, que de nouvelles données entrent, qu’un autre modèle ou sous-traitant ultérieur apparaît, ou que la vérification humaine diminue. Le renouvellement est un point de contrôle utile, mais ne doit pas être le seul déclencheur.

Utilisez la liste pour les services d’IA achetés, les API intégrées et les fonctions d’IA de produits SaaS ordinaires. Sans IA, votre examen fournisseur habituel peut suffire. Sans données personnelles, certaines questions de confidentialité peuvent être sans objet ; sécurité, confidentialité commerciale, fiabilité et contrat peuvent rester pertinents. Justifiez chaque réponse « sans objet ».

Pour chaque point, consignez réponse, lien vers les preuves, examinateur, date et lacune restante. Préférez une clause datée, un export de configuration ou un résultat de test à une assurance commerciale sans réserve.

1. Définir l’usage approuvé et les responsables

• Quelle tâche exacte le service accomplira-t-il, et pour qui ?
• Qui pourrait subir les conséquences de résultats ou d’actions incorrects ?
• Rédige-t-il, recommande-t-il, classe-t-il, décide-t-il ou exécute-t-il une action ?
• Qui assume le résultat métier, la configuration technique et l’approbation ?
• Quels usages, catégories de données et intégrations sont expressément exclus ?

Écrivez une limite techniquement applicable : « Rédiger des réponses de support à partir d’articles approuvés ; un salarié vérifie chaque réponse ; aucune modification de compte. » Évitez d’approuver « l’IA pour le support » sans limites. Consignez l’offre et l’environnement, car un compte d’essai et un déploiement entreprise peuvent avoir des conditions et contrôles différents.

Preuves à conserver : une description d’usage d’une page, les responsables nommés, un schéma d’architecture et les usages exclus. Une responsabilité non attribuée doit bloquer l’approbation jusqu’à ce qu’une personne l’accepte.

2. Identifier la chaîne de fournisseurs et de modèles

Demandez quelle entité juridique fournit le service, quels modèles il utilise, où se déroule le traitement et quelles autres organisations reçoivent vos données. Déterminez si les requêtes peuvent être orientées vers différents modèles et si votre configuration fixe ou autorise ces choix.

Demandez une liste à jour des fournisseurs et sous-traitants ultérieurs, la documentation pertinente, les informations disponibles sur modèles et versions, et la procédure de notification des changements importants. Distinguez ce que le fournisseur ne peut pas divulguer de ce qu’il n’a pas encore fourni. Les détails manquants doivent rester des incertitudes visibles, avec leur effet sur l’approbation expliqué.

Point de décision : pouvez-vous identifier les organisations et composants importants pour le risque envisagé ? Sinon, limitez le pilote aux contenus non sensibles ou faites remonter le dossier. Une longue liste de logos n’est pas une cartographie des flux de données.

3. Cartographier les données et les responsabilités de protection des données

Suivez les prompts, fichiers téléversés, documents récupérés, résultats, retours, accès du support et journaux. Interrogez séparément conservation, suppression, entraînement, accès humain et région de traitement pour chaque type de données pertinent. « Nous n’entraînons pas nos modèles avec vos données » ne précise ni la durée de conservation des journaux de détection des abus ni qui peut les consulter.

Lorsque le RGPD s’applique, déterminez les rôles de responsable du traitement et de sous-traitant pour chaque activité. L’article 28 exige des garanties suffisantes du sous-traitant et un contrat conforme ; l’article 35 impose une AIPD lorsque le traitement est susceptible d’engendrer un risque élevé. Examinez base juridique, transparence et chapitre V pour les transferts internationaux concernés. Ces vérifications dépendent du traitement réel, pas de l’étiquette « IA ». RGPD, articles 5–6, 13–14, 28, 35 et chapitre V.

Preuves à conserver : cartographie des flux, accord de traitement applicable, paramètres de conservation, évaluation des transferts si pertinente et examen documenté de la nécessité d’une AIPD. Testez la suppression avec un échantillon sans risque plutôt que de supposer que supprimer un espace de travail efface toutes les copies conservées.

4. Vérifier le champ du règlement sur l’IA et les dates applicables

Consignez le rôle de votre organisation, la destination du système et les obligations pertinentes. Acheter un produit ne fait pas nécessairement de vous uniquement un déployeur : marque, modification ou changement de destination peuvent influer sur les responsabilités. Examinez les pratiques interdites et les exigences de transparence applicables séparément du classement à haut risque. Règlement sur l’IA, articles 3, 5, 6, 25 et 50.

Selon la vérification du 8 septembre 2026, le calendrier modifié applique les principales règles à haut risque de l’annexe III à partir du 2 décembre 2027 et les règles correspondantes liées aux produits de l’annexe I à partir du 2 août 2028. Cela ne reporte pas toutes les obligations du règlement. Consignez les dispositions et règles transitoires pertinentes pour votre déploiement. Commission européenne : entrée en vigueur de l’Omnibus IA.

Point de décision : demandez les preuves adaptées au rôle et au système identifiés. Une déclaration générale de « conformité au règlement sur l’IA » ne remplace pas une analyse motivée du champ applicable. Faites remonter les incertitudes avant toute utilisation pour des décisions importantes.

5. Vérifier la sécurité et les limites d’intégration

Demandez comment le service authentifie les utilisateurs, sépare les environnements clients, protège les secrets, journalise les accès et gère les vulnérabilités. Examinez le périmètre et la période des rapports d’assurance indépendants. Vérifiez qu’ils couvrent le service d’IA et la configuration envisagés, et examinez les exceptions importantes.

Énumérez individuellement les permissions des outils connectés. Un assistant lisant des articles de connaissance ne doit pas recevoir automatiquement le droit d’exporter tous les tickets ou d’émettre des remboursements. Testez si des contenus récupérés peuvent détourner l’assistant, si des informations non autorisées apparaissent dans les résultats et si les actions risquées exigent une approbation distincte.

Preuves à conserver : configuration des accès, éléments d’assurance pertinents, permissions d’intégration, résultats des tests et décisions correctives. Donnez explicitement aux responsables techniques la charge de désactiver les accès inutiles avant lancement.

6. Tester l’utilité, les défaillances et la supervision humaine

Définissez les critères d’acceptation avant la démonstration. Préparez des cas représentatifs : entrées incomplètes, documents trompeurs, questions sans réponse disponible, langues pertinentes et abus plausibles. Utilisez des contenus synthétiques ou autrement autorisés. Consignez configuration et date du test pour délimiter la portée du résultat.

Évaluez ce qui compte pour la tâche : exactitude, traçabilité, divulgation inappropriée, traitement incohérent et arrêt sûr lorsque le système ne peut répondre. Pour des recommandations importantes, vérifiez que les examinateurs disposent des informations, du temps, de l’autorité et de la capacité pratique nécessaires pour contester un résultat.

Le NIST AI RMF organise la gestion des risques autour de Govern, Map, Measure et Manage. Il peut structurer cet examen, mais son adoption ne démontre pas à elle seule la conformité juridique. NIST AI RMF Core.

Point de décision : convenez des défaillances bloquant le lancement et de celles maîtrisables par un usage restreint. « Un humain intervient » ne suffit pas si cette personne accepte habituellement les résultats sans les vérifier.

7. Rapprocher le contrat de la configuration

Vérifiez que les conditions signées couvrent l’offre achetée, les usages autorisés, les données, la confidentialité, les engagements de sécurité, la coopération lors d’incidents, les changements importants et la résiliation. Demandez qui détient ou peut utiliser les entrées et résultats, quelles restrictions s’appliquent et ce qui se passe lors d’une réclamation de propriété intellectuelle. Ne déduisez ni propriété ni protection du discours commercial.

Comparez les promesses aux paramètres. Si le contrat permet de refuser l’entraînement sur vos données, vérifiez que ce choix est activé et qui peut le modifier. Si la suppression est promise, consignez procédure, exclusions et preuves accessibles. Demandez comment le fournisseur vous aidera à enquêter sur un incident et à respecter vos propres obligations.

Preuves à conserver : conditions signées, annexes pertinentes, exceptions approuvées et preuves de configuration. Distinguez les négociations commerciales des conditions à remplir avant l’envoi de données de production.

8. Documenter la décision, le suivi et la sortie

Utilisez des résultats explicites : approuvé dans le périmètre, approuvé sous conditions, pilote restreint, transmis pour arbitrage ou refusé. Consignez risques résiduels, personne habilitée à les accepter, échéances et prochaine date d’examen. Un blocage de lancement non résolu ne doit pas devenir une simple tâche de suivi parce que la mise en production approche.

Nommez une personne chargée de surveiller changements importants, incidents, contrôles qualité échoués, réclamations et extensions d’usage. Décidez des événements imposant un nouvel examen. Confirmez que l’équipe peut révoquer les accès, retirer les intégrations, exporter les documents nécessaires, demander la suppression et poursuivre le processus si le fournisseur devient indisponible.

Preuves à conserver : décision signée et procédure d’arrêt ou de repli testée. L’approbation doit être compréhensible par un collègue absent des échanges fournisseurs. Reliez-la aux preuves de diligence destinées aux investisseurs, au lieu de reconstruire le dossier à chaque examen.

Une fiche pratique d’approbation

Utilisez cette fiche compacte pour un fournisseur et un usage. Joignez les preuves plutôt que d’y copier des rapports entiers.

| Champ | Éléments à consigner | | --- | --- | | Périmètre | Service, offre, finalité, utilisateurs, données, intégrations, exclusions | | Responsabilité | Responsable métier, technique, examinateur juridique/vie privée, approbateur | | Constats | Références des preuves, tests, incertitudes, champ juridique | | Décision | Résultat, justification, risques résiduels, exceptions acceptées | | Conditions | Action requise, responsable, échéance, dépendance du lancement | | Suivi | Date d’examen, déclencheurs, contact incidents, procédure de sortie |

Une règle de clôture utile exige une preuve ou une lacune explicite pour chaque question requise, un traitement pour chaque lacune et un responsable pour chaque condition. « Questionnaire reçu » est un jalon d’avancement, pas une décision d’approbation.

Exemple : un assistant de rédaction pour le support

Supposons qu’une équipe SaaS souhaite faire rédiger ses réponses clients par un assistant. La proposition initiale connecte toutes les archives de tickets et autorise l’envoi automatique. L’examen repère des pièces jointes privées, une conservation des journaux incertaine et des étapes de dépannage parfois inventées.

Un pilote restreint pourrait utiliser des articles approuvés, des tickets synthétiques, aucun envoi automatique et une vérification documentée par les salariés. Avant production, l’équipe clarifierait la conservation, limiterait les accès de récupération, testerait des défaillances représentatives et approuverait le contrat pertinent. Ces contrôles sont illustratifs ; ils ne garantissent pas l’acceptabilité de tout déploiement de support.

Si l’équipe active ensuite les remboursements, l’approbation initiale ne décrit plus l’usage. Rouvrez l’examen des permissions d’écriture, scénarios d’abus, autorisations et moyens de récupération. Une fiche réutilisable est donc plus utile qu’un badge « approuvé » couvrant tout le fournisseur. Elle réduit aussi les doublons décrits dans notre guide des examens manuels du risque fournisseur.

Erreurs courantes et questions fréquentes

Un certificat de sécurité suffit-il ?

Non. Il peut étayer certaines affirmations de sécurité dans son périmètre. Il ne détermine pas si votre usage des données, votre rôle juridique, les résultats, intégrations et contrat conviennent. Conservez-le avec les preuves propres au déploiement.

Tous les fournisseurs d’IA nécessitent-ils le même examen ?

Non. Allégez les contrôles pour les usages réversibles à faible impact et approfondissez-les pour les données sensibles, décisions importantes ou permissions étendues. Documentez la justification de cette profondeur et les conditions qui la modifieraient.

Que doit documenter un fondateur en premier ?

Commencez par l’usage exact, les catégories de données, le responsable métier et les permissions. Ces faits permettent aux spécialistes de demander les bonnes preuves. Sans eux, même un questionnaire détaillé peut décrire le mauvais service.

Que faire si le fournisseur refuse des preuves importantes ?

Consignez le refus et l’incertitude créée. Envisagez d’autres preuves, un déploiement plus limité ou un autre fournisseur. Ne clôturez pas le point simplement parce que le fournisseur invoque la confidentialité.

Quand la liste est-elle terminée ?

Pour la décision actuelle, lorsque périmètre, preuves, lacunes, conditions et approbateur responsable sont consignés. Le processus opérationnel continue par le suivi et la réévaluation. Commencez cette semaine avec un fournisseur envisagé et rendez cette fiche réutilisable.

Sources et crédit photographique

Les liens associés aux affirmations renvoient au RGPD, au règlement sur l’IA consolidé actuel, à la mise à jour de la Commission européenne et au NIST AI RMF Core. La liste opérationnelle et l’exemple sont des recommandations éditoriales, pas des exigences légales supplémentaires.

Image : réunion de l’équipe Wiki Loves Monuments à Vienne, photographiée par Manfred Werner (Tsui), via Wikimedia Commons, CC BY-SA 4.0. Redimensionnée. Illustration d’un examen collaboratif ; aucun soutien n’est sous-entendu.