> ## Documentation Index
> Fetch the complete documentation index at: https://docs.replit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Transformer les retours clients en améliorations concrètes

> Transformez les retours clients en une modification ciblée du dépôt avec Replit, testez l'amélioration dans un aperçu de développement et préparez une pull request pour la relecture de l'équipe.

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](https://docs.replit.com/fr/build/code/connect-your-repository.md).

## Donner le prompt à Replit

Des clients signalent qu'ils ne savent pas quel champ obligatoire du formulaire
d'inscription ils ont oublié. Examine \[source des retours ou résumé anonymisé] et
inspecte le parcours d'inscription dans \[URL du dépôt]. Explique le comportement
actuel et propose une amélioration ciblée en utilisant nos composants de
formulaire existants. Ne change pas les règles de validation. Demande-moi de
confirmer l'approche avant de modifier quoi que ce soit, puis montre-moi un
aperçu de développement et les résultats des tests pertinents. Ne commite pas,
ne pousse pas et n'ouvre pas de pull request tant que je ne te le demande pas.

## À quoi s'attendre

```mermaid theme={null}
flowchart LR
    A["Customer feedback"] --> B["Understand the existing code"]
    B --> C["Agree on a focused change"]
    C --> D["Preview and verify"]
    D --> E["Propose it for team review"]
```

**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 :

Ouvre une pull request en brouillon pour cette amélioration. Suis les
consignes de contribution du dépôt. Décris le problème du client sans
inclure de détails privés le concernant, explique la modification et ajoute
les résultats de tests pertinents et des preuves visuelles. Indique
clairement tout ce que nous n'avons pas pu vérifier.

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

Vérifie si une issue ou une pull request ouverte traite déjà ces retours avant
que nous commencions. Si c'est le cas, résume ce travail et suggère comment je
peux contribuer sans le dupliquer.

Les retours concernent une coquille dans la confirmation d'inscription, pas la
logique d'inscription. Corrige uniquement ce texte, conserve le style existant
et montre-moi le résultat.

Cette amélioration nécessite une règle métier à confirmer par notre spécialiste
produit. Liste les décisions en suspens avant d'implémenter quoi que ce soit.
Sépare le comportement confirmé des hypothèses.

## Dépannage

> **Les retours sont trop vagues pour être reproduits**
>
> 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.

> **L'aperçu ne peut pas s'exécuter**
>
> 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é.

> **Le correctif proposé devient trop volumineux**
>
> 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.

> **Le relecteur demande des modifications**
>
> 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](https://docs.replit.com/fr/use-cases/analyze-customer-feedback.md)**
>
> Identifiez les thèmes récurrents avant de choisir une amélioration sur laquelle travailler.

> **[Coder avec Replit](https://docs.replit.com/fr/build/code/code-with-replit.md)**
>
> Comprenez le développement basé sur un dépôt et démarrez avec votre équipe.