Retour à la liste

Blog

Mener la correction d'un bug depuis son téléphone jusqu'à la validation : le cas d'un lien d'image

Suivez un bug de lien d'image depuis un rapport reproductible jusqu'à un correctif ciblé, des tests de non-régression et une validation locale — avec des invites prêtes pour mobile et un exemple exécutable.

Publié le Tags: iphone / claude-code / codex / bug-fix / testing / case-study
Blog

Suivez les mises à jour produit et ingénierie de cette catégorie.

Voir la catégorie

Une capture d'écran était bien visible dans un article de Tactic Remote, mais le lien destiné à ouvrir l'image d'origine était réécrit sous la forme d'une URL de page. Dans un article en chinois, cela se traduisait par l'ajout de /zh-CN/ à une adresse d'image partagée. L'image en elle-même était bien là ; c'était son lien qui était incorrect.

Il s'agit d'une taille de tâche idéale à piloter depuis un téléphone : un symptôme précis, une modification restreinte à inspecter et un résultat vérifiable par vous-même. Cela met également en lumière une erreur courante dans le travail assisté par IA : accepter un statut « corrigé » avant d'avoir vérifié l'action précise qui échouait à l'origine.

Le cas ci-dessous est issu d'une véritable réparation effectuée sur ce site web. Nous avons réexécuté la fonction utilitaire d'URL réelle avant et après cette correction. L'implémentation historique et les tests ont tourné sur un ordinateur ; les messages ci-dessous sont des exemples que vous pouvez envoyer via Tactic Remote, et non la transcription d'une réparation effectuée intégralement sur mobile. La capture d'écran sur iPhone constitue la ressource d'image réelle utilisée lors du test de non-régression. L'édition du code et les tests s'exécutent sur votre ordinateur de développement connecté, et non localement sur iOS.

1. Signaler l'action, le résultat attendu et le périmètre

Dire « Répare les images » laisse la porte ouverte à trop d'interprétations. Un Agent pourrait remplacer des ressources fonctionnelles, réécrire l'article ou modifier l'intégralité du routage linguistique. Un meilleur message d'ouverture décrit une action unique et ce qui doit continuer à fonctionner :

Dans le guide iPhone en chinois, la capture d'écran s'affiche bien, mais l'ouverture de son image d'origine utilise une mauvaise adresse. Reproduis d'abord ce comportement de lien. Les images partagées doivent s'ouvrir avec leur URL /images/ existante ; les liens vers les articles et la documentation doivent toujours respecter la langue sélectionnée. Identifie la réparation la plus minime ainsi qu'un test de non-régression avant d'éditer le code. Ne touche pas au texte de l'article ni aux éléments non liés.

Avant l'envoi, sélectionnez le projet du site web et vérifiez le répertoire ainsi que la branche de la conversation. Si l'Agent mentionne un autre dépôt, corrigez-le avant qu'il ne modifie quoi que ce soit. Le guide de configuration pour iPhone détaille la procédure de connexion ; le présent cas commence une fois que la machine hôte et le projet visé sont accessibles.

La nuance clé dans ce rapport est la suivante : l'image s'affiche, mais le lien est altéré. Un élément d'image charge son attribut src ; cliquer dessus suit l'attribut href du lien qui l'englobe. Ne vérifier que la première action revient à passer à côté de la seconde.

2. Demander un exemple en échec avant d'appliquer un correctif

La ressource concernée était :

/images/editorial/mobile-guides/iphone-chat-mode.png

L'ancienne fonction utilitaire traitait cette adresse de fichier comme une page locale. Sa sortie était :

Langue sélectionnéeModification indésirable de l'adresse de l'image
AnglaisAjoute un / final
Chinois simplifiéAjoute le préfixe /zh-CN/ et un / final

Ces deux versions devraient renvoyer l'adresse originale de l'image ci-dessus sans aucune modification.

La version anglaise était également touchée : la normalisation de la page ajoutait une barre oblique finale. Une adresse d'image comportant une chaîne de requête (query string) et un fragment perdait également ces éléments. Le fichier partagé devait impérativement contourner toute la localisation de page.

Notre vérification HTTP locale a renvoyé 200, image/png pour l'adresse de fichier non modifiée. L'adresse invalide /zh-CN/images/...png a renvoyé une erreur 404. Ces requêtes ont été effectuées sur la version candidate locale ; elles ne constituent pas une mesure des pannes historiques en production ni des visiteurs affectés.

Une consigne de suivi pertinente depuis un téléphone est la suivante :

Affiche l'URL d'entrée, la sortie réelle et la sortie attendue pour un cas d'échec. Inclus un lien ordinaire de documentation pour servir de témoin. Ne modifie pas le résultat attendu dans le seul but de faire réussir le test.

3. Examiner le périmètre du correctif

La fonction utilitaire en production laissait déjà intacts les exemples téléchargeables. La réparation a consisté à ajouter les images partagées au même retour anticipé :

- if (href.startsWith('/examples/')) return href
+ if (href.startsWith('/examples/') || href.startsWith('/images/')) return href

Les liens de pages continuent d'utiliser la fonction de routage linguistique existante. Cela est délibérément lié aux deux répertoires de ressources partagées de ce site ; il ne s'agit aucunement d'une règle selon laquelle toute URL contenant un point devrait contourner la localisation.

Demandez à l'Agent d'afficher la liste des fichiers modifiés ainsi que ce diff au fil de la discussion, puis inspectez la modification réelle dans la vue des fichiers/modifications mise à disposition par l'application. Comparez la branche et les chemins affichés avec le projet que vous avez sélectionné. Si la réponse propose une réécriture large du routage, demandez pourquoi cela s'avère indispensable pour cette anomalie précise.

Historiquement, cette correction a été validée (commit) en même temps que des retouches sur l'article et sur les dates. Le correctif du lien lui-même se résume à la petite condition ci-dessus ; le commit complet n'était pas un simple changement d'une seule ligne. Dans votre propre tâche, examinez l'ensemble du diff et tenez compte séparément des travaux préexistants non liés avant de valider le correctif.

4. Lire le résultat du test, pas seulement le mot « passed »

Pour ce cas de figure, nous avons exécuté six attentes dans chacune des huit langues du site web :

AttenteCe qu'elle protège
L'adresse de l'image partagée reste inchangéeLe lien vers l'image originale
La requête et le fragment de l'image restent inchangésLes paramètres associés à une URL d'image
L'adresse de l'exemple partagé reste inchangéeLes exemples existants à télécharger
L'URL externe reste inchangéeLes liens vers un autre site web
Le fragment interne à la page reste inchangéLes liens d'ancrage dans l'article
L'URL de documentation suit la langueLa navigation standard sur le site

Cela représente 48 vérifications, avec les résultats relevés suivants :

Version réelle de la fonctionRéussitesÉchecs
Avant la réparation3216
Après la réparation480

Les 16 échecs correspondent à deux attentes liées aux images réparties sur huit langues. Il ne s'agit pas de 16 articles défectueux, 16 utilisateurs ou 16 bugs distincts. Les cas témoins qui réussissent sont cruciaux : un correctif qui cesserait simplement de traduire le moindre lien réparerait l'exemple de l'image tout en brisant la navigation au sein de la documentation.

Téléchargez la reproduction exécutable, examinez-la et lancez-la sur votre ordinateur de développement :

node image-link-regression.mjs

Elle s'appuie sur les assertions natives de Node, tourne en mémoire, et n'effectue aucune requête réseau ni aucune modification de fichier. Elle reproduit le comportement d'URL avant/après pertinent sans les types TypeScript. Son résultat correspond fidèlement à l'exécution indépendante menée sur les révisions réelles du dépôt. Il s'agit d'une reproduction ciblée, et non d'un substitut aux builds de votre projet ou à ses tests d'intégration.

Depuis votre téléphone, réclamez des éléments probants rattachés à la modification inspectée :

Indique la commande exacte, le répertoire, la branche ou le commit, le code de sortie ainsi que les assertions qui ont échoué. Sépare bien les vérifications terminées de celles que tu te contentes de recommander. Si tu modifies le correctif après les tests, réexécute les vérifications concernées sur cette nouvelle version.

Lors de la réparation d'origine sur le site web, le lint du dépôt, le build de production et les vérifications SEO sont également passés avec succès. Ces contrôles plus globaux portent sur des aspects différents ; aucun d'entre eux ne prouve à lui seul qu'une personne parvient réellement à ouvrir l'image d'origine dans son navigateur.

5. Répéter l'action de l'utilisateur dans la prévisualisation locale

Revenez à présent sur l'article à l'origine du problème. Assurez-vous que l'image insérée dans le texte se charge toujours, ouvrez le fichier d'origine, confirmez qu'il s'agit bien d'une image et non d'une page d'erreur, puis revenez à l'article. Testez également un lien standard menant vers la documentation. Répétez l'opération en anglais, dans une version traduite, puis sur une largeur d'écran étroite de smartphone.

Capture native d’exemple sur iPhone utilisée pour le test de non-régression : écran New Conversation de Tactic Remote avec les choix Chat et Native Terminal.

La ressource d'image réelle utilisée lors de cette vérification. Touchez-la pour afficher l'original. Son écran d'exemple natif illustre la configuration d'une conversation ; l'anomalie se situait dans le lien du site web, non dans ces commandes d'application.

Lorsque la prévisualisation s'exécute sur votre ordinateur, gardez à l'esprit qu'une adresse 127.0.0.1 ouverte depuis un iPhone physique fait référence au téléphone lui-même. Utilisez le moyen d'accès prévu pour la prévisualisation au sein de votre projet afin de tester depuis un autre appareil. Ajuster un navigateur de bureau à la largeur d'un mobile offre un aperçu utile de la disposition, mais ne remplace pas un test sur un iPhone physique.

6. Valider le résultat à un point d'arrêt précis

Dans le cas présent, le site local réparé a passé ses vérifications et a été validé lors de l'examen en prévisualisation locale. Cette acceptation concernait la version candidate du site web ; elle n'a pas publié la mise à jour pour autant. Elle n'établit pas non plus que la tâche historique a été réalisée entièrement depuis un iPhone.

Pour une tâche semblable, votre instruction finale peut être précise :

J'ai vérifié l'image d'origine et le lien de documentation dans la prévisualisation locale. Conserve ce correctif ainsi que son test de non-régression. Résume les limitations restantes, puis arrête-toi avant toute publication ou modification supplémentaire.

Si vous n'avez pas ouvert la prévisualisation, indiquez plutôt ce qu'il reste à faire : « Les vérifications de la fonction utilitaire réussissent ; la validation visuelle reste en attente. » L'état d'inactivité d'un Agent, un compte rendu de tests au vert et votre validation du rendu visible répondent à trois exigences distinctes.

L'élément réutilisable de cette expérience réside dans l'enchaînement : décrire l'action en échec, préserver un cas témoin, examiner la plus petite modification justifiée, lier les vérifications à cette version précise et reproduire l'action de l'utilisateur avant de décider de l'étape suivante. Un smartphone peut parfaitement piloter ces décisions pendant que l'ordinateur de développement se charge du code. Si la conversation cesse de répondre en cours de route, consultez le guide de dépannage de la connexion et de l'état de transmission avant de renvoyer la même consigne.

Essayez Tactic Remote

Pilotez vos agents de programmation depuis votre téléphone

Connectez-vous à Claude Code, Codex et aux autres agents sur votre Mac, PC Windows ou Linux. Consultez leur progression et envoyez la prochaine instruction depuis votre iPhone ou iPad.