DPO et IA : le faux problème et le vrai

La scène se répète partout. Un projet IA avance bien, le cas d'usage est validé, la technologie fonctionne. Puis on présente le projet au DPO. Et le projet s'arrête. Pas parce que le DPO a dit non — mais parce que personne n'avait réfléchi aux questions qu'il allait poser.

Ce n'est pas un problème de DPO. C'est un problème de méthode.

Le faux problème : le DPO comme obstacle

Le DPO bloqueur existe. Mais il est moins fréquent qu'on ne le croit. Ce qu'on perçoit comme du blocage est souvent une découverte tardive de sujets qui auraient dû être traités au cadrage.

Un projet IA qui traite des données personnelles — c'est-à-dire presque tous les projets IA en entreprise, sauf ceux qui ne traitent que des données purement techniques — a besoin d'une base légale de traitement, d'une inscription au registre, et si le traitement est à risque élevé, d'une Analyse d'Impact sur la Protection des Données (AIPD). Ce n'est pas une invention du DPO. C'est le RGPD, qui date de 2018.

La vraie question n'est donc pas « comment convaincre le DPO » mais « pourquoi a-t-on commencé un projet IA sans vérifier ces points au départ ? »

Le vrai problème : ce que le DPO doit exiger des fournisseurs

Quand une entreprise utilise un LLM externe pour traiter des données personnelles, elle confie un traitement à un sous-traitant. Le RGPD est limpide : ce sous-traitant doit être lié par un contrat de traitement de données (DPA) conforme à l'article 28.

Ce DPA doit préciser : la nature et la finalité du traitement, les catégories de données traitées, les mesures de sécurité, la liste des sous-sous-traitants, les conditions de suppression des données. Et surtout : une garantie explicite que les données ne servent pas à entraîner le modèle.

Ce dernier point n'est pas anodin. Plusieurs grands fournisseurs d'IA cloud utilisent par défaut les inputs des utilisateurs pour améliorer leurs modèles. Ce comportement par défaut, s'il n'est pas contractuellement exclu, rend le traitement potentiellement illicite et crée un risque de fuite de données de facto.

Ce que le DPO doit exiger est donc précis : un DPA signé, une liste des sous-traitants, une garantie de non-utilisation pour l'entraînement, et pour les traitements à risque élevé, une AIPD avant mise en production. Pas après — avant.

Ce que le DPO n'a pas à exiger

Le DPO n'est pas là pour valider l'architecture technique. Il n'a pas à comprendre comment fonctionne un transformer ou à auditer le code du modèle. Son périmètre est la protection des données personnelles — ni plus, ni moins.

Il n'a pas à exiger que le traitement soit parfait. Il doit vérifier qu'il est licite, proportionné et sécurisé. Un traitement qui comporte des risques résiduels acceptables avec des mesures de mitigation documentées est conforme. La conformité RGPD n'est pas l'absence de tout risque — c'est la gestion documentée du risque.

Et surtout : le DPO n'a pas à décider seul. Son rôle est d'informer et de conseiller — pas de décider à la place du responsable de traitement. Si le DG décide de lancer un projet après avoir été informé des risques et des conditions de licéité, c'est sa responsabilité. Le DPO a rempli le sien.

Comment DSI et DPO travaillent bien ensemble

Les entreprises où ça fonctionne ont souvent mis en place quelque chose de simple : une checklist d'entrée en conformité pour tout nouveau projet IA, co-construite entre la DSI et le DPO. Cinq questions. Vingt minutes. En amont.

Le DPO y gagne de la visibilité sur les projets en cours — il ne les découvre plus à la fin. La DSI y gagne un chemin balisé — elle sait ce qu'on attend d'elle. Les projets y gagnent du temps — ils ne s'arrêtent plus en semaine 8 sur des sujets qui auraient pu être réglés en semaine 1.

Un DPO impliqué tôt n'est pas un obstacle. C'est une assurance que le projet ira en production sans surprises désagréables.