Votre établissement n’a peut-être jamais acheté de solution présentée comme une intelligence artificielle.

Il peut pourtant déjà utiliser des fonctions d’IA.

Elles peuvent être intégrées à un logiciel métier, appelées par une interface tierce ou utilisées par les équipes d’un prestataire pour assurer le développement, le support, les tests de sécurité ou l’analyse de données.

Dans ces situations, l’IA n’apparaît pas nécessairement dans l’objet du marché, dans le registre des traitements ou dans la cartographie des systèmes.

Le risque ne vient donc pas uniquement de l’IA achetée comme telle.

Il vient aussi de celle qui intervient dans la chaîne fournisseur sans avoir été clairement identifiée.

L’IA chez les fournisseurs doit donc être recherchée dans le produit, dans les interfaces tierces et dans les méthodes de travail du prestataire.

Les lignes directrices publiées par l’ENISA en juillet 2026 sur les achats de cybersécurité des hôpitaux et prestataires de santé permettent de structurer cette vigilance. Elles couvrent l’ensemble du cycle d’achat et attirent l’attention sur les fonctions d’IA intégrées à des produits, accessibles par des services tiers ou utilisées par les fournisseurs pendant l’exécution du contrat.

Pourquoi l’IA des fournisseurs échappe-t-elle aux procédures d’achat ?

Une procédure d’achat examine généralement ce qui est déclaré :

• l’objet de la prestation ;
• ses fonctionnalités principales ;
• son architecture ;
• son hébergement ;
• les mesures de sécurité ;
• les catégories de données traitées ;
• les sous-traitants connus au moment de la signature.

Cette photographie peut rapidement devenir incomplète.

Une fonction d’IA peut être ajoutée après l’attribution du contrat, activée lors d’une mise à jour ou utilisée uniquement par les équipes techniques du fournisseur.

Elle ne modifie pas nécessairement l’apparence du service.

Elle peut pourtant modifier :

• les flux de données ;
• les destinataires ;
• les sous-traitants ultérieurs ;
• les durées de conservation ;
• les finalités poursuivies ;
• les conditions de sécurité ;
• les possibilités de réutilisation des données ;
• les risques pour les personnes concernées.

Une cartographie peut donc être exacte à la date de signature et ne plus correspondre aux opérations réellement réalisées quelques mois plus tard.

Le fournisseur n’a pas nécessairement dissimulé l’usage.

Il est aussi possible que l’acheteur ne lui ait jamais posé la question de manière suffisamment précise.

Où l’IA peut-elle intervenir sans être l’objet du contrat ?

À partir des situations couvertes par les lignes directrices de l’ENISA, quatre modalités peuvent être distinguées.

Les trois premières situations concernent directement la manière dont l’IA peut intervenir dans le produit ou dans l’exécution de la prestation.

La quatrième traduit une difficulté de gouvernance contractuelle : l’usage peut évoluer alors que le contrat et l’analyse initiale restent inchangés.

L’IA intégrée à un logiciel existant

Une mise à jour peut ajouter :

• un assistant conversationnel ;
• une fonction de résumé ;
• une transcription automatique ;
• un module de recommandation ;
• une détection d’anomalies ;
• une aide au classement ;
• une génération automatique de réponses.

L’outil reste le même en apparence, mais les traitements ne sont plus nécessairement identiques.

Il faut alors vérifier si la fonction :

• est activée automatiquement ;
• peut être désactivée ;
• transmet des données à un tiers ;
• utilise les données pour améliorer un modèle ;
• produit des sorties conservées ;
• intervient dans une décision ;
• modifie la localisation ou les destinataires des données.

L’IA appelée par une interface tierce

Le produit du fournisseur peut ne pas contenir lui-même de modèle.

Il peut transmettre certaines informations à un autre service par l’intermédiaire d’une API.

Cette situation peut introduire :

• un nouveau sous-traitant ;
• un transfert hors de l’Espace économique européen ;
• une nouvelle politique de conservation ;
• une utilisation secondaire des données ;
• une dépendance technique non prévue au contrat ;
• des journaux ou métadonnées supplémentaires.

La seule question « votre produit utilise-t-il de l’IA ? » peut donc être insuffisante.

Le fournisseur peut répondre négativement parce qu’il n’a pas développé le modèle, alors même que son service en appelle un.

L’IA utilisée par les équipes du prestataire

Le risque peut également se situer en dehors du produit livré.

Les équipes du fournisseur peuvent utiliser des outils d’IA pour :

• analyser un ticket de support ;
• comprendre un journal d’erreurs ;
• générer du code ;
• documenter un incident ;
• tester une application ;
• résumer un dossier ;
• analyser un jeu de données ;
• préparer une réponse au client.

Cette utilisation peut échapper aux journaux de l’organisation cliente.

Un extrait de dossier, une capture d’écran, une base de test ou un journal technique contenant des données personnelles peut être transmis dans un service externe sans apparaître dans le système d’information du responsable du traitement.

Cette situation peut être rapprochée du shadow AI : l’usage se produit ici chez le fournisseur, avec les données confiées par son client.

Quelles informations demander avant la signature ?

Lorsqu’une fonction d’IA intervient dans une prestation, le questionnaire fournisseur doit aller au-delà d’une réponse oui ou non.

La fonction concernée

Le fournisseur doit décrire :

• la finalité de la fonction ;
• son périmètre ;
• son caractère obligatoire ou optionnel ;
• les utilisateurs concernés ;
• les opérations réalisées ;
• la place de l’IA dans le service rendu.

Il faut notamment distinguer une fonction d’assistance d’une fonction participant directement à une décision.

Le modèle et sa chaîne de fournisseurs

L’organisation doit connaître :

• le modèle utilisé ;
• son fournisseur ;
• son mode de déploiement ;
• son lieu d’hébergement ;
• les éventuelles interfaces tierces ;
• les versions applicables ;
• les conditions de changement de modèle.

La mention générique « technologie d’IA » ne permet pas d’évaluer la chaîne de dépendance.

Les données traitées

Le fournisseur doit préciser :

• les catégories de données envoyées au système ;
• les données figurant dans les invites ;
• les fichiers déposés ;
• les journaux techniques concernés ;
• les données produites ;
• les métadonnées collectées ;
• les données dérivées créées.

Pour un établissement de santé, l’analyse doit identifier expressément les données de santé, les identifiants des patients, les données administratives et les informations relatives aux professionnels.

Les finalités secondaires

Une question distincte doit porter sur l’utilisation des données pour :

• l’entraînement ;
• l’affinage du modèle ;
• l’évaluation ;
• l’amélioration du service ;
• la détection d’abus ;
• la constitution de jeux de tests ;
• le développement de nouvelles fonctionnalités.

Une formule générale autorisant « l’amélioration continue du service » n’est pas suffisamment précise pour comprendre les traitements réellement envisagés.

La conservation

Le fournisseur doit indiquer la durée de conservation :

• des données d’entrée ;
• des invites ;
• des fichiers transmis ;
• des sorties produites ;
• des journaux ;
• des copies de sauvegarde ;
• des données dérivées ;
• des jeux de données éventuellement constitués.

Il doit également préciser les modalités de suppression et les exceptions applicables.

Les sous-traitants et les transferts

Il faut identifier :

• le fournisseur du modèle ;
• l’hébergeur ;
• les opérateurs d’API ;
• les prestataires de support ;
• les autres sous-traitants ultérieurs ;
• leur localisation ;
• les mécanismes encadrant les transferts hors EEE.

Une comparaison régulière entre la liste communiquée à la signature et la liste actuelle permet souvent de détecter une évolution du service.

La supervision et la traçabilité

L’organisation doit demander :

• quelles interventions humaines sont prévues ;
• qui peut valider, modifier ou rejeter une sortie ;
• quelles opérations sont journalisées ;
• si les invites et les sorties peuvent être retrouvées ;
• comment une erreur est signalée ;
• quelles procédures de repli existent ;
• comment les incidents liés à l’IA sont traités.

Quelles clauses prévoir dans le contrat ?

Les réponses du fournisseur doivent se traduire par des engagements contractuels.

Clause de déclaration

Le fournisseur déclare les fonctions d’IA intégrées au produit, appelées par un service tiers ou utilisées dans l’exécution de la prestation.

La déclaration doit couvrir ses propres équipes et ses sous-traitants.

Clause d’autorisation préalable

Le contrat peut interdire la transmission de données personnelles, de santé, de sécurité ou d’infrastructure à un système d’IA externe sans autorisation écrite préalable.

Cette autorisation devrait être précédée d’une analyse des risques et, lorsque cela est nécessaire, d’une mise à jour de la documentation contractuelle, du registre des traitements et de l’analyse d’impact.

Clause de limitation des finalités

Le fournisseur ne doit pas utiliser les données du client pour entraîner, affiner ou améliorer un modèle sans autorisation expresse, instructions documentées et clarification préalable :

• des rôles des différents acteurs ;
• des finalités poursuivies ;
• du fondement juridique applicable ;
• des catégories de données concernées ;
• des destinataires ;
• des durées de conservation ;
• des mesures de sécurité ;
• des conditions d’exercice des droits.

Une clause générale autorisant « l’amélioration du service » ne permet pas, à elle seule, d’encadrer précisément ces traitements.

Clause de notification des changements

Le fournisseur doit notifier, avant leur mise en œuvre :

• l’introduction d’une nouvelle fonction d’IA ;
• le remplacement du modèle ;
• le changement de fournisseur ;
• l’ajout d’un sous-traitant ;
• la modification des flux ;
• l’évolution des finalités ;
• la modification des durées de conservation ;
• toute évolution substantielle des capacités du service.

La notification doit être suffisamment anticipée pour permettre une évaluation et, le cas échéant, un refus, un avenant ou une désactivation.

Clause de traçabilité

Le fournisseur doit pouvoir produire les éléments nécessaires pour reconstituer :

• la version du système ;
• les données utilisées ;
• les accès ;
• les opérations réalisées ;
• les sorties pertinentes ;
• les incidents ;
• les modifications ;
• les mesures correctrices.

Clause d’audit et de coopération

L’organisation doit pouvoir vérifier les informations déclarées par des questionnaires, des documents, des audits ou des preuves techniques proportionnées au risque.

Le fournisseur doit également coopérer lors :

• d’une demande d’exercice de droits ;
• d’une violation de données ;
• d’une analyse d’impact ;
• d’un contrôle ;
• d’un incident de cybersécurité ;
• d’une contestation liée à une sortie du système.

Comment documenter l’IA pendant le contrat ?

La détection n’est utile que si elle alimente une documentation durable.

Il faut rattacher chaque fonction d’IA :

• à un traitement identifié ;
• à une finalité précise ;
• à un fournisseur ;
• à un modèle ou à un service ;
• à un flux ;
• à des catégories de données ;
• à des personnes autorisées ;
• à une analyse des risques ;
• à une date de mise en service ;
• à une version.

Documenter la fonction, pas seulement le fournisseur

Un même prestataire peut utiliser plusieurs fonctions d’IA.

Certaines peuvent traiter des données personnelles, d’autres non.

Certaines interviennent dans le produit, d’autres uniquement pendant le support.

La fiche fournisseur ne suffit donc pas toujours.

Il faut documenter la fonction elle-même et la relier au contrat ainsi qu’au traitement concerné.

Cartographier les flux

La cartographie doit couvrir :

donnée d’entrée → transmission → modèle → traitement → sortie → conservation → réutilisation éventuelle

Elle doit intégrer les invites, les fichiers déposés, les sorties, les journaux, les copies techniques, les interfaces et les données dérivées.

Dater les évolutions

Une fonction présente à la signature et une fonction ajoutée six mois plus tard ne produisent pas la même chaîne de preuve.

Il faut conserver :

• la date de déclaration ;
• la date d’activation ;
• la version ;
• la validation interne ;
• l’analyse applicable ;
• la date de réévaluation ;
• la décision prise.

Alimenter un registre interne des usages d’IA

Ce travail peut alimenter un registre interne des systèmes et usages d’IA.

Un tel registre permet :

• d’identifier les rôles au titre de l’AI Act ;
• de qualifier les risques ;
• de relier les systèmes aux traitements RGPD ;
• de suivre les obligations applicables ;
• d’organiser les contrôles ;
• de conserver les preuves.

Le registre constitue une mesure de gouvernance utile, même lorsqu’aucune disposition n’impose formellement à l’organisation un registre unique couvrant tous ses usages.

Que vérifier lors de la réversibilité ?

La restitution et la suppression ne doivent pas porter seulement sur les données visibles dans l’application.

Lorsqu’une fonction d’IA est intervenue, la vérification doit également porter sur :

• les invites ;
• les fichiers déposés ;
• les sorties produites ;
• les journaux ;
• les caches ;
• les index ;
• les représentations vectorielles ;
• les jeux de données d’affinage ;
• les copies de test ;
• les données dérivées ;
• les sauvegardes ;
• les éléments transmis aux sous-traitants.

Ces éléments doivent être examinés lorsqu’ils demeurent rattachables au client, à ses données ou aux personnes concernées.

Il faut également documenter les éventuelles limites techniques de leur restitution ou de leur suppression.

La clause de réversibilité doit préciser :

• les catégories concernées ;
• les modalités de restitution ;
• les modalités de suppression ;
• la suppression chez les sous-traitants ;
• les délais applicables ;
• les exceptions ;
• les preuves ou confirmations attendues.

Par où commencer lorsque les contrats sont déjà signés ?

Il n’est pas réaliste de réexaminer tous les fournisseurs simultanément.

Une démarche fondée sur les risques peut être menée en six étapes.

1. Classer les prestations

Prioriser selon :

• la sensibilité des données ;
• le volume traité ;
• l’accès aux systèmes critiques ;
• la possibilité de participer à une décision ;
• l’exposition aux données de santé ;
• la dépendance au fournisseur ;
• les transferts internationaux.

Le montant du contrat ne constitue pas nécessairement le critère principal.

Un petit prestataire de maintenance disposant d’un accès au dossier patient peut présenter davantage de risques qu’une licence bureautique plus coûteuse.

2. Interroger les fournisseurs prioritaires

Adresser une demande écrite portant sur :

• les fonctions d’IA ;
• les modèles ;
• les fournisseurs tiers ;
• les données traitées ;
• les finalités secondaires ;
• la conservation ;
• les sous-traitants ;
• les changements intervenus depuis la signature.

La demande écrite constitue déjà une preuve de diligence.

3. Comparer les versions

Comparer :

• le contrat initial ;
• les conditions actuelles ;
• les listes de sous-traitants ;
• les notes de version ;
• les paramètres ;
• la documentation technique ;
• les flux observés.

4. Corriger les contrats

Préparer en priorité :

• une clause de déclaration ;
• une clause d’autorisation préalable ;
• une clause de notification des changements ;
• une clause sur l’entraînement et l’amélioration ;
• une clause de traçabilité ;
• une clause de réversibilité étendue aux données dérivées.

5. Mettre à jour les registres

Rattacher chaque usage identifié :

• au registre des traitements ;
• à la cartographie des sous-traitants ;
• au registre interne des usages d’IA ;
• à l’analyse de risques ;
• à l’AIPD lorsqu’elle est nécessaire ;
• au plan d’audit fournisseur.

6. Organiser une revue périodique

Une revue annuelle peut être trop espacée pour des services qui évoluent à chaque mise à jour.

La fréquence doit être adaptée au risque, avec une revue supplémentaire lors :

• d’une nouvelle version ;
• d’un changement de sous-traitant ;
• d’une évolution fonctionnelle ;
• d’un incident ;
• d’une modification contractuelle ;
• d’une nouvelle finalité.

La matrice de preuve à conserver

Quel rôle pour le DPO ?

Le DPO ne pilote pas seul les achats, la cybersécurité ou les contrats.

Il peut toutefois contribuer à :

• identifier les traitements concernés ;
• vérifier les finalités et les bases légales ;
• analyser les flux et les sous-traitants ;
• examiner les utilisations secondaires ;
• apprécier la nécessité d’une AIPD ;
• vérifier l’information des personnes ;
• définir les preuves à conserver ;
• participer à la rédaction des clauses ;
• organiser la réévaluation des usages ;
• documenter les recommandations et les arbitrages.

La gouvernance doit associer au minimum les achats, le métier, la direction juridique, la sécurité, les systèmes d’information et le DPO.

FAQ

Un fournisseur doit-il déclarer toute utilisation d’IA ?

Il doit fournir les informations nécessaires pour permettre à son client d’évaluer les traitements, les risques, les sous-traitants et les mesures de sécurité.

Le contrat doit préciser les usages à déclarer, notamment lorsque des données du client sont transmises à un système d’IA ou utilisées pendant l’exécution de la prestation.

Une fonction ajoutée par mise à jour doit-elle être réévaluée ?

Oui, lorsqu’elle modifie les traitements, les flux, les finalités, les destinataires, la sécurité ou les risques.

Une note de version ne remplace pas une analyse de conformité.

L’utilisation d’une IA par le support modifie-t-elle la sous-traitance ?

Elle peut modifier les conditions de la sous-traitance lorsque des données personnelles confiées par le client sont traitées dans un service d’IA.

Il faut alors identifier les acteurs, les instructions, les finalités, les flux, les durées et les transferts éventuels.

Faut-il créer un registre des systèmes d’IA ?

Un registre interne constitue une mesure de gouvernance particulièrement utile pour identifier les systèmes, les usages, les rôles, les données, les fournisseurs et les obligations applicables.

Il permet également de relier chaque usage d’IA au traitement RGPD concerné, à son analyse de risques, au contrat applicable et aux preuves conservées.

Il ne faut cependant pas le présenter comme une obligation générale et uniforme imposée à toute organisation pour tous ses usages d’IA.

Conclusion

L’IA ne se trouve pas uniquement dans les solutions achetées comme telles.

Elle peut être intégrée dans un outil existant, appelée par une interface tierce ou utilisée par les équipes d’un fournisseur pendant l’exécution du contrat.

La chaîne de contrôle doit donc couvrir :

déclaration → qualification → contrat → flux → utilisation → évolution → réversibilité → preuve

Une question générale sur l’usage de l’IA ne suffit pas.

L’organisation doit demander quelle fonction intervient, sur quelles données, avec quel modèle, pour quelle finalité, par quels acteurs et selon quelles conditions de conservation.

La question à poser aux fournisseurs n’est plus seulement :

Votre produit contient-il de l’intelligence artificielle ?

Mais :

Une fonction d’IA intervient-elle à un moment quelconque dans la fourniture, le support, la maintenance ou l’évolution du service, et pouvez-vous le démontrer ?

DPO PARTAGE peut vous accompagner pour cartographier les usages d’IA de vos fournisseurs, renforcer vos questionnaires et clauses contractuelles et structurer les preuves nécessaires au suivi de la sous-traitance.