> For the complete documentation index, see [llms.txt](https://ticketking.xyz/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ticketking.xyz/docs/fr/applications/overview.md).

# Aperçu des candidatures

Une alternative de type revue aux panneaux de ticket pour les candidatures et les inscriptions.

Un **application** est comme un ticket, mais avec une étape de relecture entre les deux. Au lieu d’ouvrir un canal lorsqu’un membre clique sur le bouton, Ticket King collecte les réponses de son formulaire et les consigne dans un canal de relecture. Les relecteurs cliquent ensuite **Approuver** ou **Refuser**.

<figure><img src="https://2951310661-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FrnuG1qjzbOoh0efVpoK8%2Fuploads%2Fgit-blob-eb45cc91d86d68fca672c689d0a3c3a5f5049b86%2Fapplication-flow-diagram.png?alt=media" alt="A flow diagram"><figcaption></figcaption></figure>

## Quand utiliser les applications plutôt que les tickets

Choisissez les applications lorsque :

* Vous voulez examiner et approuver avant d’échanger.
* Vous préférez ne pas créer un canal par candidat.
* Vous voulez que les rôles soient attribués automatiquement à l’approbation.
* Vous voulez un processus de relecture structuré avec des notes des relecteurs.

Les cas d’utilisation courants sont les candidatures du personnel, les candidatures de partenaires, les demandes d’attribution de rôles et les admissions pour les communautés protégées par invitation.

## Quand rester sur les tickets

Restez sur les panneaux de tickets lorsque :

* Vous voulez commencer une conversation tout de suite.
* La décision consiste à aider le membre, pas à l’approuver ou le refuser.
* Vous n’avez pas d’accueil structuré.

## En quoi les applications diffèrent des tickets

|                                               | Panneau de ticket                                                                                                      | Panneau d’application                                                                    |
| --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| Lorsque le membre clique                      | Un formulaire contextuel apparaît s’il est configuré, puis un canal s’ouvre                                            | Un formulaire contextuel s’ouvre                                                         |
| Où a lieu la conversation                     | Dans le canal                                                                                                          | Il n’y a pas de canal par défaut. C’est uniquement pour la relecture                     |
| Où cela se trouve                             | Un canal Discord                                                                                                       | Une entrée dans le tableau de bord des candidatures et un embed de journal dans un canal |
| Nombre maximal de questions                   | 5 (un seul formulaire)                                                                                                 | 5 (la même limite d’un seul formulaire)                                                  |
| Attribuer des rôles automatiquement           | Non                                                                                                                    | Oui, à l’approbation                                                                     |
| Filtrage d’éligibilité                        | Par option, avec les rôles requis <i class="fa-crown">:crown:</i> et les rôles bloqués <i class="fa-crown">:crown:</i> | Par option, plus l’âge du compte et l’ancienneté sur le serveur                          |
| Résultat                                      | Le ticket se ferme                                                                                                     | Approuver ou refuser                                                                     |
| Envoyer un MP au membre au moment du résultat | Un MP à la fermeture, facultatif                                                                                       | Un MP à la décision, facultatif, un seul interrupteur                                    |

## La longueur du formulaire est la même que celle des tickets

Les applications et les tickets utilisent le même système de formulaire, ils ont donc les mêmes limites : **5 questions sur le plan gratuit, jusqu’à 100 sur le plan premium**.

Au-delà de 5 questions, les applications premium deviennent **des formulaires en plusieurs étapes**. Les applications sont l’endroit où cela compte le plus : une candidature pour le personnel ou une candidature à une whitelist est généralement plus longue qu’un ticket d’assistance.

Voir [Combien de questions un formulaire peut poser](/docs/fr/formulaires/questions-per-form.md).

## L’expérience complète du candidat

Du point de vue du candidat :

1. **Cliquez sur le bouton de candidature.**
2. **Vérification d’éligibilité.** S’il ne respecte pas les règles d’ancienneté du compte, d’ancienneté sur le serveur ou de rôle requis, il reçoit un message de blocage et ne peut pas continuer.
3. **Le formulaire s’ouvre.** Jusqu’à 5 questions, ou un formulaire en plusieurs étapes allant jusqu’à 100 sur le plan premium.
4. **Soumettre.** Il reçoit une confirmation que la candidature a été envoyée.
5. **Attendre.** Un relecteur traite la demande dans le tableau de bord ou avec les boutons Approuver et Refuser dans le canal de journalisation.
6. **Résultat.** Si **Envoyer le résultat en MP au candidat** est activé, ce qui est le réglage par défaut, Ticket King lui envoie en MP un résultat avec la raison du relecteur. La raison est la partie publique de la fenêtre contextuelle de décision.

## L’expérience du relecteur

Il existe deux endroits pour examiner les candidatures :

### Dans le canal de journalisation

Chaque soumission publie un embed de journal avec **Approuver** (vert) et **Refuser** (rouge). Un relecteur clique sur l’un d’eux, puis une petite fenêtre contextuelle s’ouvre en demandant une **raison** facultative (maximum 1000 caractères, peut être envoyée au candidat par MP) et une **note** facultative (maximum 1000 caractères, interne uniquement). À l’envoi, la décision est enregistrée.

### Dans le tableau de bord

Ouvrir **Applications** dans la barre latérale. Il s’agit d’une file d’attente de toutes les soumissions, que vous pouvez filtrer et rechercher. Cliquez sur n’importe quelle soumission pour voir les réponses, puis traitez-la. La file de relecture est gratuite.

→ [La page Applications](/docs/fr/applications/the-applications-page.md)

## Ce que vous configurez

Par option d’application :

* **Type d’application.** Un libellé texte qui s’affiche comme titre du formulaire.
* **Canal de journalisation.** Où les soumissions sont publiées. C’est obligatoire. Sans cela, les soumissions ne peuvent pas être consignées et les relecteurs ne les verront pas.
* **Questions de candidature.** Jusqu’à 5.
* **Éligibilité.** Âge minimum du compte et âge minimum d’ancienneté sur le serveur.
* **Nouvelle candidature.** L’interrupteur Autoriser une nouvelle candidature et une période de cooldown en jours.
* **Rôles accordés.** Les rôles attribués à l’approbation.
* **Rôles à supprimer.** Les rôles retirés à l’approbation, par exemple un rôle de maintien « en attente ».
* **Rôles des relecteurs.** Les rôles pouvant approuver ou refuser les candidatures de cette option depuis le canal de journalisation. Toute personne disposant de l’autorisation du tableau de bord Examiner les candidatures peut aussi le faire.
* **Rôles requis** <i class="fa-crown">:crown:</i> **et les rôles bloqués** <i class="fa-crown">:crown:</i>**.** Le même filtrage par rôle par option que pour les tickets.
* **Envoyer le résultat en MP au candidat.** S’il faut envoyer un MP au candidat lors de la décision.

→ [Concevoir votre candidature](/docs/fr/applications/designing-your-application.md)

## Connexe

{% content-ref url="/pages/ee9da89816edc7dcfc636c686a3a4a473c00cfa9" %}
[Concevoir votre candidature](/docs/fr/applications/designing-your-application.md)
{% endcontent-ref %}

{% content-ref url="/pages/82493c6f9ee0d75e2dcc8e3835849888d2a80896" %}
[La page Applications](/docs/fr/applications/the-applications-page.md)
{% endcontent-ref %}

{% content-ref url="/pages/fd008f6947b4f771c125352f54614eca39a995ce" %}
[Créer un panneau de candidature](/docs/fr/panneaux/create-an-application-panel.md)
{% endcontent-ref %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://ticketking.xyz/docs/fr/applications/overview.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
