Temps de lecture estimé : 3 min · Publié le 1 octobre 2026
Définir une tâche et son niveau d’exigence
Choisissez une tâche précise : suggérer des titres, classer des demandes, traduire une page ou répondre à partir d’une documentation. Définissez le résultat attendu et ce qui constituerait une erreur importante. Une aide à la rédaction interne n’a pas les mêmes conséquences qu’une réponse publique sur un prix, un délai ou une condition contractuelle.
Le cadre de gestion des risques de l’IA du NIST et son profil consacré à l’IA générative offrent des repères pour organiser l’évaluation. Ils ne valident pas un produit particulier. Votre grille doit relier les risques au contexte de la tâche, au public et à la manière dont le résultat sera utilisé.
- Tâche et public.
- Résultat vérifiable.
- Erreurs acceptables ou bloquantes.
- Responsable de la décision.
Examiner les données et la réversibilité
Listez les données envoyées au service, les personnes qui peuvent y accéder, les règles de conservation et les conditions d’usage annoncées. Vérifiez ces informations dans la documentation et le contrat du fournisseur. Ne partez pas du principe que tous les produits d’un même éditeur ont les mêmes règles. Un compte grand public, une API et une offre d’entreprise peuvent avoir des conditions distinctes.
Préparez d’abord des exemples anonymisés ou synthétiques clairement identifiés pour les essais. Définissez ce qui peut être exporté, comment changer de fournisseur et quelle tâche restera possible en cas d’indisponibilité. Le stockage des instructions, sources et évaluations doit rester compréhensible pour l’équipe qui reprendra le projet.
- Données autorisées pour le test.
- Conditions propres à l’offre utilisée.
- Accès, conservation et export.
- Solution de reprise manuelle.
Constituer un petit jeu de tests exigeant
Réunissez des exemples représentatifs et des cas difficiles : information absente, source contradictoire, demande ambiguë, langue différente et tentative de détourner les consignes. Définissez la réponse de référence ou les critères d’acceptation avant l’essai. Un outil qui refuse de répondre lorsqu’une donnée manque peut être plus utile qu’un outil qui produit une réponse convaincante mais inventée.
Mesurez séparément exactitude, omissions, références, temps de réponse et coût dans le scénario choisi. Relisez plusieurs résultats : une génération peut varier. Conservez la version du modèle ou de l’offre quand elle est connue, les paramètres utiles, la date du test et les exemples utilisés. Aucun score global ne doit masquer un échec sur une tâche essentielle.
- Cas représentatifs et cas limites.
- Critères définis avant le test.
- Erreurs documentées par exemple.
- Version et date des essais.
Limiter le déploiement et vérifier dans la durée
Commencez par un usage où les résultats sont relus. Pour un assistant public, limitez les actions possibles, rendez les sources accessibles et prévoyez une orientation vers une personne quand la demande dépasse le périmètre. Testez la reprise après une panne, une réponse invalide ou une modification des documents. Les résultats doivent être observables sans enregistrer inutilement des données personnelles.
Refaites les tests après un changement de modèle, d’instructions, de documentation ou de fonctionnalités. Le guide de vérification des sources aide à relire les productions éditoriales. L’annuaire des ressources d’IA présente des points de départ officiels pour comparer les offres, sans garantir leurs résultats.