Évaluateur de risque de fonctionnalité IA
Un triage avant lancement en six questions. Répondez honnêtement et il renvoie un score de risque, les lacunes précises qui le plombent, et l'ordre dans lequel les corriger.
Ce qu'il vérifie
- Évalue la préparation au lancement sur six dimensions de risque
- Met en avant la correction la plus rentable
- Associe chaque lacune à une mesure concrète
- Vous donne un résumé partageable pour les parties prenantes
À propos de cet outil
Avant de livrer une fonctionnalité IA, la vraie question n'est pas « est-elle impressionnante ? » mais « que se passe-t-il quand elle a tort ? ». L'évaluateur de risque est un triage avant lancement en quelques questions : peut-elle agir (écrire, payer, envoyer) ? à qui sont les données dans la fenêtre de contexte ? journalisez-vous chaque prompt et appel d'outil ? faites-vous des évals adverses ? Répondez honnêtement et il renvoie un score, les lacunes qui le plombent, et l'ordre dans lequel les corriger.
Le score n'est pas une note d'examen — c'est une carte. Deux fonctionnalités peuvent avoir le même score pour des raisons opposées : l'une parce qu'elle déplace de l'argent sans journalisation, l'autre parce qu'elle est en lecture seule mais sans aucune éval. L'outil sépare ces cas et met en avant la correction la plus rentable.
Il s'aligne sur l'esprit du NIST AI RMF (gouverner, cartographier, mesurer, gérer) et produit un résumé partageable : de quoi cadrer une conversation de mise en production avec des parties prenantes non techniques.
Exemples
- Peut agir : envoie des e-mails clients. Données : autres utilisateurs. Journalisation : partielle. Évals adverses : non.
- Score : risque élevé. Lacune la plus rentable : journaliser intégralement prompts et appels d'outils — sans cela, un incident est ininvestigable. Étape suivante : ajouter des évals adverses avant d'élargir l'audience.
- Peut agir : lecture seule. Données : uniquement celles de l'utilisateur. Journalisation : intégrale. Évals : à chaque version.
- Score : risque faible. Aucune action bloquante. Surveiller la dérive au prochain changement de modèle ; un upgrade silencieux peut déplacer le comportement sans changer une ligne de votre code.
Faible risque ne veut pas dire zéro suivi — cela veut dire que le suivi suffit.