Le Discernement pour le code — AI Fluency — Builders

Objectifs

À l’issue de cette leçon, vous serez capable de :

Évaluer un travail produit par l’IA selon cinq angles : exactitude, solidité, adéquation, expérience et responsabilité
Placer votre exigence au-delà de « ça marche », en connaissant les modes de défaillance propres aux produits construits avec l’IA
Repérer les angles morts techniques prévisibles de l’IA avant qu’ils n’atteignent la production

« Ça tourne » n’est plus le critère

Vous avez construit quelque chose avec l’IA. Ça tourne, les tests passent. Et alors ?

Reprenez le projet fil rouge. Votre outil gère-t-il un temps d’attente estimé qui passe soudain de 10 à 90 minutes ? Tient-il compte de patients aux besoins différents ? A-t-il repris des biais historiques présents dans les données ? Un produit qui fonctionne et un bon produit ne sont pas toujours la même chose. Et quand l’IA peut produire un produit fonctionnel en quelques minutes, votre capacité à faire la différence devient la compétence la plus précieuse de la pièce.

Cette leçon donne une structure à ce jugement : cinq angles d’analyse, et cinq questions à poser à tout ce que l’IA construit.

D'après la leçon « Discernment for code » (Claude Academy, AI Fluency for Builders).

Les cinq angles du Discernement

Angle	La question	Une vérification concrète	La défaillance typique de l’IA
1. Intégrité fonctionnelle	Est-ce que ça marche ?	Un résultat correct sur de vraies entrées, pas seulement sur les données de test	Un code qui réussit ses tests unitaires mais casse sur des données réelles que le prompt n’avait pas prévues
2. Prêt pour la production	Est-ce que ça marche bien ?	Plusieurs utilisateurs simultanés sans situation de concurrence	Fluide en développement, cassé sous la charge ou derrière une vraie infrastructure
3. Adéquation au problème	Est-ce la bonne chose ?	Répond au vrai besoin de l’utilisateur, pas seulement à la lettre de votre spécification	Une fonctionnalité techniquement complète qui répond au prompt mais manque le besoin de fond
4. Qualité de l’expérience	Est-ce bien ?	Les utilisateurs accomplissent la tâche principale sans aide ni explication	Des schémas d’interface génériques qui fonctionnent mais sonnent creux, des utilisateurs perdus ou agacés
5. Impact responsable	Est-ce responsable ?	Transparent sur le rôle de l’IA, ne présente pas un contenu généré comme un fait vérifié	Un contenu généré présenté comme faisant autorité, ou une partie de la population oubliée par défaut

Le premier angle se teste facilement : on exécute et on regarde. Arrivé au cinquième, vous prenez des décisions de jugement que l’IA ne peut pas prendre à votre place.

1. L’intégrité fonctionnelle

Bogues, erreurs, failles de sécurité : c’est là que s’arrête la plupart des revues de code. C’est nécessaire, mais loin d’être suffisant. Dans le projet fil rouge, l’IA a peut-être écrit une logique saine pour afficher les temps d’attente, mais a-t-elle tenu compte de la priorité des patients ? Que fait-elle de données contradictoires, et laquelle affiche-t-elle ? Pensez à toute la gamme des tests : unitaires, d’intégration, de non-régression, cas limites, de bout en bout.

Une habitude compte particulièrement : l’IA doit écrire les tests en même temps que le code, pas après. Demandez-lui les cas de test dans la même passe, puis prévoyez des points de contrôle réguliers. Une suite de tests qu’on n’exécute pas n’est pas un filet de sécurité, seulement un faux sentiment de sécurité.

2. Prêt pour la production

Performances, montée en charge, fiabilité : que se passe-t-il quand des centaines de personnes rafraîchissent la page en même temps ? L’IA a ici des angles morts précis. Quelques gestes concrets :

demandez à l’IA de soumettre son propre code à des tests de charge ;
faites-lui générer des scénarios de production, et vérifiez comment le code s’en sort ;
posez la question explicitement : « Quelles hypothèses sur la production ce code fait-il ? » Vous ferez remonter ce qui a échappé au premier passage.

Dans le projet fil rouge : que se passe-t-il quand l’appel à l’API met cinq secondes de trop ? L’affichage se fige-t-il, montre-t-il des données périmées, ou échoue-t-il proprement ? L’IA n’y pense pas. C’est à vous.

3. L’adéquation au problème

Le produit résout-il le vrai problème de l’utilisateur, ou celui qu’il croit avoir ? Les deux peuvent diverger, comme vous l’avez vu dans la leçon précédente. Le patient demandait le temps d’attente, et l’IA peut construire un affichage d’estimation. Mais ce qu’il avait vraiment besoin de savoir, c’était si un pédiatre serait disponible dans les vingt minutes, pour juger si la fièvre de son enfant était urgente. L’IA a résolu le problème formulé ; à vous de vérifier que c’est le vrai.

4. La qualité de l’expérience

L’expérience est-elle claire, intuitive, accessible ? L’IA n’a pas de goût, elle a des schémas : elle vous donnera une interface correcte que personne n’aime utiliser. Pour un outil de temps d’attente médical, ce n’est pas qu’une question d’esthétique, c’est une question de sécurité des patients. À vous de le remarquer et de le traduire en quelque chose de concret et corrigeable. La leçon suivante est consacrée à ce discernement de l’expérience.

5. L’impact responsable

Biais, confidentialité, conséquences imprévues : qui ce produit pourrait-il léser ? Que suppose-t-il de l’utilisateur qui pourrait être faux ? Si l’algorithme estime les temps d’attente à partir de données historiques, et que ces données reflètent des inégalités, comme des attentes plus longues pour certaines populations, le modèle reproduira le même schéma. Il ne le signalera pas : il affichera un nombre. Mettez des garde-fous, demandez à l’IA d’expliciter les biais possibles pendant qu’elle construit et, surtout, questionnez toutes les hypothèses.

Là où se cachent les vrais problèmes

La plupart des formations d’ingénieurs s’arrêtent aux deux premiers angles ; un builder a besoin des cinq. Et en les appliquant, vous constaterez que les problèmes les plus graves ne sont presque jamais au premier angle. L’IA sait produire du code qui tourne. Il lui faut votre supervision pour produire un produit qui compte.

Dernier point : quand vous trouvez quelque chose d’insuffisant, observez votre réflexe. Corrigez-vous vous-même, ou revenez-vous décrire mieux ce dont vous aviez besoin ? Aucune des deux options n’est mauvaise, mais la tendance dit quelque chose de votre façon de travailler avec l’IA, et de si vous développez votre Discernement ou si vous ne faites que construire.

Dans Claude Code (ajout de Corsen) — Deux commandes intégrées aident sur le premier angle, et en partie sur le cinquième, sans remplacer votre jugement. Dans un terminal, /code-review examine les modifications de votre branche dans un sous-agent en arrière-plan, qui ne voit pas l’historique de votre conversation : il n’est donc pas influencé par le raisonnement qui a produit le code. /security-review analyse les modifications de la branche par rapport à la branche par défaut du dépôt origin, à la recherche de risques comme les injections, les problèmes d’authentification et l’exposition de données. Sources : Commands · Review locally with /code-review.

À vous de jouer

Tester le projet avec un utilisateur. Mettez votre version du projet fil rouge entre les mains d’un partenaire qui joue un patient ou un membre du personnel d’accueil. N’expliquez rien, n’aidez pas. Observez où il hésite, ce qu’il ignore, et ce qu’il aurait voulu trouver et que vous n’avez jamais construit. Notez trois changements que vous feriez, et l’angle auquel chacun se rattache.

Questions de réflexion

Quels angles appliquez-vous naturellement, et lesquels devez-vous vous rappeler de vérifier ?
Quand l’IA produit quelque chose d’insuffisant, quel est votre réflexe : corriger vous-même, ou mieux décrire ?

Sources officielles : Discernment for code (Claude Academy, vidéo, schéma interactif des cinq angles et transcription)

Points clés à retenir

Un code qui tourne peut quand même échouer : le résultat par défaut de l’IA est techniquement complet mais manque souvent l’essentiel
Cinq angles : intégrité fonctionnelle, prêt pour la production, adéquation au problème, qualité de l’expérience, impact responsable
L’IA a des angles morts prévisibles : concurrence, sécurité, et tout ce qui ne casse qu’à grande échelle
Faites écrire les tests avec le code, et exécutez-les : une suite jamais lancée n’est pas un filet de sécurité
Le goût est une compétence de builder : l’IA livre du fonctionnel, le rendre digne d’être utilisé vous revient

Crédits et licence — Adaptation française de la leçon « Discernment for code » du cours « AI Fluency for Builders » de Claude Academy, l’académie d’Anthropic, créé par Anthropic en partenariat avec CodePath. Les supports d’origine sont © 2026 Anthropic, publiés sous licence CC BY-NC-SA 4.0 ; cette adaptation, qui les traduit et les remanie, est diffusée sous la même licence. L’encadré « Dans Claude Code » est un ajout de Corsen.