Évaluer un outil d’IA sans se laisser impressionner par une démo

Une démo ne prouve rien, seule

Une démonstration choisit le meilleur chemin : une question facile, un contexte préparé et une sortie qui se juge en quelques secondes. Elle peut être utile pour comprendre l’interface, mais elle ne mesure ni la robustesse ni le coût d’un usage régulier. Avant d’ouvrir un compte, écrivez plutôt la tâche à évaluer et le dommage d’une erreur.

Le NIST AI Risk Management Framework propose de traiter le risque comme une activité continue : le contexte, les impacts et les contrôles doivent être documentés avant puis pendant l’usage. Pour un petit outil, cela peut tenir sur une page.

Constituer un jeu de test

Préparez quinze à trente cas répartis en quatre familles : cas ordinaires, formulations ambiguës, cas limites et demandes auxquelles l’outil doit refuser de répondre. Gardez les entrées dans un fichier versionné sans données personnelles. Ajoutez une réponse attendue ou une règle d’acceptation : présence d’une source, format JSON valide, absence d’un secret, ou refus explicite.

Ne changez pas le jeu de test après chaque essai. Sinon, vous sélectionnez progressivement les exemples qui arrangent l’outil. Si le fournisseur modifie son modèle, conservez la date, la version annoncée quand elle existe et le résultat brut utile à l’audit.

Noter séparément qualité et risque

Une note unique masque les arbitrages. Mesurez au moins : exactitude, complétude, stabilité entre deux exécutions, temps de réponse, quantité de retouches humaines et coût par tâche. Ajoutez une colonne « conséquence » : une erreur de style et une erreur de droit ne se traitent pas de la même façon.

Pour un agent qui appelle des outils, contrôlez aussi les permissions demandées, les données envoyées et les actions effectivement déclenchées. L’OWASP LLM Top 10 rappelle que les risques ne sont pas limités au texte produit : une intégration peut exposer des instructions, des secrets ou des outils trop puissants.

Décider avec des inconnues visibles

Une conclusion utile ne dit pas seulement « bon » ou « mauvais ». Elle indique la tâche couverte, les cas non testés, les contrôles nécessaires et le coût de sortie. Si l’outil est convaincant mais ne permet pas d’exporter les données, de supprimer un espace ou de comprendre son traitement, l’inconnue est un résultat, pas un détail à remplir par hypothèse.

Pour commencer, copiez la méthode de notre workflow Next.js avec des agents, puis remplacez le test de code par votre jeu de cas métier. Une décision prudente peut être de garder l’outil en bac à sable tant que les preuves manquent.

Sources et limites

Cet article s’appuie sur le NIST AI RMF et l’OWASP LLM Top 10, vérifiés le 21 septembre 2026. Il ne constitue ni un test d’un fournisseur précis ni une garantie de performance.