Skip to main content
Des clients oublient sans cesse un champ obligatoire dans votre formulaire d’inscription. Plutôt que de vous arrêter à un ticket de support ou à une demande de fonctionnalité, travaillez avec Replit pour comprendre le comportement actuel, proposer une amélioration ciblée et l’essayer dans un aperçu de développement. Quand le résultat est prêt, préparez une pull request pour la relecture de votre équipe. Le même workflow peut aider pour un message d’erreur peu clair, un lien d’aide cassé ou une amélioration plus vaste qui nécessite votre expertise. Commencez par un seul problème et un moyen clair de vérifier que la modification y répond.

​
Idéal pour

  • Les spécialistes du support qui veulent transformer un problème client récurrent en correctif proposé.
  • Les product managers qui veulent évaluer une amélioration par rapport à l’implémentation existante.
  • Les designers et ingénieurs qui veulent itérer sur un vrai parcours avant de soumettre les modifications à la relecture.

​
Connecteurs

Vous pouvez utiliser GitLab à la place de GitHub. Un connecteur de support est facultatif : vous pouvez commencer avec un résumé anonymisé des retours, ou indiquer à Replit une source que vous avez connectée et que vous êtes autorisé à lire.

​
Avant de commencer

Vous avez besoin d’un accès au développement basé sur un dépôt dans votre espace de travail et de l’autorisation de lire le dépôt. Ouvrir une pull request nécessite aussi l’autorisation de pousser une branche ou d’utiliser le workflow de fork approuvé par votre équipe. Choisissez un problème précis et identifiez le dépôt qui implémente l’expérience concernée. Retirez les informations personnelles des clients de vos exemples. Utilisez des données de test et des identifiants de développement lorsque vous essayez l’application, jamais de vrais comptes clients. Pour les instructions de connexion, consultez Connecter votre dépôt.

​
Donner le prompt à Replit

​
À quoi s’attendre

1

Comprendre le problème

Replit lit les retours que vous fournissez ou qu’il est autorisé à récupérer, puis examine l’implémentation concernée. Vérifiez si l’explication proposée correspond au problème du client. Quelques signalements ne prouvent pas que tous les clients sont touchés, et le code source seul ne permet pas d’établir le comportement en production.
2

Convenir de l'amélioration

Décidez ce qui doit changer et ce qui doit rester identique. Dans cet exemple, l’objectif est d’obtenir des erreurs de champ obligatoire plus claires, pas de nouvelles exigences d’inscription. Demandez à Replit de réutiliser les composants existants et de séparer les modifications sans rapport.
3

Essayer la modification dans un aperçu

Replit prépare une configuration de développement, effectue la modification convenue et démarre l’application lorsque la configuration le permet. Ouvrez l’aperçu, envoyez le formulaire avec un champ obligatoire vide, puis corrigez-le. Donnez des retours précis sur le message d’erreur, la mise en page et l’interaction.Si la configuration nécessite des identifiants, saisissez des identifiants de développement limités via le flux sécurisé des secrets. Si vous approuvez un service simulé, gardez cette limite explicite plutôt que de le considérer comme un test de l’intégration réelle.
4

Vérifier le résultat

Demandez à Replit d’exécuter les vérifications pertinentes et d’indiquer les tests réussis, échoués et bloqués. Inspectez le diff et confirmez que le comportement de validation existant reste intact. Incluez la navigation au clavier et le comportement sur petit écran lorsque c’est pertinent.Les captures d’écran peuvent aider à expliquer une modification visuelle, mais ne remplacent ni les tests ni la relecture.
5

Préparer la pull request

Une fois satisfait du résultat et conscient de ses limites, demandez :Pour GitLab, demandez une merge request en brouillon. Votre équipe relit la modification proposée selon son processus habituel. Ouvrir la demande ne la fusionne ni ne la déploie.
Vous obtenez une contribution ciblée qui relie le problème du client à une implémentation et à ses preuves de vérification. Confirmez que la modification a bien été publiée avant d’annoncer aux clients que le problème est résolu.

​
Adapter à vos besoins

​
Dépannage

Demandez l’étape concernée, le comportement attendu et le comportement observé. Utilisez des exemples anonymisés. Demandez à Replit de distinguer les explications possibles des conclusions étayées par le code et les tests de développement.
Demandez à Replit d’inspecter les instructions d’installation du dépôt et d’identifier les dépendances, services ou autorisations manquants. Signalez le blocage dans la transmission plutôt que d’affirmer que le comportement a été testé.
Revenez au problème initial et demandez la plus petite modification utile. Séparez les refontes plus larges ou les nouvelles exigences dans un travail ultérieur.
Demandez à Replit d’évaluer les retours et de mettre à jour la demande ouverte existante lorsque c’est approprié. Revérifiez le comportement concerné après les corrections. Si la demande a déjà été fusionnée, traitez la suite comme une nouvelle contribution.

​
Voir aussi

Analyser les retours clients

Identifiez les thèmes récurrents avant de choisir une amélioration sur laquelle travailler.

Coder avec Replit

Comprenez le développement basé sur un dépôt et démarrez avec votre équipe.