Comparer les sources et formuler une recommandation

Périmètre : travaillez avec des sources locales dans l’application de bureau.

Fournissez à Remy les éléments à comparer et une question claire. Utilisez-le pour repérer les différences, vérifier les éléments probants et formuler une recommandation assortie de conditions explicites. Cet exemple utilise le texte que vous fournissez et ne nécessite pas de connexion à une autre application.

1. Préparer les sources et la question

Collez les sources courtes directement dans un message. Pour des éléments locaux, placez des fichiers texte ou Markdown dans un dossier déjà ajouté à votre projet Remy et indiquez leurs chemins relatifs dans la tâche.

Expliquez la décision à prendre, par exemple « Quel processus utiliser pour traiter les retours utilisateurs ? ». Incluez les exigences à satisfaire. Demander uniquement un résumé ne répondra pas nécessairement à cette décision.

2. Essayer un exemple complet

Les éléments suivants sont fictifs et fournis pour vous exercer. Envoyez la demande complète ou remplacez les sources par les vôtres.

Nous devons choisir un processus de gestion des retours utilisateurs pour une équipe produit de cinq personnes.
Compare uniquement les éléments suivants. Ne recherche pas d’informations supplémentaires sur le Web et ne suppose pas de fonctionnalités non décrites.

[Exigences de l’équipe]
Chaque retour doit avoir un responsable et un statut, et sa description d’origine doit rester accessible.
L’équipe souhaite réduire l’organisation manuelle, mais n’a pas mesuré le temps qu’elle y consacre chaque semaine.

[Description de l’option A]
Les utilisateurs envoient leurs retours par e-mail. Les opérations les copient dans un tableur partagé avec un lien vers l’e-mail d’origine, un responsable et un statut.
Les responsables et les statuts sont gérés manuellement. Ces deux dernières semaines, l’équipe a reçu 40 retours et trouvé trois doublons.
Les coûts et le temps de maintenance à long terme ne sont pas fournis.

[Description de l’option B]
L’envoi d’un formulaire crée un ticket enregistrant la description d’origine, un responsable et un statut. Les tickets peuvent être filtrés par statut.
Le fournisseur n’a pas précisé si les retours en double peuvent être fusionnés et n’a fourni ni coûts ni mesures du temps gagné.
L’équipe ne l’a pas encore essayée.

Fournis :
1. Une comparaison pour chaque condition requise, avec la source de chaque affirmation.
2. Une distinction claire entre faits énoncés, déductions raisonnables et informations manquantes.
3. Une recommandation conditionnelle et ce qu’il reste à vérifier.

Ne transforme pas « crée un ticket » en « supprime automatiquement les doublons ». N’invente pas de gains de temps ni d’économies.

3. Vérifier que les conclusions sont étayées

Pour cet exemple, vérifiez les points suivants :

• Les deux options enregistrent un responsable, un statut et le retour d’origine. Ces fonctionnalités ne sont pas propres à l’option B.
• Des doublons ont été observés avec l’option A. Les éléments fournis ne permettent pas d’établir si l’option B résoudrait ce problème.
• L’option B crée des tickets automatiquement. Cela ne prouve pas une réduction du temps total de maintenance.
• Aucun coût n’est fourni ; il est donc impossible de classer les options selon ce critère.
• Une recommandation doit préciser ses conditions et les prochaines vérifications. Une option non essayée ne doit pas être présentée comme éprouvée.

Appliquez la même méthode à vos propres éléments : rattachez les conclusions importantes à leurs sources. Si les sources divergent, demandez à Remy de conserver le désaccord et d’identifier les sources plutôt que de choisir silencieusement une version.

4. Ajouter des éléments probants et actualiser la conclusion

Lorsque vous disposez d’un compte rendu d’essai ou d’une réponse confirmée, poursuivez dans la même conversation :

Voici un compte rendu d’essai supplémentaire.
Mets à jour la comparaison et la recommandation. Explique quelles conclusions changent et lesquelles manquent encore d’éléments probants.
Distingue les sources d’origine des nouvelles. N’étends pas les résultats de l’essai à des scénarios non testés.

[Collez le nouveau compte rendu d’essai ici]

5. Enregistrer un résultat exploitable

Après avoir vérifié les conclusions, demandez à Remy de les écrire dans un fichier Markdown du projet :

Transforme les conclusions vérifiées en une note de décision d’une page dans docs/feedback-workflow-comparison.md.
Inclus la comparaison, la recommandation, les sources qui les étayent et les questions restantes.
Si le fichier existe déjà, explique-le d’abord et attends que je décide de le remplacer ou non.

Adaptez le chemin à l’emplacement souhaité, puis ouvrez le fichier et vérifiez son contenu.

6. Poursuivre la découverte

• Guide de l’application de bureau : ajoutez un dossier source et consultez les fichiers.
• Sélection de modèles et routage automatique : choisissez comment Remy doit sélectionner un modèle avant de lancer une tâche.
• Transformer les notes de réunion en actions : organisez une discussion en décisions et prochaines étapes.