Dès qu'une entreprise dépasse deux ou trois usages IA, quelqu'un propose de créer un comité. C'est presque toujours une mauvaise idée, et pourtant le besoin derrière est réel. La gouvernance dont tu as besoin ne tient pas dans une instance : elle tient dans trois décisions attribuées à trois personnes, et une revue greffée sur une réunion qui existe déjà.
Le vrai besoin : que quelqu'un tranche
Ce qu'on appelle « gouvernance IA » recouvre en réalité un manque très concret. Trois questions reviennent, et personne ne sait à qui les poser :
- Est-ce que j'ai le droit d'utiliser cet outil ?
- Qui dit oui à ce nouveau cas d'usage, et sur quels critères ?
- Qui regarde ce qui tourne déjà, et qui débranche si ça dérape ?
Tant que ces trois questions n'ont pas de destinataire, l'entreprise oscille entre le blocage et le laisser-faire. Un comité ne répond pas à ces questions : il les met à l'ordre du jour de la prochaine séance, dans six semaines.
Décision 1 — Quels outils sont autorisés
Ce que ça recouvre : la liste des produits utilisables avec un compte professionnel, les conditions contractuelles vérifiées, ce qu'on fait quand quelqu'un demande un outil qui n'y est pas.
Qui : la personne qui porte déjà les sujets systèmes d'information et achats. Dans une PME, c'est souvent le DAF ou le responsable informatique. Dans une structure plus petite, le dirigeant lui-même.
Le critère qui compte : un délai de réponse annoncé. Deux semaines pour instruire une demande d'outil, c'est acceptable. Pas de délai du tout, c'est un refus déguisé — et le contournement commence là.
Cette décision inclut la vérification des conditions : localisation du traitement, statut du fournisseur, rétention des données. Sur les points contractuels et de données personnelles, fais valider par un juriste ou ton DPO ; ce que je décris ici est une répartition de responsabilités, pas un avis juridique.
Décision 2 — Qui valide un nouveau cas d'usage
Ce que ça recouvre : l'autorisation d'aller construire quelque chose. Pas la validation technique, la validation d'opportunité et de risque.
Qui : un responsable métier, pas la DSI. La personne qui répondra du résultat devant ses clients ou son équipe. C'est le point le plus souvent raté : quand la validation est portée par la technique, les cas d'usage retenus sont ceux qui sont faisables, pas ceux qui servent.
Sur quels critères : trois, écrits, connus de tous.
Qui est affecté par la sortie du système, et le système décide-t-il à la place d'un humain ? Quelles données entrent réellement, et sortent-elles de l'entreprise ? Qui sera propriétaire du dispositif une fois en production ?
Une fiche d'une page qui répond à ces trois questions suffit à trancher la grande majorité des demandes. Le reste, c'est précisément ce qui mérite une vraie discussion — et parfois un avis extérieur.
Décision 3 — Qui surveille ce qui tourne
Ce que ça recouvre : l'existant. La liste des dispositifs en production, leur propriétaire, leur état de santé, et l'autorité pour arrêter quelque chose qui dérive.
Qui : la personne qui tient déjà le registre des applications, ou à défaut celle qui a la meilleure vue transverse. Le point important n'est pas son titre, c'est qu'elle ait explicitement le droit de débrancher.
Avec quoi : un tableau de dix lignes. Nom du dispositif, propriétaire, date de mise en service, données concernées, dernière revue. C'est le document le plus utile de tout le dispositif de gouvernance, et il tient dans un tableur.
La revue : greffée, jamais créée
Une fois par trimestre, quarante minutes. Ajoutées à un comité de direction ou à une revue de projets qui existe déjà.
Trois points à l'ordre du jour :
- Ce qui tourne : le tableau, mis à jour, avec ce qui a été arrêté et pourquoi.
- Ce qui a été demandé et refusé, et les raisons. C'est le point qui révèle si les critères sont bien calibrés.
- Un cas d'usage regardé en détail, choisi à l'avance, avec ses chiffres réels d'utilisation.
Quarante minutes, quatre fois par an. Si le sujet grossit au point de nécessiter davantage, tu le sauras — et tu auras alors de vraies raisons de créer une instance, avec de la matière à y mettre.
Ce qui rate quand on crée un comité dédié
J'ai vu ce scénario se dérouler plusieurs fois, avec une régularité qui n'est pas un hasard.
Il se réunit trop tard. Le premier comité IA est convoqué six semaines après sa création. Entre-temps, trois équipes ont avancé sans lui, parce qu'elles avaient un travail à faire.
Il attire les mauvaises personnes. Un comité nouveau et visible attire ceux qui veulent être vus sur le sujet, pas ceux qui portent des usages. Autour de la table, il y a huit personnes dont deux qui utilisent réellement quelque chose.
Il produit de la doctrine au lieu de décisions. Faute de cas concrets à trancher, il rédige une politique, une charte, une matrice de maturité. Des documents qui ne débloquent personne.
Il déresponsabilise. Dès qu'un comité existe, plus personne ne décide seul. Une question qui se réglait en deux jours par un échange direct attend maintenant la prochaine séance. Le comité devient le goulot qu'il était censé supprimer.
Il meurt discrètement. Deux séances, puis un report, puis plus rien. Et le sujet est désormais associé à un échec, ce qui rend la deuxième tentative plus difficile que la première.
Le test en une minute
Pose la question à trois personnes de ton entreprise : « si tu veux utiliser un nouvel outil IA demain, tu demandes à qui ? » Si tu obtiens trois prénoms différents, ou trois hésitations, tu n'as pas un problème de comité. Tu as trois décisions qui n'ont pas de propriétaire. Attribue-les cette semaine, par écrit, et regarde ce qui se passe avant d'installer quoi que ce soit de plus lourd.