SaaS et IA : clauses contractuelles pour les acheteurs

L’acquisition de solutions d’intelligence artificielle en mode SaaS (Software as a Service) est devenue le mode predominant d’accès à l’IA pour les entreprises. Chatbots, outils d’analyse prédictive, systèmes de recommandation, solutions de traitement automatisé du langage naturel : la majorité des systèmes d’IA déployés en entreprise sont fournis par des éditeurs tiers sous forme d’abonnement. Cette externalisation presente des avantages opérationnels évidents mais cree des risques juridiques spécifiques que seul un cadre contractuel rigoureux peut maîtriser.

Le AI Act et le RGPD imposent des obligations tant au fournisseur qu’au deployeur (l’acheteur). L’acheteur d’une solution SaaS d’IA ne peut pas se décharger de ses responsabilités en invoquant le recours à un prestataire : il reste responsable de l’utilisation du système et des décisions prises sur la base de ses résultats. Le contrat d’acquisition constitue donc l’instrument juridique essentiel pour répartir les responsabilités, garantir la conformité et protéger les intérêts de l’acheteur.

Le cadre juridique applicable

Les obligations de l’acheteur-deployeur au titre du AI Act

L’acheteur d’une solution SaaS d’IA est un “deployeur” au sens du AI Act. Pour les systèmes à haut risque, le deployeur à des obligations propres qui ne peuvent être satisfaites que si le contrat les prend adequatement en compte.

Le deployeur doit utiliser le système conformément aux instructions d’utilisation (article 26), s’assurer que les personnes chargées du contrôle humain disposent des compétences et de l’autorité nécessaires, s’assurer que les données d’entrée sont pertinentes et représentatives, surveiller le fonctionnement du système et signaler les incidents au fournisseur, réaliser une analyse d’impact sur les droits fondamentaux (pour les deployeurs publics et les entités fournissant des services publics), enregistrer son utilisation du système dans la base de données de l’UE (pour les deployeurs publics) et conserver les journaux de bord automatiquement generes par le système.

Les obligations au titre du RGPD

L’acheteur qui utilise une solution SaaS d’IA pour traiter des données personnelles est généralement responsable de traitement au sens du RGPD. Le fournisseur SaaS est sous-traitant lorsqu’il traité des données personnelles pour le compte de l’acheteur. L’article 28 du RGPD impose alors un cadre contractuel détaillé, dont le contenu est analysé dans notre guide sur la sous-traitance IA.

L’acheteur doit s’assurer que le fournisseur presente des garanties suffisantes, que le contrat contient les clauses obligatoires de l’article 28, que les droits des personnes concernées sont effectivement exercables et qu’une AIPD est réalisée lorsque le traitement presente un risque élevé.

Les clauses contractuelles essentielles

1. Clause de définition et de qualification du système d’IA

Le contrat doit qualifier précisément le système d’IA fourni : sa nature (apprentissage automatique, système expert, modèle de langage, etc.), sa finalité prévue, son niveau de risque au sens du AI Act, les performances déclarées et les limites connues du système.

Cette qualification est déterminante car elle conditionné le régime d’obligations applicable. Si le système est qualifié de système à haut risque, l’ensemble des obligations des articles 8 à 15 du AI Act s’appliquent. La qualification doit être claire et non ambiguë pour éviter les contentieux posterieurs.

Le contrat doit également préciser les cas d’utilisation autorisés et interdits. Le AI Act prévoit que le deployeur qui utilise un système d’IA en dehors des cas d’utilisation prévus par les instructions peut devenir fournisseur et assumer les obligations correspondantes. La clause de définition des cas d’utilisation protégé l’acheteur contre ce risque de requalification.

2. Clause de transparence et de documentation

L’acheteur doit obtenir du fournisseur l’accès à la documentation technique du système, aux instructions d’utilisation, aux métriques de performance déclarées et aux limités connues. Cette clause est indispensable pour permettre au deployeur de satisfaire ses propres obligations de transparence vis-à-vis des personnes affectées par le système.

La clause doit prévoir la fourniture initiale de la documentation technique (ou d’un résumé suffisamment détaillé), la communication des mises à jour de la documentation lors de chaque évolution du système, l’accès aux métriques de performance en temps réel ou a intervalles réguliers et la notification des limites et des biais connus du système.

Pour les systèmes relevant du RGPD, la clause de transparence doit également couvrir les informations nécessaires pour satisfaire les obligations d’information des personnes concernées (articles 13 et 14 du RGPD) et les demandes d’explication des décisions algorithmiques.

3. Clause relative aux données

La clause relative aux données est l’une des plus critiques du contrat SaaS d’IA. Elle doit couvrir plusieurs dimensions.

Les données d’entrée : le contrat doit préciser les catégories de données que l’acheteur peut soumettre au système, les conditions de traitement de ces données par le fournisseur, les mesures de sécurité applicables et les conditions de suppression à l’issue du traitement.

L’utilisation des données pour l’entraînement : c’est un point de négociation crucial. De nombreux fournisseurs SaaS d’IA utilisent les données de leurs clients pour améliorer leurs modèles. Le contrat doit clairement préciser si le fournisseur est autorisé a utiliser les données de l’acheteur pour l’entraînement ou l’amélioration de son modèle. Si cette utilisation est autorisée, les conditions doivent être détaillées : anonymisation préalable, données synthétiques, agrégation, garanties de non-ré-identification.

La propriété et la portabilité : le contrat doit garantir que l’acheteur conservé la propriété de ses données, qu’il peut les récupérer dans un format exploitable en cas de changement de fournisseur et que les données sont effectivement supprimées par le fournisseur à l’issue du contrat.

4. Clause d’audit et de contrôle

Le droit d’audit est un élément essentiel du contrat SaaS d’IA. L’article 28(3)(h) du RGPD impose que le contrat de sous-traitance prevoie le droit du responsable de traitement de réaliser des audits. Le AI Act renforcé cette exigence pour les systèmes à haut risque en imposant un système de surveillance continue.

La clause d’audit doit prévoir le droit pour l’acheteur de réaliser ou de faire réaliser des audits de conformité (RGPD et AI Act), les modalités pratiques (préavis, fréquence, accès, confidentialité des résultats), l’obligation pour le fournisseur de fournir les résultats de ses propres audits internes (rapports SOC 2, certifications ISO, audits de non-discrimination) et le droit d’accès aux journaux de bord (logs) du système.

Un point de vigilance : de nombreux fournisseurs SaaS refusent les audits sur site et proposent à la place des rapports d’audit tiers (SOC 2 Type II). Ces rapports, bien qu’utiles, ne suffisent pas à couvrir les aspects spécifiques à l’IA (équité, non-discrimination, explicabilité). L’acheteur doit négocier un droit d’audit complémentaire couvrant ces aspects.

5. Clause de performance et de niveaux de service (SLA)

Le contrat doit inclure des engagements de performance spécifiques à l’IA, au-delà des SLA traditionnels de disponibilité et de temps de réponse. Les métriques de performance du système d’IA doivent être définies contractuellement : précision, rappel, taux de faux positifs, taux de faux négatifs et toute metrique pertinente pour le cas d’usage.

Le contrat doit prévoir les seuils minimaux de performance en dessous desquels le fournisseur est en défaut, les mécanismes de mesure et de vérification de la performance, les conséquences du non-respect des seuils (pénalités, droit de résiliation) et les obligations de maintien de la performance dans le temps (dégradation du modèle).

6. Clause de gestion des modifications et des mises à jour

Les systèmes d’IA évoluent fréquemment : mises à jour de l’algorithme, reentrainement du modèle, modification des données d’entraînement. Ces évolutions peuvent affecter la performance, l’équité et la conformité du système.

Le contrat doit prévoir l’obligation pour le fournisseur de notifier l’acheteur de toute modification substantielle du système, un délai de préavis suffisant pour permettre à l’acheteur d’évaluer l’impact de la modification, le droit pour l’acheteur de refuser une modification et de maintenir la version précédente, les procédures de test et de validation des modifications et la mise à jour de la documentation technique et des instructions d’utilisation.

Pour les systèmes à haut risque, une modification substantielle peut nécessiter une nouvelle évaluation de conformité. Le contrat doit répartir les responsabilités et les coûts associés à cette réévaluation.

7. Clause de responsabilité et d’indemnisation

La répartition de la responsabilité entre le fournisseur et l’acheteur est un enjeu central du contrat SaaS d’IA. Le contrat doit préciser la responsabilité du fournisseur en cas de défaut du système (erreurs, biais, discriminations, violations de données), la responsabilité de l’acheteur en cas d’utilisation non conforme aux instructions, les mécanismes d’indemnisation en cas de sanctions ou de condamnations résultant d’un défaut du système, la couverture assurantielle du fournisseur et les limites de responsabilité et les exclusions.

Les plafonds de responsabilité classiques des contrats SaaS (généralement limités au montant de l’abonnement annuel) sont souvent inadéquats au regard des risques liés à l’IA. Les sanctions RGPD et les sanctions AI Act peuvent atteindre des montants considérablement superieurs. L’acheteur doit négocier des plafonds de responsabilité adaptés aux risques réels.

8. Clause de sortie et de réversibilité

La dépendance à un fournisseur SaaS d’IA (vendor lock-in) est un risque stratégique majeur. Le contrat doit prévoir les conditions de restitution des données, les conditions de transfert des modèles et des configurations, les délais de préavis et de transition, l’assistance du fournisseur pendant la période de transition et les formats de données et les interfaces de portabilité.

Le registre des systèmes IA doit être mis à jour lors de tout changement de fournisseur, et les obligations de conformité IA-RGPD doivent être verifiees pour le nouveau système.

Les points de négociation prioritaires

La hiérarchie des enjeux

Tous les points contractuels n’ont pas la même criticite. Les points de négociation prioritaires, dans l’ordre, sont l’interdiction d’utilisation des données pour l’entraînement du modèle du fournisseur (sauf accord explicite et encadré), le droit d’audit effectif couvrant les aspects spécifiques à l’IA, la notification des modifications substantielles avec droit de refus, la transparence sur les métriques de performance et les biais connus, la couverture de responsabilité adéquate et les conditions de sortie et de portabilité des données.

La stratégie de négociation

Pour les solutions SaaS standardisées proposées par de grands éditeurs, la marge de négociation est souvent limitée. L’acheteur doit identifier les clauses non négociables du fournisseur, évaluer si ces clauses sont compatibles avec ses obligations légales, documenter les risques residuels acceptés et mettre en place des mesures compensatoires internes le cas échéant.

La CNIL a souligne que le responsable de traitement ne peut pas invoquer le refus du sous-traitant de modifier ses conditions contractuelles pour justifier un défaut de conformité. Si les conditions du fournisseur ne permettent pas de satisfaire les obligations du RGPD, l’acheteur doit changer de fournisseur.

Le cadre légal est consultable sur Legifrance pour le droit national et sur EUR-Lex pour le droit européen.

FAQ

Le fournisseur SaaS d’IA peut-il utiliser mes données pour entraîner son modèle ?

L’utilisation des données du client pour l’entraînement du modèle du fournisseur est une pratique répandue mais juridiquement sensible. Si les données concernées sont des données personnelles, cette utilisation constitue un traitement distinct du traitement realise pour le compte du client. Le fournisseur ne peut pas l’effectuer en tant que simple sous-traitant au titre de l’article 28 du RGPD : il doit disposer de sa propre base légale (généralement l’intérêt légitime ou le consentement), informer les personnes concernées et respecter l’ensemble des obligations du RGPD. Le contrat doit clairement distinguer les traitements réalisés en tant que sous-traitant (pour le compte du client) et les traitements réalisés pour les propres finalités du fournisseur. En cas de doute ou de risque excessif, l’acheteur doit exiger contractuellement l’interdiction d’utilisation des données pour l’entraînement.

Comment vérifier que le système d’IA SaaS n’est pas discriminatoire ?

La vérification de la non-discrimination d’un système SaaS d’IA requiert une approche combinant les audits contractuels et les tests opérationnels. Sur le plan contractuel, l’acheteur doit obtenir du fournisseur les résultats des tests d’équité réalisés sur le système, les métriques de non-discrimination calculees (taux de sélection differentiel, égalité des chances), la description des mesures de debiaisage mises en oeuvre et le droit de réaliser ses propres tests sur le système. Sur le plan opérationnel, l’acheteur doit mettre en place un suivi continu des résultats du système, ventile par groupes demographiques pertinents, analyser les écarts et signaler les biais detectes au fournisseur. L’audit algorithmique périodique doit couvrir la dimension de non-discrimination. Pour les systèmes de recrutement ou de crédit, classes à haut risque par le AI Act, ces vérifications sont juridiquement obligatoires.

Que faire si le fournisseur SaaS refusé de modifier ses clauses contractuelles standard ?

Le refus du fournisseur de modifier ses clauses ne décharge pas l’acheteur de ses obligations légales. Plusieurs options s’offrent à l’acheteur. Premièrement, évaluer si les clauses standard du fournisseur, même non idéales, satisfont les exigences minimales du RGPD et du AI Act. Deuxièmement, documenter les risques residuels liés aux clauses non modifiées et les mesures compensatoires internes mises en place (contrôles renforcés, limitations d’usage, formation des utilisateurs). Troisièmement, négocier des amendements ciblés sur les points les plus critiques (utilisation des données pour l’entraînement, droit d’audit, notification des modifications). Quatriemement, si les clauses standard sont incompatibles avec les obligations légales (par exemple, absence de clause conforme à l’article 28 du RGPD), l’acheteur doit changer de fournisseur. La documentation de l’analyse et de la décision est essentielle pour démontrer la diligence de l’acheteur en cas de contrôle.