Refonte de WPML avec Claude Code — et ce que j’apprends sur la création avec l’IA

Je suis le fondateur d’OnTheGoSystems. Cette semaine, j’ai personnellement procédé à la refonte de l’interface d’administration de WPML, notre produit phare. Je n’ai pas géré le projet. Je n’ai pas révisé le travail de quelqu’un d’autre. Je me suis assis avec Claude Code et j’ai effectué moi-même le travail de conception proprement dit.

Deux raisons.

Premièrement, une administration plus claire et plus intuitive est la demande numéro un de nos clients. Depuis des années, ils nous disent que WPML comporte trop d’écrans, que les réglages sont répartis dans des zones sans rapport entre elles et que les fonctionnalités importantes sont difficiles à trouver. Quand quelque chose compte autant pour les clients, je veux le diriger de mes propres mains — pas à distance.

Deuxièmement, je voulais apprendre de première main à quoi ressemble aujourd’hui la création d’un produit réel avec l’IA. Pas ce que montrent les démos. Pas ce que prétendent les leaders d’opinion. Le travail concret sur le produit, sur une base de code que les vrais clients verront, avec toute la complexité que cela implique. Je préfère découvrir ce qui fonctionne en faisant le travail moi-même plutôt que de me faire faire un rapport.

Ce que j’ai découvert m’a surpris dans les deux sens. Certaines choses que je pensais faciles se sont avérées difficiles — en particulier maintenir l’IA alignée sur la réalité lorsqu’elle était tentée d’inventer des fonctionnalités qui semblaient plausibles mais ne figuraient pas dans notre produit. D’autres choses que je pensais difficiles se sont avérées presque triviales — comme produire treize fichiers HTML cohérents pour une nouvelle section en moins d’une heure, chacun avec un JavaScript fonctionnel pour les bascules d’état et l’indexation de recherche, et chacun d’entre eux utilisable comme référence de conception pour l’équipe implémentant la version réelle.

La rapidité, honnêtement, a été la plus petite surprise. La plus grande a été de voir à quel point la méthode importe. Adoptez la bonne méthode et vous obtiendrez des résultats exponentiels — de meilleurs résultats, plus rapidement, avec une documentation prête à être transmise. Trompez-vous de méthode et vous atteindrez simplement la médiocrité plus vite.

Ce qui suit est la méthode complète que j’ai utilisée — les invites qui ont fonctionné, les erreurs que j’ai commises, les cycles de révision qui ont permis de détecter les fonctionnalités inventées par l’IA avant qu’elles ne soient livrées. Ce texte est écrit principalement pour les développeurs d’OTGS qui souhaitent mener eux-mêmes des projets de ce type, mais toute personne créant une interface utilisateur avec l’IA aujourd’hui peut probablement en tirer profit.

La règle unique qui permet d’y parvenir

Planifiez par écrit avant de produire du code.

Claude Code construira volontiers du HTML dès que vous le lui demanderez. Il construira également le mauvais HTML, poliment, rapidement et en grandes quantités. Chaque fois que vous gagnez du temps en sautant une phase de planification, vous payez le double en retravail — et le retravail est plus difficile que la planification initiale car il y a maintenant du code que vous ne voulez pas jeter.

Chaque branche réussie de la session WPML présentait la même structure :

1. Amir a exposé un problème ou une intention.
2. Claude a posé des questions de clarification.
3. Amir a répondu de manière concise.
4. Claude a proposé un plan par écrit.
5. Amir a confirmé ou modifié le plan.
6. C’est seulement alors que Claude a construit.

Chaque fois que cette structure a été rompue, nous avons dû revenir en arrière. Si vous ne devez retenir qu’une chose de ce guide, retenez les six étapes ci-dessus.

Les huit phases d’une session

1. Cadrez le problème, pas la solution

Commencez par la douleur ressentie par l’utilisateur, pas par l’écran que vous voulez changer.

Mauvaise approche :

« Ajouter une nouvelle page de réglages pour la facturation de la traduction par IA. »

Bonne approche (comment la session WPML a réellement commencé) :

« Les utilisateurs signalent que WPML semble accablant et peu intuitif en raison de :

• Trop d’écrans différents liés à la traduction.
• Des réglages répartis sur plusieurs zones, parfois sans rapport entre elles.
• Des options proéminentes mais de faible priorité qui distraient des flux de travail de traduction principaux.
• Des sections liées réparties sur différents écrans sans dépendances claires ni chemins de navigation.
• Un manque de liens croisés entre les fonctionnalités liées… »

La seconde version donne à Claude un périmètre sur lequel raisonner. Il connaît la douleur de l’utilisateur, il peut repérer d’autres éléments qui y contribuent et il peut s’opposer si la solution que vous proposez ne s’attaque pas à la cause profonde. La première version réduit Claude à un simple dactylo.

Dans la session WPML, le cadrage du problème a mené directement à des décisions que Claude n’aurait pas pu prendre seul : que « Paiements et maintenance » était l’écran de trop, que les « Paquets » ne devraient pas être au premier niveau, que le journal de communication n’était pas dans le bon menu, que le Glossaire n’était ni un réglage ni un élément de facturation. Rien de tout cela n’aboutit si vous commencez par « refaire les Réglages ».

2. Rassemblez votre matériel avant le début de la session

Mettez tout ce dont l’IA a besoin dans le répertoire de travail avant de lancer l’invite :

• Captures d’écran de l’interface utilisateur actuelle. Chaque écran que vous pourriez toucher. Dans la session WPML, ils se trouvaient dans Current/ — WPML settings.jpg, debug-main.jpg, td-invoices.jpg, td-translators.jpg, etc. Une dizaine de JPG couvrant tout le périmètre.
• Un instructions.txt énonçant le problème, le périmètre et les attentes en matière de résultats. Voir ../instructions.txt pour le document réel — remarquez comment il s’est étoffé au fil de trois passages (--- 1 ---, --- 2 ---, --- 3 ---) à mesure que de nouveaux éléments étaient ajoutés, plutôt que d’être réécrit à chaque fois.
• Tout design préexistant dans un dossier already-updated/. La session WPML a commencé avec un fichier ai-translation.html stylisé que Claude a utilisé comme modèle visuel pour tout le reste produit durant la session — la configuration Tailwind, la classe de carte, le modèle de lien de retour, l’animation flash pour les sauts d’ancrage. Ce seul fichier a permis d’économiser environ 30 minutes de décisions relatives au système visuel.
• Liens externes que vous voulez que Claude consulte. Pour le Dépannage, la page des prérequis minimaux de WPML (wpml.org/home/minimum-requirements/) a guidé la conception du panneau d’avertissement.

Claude travaille mieux lorsqu’il peut voir la source de vérité. Les captures d’écran lui permettent de vérifier les affirmations par rapport à la réalité. Les liens externes lui permettent d’effectuer des recherches via des sous-agents (voir phase 8) sans vous solliciter pour obtenir des informations de base.

3. Terminez chaque briefing par « pose-moi des questions, ne fais pas de suppositions »

C’est la phrase qui a le plus d’impact dans ce guide. Chaque ensemble d’instructions de la session WPML se terminait par une version de :

« Avant de commencer la conception, examine tout, crée une liste de questions et pose-les-moi. Ne fais pas de suppositions. »

Sans cela, Claude se contente d’agir directement sur votre briefing. Avec cela, Claude prend un tour pour identifier ce qu’il ne sait pas et vous interroge. Ce tour permet de gagner des heures.

Lorsque Claude pose des questions en retour, répondez-y de manière concise. Vous ne lui devez pas des paragraphes entiers. Exemple tiré de la session WPML :

Q : « Libellé du menu — conserver ‘Paiement pour la traduction par IA’ ? (un peu maladroit) »
R : « Facturation de la traduction par IA »

Q : « Structure de la page — une seule longue page avec des sections, ou des sous-pages ? »
R : « Sous-pages, en suivant une structure similaire à celle de la page Réglages. Nous devrons planifier avant que tu n’implémentes. »

Des réponses d’une ligne suffisent. Des phrases complètes conviennent aussi. Les paragraphes entiers sont généralement le signe que vous faites le travail de Claude à sa place.

4. Enchaînez les cycles de questions avant toute implémentation

La section Facturation de la session WPML est passée par deux cycles complets de questions avant qu’une seule ligne de HTML ne soit écrite.

Cycle 1 — 8 questions couvrant : le libellé du menu, la structure de la page, les variations d’état, le compteur redondant des sites connectés, l’emplacement du Glossaire, l’emplacement de « Qui peut utiliser », le périmètre de facturation, la gestion des actions réservées au propriétaire.

Cycle 2 — 7 questions plus ciblées : vue d’ensemble vs index, l’appel à l’action « Fatigué d’attribuer des crédits », le contenu des rapports d’utilisation, l’expérience utilisateur du transfert de crédits, les champs d’état actif du Paiement à l’utilisation, l’état actif prépayé, le périmètre réservé au propriétaire.

Ce n’est qu’après ces deux cycles que Claude a proposé le plan de fichiers. Ce n’est qu’après la confirmation du plan de fichiers que le HTML a été écrit. Temps de planification total écoulé : peut-être quinze minutes d’échanges. Nombre total de fichiers produits : cinq, tous corrects dès la première fois.

Le contre-exemple est de s’engager sur le résultat après un seul cycle, puis de régénérer chaque fichier deux ou trois fois parce que les contraintes n’avaient pas été totalement identifiées. Ce chemin semble plus rapide jusqu’à la troisième heure.

5. Désignez explicitement les fonctionnalités réservées à la maquette

Les maquettes doivent souvent montrer plusieurs états d’un même écran — vide vs rempli, sécurisé vs avertissement, forfait actif vs forfait inactif. Deux modèles ont bien fonctionné lors de cette session :

La bascule d’état de Facturation. La page d’accueil de la Facturation comporte un contrôle Preview state: No plan | PAYG active en haut à droite. Cliquer sur l’un ou l’autre fait basculer le panneau de vue d’ensemble entre les deux états — « aucun forfait » affiche les deux cartes d’acquisition, « Paiement à l’utilisation actif » affiche le panneau unique « Votre forfait de paiement à l’utilisation » avec les détails de la carte. Libellé « État de l’aperçu : » pour que les réviseurs comprennent qu’il s’agit d’une fonctionnalité de maquette, et non de l’interface du produit.

La bascule d’avertissements de Dépannage. Preview state: Has warnings | All OK affiche ou masque le panneau jaune des prérequis minimaux. Même libellé, même raison.

Sans cela, vous livreriez deux fichiers HTML distincts pour chaque écran présentant une transition d’état. Avec cela, un seul fichier démontre toute la surface de conception. Les réviseurs en voient plus, plus rapidement.

Dans la mise à jour du ticket YT, signalez-les explicitement :

« Il y a une bascule en haut : ‘État de l’aperçu : Aucun forfait / Paiement à l’utilisation actif’. Utilisez-la pour voir les deux états. Bien entendu, cela ne fait partie que de la maquette et non de l’interface utilisateur réelle. »

La clause en italique est importante. Sinon, un développeur demandera pourquoi le produit comporte une bascule d’état.

6. Effectuez un cycle de révision en comparant les maquettes à la source

Une fois que tout est construit, avant de vous engager dans la transmission, effectuez un cycle de révision. Dans cette session, il s’agissait d’une seule invite :

« Tout semble correct. Fais un cycle de révision :

1. Vérifie en détail les captures d’écran d’entrée pour t’assurer que tu n’as pas ajouté d’éléments que WPML ne possède pas et que tu n’as pas supprimé d’éléments qui devraient s’y trouver. »
2. Vérifie que les explications textuelles pour chaque page et chaque fonction sont suffisamment descriptives pour que les clients comprennent ce que ‘ceci’ fait, à quoi cela sert et à quoi s’attendre. »

Claude a réexaminé chaque capture d’écran, les a comparées à chaque fichier produit et a renvoyé un rapport structuré. Extrait de la révision du Dépannage de WPML :

• Manquant dans ma conception — cinq outils présents dans l’interface actuelle qui n’avaient pas été portés : « Supprimer les commentaires qui ne correspondent pas à la langue du contenu », « Messages et notifications / Supprimer tous les messages et notifications », « Corriger le code wpml_language dans la configuration de WPML », « Réinitialiser l’ATE / Réinitialiser le journal de débogage », et le tableau du journal de l’installateur sur la page de soutien de l’installateur.
• Éléments ajoutés qui n’existent pas — la maquette de vérification du système affichait 4 serveurs de connectivité ; le produit actuel n’en vérifie que 2. Elle listait 4 bibliothèques PHP ; l’actuel en affiche 2.
• Explications à affiner — le journal de communication n’expliquait pas à quoi ressemblent le succès ou l’échec ; la gestion des paquets ne mentionnait pas que les paquets sont créés automatiquement par d’autres extensions ; la liaison des types de contenu n’expliquait pas l’effet visible du changement d’une correspondance.

Chaque élément a pu être corrigé en un seul tour de suivi. Aucun n’aurait été détecté sans l’invite de révision. L’IA a ici un avantage sur vous — elle peut relire chaque page et chaque capture d’écran simultanément en un seul tour.

Faites-le systématiquement. Ne le considérez pas comme facultatif.

7. Rédigez la transmission aux développeurs en parallèle, pas à la fin

La mise à jour du ticket YT dans la session WPML est passée par plusieurs itérations pendant la session — affinée au fur et à mesure de l’évolution de la conception, et non assemblée dans l’urgence à la fin. Lorsque PostHog a été renommé en « Suivi et rapports d’utilisation », la mise à jour du ticket l’a reflété au cours du même tour.

Une bonne mise à jour de ticket pour une transmission de refonte d’interface comprend :

1. Un résumé d’un paragraphe de ce qui change.
2. Des points clés sur les changements de haut niveau — ce qui est déplacé, ce qui est supprimé, ce qui est ajouté.
3. Un tableau détaillé par zone — nom de la page, ce qui a changé, pourquoi. Ignorez l’aspect cosmétique lorsque toute la section a été restylée — c’est superflu.
4. Un tableau de correspondance pour la migration pour tout ce qui traverse les menus d’administration. Utilisez les chemins exacts de l’interface actuelle : WPML → Translation Dashboard → Payments & Maintenance → Advanced Translation Editor → Overview → Who can use Automatic Translation? — pas de résumés, pas de paraphrases.
5. Éléments ouverts — ce qui nécessite encore l’intervention de l’équipe réceptrice.
6. Mentions @ des personnes spécifiques qui doivent examiner des zones précises.

La mise à jour réelle du ticket WPML fait environ 2 500 mots et couvre trois menus de premier niveau (Réglages / Facturation de la traduction par IA / Dépannage). C’est plus long que la plupart des tickets car la surface de changement est vaste — n’ayez pas peur de la longueur lorsque le changement est complexe, mais soyez rigoureux sur ce qui appartient au tableau (chemins et destinations) par rapport à ce qui appartient à la prose (principes et raisonnement).

Lorsque vous voulez que Claude actualise le ticket à mesure que la conception évolue, une invite structurée fonctionne mieux :

« J’ai besoin que tu mettes à jour mon message qui explique les changements effectués.

1. Il devrait comporter une nouvelle section sur [X].
2. Explique pourquoi nous avons [fait Y].
3. Inclus un tableau avec les détails du changement. Ignore l’aspect cosmétique car tout dans cette section a une nouvelle apparence.
4. Mets à jour les instructions actuelles car tu as maintenant déplacé quelques contrôles vers [Z]. »

C’est spécifique, structuré, et cela indique à Claude ce qu’il doit préserver par rapport à ce qu’il doit changer.

8. Utilisez des sous-agents pour la recherche externe

Lorsque Claude a besoin d’informations provenant de l’extérieur du répertoire de travail — documentation fournisseur, articles de blog, prérequis minimaux — déléguez à un sous-agent. Ne faites pas de copier-coller manuel.

L’invite qui a lancé la recherche pour le Dépannage de WPML :

« Recherche les fonctionnalités de dépannage/débogage de l’extension WPML sur wpml.org (le site de documentation officiel) et renvoie un résumé concis de ce que fait chaque fonctionnalité et de la manière dont l’équipe de soutien de WPML demande généralement aux utilisateurs de l’utiliser. […] Merci de consulter la documentation pour chacun des éléments suivants et de m’indiquer :

• Ce que fait l’outil (1-2 phrases)
• Qui l’utilise — libre-service pour l’utilisateur final, ou uniquement sur instruction du soutien
• Est-ce destructif/risqué ? (réinitialise les données, vide le cache, etc.)
• Toute confusion d’utilisateur connue signalée par la documentation. »

Ce sous-agent a renvoyé un résumé structuré avec des liens sources qui ont directement façonné l’organisation en trois niveaux (sécurisé / journaux / soutien uniquement) de la refonte du Dépannage. Sans cela, nous aurions soit deviné qui utilise quoi, soit interrompu le flux pour lire la documentation nous-mêmes.

Lorsque vous déléguez à un sous-agent, dites-lui :

• Ce que vous essayez d’accomplir (afin qu’il puisse juger les cas particuliers, et pas seulement suivre des instructions).
• Exactement quel format vous souhaitez en retour (tableau ? puces ? une phrase chacun ?).
• Un budget de mots ou de temps. Sinon, il renvoie une dissertation.

Principes UX critiques issus du travail

La méthode est l’élément principal. Mais quelques principes sont revenus assez souvent pour mériter d’être connus dès le départ — ils vous épargneront un cycle de questions ou deux.

Organisez par risque, pas par sujet

La page de dépannage actuelle de WPML est un défilement géant d’environ 25 outils, mélangeant « Vider le cache » avec « Réinitialiser entièrement WPML » avec le même poids visuel. Les clients ne peuvent pas savoir ce qui est sûr. Les assistants ne peuvent pas pointer vers une URL.

La refonte classe chaque outil dans l’un des trois niveaux avec des badges de couleur :

• Sûr à exécuter soi-même (vert) — corrections en libre-service que les clients peuvent essayer sans aide.
• Journaux — lecture seule (info bleu) — diagnostics qui ne modifient jamais rien.
• Avancé — uniquement à la demande du soutien WPML (rouge, plus un paragraphe explicatif au niveau du groupe) — outils pouvant entraîner une perte de données ou casser un site s’ils sont mal utilisés.

Si vous vous retrouvez à refaire une page technique dense, demandez-vous « quel est le rayon d’action de chaque outil ? » avant de vous demander « à quel sujet chaque outil appartient-il ? ».

Chaque outil répond à trois questions

Pour qu’un outil fonctionne en libre-service, son texte doit indiquer à l’utilisateur :

1. Ce qu’il fait.
2. Quand il est utile.
3. À quoi s’attendre après.

L’outil WPML « Corriger post_parent dans les traductions » est passé de la description concise du produit actuel « Corrige les relations parentales des publications traduites » à :

« Lie à nouveau les pages enfants traduites (ou tout contenu hiérarchique) à la version traduite de leur parent, au lieu de pointer vers le parent en langue originale. Utile après des migrations ou des importations massives. »

Même outil, 3 fois plus utile car l’utilisateur sait maintenant quand y recourir.

Contrôles de sécurité gradués

Toutes les actions destructives n’ont pas besoin du même modèle de confirmation. La session WPML a abouti à trois niveaux :

• Action sûre → un bouton.
• Action à risque moyen → une case à cocher « Je comprends » active le bouton ; un paragraphe rouge au-dessus explique le risque spécifique.
• Action radicale (Réinitialiser entièrement WPML) → la case à cocher ET une phrase saisie RESET WPML doivent toutes deux être correctes.

Différents niveaux de risque, différents niveaux de friction.

Faites des liens croisés, ne dupliquez pas

Lorsqu’un outil chevauche un réglage, faites un lien plutôt que de vous l’approprier. La page Dépannage → Rapports d’utilisation renvoie vers Réglages → Traduction par IA → « Qui peut utiliser la traduction automatique » plutôt que de réimplémenter ce contrôle. Une seule source de vérité, un seul endroit à maintenir, une expérience cohérente.

Renommez pour les clients

Les noms de fournisseurs internes ou les acronymes n’ont pas leur place dans les textes destinés aux clients. Dans cette session :

• « Intégration PostHog » → « Suivi et rapports d’utilisation » (les clients ne savent pas ce qu’est PostHog).
• « ATE » comme libellé d’interface → « Éditeur de traduction avancé » (ATE reste un raccourci interne uniquement dans les commentaires YT).
• « Crédits » → « Mots » (changement de modèle de tarification — mais la leçon UX se généralise : n’exposez pas les rouages internes du fournisseur ou de la facturation comme des noms destinés à l’utilisateur).

La recherche l’emporte sur la navigation pour les surfaces denses

L’index des réglages de WPML comporte 16 sections ; la page de dépannage compte environ 25 outils. Attendre d’un utilisateur qu’il balaie du regard et trouve le bon est irréaliste. Une recherche proéminente et ciblée avec indexation des sous-éléments — de sorte que taper « fantôme » saute directement à l’ancre de l’outil des entrées fantômes — résout mieux la découvrabilité que n’importe quel nettoyage de navigation.

La section Facturation était différente : 4 sous-pages, toutes avec des libellés en langage clair. Nous avons ajouté la recherche au départ, puis l’avons supprimée après avoir évalué la densité réelle. Le principe :

Si une page comporte ≤ 6 éléments de premier niveau avec des libellés en langage clair, n’ajoutez pas de recherche. Si elle comporte > 10 éléments techniques, la recherche vaut presque toujours la peine.

Avertissements proactifs plutôt que réglages passifs

Si votre site ne répond pas à une exigence connue, dites-le à l’utilisateur en haut de la page — n’attendez pas qu’il le découvre par un échec. La page d’accueil du Dépannage exécute chaque vérification de la liste des prérequis minimaux de WPML et affiche les échecs dans un panneau jaune au-dessus de la recherche. Lorsque tout est conforme, le panneau est entièrement masqué.

Modèles d’invites qui ont fonctionné

Voici les formulations exactes qui ont permis de maintenir la session WPML sur les rails. Reprenez-les.

Forcer les cycles de questions

« Avant d’aller plus loin, vérifie tout et demande-moi des clarifications. Ne fais pas de suppositions. »

« Si tu as d’autres questions, pose-les. »

« Compile le matériel et pose-moi des questions avant de produire le résultat. »

Piloter la révision

« Fais un cycle de révision :

1. Vérifie en détail les captures d’écran d’entrée pour t’assurer que tu n’as pas ajouté d’éléments que WPML ne possède pas et que tu n’as pas supprimé d’éléments qui devraient s’y trouver.
2. Vérifie que les explications textuelles pour chaque page et chaque fonction sont suffisamment descriptives pour que les clients comprennent ce que ‘ceci’ fait, à quoi cela sert et à quoi s’attendre. »

Évaluer avant d’agir

« En fait, je vois que la fonctionnalité de recherche pour la section facturation n’est pas requise. Merci d’évaluer et de me dire s’il y a un besoin, en fonction du contenu des sous-pages. »

Demander à Claude d’évaluer avant d’implémenter est le moyen d’éviter d’avoir à annuler quelque chose trois modifications plus tard. Dans la session WPML, cette invite a permis de supprimer proprement la recherche de la Facturation en une seule étape, au lieu qu’elle soit à moitié implémentée puis retirée.

Faire émerger l’ambiguïté

« Vérifie la cohérence et les conflits. Produis une version mise à jour exempte de conflits et d’ambiguïtés. Avant de le faire, pose-moi des questions pour ne pas avoir à supposer ou inventer. »

Lorsqu’on lui a demandé cela, Claude a renvoyé une liste structurée de contradictions dans un projet de mise à jour de ticket (« des éléments listés comme supprimés sont également listés comme déplacés — qu’en est-il ? », « ‘ATE’ est ambigu : Éditeur de traduction avancé ou moteur de traduction automatique ? »). Chacune a pu être résolue en une seule réponse. Sans cette invite, ces contradictions auraient été livrées.

Renommages et déplacements ciblés

« Renomme ‘X’ en ‘Y’ dans tous les fichiers de dépannage. »

« Déplace le bloc jaune des prérequis minimaux pour qu’il soit au-dessus de la recherche dans troubleshooting.html. »

C’est chirurgical. Spécifique. Cela fonctionne toujours — tant que le changement est réellement mécanique. Pour tout ce qui nécessite du jugement, revenez au modèle de planification.

Pièges à éviter

• Sauter la planification pour « gagner du temps ». Chaque cycle de planification sauté coûte plus cher en retravail qu’il n’a permis d’économiser.
• Accepter des fonctionnalités dont vous n’avez pas vérifié l’existence. Claude a initialement ajouté 4 serveurs de connectivité à la vérification du système ; le produit n’en a que 2. Détecté lors de la révision. Vous êtes responsable de la vérification de cohérence — ne vous fiez pas à la plausibilité comme gage d’exactitude.
• Dérive des noms. Une fois qu’une décision est prise (« ATE » est interne uniquement ; l’interface client indique « Éditeur de traduction avancé »), appliquez-la partout. La dérive entre les fichiers de maquette et les tickets s’avère source de confusion pour les développeurs. Demandez à Claude de propager les renommages — ne le faites pas manuellement.
• Contrôles réservés à la maquette non étiquetés. Les bascules d’aperçu sont excellentes pour les révisions. Sans l’étiquette « État de l’aperçu : », elles sont interprétées comme faisant partie de l’interface du produit.
• Oublier la cohérence entre les documents. Lorsqu’une fonctionnalité est renommée, le HTML, l’index de recherche, le nom du fichier, chaque href et le ticket YT doivent tous être mis à jour. Dites à Claude de propager — ne le faites pas fichier par fichier.
• Laisser les documents de transmission pour la fin. Rédigez le ticket au fur et à mesure. Lorsque la conception se stabilise, le ticket est terminé.
• Laisser l’IA décider de ce qui est important. Claude est excellent pour l’exécution ; il est médiocre pour les jugements qui dépendent du contexte institutionnel. La décision « nous n’avons pas besoin de recherche ici » pour la Facturation était celle d’Amir, pas celle de Claude — et elle était juste. N’abandonnez pas les décisions éditoriales à l’outil.

Exemple de structure de session

Si vous avez lu jusqu’ici, voici l’ensemble du flux de travail condensé :

1. Cadrer — exposez le problème de l’utilisateur, listez les écrans/zones concernés, joignez des captures d’écran.
2. Briefer — rédigez un instructions.txt qui se termine par « examine tout, pose-moi des questions, ne fais pas de suppositions. »
3. Cycle de questions 1 — laissez Claude poser 5 à 10 questions. Répondez-y de manière concise.
4. Planifier — Claude propose une structure globale. Vous confirmez ou ajustez.
5. Cycle de questions 2 — questions restantes plus précises (généralement sur les variations d’état, les cas particuliers, les confirmations).
6. Sous-planifier — liste des fichiers et structure par fichier.
7. Construire — Claude écrit les fichiers. Vérifiez chacun d’eux au fur et à mesure.
8. Réviser — comparaison avec les captures d’écran sources ; recherche d’éléments manquants/ajoutés ; affinage des textes.
9. Consolider — rédigez le projet de mise à jour du ticket YT et faites-le évoluer parallèlement à la conception.
10. Transmettre — poussez vers le dépôt, enregistrez une courte vidéo de présentation, mentionnez @ l’équipe réceptrice.

Prévoyez du temps pour les étapes 3 à 5 et l’étape 8 — le reste n’est principalement que de l’exécution.

Conclusion

La plus grande leçon de la session WPML est que Claude Code n’est pas un designer ; c’est un bâtisseur discipliné capable d’exécuter un plan bien spécifié à une vitesse inhabituelle. Votre valeur dans la boucle réside dans le jugement, pas dans la saisie. Donnez le problème à Claude, exigez qu’il pose des questions, insistez sur un plan écrit, révisez le résultat par rapport à la source de vérité et préparez la transmission au fur et à mesure.

Si vous faites cela, la vitesse que vous obtiendrez n’est pas une amélioration de 2 fois par rapport au travail UX manuel. Elle est proche d’un ordre de grandeur — et la qualité du résultat est supérieure, car la discipline de révision est intégrée au flux de travail au lieu d’être quelque chose que vous devriez vous rappeler de faire.

Cette mise à jour de conception sera intégrée à WPML 4.10. À l’instar de la conception pilotée par l’IA, nous implémenterons cette mise à jour majeure en déployant des agents d’IA pour travailler de manière autonome, en équipe. Si vous êtes intéressé par un aperçu, voici une courte vidéo :