J'ai donné une application à Claude et je lui ai demandé de se comporter comme quatre développeurs seniors différents — voici ce qui s'est passé

On trouve en ligne, notamment sur X, de nombreuses affirmations prétendant améliorer l'efficacité des chatbots. Lorsque j'ai découvert les affirmations de David Max , expert en éducation à l'IA , j'étais sceptique, ce qui m'a justement poussé à les tester. Ces affirmations prétendent transformer Claude en un expert en débogage et en performance, et pas seulement en un débogueur chevronné. Voici ce qui s'est passé lorsque j'ai décidé d'enquêter. Si vous souhaitez découvrir d'autres affirmations efficaces, vous pouvez consulter « 7 affirmations efficaces concernant Claude 4 pour développer vos idées et booster votre productivité ».

Consultez mon tableau de suivi des dépenses liées à mon domicile sur Claude

J'avais déjà créé un outil de suivi des dépenses avec des espaces réservés pour les dépenses à l'aide de ChatGPT Work. Je l'ai donc utilisé, puis j'ai demandé à Claude de relire l'application à quatre reprises. À chaque fois, je lui ai confié un rôle technique majeur différent : ingénieur full-stack, ingénieur de débogage, ingénieur front-end et ingénieur de performance.

Le résultat s'est avéré bien plus révélateur que de simplement demander à Claude d'« améliorer l'application ». Chaque intervenant s'est concentré sur un ensemble de problèmes différents, et a même parfois mis au jour des problèmes que le précédent « développeur » avait négligés. Voici ce qui s'est passé et les arguments avancés.

1. L'ingénieur Full-Stack senior a développé l'application.

Tout a commencé par une demande de Claude : créer un outil interactif de suivi des dépenses du ménage, accessible à tous. Pour en savoir plus sur les compétences de Claude en matière de développement d'applications, consultez l'article « J'ai créé 3 applications en quelques minutes avec Claude et Gemini : l'une d'elles possède une fonctionnalité cachée ».

Le défi : créer un outil interactif de suivi des dépenses du ménage, accessible à tous, permettant d’enregistrer et de comprendre ses dépenses. Il doit offrir la possibilité d’ajouter et de supprimer des dépenses, de les catégoriser, de filtrer les transactions, de calculer le total des dépenses et de visualiser le détail des catégories.

Imaginez-vous en tant qu'ingénieur full-stack senior développant un MVP abouti pour une startup. Avant d'écrire la moindre ligne de code, définissez brièvement l'architecture, la structure des données et le parcours utilisateur. Ensuite, créez l'application sous forme d'artefact cloud.

Veillez à ce que l'interface soit réactive et facile à utiliser, mais ne perdez pas de temps à relire, déboguer ou améliorer le code final. Je déléguerai ces tâches à d'autres développeurs.

Claude a créé une application React étonnamment aboutie. Elle incluait des exemples de transactions, le total des dépenses, le classement par catégorie, des fonctions de recherche et de filtrage, ainsi que la possibilité de trier les transactions par date. De plus, les modifications étaient sauvegardées et restaient disponibles même après la réouverture de l'application.

Au premier abord, cela ressemblait bien plus à un produit fini qu'à un prototype incomplet. On y trouvait des fiches statistiques en haut, un formulaire de dépenses clair et des barres colorées indiquant les dépenses dans chaque catégorie.

2. L'ingénieur de débogage principal a découvert quelques problèmes.

Après cela, j'ai demandé à Claude d'ignorer les apparences et d'examiner son propre travail d'ingénieur de débogage préparant une application pour son lancement.

La demande : Agissez maintenant comme le débogueur en chef qui a hérité de cette application avant sa publication.

Examinez attentivement l'application et son code existant sans en modifier les fonctionnalités ni l'interface. Testez les principaux parcours utilisateurs et recherchez les erreurs fonctionnelles, les problèmes de gestion des entrées, les risques de perte de données, les erreurs de calcul, les problèmes de persistance et les cas limites.

Avant de modifier le code, veuillez me fournir un bref rapport de débogage contenant les éléments testés, chaque problème rencontré, la cause première de chaque problème, sa gravité et la solution recommandée.

Ensuite, effectuez les réparations et vérifiez que les éléments d'origine fonctionnent toujours. Ne modifiez pas la façade, n'entreprenez pas de rénovation architecturale majeure et n'apportez pas de modifications purement esthétiques.

Le processus de débogage a mis au jour de nombreux problèmes réels.

Par exemple, le formulaire initial n'était pas valide. Cliquer sur le bouton « Enregistrer la transaction » fonctionnait, mais la touche Entrée pouvait ne pas répondre. Claude a corrigé ce problème en transformant la section en un formulaire valide avec un bouton « Soumettre ».

Il a également découvert que les utilisateurs pouvaient effacer l'historique et enregistrer une transaction avec des informations de date invalides. Claude a ajouté une validation des dates, renforcé les contrôles des montants invalides et corrigé un calcul qui faisait apparaître « Logement » comme la catégorie la plus importante même lorsque le suivi était vide.

Il était toujours possible de supprimer définitivement des transactions en un seul clic. Les erreurs de stockage restaient invisibles dans la console développeur, ce qui pouvait laisser croire aux utilisateurs que leurs informations étaient enregistrées alors que ce n'était pas le cas. De plus, Claude n'avait pas mis en place de tests automatisés pour vérifier l'efficacité de ses correctifs.

3. L'ingénieur front-end expérimenté a remarqué une application complètement différente.

Au troisième tour, j'ai demandé à Claude de traiter le logiciel de suivi des dépenses comme un ingénieur front-end spécialisé dans la conception réactive et l'accessibilité.

L'exigence : Agissez dès maintenant comme un ingénieur front-end chevronné, spécialisé dans les applications grand public accessibles et réactives.

Analysez votre outil de suivi des dépenses actuel du point de vue d'un utilisateur sur téléphone, clavier ou technologie d'assistance. Préservez ses fonctionnalités et son identité visuelle, mais améliorez son ergonomie et son accessibilité.

Avant de modifier le code, veuillez fournir une brève analyse portant sur le comportement et la réactivité du téléphone mobile, la navigation au clavier, l'ergonomie des formulaires, l'accessibilité pour les lecteurs d'écran, le contraste des couleurs, les états de chargement et d'erreur, les actions destructives et les commandes sources de confusion.

Ensuite, mettez en œuvre les améliorations. Assurez-vous que chaque champ de saisie et chaque contrôle interactif possède un nom accessible, que les états de focus sont clairement visibles, que les messages de vérification peuvent être annoncés par un lecteur d'écran et que les détails des dépenses transmettent des informations sans se limiter aux barres colorées.

Il s'agissait de l'analyse la plus complète de l'expérience.

Claude a constaté que l'application supprimait la bordure naturelle autour des champs de saisie sélectionnés sans la remplacer. Par conséquent, une personne naviguant au clavier aurait des difficultés à voir le champ actif.

Il a également été constaté que les étiquettes visuelles n'étaient pas correctement associées à leurs champs de saisie correspondants, que le champ de recherche reposait uniquement sur le texte d'espace réservé et que les erreurs de validation n'étaient pas configurées pour être annoncées par les lecteurs d'écran.

Claude a rétabli les indicateurs visuels de focus, lié les étiquettes aux contrôles de formulaire, ajouté des descriptions pour les lecteurs d'écran et augmenté le contraste de nombreux éléments de texte gris clair. Il a également optimisé la barre de recherche pour les petits écrans et ajouté des étiquettes plus descriptives aux boutons ne contenant que des icônes.

Plus important encore, ce personnage a découvert un problème de suppression que le débogueur avait négligé. Claude a remplacé le bouton de suppression en un clic par un processus de confirmation en deux étapes, obligeant les utilisateurs à choisir entre supprimer ou conserver la transaction.

Toutes les affirmations n'étaient pas irréprochables. Claude a décrit 44 x 44 pixels comme la taille minimale d'une zone tactile, mais il n'a agrandi le bouton Supprimer principal qu'à 36 x 36 pixels. Cela respecte le niveau AA minimal des WCAG 2.2, mais pas la recommandation de 44 pixels qu'il avait mentionnée.

Cependant, le changement de rôle de Claude a clairement modifié la perspective. Le débogueur vérifiait le bon fonctionnement de l'application, tandis que le développeur front-end examinait si un utilisateur réel pouvait l'utiliser aisément. Cette expérience démontre comment une simple exigence peut avoir un impact significatif sur les résultats de Claude.

4. L'ingénieur de performance a reconnu que l'application n'avait pas besoin de beaucoup d'aide.

Finalement, j'ai demandé à Claude de mettre en place un outil de suivi des dépenses capable de gérer au moins 10 000 transactions.

La demande : Agissez maintenant en tant qu'ingénieur de performance senior, en préparant cet outil de suivi des dépenses à gérer des milliers de transactions.

Analysez l'implémentation actuelle pour identifier les rendus inutiles, les calculs redondants, le tri ou le filtrage inefficace, les goulots d'étranglement du stockage, la croissance de la mémoire et les interactions qui peuvent devenir lentes à mesure que la taille des données augmente.

Ne présumez pas d'un problème de performance. Mettez en place un système de test réaliste de l'application avec au moins 10 000 transactions et établissez une base de référence pour les opérations critiques.

N'implémentez ensuite que les améliorations justifiées par l'analyse. Préservez l'apparence, l'accessibilité et le comportement actuel de l'application. N'annoncez aucun gain de vitesse sans l'avoir mesuré ou clairement défini comme une amélioration attendue.

Claude a identifié un goulot d'étranglement particulièrement important. L'application créait un nouvel objet de format de devise à chaque affichage d'un montant. Avec 10 000 lignes, Claude a mesuré ce processus à 349 millisecondes. La réutilisation d'un seul formateur a permis de réduire ce temps à 5.2 millisecondes, soit une amélioration d'un facteur 67, selon ses calculs.

Claude a également ajouté une fonctionnalité de « virtualisation des tables », ce qui signifie que le navigateur n'affiche que les transactions visibles à l'écran, au lieu de milliers de lignes simultanément. Les mises à jour de la recherche et du stockage ont été différées d'une fraction de seconde afin d'éviter des requêtes répétitives coûteuses après chaque frappe ou modification rapide.

Claude a même ajouté des boutons permettant de générer 1 000, 10 000 ou 50 000 transactions d’exemple pour les tests de résistance.

Mais l'élément le plus convaincant du rapport était l'aveu de Claude selon lequel la plupart de ces améliorations n'étaient pas nécessaires à l'objectif visé par l'application.

Un ménage type peut ajouter entre 30 et 50 transactions par mois. Même dix ans plus tard, Claude a conclu que l'application d'origine aurait probablement géré ces données sans problème majeur. Hormis la mise en cache du formateur de devises, la plupart des améliorations n'étaient utiles que parce que j'avais expressément demandé la prise en charge de milliers de transactions.

Cette retenue (ou maîtrise de soi) semblait plus « mature » et « professionnelle » que de simplement changer les choses pour le plaisir de pouvoir le faire.

Ma conclusion finale

J'ai trouvé ces affirmations extrêmement pertinentes, car chacune mettait clairement en lumière les points forts et les points faibles de Claude. Chaque rôle offrait une perspective d'évaluation unique, que j'ai trouvée très utile et que je ne manquerai pas d'appliquer dans mes futures évaluations d'autres applications et sites web.

Tandis que l'ingénieur de débogage a détecté un comportement anormal, l'ingénieur front-end a relevé des problèmes d'accessibilité et d'ergonomie. L'ingénieur de performance, quant à lui, a analysé les conséquences de l'augmentation du volume de données et a su identifier les cas où l'optimisation était superflue.

Cette expérience a également démontré pourquoi une exigence unique et générale comme « Rendre ce produit prêt pour la production » n'est pas toujours la meilleure approche. Un examen unique risque de passer à côté de points importants, même si l'exigence semble exhaustive. En décomposant le travail en phases ciblées, Claude a pu réduire le nombre de priorités à traiter et faciliter l'évaluation de ses résultats.

Attention aux limites d'utilisation du cloud. La prochaine fois, j'essaierai peut-être de combiner les invites pour éviter d'atteindre la limite maximale autorisée.

---

---