/tickets — enregistrer et trier les demandes
Ce qui arrive de l'extérieur : retours de réunion, bugs signalés, questions. On enregistre, on trie, on ne cadre pas.
/ticketsColle tes notes après la commande, ou lance-la seule pour trier ce qui attend déjà.
Quand l'utiliser
Dès qu'une demande arrive de l'extérieur : un retour de réunion client, une remarque en revue, un bug signalé, une question. Ces demandes ne passent pas par le parcours normal — elles entrent ici.
La file existe indépendamment de cette commande. Le portail client et le widget y écrivent
directement. Ne suppose jamais qu'elle est vide parce que tu n'as rien collé : lance /tickets
seule de temps en temps pour voir ce qui attend.
Comment ça se passe
Si tu colles des notes, Alfred les lit et te propose un tableau — une ligne par demande, avec un titre, un type, la fonctionnalité concernée devinée, et une priorité.
Tu corriges les cases fausses. Une seule fois. S'il te repose une deuxième série de questions, il est en train de cadrer, et ce n'est pas son travail.
Les trois types :
| Type | Le test |
|---|---|
| Bug | Ça ne marche pas comme c'était décrit. |
| Demande de changement | Ça marche, et il faut que ça change. |
| Question | Une réponse suffit, il n'y a pas de code à écrire. |
En cas d'hésitation entre les deux premiers : est-ce que la demande contredit un critère écrit ? Oui → bug. Non → demande de changement.
Le tri : quatre sorties
Chaque demande part vers l'une de ces quatre sorties, et une seule.
| Sortie | Quand | Ce qui suit |
|---|---|---|
| Changement | Une fonctionnalité existante peut accueillir la demande | /cadrage T-XXX puis /dev T-XXX |
| Naissance | Aucune fonctionnalité existante ne l'accueille | /feature puis /cadrage |
| Mise de côté | Ça déborde : ça touche à autre chose, ou c'est hors sujet maintenant | Rien — le sujet est posé avec sa condition de retour |
| Réponse | C'était une question | Une réponse est rédigée pour le client |
Ce qui est mis de côté porte toujours une condition de retour. C'est ce qui sépare une mise de côté d'une poubelle : sans elle, le sujet est écrit une fois et relu par personne.
Deux textes différents sont écrits pour chaque demande traitée : une note interne, qui dit pourquoi la décision a été prise, et éventuellement une réponse au client, qui est ce que le client lit. Les confondre publierait une note d'équipe chez lui.
Ce que ça ne fait pas
- Aucun cadrage. C'est la raison d'être de la commande : séparer « enregistrer une demande » de « décider ce qu'on en fait précisément ».
- Aucun code.
- Aucune création de fonctionnalité. Une demande classée « naissance » attend
/feature.
Ensuite
La commande te dit, pour chaque sortie, ce qui attend un geste. Aucun de ces gestes n'est le sien.