La gouvernance de l'IA dans une PME : les contrôles qui rendent un cas d'usage défendable

Il y a une question qui vient avant le choix de l'outil et une qui vient après. La première — « dois-je me conformer à l'AI Act ? y suis-je obligé ? » — nous l'avons abordée dans l'article sur l'EU AI Act pour les PME, et pour la plupart des entreprises la réponse est plus rassurante que prévu. Voici l'autre : une fois que vous avez décidé de mettre en production un cas d'usage — un copilote pour les ventes, un bot de support, une automatisation en administration — comment le gouvernez-vous pour qu'il tienne ? Qu'il résiste à un contrôle du Garante Privacy (l'autorité italienne de protection des données), à la demande d'un client, à un incident, à la question embarrassante d'un auditeur.

C'est une question différente de la conformité formelle, et c'est celle sur laquelle nous voyons le plus de légèreté. Non pas « suis-je en règle avec la loi ? », mais « si quelque chose tourne mal, qu'est-ce que je peux montrer ? ». La différence entre les deux, c'est toute la gouvernance. Essayons de la mettre en ordre, en langage clair, sans alarmisme et sans la transformer en un sempiternel document de vingt pages que personne ne lit.

La gouvernance n'est pas un document : c'est un bloc qui accompagne chaque cas d'usage

L'erreur la plus courante est de penser la gouvernance de l'IA comme une politique générale — un PDF qui déclare des principes et finit dans un dossier. Ça ne fonctionne pas ainsi, parce que le risque ne vit pas dans l'entreprise de manière abstraite : il vit dans le workflow individuel. Un copilote qui suggère des réponses au support et un système qui filtre les CV entrants ont le même « niveau d'attention de l'entreprise », mais un profil de risque incomparable. La gouvernance sérieuse s'accroche au cas d'usage, pas à l'organisation.

Ce que nous utilisons — et c'est la structure que nous conseillons à toute PME, même sans nous — est un bloc court et répétable qui accompagne chaque conception de workflow. Cinq lignes, toujours les mêmes :

• Niveau de risque — où le cas d'usage se situe sur l'échelle de l'AI Act (presque toujours minimal ou limité ; haut risque uniquement pour le personnel, le crédit, la biométrie).
• Faut-il une AIPD ? — le contrôle RGPD sur le traitement des données personnelles concernées (voir plus bas : quand elle se déclenche et pourquoi celle « standard » ne suffit pas).
• Étiquettes de risque — une classification des façons dont ce workflow peut échouer, avec un vocabulaire partagé plutôt qu'avec des mots (voir la taxonomie du MIT plus loin).
• Mitigations — ce que nous mettons autour du risque : seuils, limites d'autonomie, revue humaine, minimisation des données.
• Surveillance et traçabilité — qui veille sur le fonctionnement et ce qui reste enregistré, et pour combien de temps.

La valeur de ce bloc n'est pas formelle : elle est opérationnelle. Quand le Garante, un client ou un auditeur demande « comment gérez-vous ce système ? », vous ne répondez pas par une philosophie — vous ouvrez le bloc du workflow spécifique et vous montrez les cinq lignes. C'est la différence entre déclarer être gouverné et l'être pour de vrai.

L'AIPD pour l'IA : quand elle est nécessaire, et pourquoi celle « standard » ne suffit pas

L'analyse d'impact relative à la protection des données (AIPD, art. 35 RGPD) est le premier outil concret de la gouvernance, mais c'est aussi le plus mal compris. Elle n'est pas toujours nécessaire : elle devient obligatoire quand le traitement est « susceptible d'engendrer un risque élevé ». Il y a trois cas qui la rendent automatique — décisions automatisées avec effets juridiques ou significatifs sur la personne, traitement à grande échelle de données sensibles (santé, opinions, biométrie), et surveillance systématique de zones accessibles au public — auxquels l'EDPB ajoute neuf critères supplémentaires (profilage, évaluation, usage de technologies innovantes). La plupart des déploiements d'IA en entreprise en touchent au moins un.

Jusqu'ici, c'est du RGPD classique. Le point que presque aucun modèle ne prend en considération, c'est qu'une AIPD générique, pensée pour une base de données ou un logiciel de gestion, passe à côté des risques propres à l'IA. Un modèle n'est pas un tableau : il a des comportements qu'une évaluation traditionnelle ne prévoit pas. Dans une AIPD pour l'IA, il faut ajouter, en tant que section dédiée, au moins quatre points qui n'existent pas ailleurs :

• Opacité du modèle — la décision peut ne pas être explicable ligne par ligne. Si le workflow a un impact sur une personne, « je ne sais pas pourquoi il a décidé ainsi » est un problème de conformité, pas seulement technique.
• Dérive (drift) — un modèle qui fonctionnait bien se dégrade avec le temps si les données d'entrée changent. Un contrôle fait une seule fois au lancement ne suffit pas : il doit être refait.
• Mémorisation des données d'entraînement — un modèle peut régurgiter des fragments des données avec lesquelles il a été entraîné, y compris des informations personnelles. C'est un vecteur de violation qu'une base de données n'a pas.
• Conflit avec le droit à l'oubli — effacer une donnée personnelle d'une base de données est trivial ; « désapprendre » une donnée d'un modèle déjà entraîné, souvent, ne l'est pas. L'AIPD doit dire ce qu'on fait quand cette demande arrive.

Si votre consultant vous propose l'AIPD qu'il utiliserait pour n'importe quel logiciel, sans cette section, il vous donne un formulaire, pas une évaluation. Et si l'AIPD révèle un risque élevé que vous ne parvenez pas à atténuer, le RGPD (art. 36) impose de consulter l'autorité de contrôle avant de procéder : rare pour une PME, mais à prévoir comme branche d'escalade, pas à découvrir une fois l'incident survenu.

Un vocabulaire partagé pour le risque, plutôt que des mots

« Ce système est risqué » n'est pas une information utile : c'est une impression. Le saut de qualité dans la gouvernance, c'est passer d'une prose vague à une étiquette répétable et citable, la même pour tous les workflows, de sorte que deux cas d'usage différents puissent être comparés. C'est pourquoi nous utilisons comme vocabulaire de référence l'AI Risk Repository du MIT, qui classe le risque selon deux axes :

• Comment naît le risque (axe causal) : l'entité qui le génère (humain / IA / autre), l'intention (intentionnelle / non intentionnelle), le moment (avant ou après le déploiement).
• De quel type de risque il s'agit (axe de domaine) : sept domaines — discrimination, vie privée et sécurité, désinformation, usage malveillant, interaction homme-machine, effets socioéconomiques, défaillances et limites du système.

Un exemple rend la méthode concrète. Un copilote pour les ventes qui de temps en temps « invente » un détail sur un produit — la classique hallucination — s'étiquette comme (entité : IA · intention : non intentionnelle · moment : après le déploiement) × (domaine : désinformation). Ce n'est pas une coquetterie académique : cette étiquette vous dit où agir (en aval, avec une vérification humaine sur la sortie avant qu'elle n'arrive au client) et vous donne un mot commun pour en parler avec ceux qui ne comprennent pas le modèle. La prose ne le fait pas : l'étiquette, si.

Les deux contrôles opérationnels qui comptent plus que tous les autres

On peut rédiger une gouvernance élaborée et rester exposé ; ou en tenir une légère avec deux contrôles solides et être vraiment défendable. Dans presque chaque cas d'usage d'une PME, ces deux-là font la différence.

Le premier est l'humain dans la boucle. Non pas comme un slogan, mais comme une architecture : qui veille sur le fonctionnement du système, avec quelle autorité pour l'arrêter, et sur quelles décisions son passage est obligatoire. C'est le même principe qui rend défendable un agent en administration et finance — où le résultat est irréversible parce qu'il déplace de l'argent — mais il vaut partout où une décision touche une personne. La règle pratique que nous donnons : n'accordez d'autonomie au système que là où le résultat est réversible et vérifiable ; tout le reste passe par une personne.

Le second est la traçabilité. Pour les usages à haut risque, l'article 26 de l'AI Act demande au déployeur de conserver les logs pendant au moins six mois et de signaler les incidents graves ; mais même en dehors de ce périmètre, garder trace de ce que le système a décidé, sur quelles données et qui a approuvé est ce qui transforme « on se fait confiance » en « on peut le démontrer ». Un registre à l'épreuve d'un contrôle, pas un prompt. C'est le contrôle le moins cher à mettre en place et le plus coûteux à ne pas avoir quand il le faut.

Le cadre italien : la conformité est un domaine vivant, pas une case à cocher

Ceux qui vous vendent une gouvernance « une fois pour toutes » ne regardent pas ce qui se passe en Italie. La loi 132/2025 a introduit les principes généraux du pays en matière d'intelligence artificielle et élargit le champ de l'AIPD pour les usages d'intelligence artificielle au-delà de la base du RGPD — ce qui signifie qu'il faut vérifier les exigences actuelles avant de les citer à un client, parce que le texte est récent et que la matière évolue. Côté contrôles, le Garante pour la protection des données personnelles a programmé, par sa délibération du 30 décembre 2025, au moins 40 missions d'inspection pour la période janvier-juillet 2026, et les domaines annoncés incluent explicitement les vérifications sur les outils d'IA utilisés en milieu scolaire. Même si votre cas d'usage est loin de l'école, cela dit une chose qui compte : les contrôles sur l'IA sont déjà au programme, ce n'est pas une hypothèse. La page du Garante sur l'IA est la source canonique à revérifier à chaque projet, parce que les orientations se mettent à jour souvent.

La lecture pratique : la gouvernance n'est pas un document que vous signez et archivez, c'est une pratique qui se révise. Un modèle dérive, une norme change, un cas d'usage s'étend — et le bloc des cinq lignes doit être rouvert. Ceux qui vous la vendent comme une case cochée une fois pour toutes vous rassurent, ils ne vous protègent pas.

De l'orientation à l'action, en pratique

Si vous êtes sur le point de mettre en production un cas d'usage et que vous voulez qu'il tienne, le chemin est court et ordonné :

• Accrochez le bloc au workflow, pas à l'entreprise — niveau de risque, AIPD oui/non, étiquettes, mitigations, surveillance. Cinq lignes pour chaque cas d'usage, pas un PDF pour l'entreprise entière.
• Si une AIPD est nécessaire, utilisez-en une avec la section IA — opacité, dérive, mémorisation, droit à l'oubli. Sans ces points, ce n'est pas une évaluation de l'IA, c'est un formulaire.
• Donnez une étiquette au risque, pas un adjectif — un vocabulaire partagé rend les cas comparables et les mitigations évidentes.
• Mettez l'humain-dans-la-boucle et la traçabilité dès le premier jour — ils ne ralentissent pas le projet : ils le rendent défendable. Ce sont les deux contrôles qui valent plus que toute la politique écrite.
• Traitez-la comme vivante — revérifiez le modèle, la norme italienne et le périmètre d'usage à intervalles réguliers, pas une seule fois au lancement.

Mais avant même cela, il vaut mieux savoir où vous en êtes : notre évaluation d'AI-readiness aide à comprendre par quel service commencer avec le plus de retour et le moins de friction, et quels contrôles mettre autour du premier workflow. C'est exactement ce bloc de gouvernance que notre overlay de conformité accroche à chaque conception que nous réalisons — pas un document à part, mais les contrôles à l'intérieur du flux.

Nous avons transformé le premier pas en une évaluation self-service et gratuite : quelques questions et une indication sur par où commencer, avec quels contrôles autour. Faites l'évaluation d'AI-readiness — et si le sujet est la gouvernance d'un cas d'usage que vous êtes sur le point d'adopter, écrivez-nous et nous en parlerons.

Cet article a une visée d'orientation et ne constitue pas un conseil juridique. Le cadre réglementaire sur l'AI Act, le RGPD et la loi italienne est en évolution — en particulier les échéances, le champ de l'AIPD et les orientations du Garante peuvent changer : ils doivent être vérifiés sur le texte en vigueur pour le cas concret de chaque entreprise.