Quand évaluer un fournisseur d’IA et que faire ensuite

La diligence raisonnable concernant un fournisseur d’IA doit commencer avant que son service reçoive des données importantes, se connecte aux systèmes de l’entreprise ou influence des décisions lourdes de conséquences. Répétez les contrôles concernés lorsque sa finalité, ses autorisations, le traitement des données ou le service évoluent. Commencez par définir l’usage prévu, désigner un responsable et réunir les preuves nécessaires à une autorisation délimitée.

Pour les équipes SaaS, cette évaluation relie les achats aux décisions produit, sécurité, confidentialité et exploitation. Les recommandations suivantes décrivent une méthode pratique, pas un questionnaire légal universel. La profondeur de l’examen doit refléter les défaillances possibles et les personnes touchées. Un assistant rédigeant une aide publique appelle une évaluation différente d’un agent modifiant les comptes clients.

Repérer les déclencheurs

Commencez lorsqu’il reste possible de changer de fournisseur, de limiter l’usage ou de négocier les conditions. Attendre la signature ou le lancement complique la résolution des questions ouvertes. Incluez les essais gratuits, abonnements des salariés, API, modèles intégrés et fonctions d’IA activées dans une plateforme existante.

Ces événements doivent ouvrir ou rouvrir un examen :

• Nouvel achat : une équipe propose un service ou une intégration d’IA.
• Nouvelle capacité : un fournisseur existant ajoute un assistant, une fonction de recherche documentaire ou une action automatisée.
• Davantage de données : un pilote passe d’exemples synthétiques aux dossiers clients ou documents confidentiels.
• Davantage de pouvoirs : un outil exécute des actions qu’il se contentait de proposer.
• Changement substantiel : routage des modèles, hébergement, conservation, conditions ou sous-traitants évoluent d’une manière pertinente pour l’autorisation.
• Constat défavorable : un incident, une réclamation ou une évaluation échouée remet en cause une hypothèse justifiant la poursuite de l’usage.

Le renouvellement constitue un point de contrôle utile, mais ne doit pas être le seul déclencheur. Désignez une personne chargée de recevoir les notifications du service et de les rattacher au dossier de déploiement. La relation commerciale peut rester identique alors que le risque réel change sensiblement.

Déterminer les contrôles pertinents

Décrivez en une phrase la tâche, les utilisateurs, les données et les limites d’action. Exemple : « Les agents du support utilisent l’espace entreprise pour préparer des réponses à partir de documentation publique ; ils envoient eux-mêmes les réponses ; les tickets clients sont exclus. » Consignez aussi l’offre achetée et la configuration.

Identifiez ensuite les volets d’examen. La confidentialité évalue les traitements de données personnelles ; la sécurité, les accès et intégrations ; le produit, la qualité des sorties et les conséquences des erreurs ; le juridique, les obligations applicables et leur répartition contractuelle. Les achats coordonnent les preuves et le processus commercial. Dans une petite structure, une personne peut cumuler les rôles, mais chaque décision exige un responsable identifié.

Lorsque le RGPD s’applique, l’article 28 exige des garanties suffisantes des sous-traitants. RGPD, article 28. Faites établir les rôles des parties et les modalités du traitement avant de considérer le contrat standard du fournisseur comme suffisant.

Pour délimiter l’application du règlement sur l’IA, demandez au juridique d’identifier rôle, finalité prévue, dispositions et dates pertinentes. Une déclaration générale de conformité du fournisseur ne répond pas à ces questions propres au déploiement. Consignez le raisonnement et les points ouverts plutôt qu’une affirmation commerciale copiée dans l’autorisation.

Au 10 septembre 2026, les échéances de haut risque sont le 2 décembre 2027 pour l’annexe III et le 2 août 2028 pour l’annexe I. Calendrier actualisé de la Commission européenne. Vérifiez séparément les dispositions concernant votre usage avant de décider des mesures immédiates.

Quand un examen plus restreint est raisonnable

Sans fonctionnalité d’IA, le processus fournisseur habituel peut suffire. Si un outil traite uniquement des contenus publics, sans accéder aux systèmes ni agir, un examen d’IA plus court peut être proportionné. Documentez ces limites et confirmez que la configuration les impose.

L’absence de données personnelles ne supprime pas automatiquement l’examen. Confidentialité, propriété intellectuelle, fiabilité, continuité et engagements clients peuvent rester importants. Inversement, l’IA ne justifie pas de demander tous les documents à chaque fournisseur. Demandez des preuves utiles à une décision précise et expliquez les contrôles inapplicables.

Un pilote permet de réunir des preuves dans un périmètre convenu. Il n’autorise pas automatiquement l’envoi de données de production. Définissez données, utilisateurs, intégrations, durée et conditions d’arrêt avant d’accorder l’accès. Précisez qui pourra autoriser une extension après examen des résultats.

Suivre une méthode de décision en six étapes

1. Constituer le dossier d’usage

Consignez tâche, service, offre, utilisateurs, catégories de données, lieux, intégrations et actions autorisées. Nommez les responsables métier et technique. Liez le schéma d’architecture ou de flux de données et énumérez les usages exclus. Ce dossier devient la référence commune des spécialistes.

Séparez le déploiement prévu des fonctionnalités futures. Si l’équipe souhaite automatiser les remboursements plus tard, consignez ce projet comme un changement nécessitant un nouvel examen. Une feuille de route générale ne doit pas élargir discrètement l’autorisation actuelle.

2. Suivre les données et les accès

Demandez ce que deviennent les requêtes, pièces jointes, contenus récupérés, sorties, retours et journaux. Établissez conservation, suppression, accès du support, destinataires ultérieurs et utilisation pour l’entraînement. Rattachez les réponses à l’offre et aux paramètres réellement prévus.

Pour les services connectés, consignez identifiants et autorisations. Limitez l’accès au strict nécessaire, puis testez cette limite. « Lecture seule » dans un formulaire ne suffit pas si l’intégration reçoit des droits d’écriture. Conservez un export de configuration ou une preuve équivalente.

3. Relier les affirmations aux preuves

Utilisez un tableau court : affirmation, document ou test, périmètre, date, évaluateur et lacune restante. Un rapport de sécurité peut étayer des contrôles dans son périmètre ; un contrat, des engagements convenus ; un test, un comportement observé dans des conditions consignées. Gardez ces distinctions visibles.

Demandez des précisions lorsqu’un document exclut la fonction d’IA ou couvre un autre environnement. Si les preuves manquent, notez l’incertitude et son effet sur la décision. Taille, réputation ou démonstration soignée ne doivent pas clore une question sans réponse.

4. Tester le fonctionnement réel

Fixez les critères d’acceptation avant les tests. Incluez tâches représentatives, informations incomplètes, entrées trompeuses, limites d’autorisation et reprise après défaillance. Utilisez des données synthétiques ou autorisées. Consignez version disponible, paramètres, date, résultats et défauts non résolus.

Testez aussi le contrôle humain. L’évaluateur peut-il consulter les éléments justificatifs, rejeter une suggestion erronée et arrêter une action à temps ? Sinon, modifiez le processus ou réduisez la capacité. Une bonne moyenne ne doit pas masquer une défaillance exposant les informations d’un autre client.

5. Prendre une décision explicite

Choisissez : autorisation dans le périmètre, autorisation conditionnelle, limitation au pilote, escalade ou refus. Distinguez les conditions bloquant la production des améliorations ultérieures. Attribuez à chaque condition un responsable, une échéance et une preuve d’achèvement.

Consignez risques résiduels et exceptions autorisées, avec justification et expiration. La signature ne doit pas lever implicitement un blocage technique ou relatif à la confidentialité. La personne activant l’intégration doit comprendre la décision sans reconstituer les échanges de courriels et de messagerie.

6. Surveiller et préparer la sortie

Fixez une date d’examen selon l’usage et ses risques, en complément des événements précédents. Attribuez la responsabilité des notifications, incidents, réclamations et résultats d’évaluation. Rouvrez seulement les contrôles touchés lorsque cela se justifie, en conservant l’historique.

Décrivez comment révoquer les accès, retirer les intégrations, exporter les dossiers utiles, demander la suppression et poursuivre la tâche en cas de panne ou de sortie. Exercez les étapes critiques avant d’en dépendre. Des dossiers réutilisables réduisent aussi les doublons évoqués dans notre guide des examens manuels des risques fournisseurs.

Exemple : un assistant commence à lire des tickets privés

Imaginez un support utilisant déjà un assistant pour préparer des réponses à partir de documentation publique. Le produit souhaite maintenant récupérer des tickets privés. Fournisseur et abonnement restent identiques, mais le périmètre des données change. Un examen doit précéder l’activation.

Le responsable actualise le dossier. La confidentialité vérifie les modalités du traitement ; la sécurité teste les autorisations des tickets et la séparation entre clients ; le produit recherche les divulgations inutiles dans les réponses. Les achats confirment que les engagements couvrent la nouvelle fonction. L’usage initial de rédaction reste en place pendant ces contrôles.

Si les autorisations échouent aux tests, la nouvelle capacité reste bloquée. Si les contrôles réussissent, l’autorisation consigne données permises, paramètres, résultats, supervision et déclencheurs de réexamen. Cet exemple illustre une décision, sans conclure qu’un déploiement précis respecte toutes les lois applicables.

Éviter les erreurs courantes

Autoriser un nom d’entreprise plutôt qu’un usage défini rend les changements ultérieurs invisibles. Accumuler des documents sans constats crée du stockage plutôt que des preuves. Qualifier un pilote de « faible risque » sans limiter données ou autorisations laisse la question essentielle ouverte.

Autre erreur : attribuer toutes les actions à la « conformité ». Le responsable métier explique la tâche et en assume la responsabilité opérationnelle ; l’ingénierie vérifie les contrôles ; les spécialistes décident dans leur domaine. Un coordinateur peut faire avancer le processus sans devenir responsable de tous les risques.

Questions fréquentes

Quel est l’objectif pratique ?

Décider si un service précis peut servir une tâche définie, avec preuves, conditions et responsables. Le résultat doit indiquer ce que l’équipe peut activer et ce qui reste restreint.

Que doit documenter un fondateur en premier ?

La tâche, les données, les autorisations et le responsable. Ces faits rendent les questions suivantes concrètes. Commencez par un usage important plutôt qu’un questionnaire indifférencié distribué partout.

Chaque changement impose-t-il de tout recommencer ?

Non. Comparez le changement aux hypothèses consignées et rouvrez les contrôles pertinents. Conservez la justification en l’absence d’effet substantiel. Faites remonter les conséquences incertaines.

Que faire la semaine prochaine ?

Choisissez un service d’IA proposé ou actif. Rédigez son dossier d’usage, identifiez la principale lacune de preuve et désignez un évaluateur. Convenez d’une décision délimitée et consignez le prochain déclencheur avant d’élargir l’accès.

Sources et crédit photographique

Références juridiques vérifiées le 10 septembre 2026. Les sources liées étayent les affirmations juridiques et calendaires ; la méthode et l’exemple sont des recommandations éditoriales.

Photo : Team Meeting, woodleywonderworks, CC BY 2.0. Redimensionnée à 1280 × 482 pixels. Photographie illustrative.