Troisième et dernier article d’une série en trois parties sur l’intelligence artificielle : définitions, applications professionnelles et gouvernance.
Le deuxième article de cette série se terminait sur une chaîne de raisonnement : la performance d’un modèle mesure s’il atteint l’objectif qu’on lui a fixé, mais elle ne dit rien sur la légitimité de cet objectif — et c’est précisément ce glissement, de la performance vers l’objectif, puis de l’objectif vers les valeurs qu’il est censé refléter, qui rend la gouvernance des systèmes d’IA indispensable. Ce troisième article part de ce constat pour aborder de front la question qui le sous-tend : comment s’assurer qu’un système d’IA reste aligné avec ce qu’on attend réellement de lui ?
Alignement et spécification : deux problèmes liés, mais différents
En recherche en IA, on parle de problème d’alignement des valeurs pour désigner une question large : comment faire en sorte qu’un système poursuive des objectifs compatibles avec les intentions et les valeurs humaines ? Une des principales difficultés qui rend ce problème concret s’appelle le problème de spécification : comment traduire une intention humaine, forcément nuancée, en un objectif suffisamment précis pour qu’une machine puisse l’optimiser ?
Concrètement, un objectif « suffisamment précis » pour un programmeur, c’est un nombre à faire monter ou descendre : « minimiser l’écart entre le prix prédit et le prix réel », « maximiser le taux de clic sur une recommandation », « maximiser le temps passé sur une page ». Le problème, c’est que l’intention humaine derrière ces objectifs est presque toujours plus large que le nombre choisi pour la représenter. On ne veut pas vraiment « maximiser le temps passé sur une page » — on veut que le contenu proposé soit utile ou intéressant, et on choisit « le temps passé » parce que c’est facile à mesurer et qu’on suppose que ça reflète l’intérêt de l’utilisateur. C’est cet écart entre l’intention réelle et le nombre choisi pour l’approximer qui constitue le problème de spécification.
Cette distinction n’est pas qu’un détail terminologique. Elle permet de formuler une idée beaucoup plus intéressante que « l’IA doit être éthique » : le problème n’est pas toujours que le système ne suit pas l’objectif qu’on lui a donné. Parfois, il le suit parfaitement — mais cet objectif était une mauvaise représentation de ce qu’on voulait réellement.
On retrouve ce même piège en dehors de l’IA, à chaque fois qu’on remplace un objectif par un indicateur censé le mesurer : demandez à une équipe commerciale de maximiser le nombre d’appels passés plutôt que le nombre de ventes, et elle finira par passer plus d’appels courts et inutiles — l’indicateur grimpe, l’objectif réel s’éloigne. C’est ce qu’on appelle parfois la loi de Goodhart : dès qu’un indicateur devient la cible qu’on optimise directement, il cesse d’être une bonne mesure de ce qu’il était censé représenter.
Le même phénomène peut se produire avec une IA, simplement de façon plus systématique et à plus grande échelle. Prenons un exemple hypothétique : un algorithme de recommandation reçoit pour consigne de maximiser le temps que les utilisateurs passent sur une plateforme, choisi comme indicateur approximatif de leur « satisfaction ». S’il s’avère que le contenu le plus polarisant ou le plus addictif retient le plus longtemps l’attention, l’algorithme va apprendre à en recommander davantage — non pas parce qu’il a mal fonctionné, mais parce qu’il a très bien optimisé l’indicateur qu’on lui avait donné, un indicateur qui, une fois transformé en cible, ne représentait plus vraiment la satisfaction qu’il était censé mesurer.
C’est exactement le même mécanisme qu’on a vu dans l’article précédent avec le scoring de crédit biaisé : le modèle ne « se trompe » pas au sens statistique, il optimise fidèlement un objectif qui, lui, ne capturait pas ce qu’on entendait réellement par une décision juste.
Quand il n’existe pas de bonne réponse universelle
Le dilemme du véhicule autonome illustre une autre facette du problème : que doit faire une voiture autonome si un accident devient inévitable — protéger ses passagers en priorité, ou minimiser le nombre total de victimes, y compris chez les piétons ?
En 2018, une équipe du MIT a exploré cette question à grande échelle avec la plateforme Moral Machine, en soumettant des millions de scénarios de ce type à des participants du monde entier. Les résultats, publiés dans la revue Nature, ont montré que les préférences morales varient significativement selon les cultures et les régions — il n’existe pas de consensus universel sur la « bonne » réponse.
Cela soulève une question qu’on esquive trop souvent : qui décide, concrètement, des valeurs encodées dans un système ? Ce n’est presque jamais un seul acteur — ni le data scientist qui construit le modèle, ni l’ingénieur qui le déploie, ni le fournisseur de la technologie, ni l’auditeur qui le contrôle, ni même le régulateur. C’est souvent un mélange de tous ces rôles, et parfois, en pratique, ce n’est explicitement personne — les valeurs restent implicites dans les choix techniques successifs, sans jamais avoir été formulées ni validées comme telles.
C’est précisément là que la gouvernance devient nécessaire : les valeurs qui gouvernent un système ne peuvent pas rester implicites dans le code. Elles doivent être rendues explicites, documentées, et révisables.
Le rôle de l’audit : évaluer le système de contrôle, pas le modèle
C’est ce constat qui explique pourquoi des fonctions comme l’audit interne commencent à s’intéresser de près aux systèmes d’IA déployés en entreprise — même si, à ce jour, cette pratique reste jeune et inégale selon les organisations et les secteurs.
Le rôle de l’auditeur n’est pas de répondre à la question « ce modèle est-il mathématiquement optimal ? ». C’est une question technique qui revient aux data scientists. Le rôle de l’auditeur est plutôt de vérifier :
- qui a défini l’objectif du système, et pourquoi ce choix a été fait ;
- quelles données ont été utilisées, et quelles hypothèses ont été posées ;
- quels risques ont été identifiés, et par qui ;
- qui est responsable du système une fois en production ;
- quels contrôles existent, et comment le système est surveillé dans la durée ;
- ce qui se passe lorsqu’il se trompe, et qui peut le suspendre, le corriger ou le désactiver.
Autrement dit : l’auditeur ne valide pas le modèle ; il évalue le système de contrôle qui permet à l’organisation de lui faire confiance. C’est une nuance importante — et c’est elle qui permet à quelqu’un sans expertise en machine learning de jouer un rôle légitime et utile dans la gouvernance de systèmes très techniques.
Un point mérite d’être isolé dans cette liste : le contrôle et l’intervention humaine. Existe-t-il un mécanisme permettant de suspendre, corriger ou désactiver le système lorsque son comportement s’écarte de ce qui était attendu ? Sans cette capacité d’intervention, tout le reste — traçabilité, documentation des risques, tests de biais — reste largement théorique.
La gouvernance ne s’arrête pas au déploiement
Il manque un élément à ce tableau si on s’arrête à la phase de conception et de mise en production : ce qui se passe après. Un modèle validé au moment de son déploiement peut dériver avec le temps — les données changent, les comportements des utilisateurs évoluent, le contexte réglementaire se transforme, ou le système finit par être utilisé dans un cadre différent de celui pour lequel il avait été conçu et validé.
Un modèle correctement gouverné n’est donc pas seulement un modèle correctement validé avant son déploiement. C’est un système dont le comportement continue d’être surveillé, réévalué et, si nécessaire, corrigé après sa mise en production. C’est d’ailleurs exactement la logique que retient le NIST AI Risk Management Framework aux États-Unis, un cadre volontaire structuré autour de quatre fonctions — Govern, Map, Measure, Manage — qui présente explicitement la gestion des risques liés à l’IA comme une démarche continue sur tout le cycle de vie du système, et non comme une étape ponctuelle.
Du côté réglementaire, l’AI Act européen adopte une approche fondée sur le niveau de risque du système, avec des obligations croissantes selon cette classification ; certaines obligations de transparence prévues à l’article 50 sont d’ailleurs applicables depuis le 2 août 2026. Le NIST AI RMF, à la différence de l’AI Act, n’a pas de valeur contraignante : c’est un cadre volontaire destiné à aider les organisations à structurer elles-mêmes leur gestion des risques liés à l’IA.
Où je me positionne
J’ai été des deux côtés de ce problème : construire et analyser des modèles, et devoir ensuite évaluer les risques qu’ils introduisent une fois déployés. Cette double perspective m’a convaincu que l’avenir de la gouvernance IA ne repose pas sur des règles de plus en plus rigides imposées de l’extérieur aux équipes techniques après coup. Les cas les plus solides que j’ai rencontrés sont ceux où la question de l’alignement est posée dès la conception du modèle, pas ajoutée après comme une couche de conformité.
Cela suppose un dialogue plus étroit entre data scientists, auditeurs et décideurs métier — trois rôles qui, aujourd’hui encore, se parlent souvent trop tard dans le cycle de vie d’un projet IA.
Ce que cette série retient
Cette série a suivi un même fil : d’abord comprendre ce qu’est réellement l’IA — imitation ou rationalité — puis voir comment cette rationalité s’exprime dans des décisions professionnelles à fort enjeu, et enfin constater qu’une décision rationnelle n’est jamais automatiquement une bonne décision, ni une décision gouvernée dans la durée. La question qui reste, pour toute organisation qui déploie de l’IA aujourd’hui, n’est donc pas « notre modèle est-il performant ? », mais « savons-nous encore pourquoi il décide ce qu’il décide, et sommes-nous prêts à en répondre — aujourd’hui comme dans un an ? »
Et vous : dans votre organisation, qui pose aujourd’hui ces questions de gouvernance sur les systèmes d’IA déployés — l’équipe technique, la conformité, personne encore ? Dites-le moi en commentaire.