Un responsable de programme IA reçoit généralement un seul mandat : veiller à ce que l'IA soit adoptée, que les équipes en tirent un gain de rapidité, que le programme montre des résultats. Un second mandat s'y ajoute rarement : veiller à ce que tout ce qui se développe en parallèle soit responsable. Pourtant, il est jugé sur les deux dès que quelque chose se passe mal. C'est le cœur de son risque : il est responsable d'un programme dont il ne connaît pas les limites.
Ce qu'il gagne avec l'adoption — des processus plus rapides, des équipes satisfaites, une histoire d'innovation visible — s'oppose à ce qu'il perd si les choses tournent mal : un incident avec un outil qui ne figurait pas sur sa liste, un audit qui pose des questions à lesquelles il n'a pas de réponse, un conseil de direction qui demande pourquoi le programme n'a pas vu ce qui était déjà en cours. Cette asymétrie rend sa position vulnérable, même si le programme lui-même se déroule bien.
Sa question n'est pas « quels outils IA avons-nous approuvés ». Cette liste, il la possède, et elle est souvent plus courte que la réalité. Sa question est : qu'utilisent les équipes qui ne figurent pas sur ma liste, et comment obtenir cette visibilité sans que les gens le cachent. Un responsable de programme qui veut stimuler l'adoption ne peut pas se permettre que les utilisateurs cachent leurs outils par peur d'une sanction. Celui qui demande ce qui est utilisé et en fait ensuite un problème n'obtiendra plus de réponse à la question suivante. La gouvernance et l'adoption jouent ici l'une contre l'autre si l'approche est mal menée.
Une réponse qu'il n'accepte pas est un simple blocage : « L'utilisation de l'IA n'est pas autorisée sans approbation. » Cette réponse satisfait un auditeur pendant un instant, mais déplace l'usage vers des endroits que personne ne voit. C'est le contraire de ce qu'un responsable de programme veut atteindre : il veut que l'usage de l'IA soit visible et encadré, pas qu'il passe dans la clandestinité. Une interdiction sans mécanisme de signalement et d'apprentissage représente pour lui une perte, même si elle paraît conforme sur le papier.
Il n'accepte pas non plus une réponse qui traite tout de la même manière. Un outil qui résume des textes pour un usage interne ne représente pas le même risque qu'un outil qui prend automatiquement des décisions concernant des clients ou des collaborateurs. Sans distinction selon le rôle et le niveau de risque, un programme ne peut pas établir de priorités, et un responsable de programme qui ne peut pas prioriser ne peut pas exécuter son mandat.
Ce qui fonctionne, c'est un inventaire qui part de ce qui existe, et non de ce qui est approuvé. Cela signifie poser des questions aux équipes sur ce qu'elles utilisent réellement, et le faire d'une manière qui n'entraîne pas de sanction. Ce n'est qu'ainsi que l'IA fantôme apparaît — les systèmes introduits sans démarche formelle, souvent parce qu'ils allégeaient le travail et que personne ne voyait de raison d'attendre une approbation.
Vient ensuite la classification : quelle application concerne les clients, laquelle ne concerne que le processus interne, laquelle prend des décisions sans intervention humaine. Cette répartition déterminera où le contrôle doit être renforcé et où il peut rester léger. Sans cette répartition, un programme traite tout avec la même intensité, faible ou forte, et les deux posent problème : la première freine l'adoption, la seconde laisse les risques non maîtrisés.
La structure de gouvernance qui en découle doit s'articuler avec ce qui existe déjà au sein de l'organisation — les comités de risque existants, les lignes de reporting existantes — et non créer un circuit parallèle. C'est aussi ce qui distingue un responsable de programme des autres rôles au sein de l'organisation : un administrateur veut savoir ce qu'un administrateur doit savoir sur le risque IA au niveau de la responsabilité finale, un CIO aborde la question sous l'angle des systèmes et des accès comme décrit dans ce qu'un CIO doit savoir sur le risque IA, et un General Counsel se penche sur la responsabilité juridique et l'obligation de documentation via ce qu'un General Counsel doit savoir sur le risque IA. Un responsable de programme doit pouvoir intégrer ces trois perspectives sans perdre sa propre mission — l'adoption.
Quelles obligations concrètes s'appliquent à quelle catégorie de risque, et dans quels délais, n'est pas l'objet de cette page. Ce texte évolue, se précise et fait l'objet d'explications ailleurs. Il s'agit ici du mécanisme : comment un programme obtient une vue sur ce qui se passe réellement, comment il traduit cela en niveaux de risque, et comment il le démontre de manière probante au conseil de direction et aux instances de contrôle, indépendamment de ce que prescrit exactement le texte réglementaire à un moment donné.
Dès qu'il est clair ce qui est en cours et qui en est responsable, une autre question se pose : ce que rapporte le fait de bien organiser ce travail. C'est une question qui doit être répondue tâche par tâche, et non organisation par organisation. Le werkscan de FTE TO AI calcule à ce niveau quelle part du travail peut être reprise par l'IA, afin qu'un responsable de programme sache non seulement ce qui se passe, mais aussi où l'ajout de capacité fait réellement la différence.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.