Tester un outil créé avec Claude : le plan de tests en six cas

Vous avez demandé à Claude de construire un petit outil. Il tourne devant vous, avec vos données d'essai, et le résultat est convaincant.

La vraie question vient après. Que se passe-t-il le lundi suivant, quand toute l'équipe s'en sert, avec des données moins propres et des demandes que vous n'aviez pas prévues ?

Cet article propose un plan de tests en six cas, lisible sans être développeur. Si vous débutez avec Claude, Maîtriser ChatGPT et Claude au travail est un meilleur point de départ.

La formation Claude avancé : automatiser et créer ses outils y consacre une séquence, « Tests et qualité », qui livre un plan de tests et un journal des corrections. Ce qui suit est notre lecture de ce vocabulaire, pas son programme.

Pourquoi « ça marche » ne suffit pas pour un outil créé avec Claude ?

Parce que vous l'avez essayé une fois, avec les données auxquelles vous pensiez. Un essai réussi montre que le cas prévu fonctionne. Il ne dit rien des autres.

La documentation d'Anthropic sur la création de tests le dit pour les applications bâties sur Claude : les évaluations doivent refléter les tâches réelles, y compris les cas limites. Elle cite par exemple des données absentes ou sans rapport, des entrées trop longues et des cas ambigus où même des humains hésiteraient (page consultée le 21 octobre 2026, sans date de mise à jour affichée).

Un outil interne est dans la même situation, avec de vrais utilisateurs à la place du jeu d'essai. S'il doit faire gagner du temps, comme dans la formation sur l'IA pour gagner du temps en entreprise, une erreur silencieuse en fait perdre.

Que doit faire l'outil, et que ne doit-il pas faire ?

Écrivez-le avant de tester, sur une page. Sinon, chaque résultat se discutera.

• À quoi sert l'outil, pour qui, avec quelle entrée et quelle sortie.
• Ce qu'il ne fait pas. Par exemple : il ne décide rien seul et ne modifie aucun fichier d'origine.
• Les données qu'il touche, et celles qu'il ne doit jamais toucher.

Si vous hésitez encore sur la tâche, choisir le premier cas d'usage d'un agent IA vient avant cet article. Si l'outil repose sur des instructions, gardez-les avec la page : un prompt que toute l'équipe peut réutiliser en décrit la structure.

Quels sont les six cas du plan de tests ?

1. Le cas nominal. L'usage prévu, avec des données réelles et non un exemple soigné.
2. Les cas limites et les données mal formées : champ vide, texte très long, mauvaise langue, fichier incomplet, demande qui n'a rien à voir.
3. Les erreurs et les pannes : le service ne répond pas, la limite d'usage est atteinte, une réponse arrive à moitié. L'outil doit le dire clairement et ne pas inventer une réponse.
4. Les permissions et les données sensibles : qui voit quoi, ce que l'outil peut lire ou modifier.
5. Les coûts d'usage : ce que coûte une journée normale, et une journée anormale.
6. Le retour en arrière : après chaque correction, on rejoue les cas précédents pour vérifier que rien ne s'est cassé.

Un tableur à cinq colonnes suffit : l'entrée, le résultat attendu, le résultat obtenu, ok ou non, la correction.

Selon nous, une personne non technique peut souvent mener les cas 1, 2 et 3, et observer le 5. Les cas 4 et 6 demandent le plus souvent un regard technique.

Que vérifier sur les permissions, les données et les secrets ?

L'OWASP, qui recense les risques des applications reposant sur un modèle de langage, décrit trois causes d'« excessive agency » : trop de fonctions, trop de droits, trop d'autonomie sans validation pour les actions à fort impact. Il conseille de ne donner à l'outil que le nécessaire et de demander l'accord d'une personne avant une action importante (fiche LLM06:2025, consultée le 21 octobre 2026).

Pour un petit outil interne, cela donne ces questions.

• L'outil peut-il écrire, supprimer ou envoyer quelque chose ? Si oui, une personne valide-t-elle avant ?
• Quels fichiers, quelles boîtes mail, quels comptes lui sont ouverts ? Le minimum suffit-il ?
• Des données personnelles ou confidentielles passent-elles par l'outil ?
• Où est la clé d'accès ? Le support d'Anthropic recommande de ne jamais l'écrire dans le code ni dans un fichier de configuration, mais de passer par une variable d'environnement (page consultée le 21 octobre 2026).

Cet article ne dit pas si votre outil respecte le RGPD. Pour les données personnelles, demandez l'avis de la personne qui s'en occupe chez vous.

Comment mesurer les coûts d'usage avant de généraliser ?

Si votre outil appelle l'API de Claude, chaque usage se paie, par million de tokens, avec un prix pour ce que l'outil envoie et un autre pour ce qu'il produit (page tarifaire consultée le 21 octobre 2026). Les tarifs changent : relisez-la le jour où vous budgétez.

L'OWASP range aussi dans ses risques la consommation non maîtrisée : un volume d'appels excessif qui fait grimper la facture. Parmi les parades, des quotas et une surveillance de l'usage (fiche LLM10:2025, consultée le 21 octobre 2026).

Faites tourner l'outil sur une journée type avec vos vraies données, puis relevez l'usage dans la console. Refaites l'essai avec les entrées les plus longues. Si votre compte le permet, fixez une limite de dépense : le support d'Anthropic la conseille.

À quoi ressemble un journal des corrections, et pourquoi tout rejouer ensuite ?

Cas fictif : un mini-outil imaginaire lit une demande interne et propose le service concerné (informatique, achats, ressources humaines). Aucune entreprise réelle n'est derrière, et les trois défauts sont inventés.

1. Cas limite. Une demande vide est classée « achats » par défaut. Correction : l'outil répond « à trier à la main ». Test rejoué : demande vide, puis demande d'un seul mot.
2. Permission. Les résultats arrivent dans un tableur partagé par toute l'équipe, y compris les demandes sensibles des ressources humaines. Correction : ces demandes vont dans un onglet à accès restreint. Test rejoué : une demande de ce type, vue depuis un compte sans droits.
3. Régression. Après la première correction, une demande en anglais est refusée alors qu'elle passait avant. Correction : la consigne sur la langue est reprise. Test rejoué : la demande en anglais, plus tous les cas précédents.

Le troisième défaut vient d'une correction du premier. Sans journal, personne ne l'aurait vu avant un utilisateur.

La règle : toute modification, même minuscule, relance l'ensemble des cas. L'évaluation de la formation cite d'ailleurs les tests de non-régression.

Quand s'arrêter, et quand demander de l'aide technique ?

Arrêtez-vous si l'outil échoue sur un cas de permission ou de données sensibles. Le reste peut se corriger plus tard.

Demandez de l'aide si le code touche à des comptes, à des paiements ou à des données clients, ou si personne ne sait lire ce qu'il fait.

Écrivez enfin les limites connues : ce que l'outil ne gère pas, les cas où il faut le contourner. Une limite écrite informe l'équipe. Une limite cachée devient un incident.

Si vous démarrez avec les agents, Créer son premier agent IA pose les bases. Pour choisir ce qui mérite d'être automatisé, cartographier les tâches où l'IA fait gagner du temps vient d'abord.

Notre position

Un petit outil utile se teste comme un vrai outil. Il lui faut un plan de tests écrit, des permissions réduites, un coût connu et des limites annoncées avant qu'on le confie à d'autres.

C'est le sens de la séquence « Tests et qualité » de Claude avancé : automatiser et créer ses outils. La page précise qu'aucun logiciel de production n'est garanti à l'issue : l'évaluation porte sur un prototype, des tests de non-régression et une soutenance avec limites connues. Le parcours IA utile et agents réunit des formations voisines.