L’annonce disait « AI Governance Manager » et la fiche de poste était, paragraphe pour paragraphe, celle d’un délégué à la protection des données avec deux phrases sur l’intelligence artificielle collées à la fin. Ce n’est pas un cas isolé : c’est le schéma avec lequel le marché couvre la fonction. On part du principe que celui qui vient de la protection des données ou de la conformité a déjà fait la moitié du chemin en gouvernance de l’IA. C’est à moitié vrai et à moitié un piège, et la différence ne se voit que depuis l’intérieur d’un système qui tourne en production depuis des mois.
La thèse en une ligne : les trois fonctions qu’on confond tous les jours — DPO, responsable conformité et responsable gouvernance de l’IA — ne se délimitent pas par l’organigramme, elles se délimitent par l’objet que chacune surveille. La donnée personnelle, le cadre réglementaire, le cycle de vie du système. Les confondre n’est pas un problème de titres sur une carte : c’est la raison pour laquelle, quand un agent se trompe, la réunion part quarante minutes sans que personne puisse dire qui répond.
La différence entre DPO et AI Governance Manager est dans l’objet, pas dans l’organigramme
Les trois fonctions répondent à des questions différentes parce qu’elles surveillent des choses différentes. Le DPO surveille un traitement : qu’il y ait une base légale, que la donnée soit le minimum nécessaire, que la personne sache qu’il existe. Le responsable conformité surveille un cadre : que l’entreprise soit dans la norme qui l’oblige, sectorielle, sociétaire ou sociale. Le responsable gouvernance de l’IA surveille un système dans le temps : avec quelles données il a été construit, ce qu’il décide, à quelle vitesse il dérive, qui l’approuve et qui l’éteint. Trois objets, trois horloges différentes.
| Fonction | Objet surveillé | Norme de référence | Question à laquelle elle répond |
|---|---|---|---|
| DPO / Délégué à la protection des données | Le traitement de données personnelles | RGPD, art. 37 à 39 | Ce traitement est-il licite et proportionné ? |
| Responsable conformité | Le cadre réglementaire qui oblige l’entreprise | Sectoriel, sociétaire, social | Sommes-nous dans la norme qui nous s’applique ? |
| Responsable gouvernance de l’IA | Le cycle de vie du système d’IA | Règlement européen sur l’IA, art. 10 et 26 | Ce système peut-il être déployé, et qui répond s’il échoue ? |
Dans une entreprise de soixante personnes, les trois peuvent être la même personne, et ça ne pose aucun problème : la fonction n’impose pas un poste. Ce qui casse, en revanche, c’est de supposer que couvrir un objet couvre les deux autres. Un traitement impeccable du point de vue de la protection des données peut reposer sur un système qui se trompe depuis quatre mois dans un cas sur douze sans que personne l’ait mesuré, parce que cette erreur n’est pas un problème de donnée personnelle : c’est un problème de cycle de vie.
Ce qu’un DPO surveille exactement, et où s’arrête son périmètre
L’article 39 du RGPD énumère cinq missions du délégué à la protection des données : informer et conseiller, contrôler le respect des règles de protection des données, dispenser des conseils sur l’analyse d’impact et en vérifier l’exécution, coopérer avec l’autorité de contrôle et faire office de point de contact pour elle. Les cinq pendent du même objet, le traitement de données personnelles. C’est la délimitation légale, pas notre lecture : voir article 39 du RGPD, missions du délégué à la protection des données. Portée : Union européenne.
Mets maintenant deux pannes réelles à côté. Un agent qui classe les tickets entrants et en aiguille mal un sur douze, si bien que le client attend deux jours de plus qu’il ne devrait. Un agent qui chiffre avec une grille tarifaire restée en arrière à la dernière révision. Dans aucun des deux il n’y a de donnée personnelle en risque, et dans les deux il y a de l’argent et de la confiance perdus. Le DPO n’a rien à surveiller là, et ce n’est pas un échec du DPO : la panne tombe hors de son objet. Ce qui tombe bien dans l’objet de la gouvernance de l’IA, dès le premier jour, c’est la portée avec laquelle cet agent peut toucher tes systèmes : le détail est dans quelles permissions donner à un agent IA.
Pourquoi venir de la conformité est la moitié du chemin et pas le chemin entier
Le règlement européen sur l’IA le dit avec une précision qu’il vaut la peine de lire en entier. L’article 26.2 établit que les déployeurs « confient le contrôle humain à des personnes physiques qui disposent des compétences, de la formation et de l’autorité nécessaires ainsi que du soutien nécessaire ». Source : article 26 du règlement (UE) 2024/1689, texte consolidé. Trois pieds, pas un. Et la norme ne se contente pas qu’un responsable existe dans l’organigramme : elle demande que cette personne comprenne le système, ait été formée sur ce système précis et puisse agir sur lui.
Voilà le piège du raccourci. Celui qui vient de la conformité apporte le troisième pied presque entier — l’autorité, et l’habitude de l’écrire, ce qui n’est pas rien — et apporte beaucoup du premier quand le risque est réglementaire. Ce qu’il n’apporte pas par défaut, c’est la compétence sur le système : savoir ce que signifie une sortie, dans quelles conditions elle se dégrade, à quoi ressemble une réponse plausible et fausse, ce que coûte un faux positif face à un faux négatif dans ce processus précis. Ça ne se lit pas, ça s’acquiert en exploitant. Donc « la moitié du chemin », c’est exact. Le problème commence quand on recrute comme si c’était le chemin entier, et que le trou apparaît le jour du premier incident.
Où commence vraiment l’obligation : articles 10 et 26
La conversation sur la gouvernance de l’IA commence d’habitude par l’article 10, qui régit les données et leur gouvernance : les jeux d’entraînement, de validation et de test, leurs critères de qualité, l’examen des biais et la traçabilité de la provenance. C’est un article décisif, mais il parle surtout de celui qui construit le système. Et la plupart des entreprises ne construisent pas : elles déploient. Elles achètent, configurent, branchent sur leurs données et mettent en service. Pour elles, l’article qui serre est le 26, celui des déployeurs, et cet ordre — d’abord où tu te situes, ensuite ce qui t’oblige — est celui qui ordonne tout le reste. La version longue, avec le cadre complet, est dans le guide gouvernance et contrôle de l’automatisation par l’IA.
Trois paragraphes de ce même article 26 dessinent la fonction mieux que n’importe quelle fiche de poste. Le paragraphe 5 oblige à surveiller le fonctionnement, à informer le fournisseur et l’autorité de surveillance du marché en cas de risque et à suspendre l’utilisation du système, et à signaler immédiatement les incidents graves. Le paragraphe 6 oblige à conserver les journaux générés automatiquement pendant au moins six mois. Et le paragraphe 9 renvoie à l’analyse d’impact de l’article 35 du RGPD. Ce dernier est la couture : l’analyse d’impact est le seul point où les deux objets se touchent vraiment, et c’est pour ça que c’est le document que DPO et gouvernance de l’IA signent ensemble au lieu de séparément.
Le report de l’Omnibus ne t’offre pas deux ans
Le calendrier du haut risque a bougé. Le règlement (UE) 2026/1744, l’Omnibus numérique sur l’IA, publié au Journal officiel de l’Union européenne, reporte les obligations des systèmes à haut risque autonomes au 2 décembre 2027 et celles des systèmes intégrés dans des produits déjà régulés à août 2028 ; le suivi du calendrier d’application publié par le Future of Privacy Forum le détaille bloc par bloc. Ce qui reste debout en août 2026, on l’a déjà développé dans l’AI Act a été reporté, mais ton chatbot doit toujours prévenir et on ne le répète pas ici. Portée : Union européenne.
Le point opérationnel est ailleurs, et c’est celui que presque personne ne tire du report : la date qui bouge est celle du manquement, pas celle du problème. Et un détail le rend urgent quand même. Si la norme va te demander au moins six mois de journaux, un système qui commence à journaliser la semaine où l’obligation tombe arrive avec le dossier vide, ce qui en pratique revient à arriver sans journaux. L’horloge de la preuve démarre avant celle de la conformité, et c’est le seul argument nécessaire pour ne pas attendre 2027.
Les deux questions qui délimitent la fonction mieux que n’importe quelle fiche de poste
Les fiches de poste de cette fonction se ressemblent toutes parce qu’elles sont écrites depuis la norme. Si tu veux savoir si tu l’as vraiment couverte, ne regarde pas le document : pose deux questions sur un système concret, celui qui bouge le plus d’argent, et écoute si la réponse tarde.
- Qui signe le déploiement ? Pas qui l’a approuvé en comité, mais qui a mis son nom sur la décision que ce système sorte en production avec cette portée et ces permissions. Si la réponse est un organe collégial, personne ne signe. Si la réponse est « le fournisseur le certifie », non plus : le fournisseur répond du produit, le déployeur répond de l’usage.
- Qui répond quand ça échoue ? Et dedans, la seule question qui sépare vraiment le contrôle du théâtre : qui peut l’éteindre sans demander la permission ? L’article 26 demande de l’autorité, et l’autorité sans la faculté d’arrêter est une signature décorative. Si pour débrancher l’agent il faut attendre le comité du jeudi, le système n’est pas surveillé : il est accompagné.
Les deux questions ont une propriété utile : elles se répondent avec un nom ou elles ne se répondent pas. Un cadre de gouvernance peut être impeccable en PDF et échouer aux deux. Si tu veux voir le saut de la politique écrite à la politique qui s’exécute, on l’a développé dans ta politique d’usage de l’IA est dans un PDF et ton agent ne sait pas le lire.
Quand tu n’as PAS besoin d’un AI Governance Manager
Avec un système en production, un processus et un responsable qui le connaît par cœur, nommer un responsable gouvernance de l’IA est prématuré, et ce que tu achètes avec cette nomination n’est pas un contrôle : c’est un comité. La gouvernance lourde trop tôt a un coût concret et mesurable, celui des semaines que le premier cas d’usage passe à ne pas sortir pendant qu’on rédige le cadre qui va le régir. Le profil complet de la fonction, avec son échelle de séniorité et ce que demande le marché, est sur la fiche AI Governance Lead.
Le seuil n’est pas un chiffre d’effectif, c’est un symptôme : le jour où personne ne peut énumérer de mémoire tous les agents qui tournent dans l’entreprise, la fonction est déjà nécessaire, nommée ou pas. Et avant la fonction vient le recensement, parce qu’on n’applique pas une politique à une flotte qu’on n’a pas comptée : on en a discuté dans l’inventaire des agents que ton entreprise n’a pas.
Ce que je ferais lundi
- Liste les systèmes d’IA qui tournent et, à côté de chacun, un nom. Pas l’équipe : la personne. Les cases vides sont ton diagnostic, et il y en a d’habitude plus que prévu.
- Pour les deux qui bougent le plus d’argent, réponds par écrit aux deux questions. Une phrase chacune. Si ça ne tient pas en une phrase, ce n’est pas encore répondu.
- Sépare sur une feuille l’objet du DPO et l’objet de la gouvernance de l’IA pour ces deux systèmes, et marque le point où ils se croisent : l’analyse d’impact. C’est le seul document que les deux signent.
- Allume l’horloge des journaux aujourd’hui, même si l’obligation est de 2027. Six mois d’historique ne se rétroactivent pas, et c’est le seul point de cette liste qui dépend du calendrier et pas de toi.
La gouvernance de l’IA ne se règle pas en recrutant un titre, elle se règle en décidant qui signe et qui éteint, et en laissant une trace des deux. Si tu veux monter cette fonction sans passer six mois à écrire le cadre avant de contrôler quoi que ce soit, c’est exactement ce qu’on fait dans gouverner les agents IA de ton entreprise : la trace, les permissions et la chaîne de responsabilité d’abord, et le document après, qui est l’ordre dans lequel ça marche vraiment.