Les politiques consacrées aux risques de l’intelligence artificielle semblent souvent convaincantes jusqu’au moment où une équipe doit décider si un système est prêt à être utilisé par de vraies personnes. Le National Institute of Standards and Technology des États-Unis, ou NIST, a conçu son cadre volontaire AI Risk Management Framework, l’AI RMF, pour aider les organisations à intégrer les considérations de fiabilité à la conception, au développement, à l’utilisation et à l’évaluation des systèmes d’IA. Son noyau pratique s’organise autour de quatre fonctions : Govern, Map, Measure et Manage.
Ces fonctions ne constituent ni une séquence à exécuter une seule fois ni un label de certification. Ce sont des formes de travail interdépendantes. La gouvernance façonne chaque décision ; la cartographie donne un contexte aux mesures ; la mesure fournit des preuves ; et la gestion transforme ces preuves en priorités et en actions.
Govern : rendre les responsabilités visibles
Govern constitue le socle. Une équipe a besoin de responsables nommément désignés, de voies d’escalade, de politiques, d’exigences documentaires et d’un moyen d’intégrer le point de vue des personnes concernées. Elle doit savoir qui peut approuver le déploiement, qui peut l’arrêter, qui enquête sur un incident et quelles preuves doivent être conservées.
Un registre de gouvernance utile est précis. Au lieu d’affirmer que « l’humain garde le contrôle », il faut identifier la décision qu’une personne examine, les informations dont elle dispose, le temps qui lui est accordé et ce qui se passe lorsque le niveau de confiance est faible. La gouvernance couvre également les fournisseurs : l’achat d’un modèle ne transfère pas la responsabilité hors de l’organisation qui l’utilise.
Map : comprendre le système dans son contexte
Map consiste à déterminer à quoi sert le système d’IA, où il fonctionnera et qui pourra en ressentir les bénéfices ou les préjudices. Un même modèle peut présenter des risques très différents dans un outil privé de rédaction, un dispositif de présélection pour le recrutement ou un processus clinique. Les équipes doivent décrire l’usage prévu, les détournements prévisibles, les groupes concernés, les dépendances, la provenance des données et les conséquences d’une défaillance.
Une bonne cartographie consigne aussi les hypothèses. La langue des données d’entrée est-elle prise en charge ? L’utilisateur saura-t-il que le résultat a été généré par une machine ? Une personne peut-elle contester un résultat ? Quel environnement a été utilisé pendant les tests et en quoi la production diffère-t-elle ? Une hypothèse explicite peut être testée ; une hypothèse cachée devient une surprise.
Measure : recueillir des preuves qui répondent aux questions cartographiées
Measure ne se limite pas à communiquer un seul score de précision. Selon le contexte, les preuves peuvent porter sur la fiabilité face à des entrées variables, les performances de différents sous-groupes, les tests de confidentialité et de sécurité, les taux de contenu préjudiciable, la calibration, l’accessibilité, les études sur les facteurs humains et les observations après déploiement. L’indicateur doit être relié au risque décrit lors de la cartographie.
Les équipes doivent définir les seuils avant de connaître les résultats, documenter les limites et conserver les tests qui ont échoué au lieu de ne retenir que les chiffres favorables. Certains préjudices se réduisent difficilement à un seul indicateur ; une analyse qualitative et les retours des personnes concernées peuvent donc compléter les tests quantitatifs. La mesure réduit l’incertitude ; elle ne l’élimine pas.
Manage : hiérarchiser, agir et poursuivre la surveillance
Manage transforme le tableau des risques en décisions. Une équipe peut atténuer un risque, restreindre le cas d’usage, ajouter une vérification humaine, surveiller un indicateur précurseur, préparer un retour à l’état précédent ou décider de ne pas déployer. Les priorités doivent refléter la probabilité, la gravité et la tolérance au risque de l’organisation, et non simplement la facilité d’une correction.
La gestion se poursuit après le lancement. Les modèles, les données, le comportement des utilisateurs et les conditions extérieures peuvent évoluer. Un plan pratique comprend donc la surveillance, le traitement des incidents, la maîtrise des changements et un déclencheur de réévaluation. Si une mise à jour du modèle modifie son comportement, un ancien rapport de test est une preuve historique, pas une autorisation automatique de la nouvelle version.
Utiliser des profils pour adapter le cadre au contexte local
Le NIST décrit les profils comme des mises en œuvre des fonctions, catégories et sous-catégories du cadre dans un environnement particulier. Un profil actuel peut décrire la manière dont une organisation gère aujourd’hui un cas d’usage ; un profil cible peut décrire l’état souhaité. L’écart entre les deux produit une liste concrète d’améliorations à réaliser.
Cette adaptation est importante, car le Playbook n’est pas une liste de contrôle que chaque organisation doit suivre intégralement. Le NIST propose des actions parmi lesquelles les utilisateurs peuvent choisir selon leur cas d’usage, leurs ressources et leurs centres d’intérêt. Reprendre chaque proposition sans la relier à une décision réelle peut créer de la paperasserie sans rendre les résultats plus sûrs.
Un schéma de départ pour une petite équipe
- Govern : nommez le responsable, la personne chargée de la vérification, l’autorité habilitée à interrompre le système et l’emplacement des preuves.
- Map : consignez l’usage prévu, les personnes concernées, les principaux modes de défaillance et les hypothèses.
- Measure : choisissez des tests et des seuils qui traitent ces modes de défaillance.
- Manage : décidez ce qui doit changer avant le lancement et ce qui déclenchera ensuite un retour en arrière ou une nouvelle vérification.
Reprenez les quatre fonctions lorsque le cas d’usage, le modèle, les données ou l’environnement opérationnel changent. La valeur ne réside pas dans le nombre de documents produits. Elle réside dans la capacité de l’organisation à expliquer ce qu’elle savait, ce qu’elle a testé, ce qu’elle a décidé et qui reste responsable.
Ce que le cadre peut prouver — et ce qu’il ne peut pas prouver
L’utilisation de l’AI RMF peut améliorer la discipline et le langage commun, mais elle ne prouve pas à elle seule qu’un système est sûr, légal ou adapté. Le NIST décrit le cadre comme volontaire et le Playbook qui l’accompagne comme une ressource flexible. Les obligations légales, les règles sectorielles et une assurance indépendante peuvent toujours s’appliquer.
L’affirmation responsable reste donc mesurée : les quatre fonctions aident les équipes à poser de meilleures questions et à relier les principes à des décisions étayées par des preuves. Elles constituent une structure de gestion continue des risques, et non un badge qui met fin à la discussion.
Sources primaires
NIST AI Risk Management Framework et NIST AI RMF Playbook. Consultés le 11 septembre 2026.