Non. **Un registre des cas d’usage IA est un point de départ, pas une preuve suffisante de conformité.** Il permet de savoir où l’intelligence artificielle intervient, qui en est responsable et quels risques examiner. Mais une ligne dans un tableau ne démontre ni la licéité d’un traitement de donnée...
Non. Un registre des cas d’usage IA est un point de départ, pas une preuve suffisante de conformité. Il permet de savoir où l’intelligence artificielle intervient, qui en est responsable et quels risques examiner. Mais une ligne dans un tableau ne démontre ni la licéité d’un traitement de données ni l’application des obligations de l’AI Act.
Pour une PME ou une scale-up, l’objectif n’est pas de multiplier les documents. Il consiste à relier chaque usage à une qualification, à des contrôles réellement appliqués et à des justificatifs accessibles. Voici comment construire ce dispositif sans transformer votre inventaire en usine à gaz.
Un inventaire décrit ce que l’entreprise utilise. La conformité concerne aussi ce que l’entreprise fait pour respecter les règles applicables.
Par exemple, inscrire « assistant IA pour le support client » ne répond pas aux questions décisives : quelles données sont transmises au prestataire ? Les clients doivent-ils être informés qu’ils interagissent avec une IA ? Qui peut consulter les conversations ? Une réponse erronée peut-elle déclencher une action dans votre logiciel métier ?
Le règlement européen sur l’intelligence artificielle, ou AI Act, ne prévoit pas un inventaire interne universel qui dispenserait de ses autres obligations. Celles-ci dépendent notamment de votre rôle, de la finalité du système et de sa catégorie réglementaire.
De son côté, le RGPD impose au responsable du traitement de respecter ses principes et de pouvoir démontrer ce respect, conformément au principe de responsabilité de l’article 5, paragraphe 2.
Le registre devient donc utile lorsqu’il sert de point d’entrée vers les décisions et les preuves, plutôt que de simple catalogue d’outils.
Le mot « registre » peut désigner des objets très différents. Leur confusion conduit souvent à croire qu’une obligation est couverte alors qu’elle ne l’est pas.
Document ou dispositif | Fonction | Limite |
|---|---|---|
Inventaire interne des usages IA | Recenser les usages, responsables, données et risques | Ne remplace pas les obligations propres à chaque usage |
Registre des activités de traitement du RGPD | Documenter les traitements de données personnelles selon l’article 30 | Ne couvre pas, à lui seul, les exigences de l’AI Act |
Enregistrement dans la base de données de l’UE | Répondre à certaines obligations spécifiques de l’AI Act | Ne concerne pas indistinctement tous les outils et toutes les entreprises |
Les obligations d’enregistrement européen concernent notamment certains fournisseurs de systèmes à haut risque et certains déployeurs publics, selon les cas prévus par le règlement. Ce n’est pas l’équivalent d’un tableau partagé dans votre entreprise.
Inversement, votre inventaire interne peut couvrir des usages sans données personnelles, absents du registre RGPD. Lorsqu’un usage traite des données personnelles, les deux documents doivent pouvoir être rapprochés.
Le seuil de 250 salariés ne constitue pas une exemption générale du registre RGPD : les exceptions prévues par l’article 30 sont limitées. Un traitement non occasionnel peut notamment imposer sa tenue.
Une même application peut servir à reformuler un courriel, à évaluer des candidats ou à orienter une décision commerciale. Son nom ne suffit donc pas à déterminer les règles applicables. La qualification doit porter sur l’usage réel et son contexte.
Une entreprise qui utilise un système d’IA sous son autorité est généralement un déployeur au sens de l’AI Act. Une entreprise qui développe un système, ou le fait développer pour le mettre sur le marché ou en service sous son nom, peut être fournisseur.
Certaines modifications d’un système à haut risque ou de sa finalité peuvent également modifier cette répartition des responsabilités. Acheter une solution ne signifie donc pas que le prestataire prend en charge toutes vos obligations.
Consignez votre rôle et son raisonnement dans la fiche. Pour un projet sur mesure, clarifiez aussi contractuellement les responsabilités de chaque partie. Le contrat facilite cette répartition opérationnelle, mais ne peut pas effacer un rôle défini par la loi.
Une organisation IA avec des rôles et responsabilités explicites facilite ensuite l’attribution de ces décisions aux bonnes personnes.
Un registre des cas d’usage IA doit distinguer la qualification juridique du système et votre propre appréciation des risques.
Une aide à la rédaction peut présenter un risque de divulgation de secrets commerciaux sans relever, pour cette seule raison, de la catégorie réglementaire « à haut risque ». À l’inverse, un système destiné à filtrer ou classer des candidatures peut relever des dispositions relatives aux systèmes à haut risque, selon ses caractéristiques et les exceptions applicables.
Évitez donc une seule colonne « risque : faible, moyen, fort ». Prévoyez deux champs : qualification réglementaire motivée et risques opérationnels identifiés.
La qualification doit également permettre de repérer un usage interdit. Un tel usage ne devient pas acceptable parce qu’un responsable l’a approuvé ou qu’une personne contrôle les résultats.
Pour les échéances et obligations détaillées, utilisez en complément notre guide des obligations de l’AI Act pour les PME et scale-ups, puis vérifiez le calendrier réglementaire en vigueur pour votre situation.
Le bon niveau de détail permet à une personne extérieure au projet de comprendre son fonctionnement, les arbitrages retenus et les conditions de son autorisation interne.
Voici une structure de départ. Il s’agit d’un modèle de gouvernance recommandé, pas d’une liste de champs légalement obligatoire pour tous les usages.
Champ | Informations à renseigner |
|---|---|
Identifiant et finalité | Référence stable, problème traité et périmètre autorisé |
Responsable métier | Personne qui porte l’usage et peut décider de sa suspension |
Système et prestataire | Solution, version ou configuration pertinente et fournisseur |
Rôle de l’entreprise | Déployeur, fournisseur ou autre rôle applicable, avec justification |
Données et flux | Catégories de données, sources, destinataires, lieux de traitement et conservation |
Qualification réglementaire | Analyse AI Act, traitements RGPD associés et obligations identifiées |
Effets des résultats | Simple suggestion, communication externe ou action automatisée |
Contrôles appliqués | Accès, validation humaine, tests et restrictions d’utilisation |
Justificatifs | Liens vers contrats, analyses, rapports de test et procédures |
Statut et réexamen | Autorisation interne, réserves, date de revue et changements déclencheurs |
Un registre des cas d’usage IA peut commencer dans un tableur. La qualité du dispositif dépend davantage de la fiabilité des informations et du suivi des décisions que du logiciel choisi.
Les justificatifs peuvent rester dans leurs espaces habituels, à condition que les liens soient accessibles aux personnes habilitées. Évitez de copier des données sensibles dans le registre uniquement pour rendre la fiche plus complète.
Prenons un cas fictif : une PME veut générer des brouillons de réponses à partir de ses tickets et de sa documentation produit. Un salarié relit chaque proposition avant l’envoi.
Une fiche limitée à « outil approuvé, risque faible » est insuffisante. Elle ne décrit pas les informations transmises, les destinataires ni les actions que le système peut effectuer.
La fiche utile précise que l’assistant produit uniquement des brouillons, n’effectue aucun remboursement et ne modifie aucun compte client. Elle identifie les catégories de données présentes dans les tickets et les restrictions sur les pièces jointes. Elle renvoie aux conditions contractuelles du prestataire, à l’analyse RGPD et aux résultats des tests retenus avant l’ouverture aux équipes.
Les tests peuvent couvrir des réponses inventées, des tentatives d’obtenir des informations sur un autre client ou des instructions malveillantes contenues dans un ticket. Ils ne prouvent pas toute la conformité, mais documentent des contrôles concrets.
L’autorisation interne vaut pour ce périmètre, pas pour toutes les évolutions futures. Si l’assistant commence à répondre directement aux clients, à consulter de nouvelles bases ou à déclencher des remboursements, une nouvelle analyse devient nécessaire.
Cet exemple illustre la fonction du registre des cas d’usage IA : rendre visibles les conditions d’utilisation et les changements qui imposent de réexaminer le dossier.
Il n’existe pas de dossier identique pour tous les systèmes. Les pièces nécessaires dépendent des règles applicables et des risques. Le registre doit permettre de retrouver celles qui justifient vos choix, sans demander systématiquement une documentation disproportionnée.
Si l’usage traite des données personnelles, les justificatifs doivent couvrir les exigences pertinentes du RGPD : finalité, base juridique, minimisation, information des personnes, conservation et sécurité.
Selon la relation avec le prestataire, un contrat de sous-traitance conforme à l’article 28 peut être nécessaire. D’éventuels transferts hors de l’Espace économique européen doivent également être examinés. Une promesse commerciale d’« hébergement européen » ne répond pas, à elle seule, à toutes ces questions.
Une analyse d’impact relative à la protection des données, ou AIPD, est requise lorsque le traitement est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes. Ce critère n’est pas identique à la catégorie « système d’IA à haut risque » de l’AI Act.
Enfin, lorsqu’une décision est entièrement automatisée et produit des effets juridiques ou affecte significativement une personne, l’article 22 exige une analyse spécifique. Une validation humaine purement formelle ne suffit pas à transformer le fonctionnement réel du processus.
La maîtrise de l’IA visée par l’article 4 appelle des mesures adaptées aux personnes qui utilisent les systèmes pour votre compte. Conserver les contenus de formation, les publics concernés et les consignes données aide à démontrer ces mesures. Le règlement n’impose pas un certificat de formation universel.
Pour les systèmes à haut risque, les obligations des déployeurs peuvent notamment porter sur le respect des instructions, la supervision humaine, la surveillance du fonctionnement et la conservation des journaux sous leur contrôle. Leur application doit être examinée précisément, plutôt que remplacée par une case « supervision prévue ».
Certains usages appellent aussi des mesures de transparence, par exemple pour informer une personne qu’elle interagit avec une IA lorsque cette information est requise.
Le registre des cas d’usage IA doit pointer vers ces dispositifs et leurs preuves. Il ne les réalise pas lui-même : inscrire « journalisation active » ne démontre ni que les journaux existent ni qu’ils sont conservés correctement.
Le principal risque d’un inventaire est de devenir une photographie périmée. Pour éviter cela, rattachez sa mise à jour aux événements qui modifient réellement l’exposition de l’entreprise.
Une nouvelle finalité, un changement de prestataire, l’ajout de données sensibles ou le passage d’une suggestion à une action automatique doivent déclencher une réévaluation. Une mise à jour de modèle peut aussi justifier de nouveaux tests si elle modifie le comportement du système.
Une procédure légère peut distinguer trois états : à examiner, test autorisé dans un périmètre défini et usage autorisé sous conditions. Aucun de ces statuts ne constitue une certification juridique. Ils indiquent ce que votre organisation a décidé et sur quelle base.
Prévoyez un canal simple pour déclarer les nouveaux usages, y compris ceux introduits directement par les équipes. Un registre qui ne couvre que les projets informatiques officiels laisse de côté une partie des usages réels.
Enfin, désignez la personne qui peut suspendre l’usage en cas d’incident. Une fiche sans responsable de suivi reste un document descriptif, même si elle est très détaillée.
Un tableur suffit-il pour tenir le registre ? Oui, pour commencer, si les accès sont maîtrisés, les fiches sont à jour et les justificatifs restent accessibles. Un outil plus structuré devient utile lorsque le volume d’usages, les validations ou les changements deviennent difficiles à suivre.
Faut-il enregistrer chaque prompt envoyé à une IA ? Pas systématiquement. L’inventaire porte d’abord sur les usages et leurs conditions. Des journaux peuvent être nécessaires selon le système et les obligations applicables, mais conserver tous les prompts peut créer des risques supplémentaires pour les données personnelles et la confidentialité.
Le fournisseur peut-il garantir notre conformité ? Ses documents et engagements sont utiles, mais ne couvrent pas automatiquement votre utilisation. Vous restez responsable des obligations attachées à votre rôle, à vos données et à votre processus métier.
Faut-il une AIPD pour chaque projet IA ? Non. Elle est obligatoire lorsque le traitement de données personnelles est susceptible d’engendrer un risque élevé. L’analyse doit être menée au cas par cas et son résultat documenté.
Commencez par un usage prioritaire : décrivez son périmètre, qualifiez les obligations et réunissez les justificatifs manquants avant d’élargir son utilisation. Cette démarche permet de distinguer les questions juridiques des travaux techniques à réaliser.
Impulse Lab accompagne les entreprises dans leurs audits d’opportunités IA, leurs intégrations et leurs développements sur mesure, ainsi que dans la formation à l’adoption de l’IA. Ce cadrage technique et opérationnel peut s’articuler avec l’analyse de votre DPO ou de votre conseil juridique, sans confondre audit d’opportunités et validation de conformité.
Notre équipe d'experts vous répond rapidement pour comprendre vos besoins et vous proposer la meilleure solution.
Vous avez des questions ? On a les réponses.
Leonard
Co-fondateur