Gouvernance IA en entreprise : organiser les décisions

Une gouvernance IA utile permet de répondre à quatre questions : quels usages existent, qui en répond, sur quelles preuves leur lancement a été autorisé et qui intervient lorsqu’un problème apparaît. Elle doit fonctionner aussi lorsqu’un outil connu reçoit une nouvelle fonctionnalité ou qu’un métier change son usage.

Il n’existe pas de modèle universel imposant à toute PME un comité IA mensuel ou un poste de responsable IA. Certaines obligations légales exigent en revanche des responsabilités, des compétences et des procédures effectives. Il faut les identifier selon le système, le rôle de l’entreprise et la date d’application.

Commencer par les usages réels

Le recensement doit couvrir les outils achetés par la DSI, les services acquis par les métiers, les modèles développés en interne et les fonctions IA activées dans des logiciels existants. Un nom de produit ne suffit pas : notez ce que l’équipe en fait, quelles personnes sont concernées et quelles décisions utilisent ses résultats.

Une fiche simple peut contenir le propriétaire métier, la finalité, le fournisseur et la version, les données et accès, les utilisateurs, les décisions influencées, les incidents connus et l’état de l’autorisation. Le registre des systèmes d’IA fournit une méthode pour relier cet inventaire au registre RGPD et, lorsque nécessaire, à l’enregistrement européen.

Cet inventaire interne est une mesure d’organisation. Il ne faut pas le confondre avec l’article 30 du RGPD ni avec les conditions précises des articles 49 et 71 de l’AI Act. RGPD, Art. 30 ; AI Act, Art. 49 et 71.

Attribuer les responsabilités sans tout confier au DPO

Le comité de gouvernance peut réunir direction, métiers, juridique, DSI, sécurité et DPO. C’est une option adaptée aux projets transversaux ; une PME peut organiser le même travail avec un responsable métier et des avis spécialisés. L’essentiel est de savoir qui décide et qui exécute les mesures.

Le DPO doit être associé en temps utile, disposer de ressources et éviter les conflits d’intérêts. Sa participation à la coordination ne permet pas de lui attribuer automatiquement les décisions sur les finalités et moyens des traitements. Art. 38(1) à (3), (6) et 39(1) du RGPD. Le guide DPO et AI Act précise les limites de ce cumul.

Construire une revue avant lancement

La revue proposée ci-dessous sert à décider sur des faits. Son niveau de détail dépend du risque ; elle ne remplace pas les procédures légales applicables.

1. Décrire l’usage. Qui reçoit le résultat, que peut-il décider et quelles personnes en subissent les conséquences ?
2. Qualifier le système et le rôle. Examiner les interdictions, le haut risque, les obligations de transparence et l’éventuel rôle de fournisseur, au lieu de présumer qu’un acheteur reste toujours simple déployeur.
3. Vérifier les données. Sources, base légale, informations, droits, contrats, transferts et durées doivent correspondre aux opérations réelles.
4. Examiner les garanties. Essais pertinents, limites connues, contrôle humain, accès et possibilité d’arrêter l’usage.
5. Décider et fixer les conditions. Autorisation, autorisation après réalisation de mesures, demande d’informations ou refus motivé.

La modification substantielle, l’apposition de son nom ou la modification de la destination peuvent, dans les conditions de l’article 25(1), faire changer le rôle d’un opérateur. Ce point mérite une nouvelle analyse lorsque l’entreprise personnalise un système ou le réutilise pour une décision sensible. AI Act, Art. 25.

Vérifier le calendrier et les analyses requises

Au 26 septembre 2026, le règlement 2026/1744 a modifié l’AI Act. Les sections 1 à 3 du chapitre III s’appliqueront aux systèmes concernés de l’annexe III le 2 décembre 2027, et à ceux de l’annexe I le 2 août 2028, sous les règles et exceptions du texte. Ce report n’englobe pas toutes les autres dispositions du règlement. Règlement 2026/1744, Art. 1(40).

L’AIPD du RGPD dépend du risque élevé du traitement de données. La FRIA de l’article 27 de l’AI Act concerne certains déployeurs de systèmes de l’annexe III, avec une exclusion pour le point 2 ; elle ne s’impose pas à toute entreprise utilisant une IA à haut risque. RGPD, Art. 35(1) ; AI Act, Art. 27(1).

La méthode d’AIPD adaptée à l’IA permet de documenter les risques pour les personnes. Une approbation interne ne dispense jamais de cette analyse lorsqu’elle est obligatoire, ni d’une consultation préalable de la CNIL dans les conditions de l’article 36.

Définir une politique compréhensible par les équipes

La politique interne doit indiquer les outils et usages autorisés, les données admises, la procédure pour demander un nouvel usage et le contact en cas de problème. Évitez les règles impraticables telles que « aucune erreur n’est permise » sans expliquer comment vérifier un résultat.

Une entreprise peut choisir une interdiction interne plus protectrice que le minimum légal : par exemple, interdire aux équipes de charger des dossiers RH dans des services non approuvés. Il faut présenter cette règle comme un choix interne, et non comme une interdiction légale générale de toute donnée personnelle dans toute IA.

Prévoyez aussi les activités qui exigent une autorisation distincte : connecter une base documentaire, activer un agent pouvant envoyer des messages, utiliser des résultats pour évaluer une personne ou permettre la réutilisation de données par un fournisseur. Le modèle de charte IA aide à traduire ces choix en consignes.

Former selon les tâches et les conséquences

L’article 4 modifié impose aux fournisseurs et déployeurs des mesures soutenant le développement de la maîtrise de l’IA, compte tenu notamment des connaissances et du contexte d’utilisation. Il ne prescrit pas un certificat unique ni un volume universel d’heures. Règlement 2026/1744, Art. 1(5).

La direction doit comprendre les risques et les responsabilités ; les utilisateurs doivent savoir vérifier les résultats et signaler un problème ; les équipes techniques doivent maîtriser les limites des systèmes qu’elles intègrent. Conservez des éléments utiles : objectifs, participants, supports et exercices correspondant aux usages. Cette documentation est une recommandation d’organisation, sans format universel obligatoire déduit de l’article 4.

Suivre les changements, incidents et réclamations

La gouvernance ne s’arrête pas à l’autorisation. Définissez les événements qui imposent une revue : nouveau modèle, nouvelle source documentaire, changement de finalité, incident, plainte ou résultat révélant un défaut. Prévoyez qui peut suspendre le service et comment revenir à une procédure manuelle.

Les obligations de suivi diffèrent entre fournisseur et déployeur. L’article 72 organise le suivi après commercialisation par les fournisseurs concernés ; l’article 26 prévoit notamment le contrôle du fonctionnement et certaines obligations d’information pour les déployeurs de systèmes à haut risque. Leur application doit être examinée dans le calendrier propre à chaque disposition. AI Act, Art. 26 et 72.

Pour les données personnelles, le traitement des incidents suit aussi les articles 33 et 34 : notification à l’autorité sauf absence de risque, et information des personnes en cas de risque élevé sous les exceptions prévues. Tout résultat incorrect n’est pas une violation de données ; qualifiez les faits avant d’appliquer une procédure. RGPD, Art. 33(1), (5), 34(1) et (3).

Un dossier de décision plutôt qu’une accumulation de réunions

Pour chaque usage significatif, conservez une fiche datée, la qualification retenue, les pièces examinées, les avis, les conditions de lancement, le décideur et les points de réexamen. Si un risque reste ouvert, la décision doit indiquer son traitement ; écrire « validé par le comité » ne suffit pas à comprendre le raisonnement.

La checklist de conformité IA peut servir à identifier les pièces manquantes. Le bon indicateur de gouvernance est la capacité à retrouver une décision justifiée et à agir lorsqu’un fait change, pas le nombre de pages d’une politique.

Ce qu’il faut retenir

• Recensez les usages et leurs conséquences, au-delà des seuls noms de logiciels.
• Attribuez les décisions, l’exécution des mesures et le contrôle à des personnes identifiées.
• Séparez obligations légales, calendrier d’application et choix internes de prudence.
• Préservez l’indépendance du DPO et vérifiez le champ propre de chaque analyse d’impact.
• Organisez la suspension, les incidents et les changements après le lancement.

FAQ

Un comité IA est-il obligatoire dans chaque PME ?

Non, l’AI Act n’impose pas un comité universel. L’organisation doit néanmoins satisfaire les obligations applicables à ses systèmes et à ses rôles, avec des responsabilités et des moyens effectifs.

Peut-on utiliser la même procédure pour tous les outils ?

Un socle commun est utile, mais l’examen doit être proportionné au risque. Un assistant de rédaction et un système participant à une décision de recrutement n’appellent pas les mêmes vérifications.

À quelle fréquence faut-il revoir un usage ?

Fixez une fréquence adaptée et des événements déclencheurs. Pour l’AIPD, le RGPD exige notamment un réexamen lorsque le risque change ; une revue annuelle figée ne remplace pas cette réaction.

Recevez nos analyses pratiques de conformité dans la newsletter.

À propos de l’auteur. Thiébaut Devergranne est docteur en droit privé, titulaire du CAPA et fondateur de Legiscope. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.