Pipeliner Client

### Problème
Actuellement, les utilisateurs créent des demandes (bugs, évolutions, problèmes de sécurité) sans guidage suffisant, ce qui entraîne des erreurs de classification, des reclassements manuels fréquents et des demandes incomplètes. Cela ralentit le traitement et nécessite des interventions supplémentaires de l’équipe.

### Contexte
Pour améliorer la qualité des demandes dès leur création, il est nécessaire de spécialiser les agents conversationnels afin qu’ils posent des questions ciblées en fonction du type de demande (bug technique, évolution fonctionnelle, sécurité). Cette spécialisation doit s’intégrer avec les fonctionnalités existantes, comme le champ d’argumentation (ticket #50), la classification automatique (ticket #49), et les règles de déduplication (ticket #47).

### Comportement proposé
1. **Déclenchement des agents spécialisés** :
- L’utilisateur choisit explicitement le type de demande dès le début via des boutons dédiés (ex : "Signaler un bug", "Demander une évolution", "Problème de sécurité").
- *Alternative* : Détection automatique après 2-3 échanges, avec proposition de basculer vers un mode spécialisé.

2. **Questions ciblées et pré-remplissage** :
- **Bug technique** : Questions sur les étapes de reproduction, le navigateur/système utilisé, et possibilité de joindre une capture d’écran.
- **Évolution fonctionnelle** : Questions sur l’objectif, les bénéficiaires, et la priorité estimée.
- **Sécurité** : Détection automatique des mots-clés (ex : "vulnérabilité"), application du tag `Sécurité` et du statut `Submitted`.
- Pré-remplissage des champs (classification, tags, statut) en fonction du type de demande.

3. **Avertissements et feedback visuel** :
- Messages contextuels (ex : "⚠️ Ce type de demande nécessite une revue par l’équipe OmDev. Voulez-vous ajouter une justification ?").
- Confirmation visuelle du mode activé (ex : "Mode 'Signalement de bug' activé").
- Indication des champs obligatoires.

4. **Intégration avec les fonctionnalités existantes** :
- Cohérence avec les champs de classification, les règles de déduplication, et les statuts (tickets #47, #49).
- Respect des contraintes multi-langues (FR/EN).
- Non-bloquant : l’utilisateur peut créer une demande même si elle est incomplète.

## Acceptance criteria
['- [ ] L’utilisateur peut sélectionner un type de demande (bug, évolution, sécurité) dès le début de la conversation via des boutons dédiés.', '- [ ] Chaque type de demande déclenche un agent spécialisé qui pose des questions ciblées (ex : étapes de reproduction pour un bug, objectif pour une évolution).', '- [ ] Les champs de classification, tags et statut sont pré-remplis en fonction du type de demande sélectionné.', '- [ ] Des avertissements contextuels sont affichés pour guider l’utilisateur (ex : revue par l’équipe OmDev pour certaines demandes).', '- [ ] Le mode spécialisé activé est confirmé visuellement (ex : "Mode \'Signalement de bug\' activé").', '- [ ] Les demandes créées via un agent spécialisé sont mieux qualifiées (moins de reclassements manuels).', '- [ ] L’intégration avec les fonctionnalités existantes (classification, déduplication, multi-langue) est fonctionnelle et testée.', '- [ ] Le comportement est non-bloquant : l’utilisateur peut créer une demande même si elle est incomplète.', '- [ ] Les tests utilisateurs valident la clarté et l’efficacité des agents spécialisés (feedback positif ou métriques améliorées).']

## Classification
- feature

## Complexity
- 8/10 — La complexité est élevée en raison de l’intégration avec plusieurs fonctionnalités existantes (classification, déduplication, multi-langue), de la gestion des agents spécialisés, et des tests utilisateurs nécessaires pour valider l’expérience.