--- title: "Demandes d'intervention" description: "Une demande d'intervention est ce que votre atelier signale quand quelque chose cloche : « la presse ne démarre pas », « le chariot élévateur fait un bruit », « la climatisation fuit »." --- > Documentation Index > Fetch the complete documentation index at: https://docs.beelocity.com/llms.txt > Use this file to discover all available pages before exploring further. # Demandes d'intervention Une **demande d'intervention** est ce que votre atelier signale quand quelque chose cloche : « la presse ne démarre pas », « le chariot élévateur fait un bruit », « la climatisation fuit ». C'est la corbeille qui alimente le circuit des ordres de travail de maintenance. Une demande n'est _pas encore_ un travail de maintenance — c'est un candidat au travail de maintenance, en attente de la relecture d'un planificateur. ## Soumettre une demande Le formulaire de soumission, pensé pour le téléphone, capte : - L'équipement (s'il est connu) — le scan du QR collé sur la machine le pré-remplit. - Le poste technique (si aucun équipement précis) — utile quand la personne n'arrive pas à identifier la machine exacte. - Un code problème du catalogue — filtré sur les codes qui concernent la classe de l'équipement. - Une gravité forcée facultative — H (haute), M (moyenne) ou L (basse). À utiliser quand votre intuition diffère de ce que suppose le catalogue. - Les détails, en texte libre, de ce qui cloche. Le champ s'appelle **Détails**, parce qu'il porte la description d'un problème et non la désignation d'un article. - Des pièces jointes facultatives — photo, courte vidéo. La soumission calcule : - Un numéro de demande généré tout seul (par exemple `WR-2026-0042`). - Un **palier de service** — `Immédiat` / `Urgent` / `Standard` / `Faible` — calculé à partir de la criticité de l'équipement × la gravité du problème. La colonne de la grille s'appelle **Palier de service**. - Une **échéance de réponse** — le moment, au calendrier d'exploitation, avant lequel un planificateur doit accepter ou rejeter la demande. La colonne de la grille s'appelle **Échéance de réponse**. La nouvelle demande atterrit dans la corbeille du planificateur au statut `Nouveau`. ## Paliers de service Le palier fixe le niveau de service : - **Immédiat** — équipement de criticité A avec une gravité H. Première réponse comptée en minutes. - **Urgent** — criticité A avec une gravité M, ou criticité B avec une gravité H. Première réponse sous environ 4 heures d'exploitation. - **Standard** — criticité B avec une gravité M, ou criticité C avec une gravité H ou M. Première réponse sous environ une journée d'exploitation. - **Faible** — criticité C avec une gravité L. Réexaminée périodiquement. Votre grille de paliers se règle — chaque organisation a sa propre tolérance au délai. La file de triage resserre avec son **bouton de filtre** : **Statut**, **Palier de service**, **Équipement**, **Code problème**, **Poste technique**, **Actif**, ou une fenêtre de dates **Date de soumission** / **Échéance de réponse** — `Statut = Nouveau`, `Palier de service = Immédiat` est ce qu'un planificateur ouvre en premier ([Utiliser les listes](../getting-started/working-with-lists.html#narrowing-the-list)). ## États du triage Le planificateur relit chaque demande et la fait passer par l'un de ces états : - **Nouveau** — tout juste soumise ; en attente de relecture. - **Accepté** — le planificateur l'a vue et s'engage à agir. Ce n'est pas encore un ordre de travail — les pièces, l'équipe et la planification restent à régler. - **Différé** — on s'en occupera plus tard ; un **Motif de report** et une **Date de réexamen** sont tous deux obligatoires. Les demandes différées redeviennent `Nouveau` à leur date de réexamen. L'action groupée appelle cette issue **Différer** elle aussi — le bouton, le champ et le statut ne font qu'un mot. - **Converti** — transformée en ordre de travail de maintenance. Terminal — une fois convertie, la demande est en lecture seule et toute modification se joue sur l'ordre de travail. Le champ **Converti en ordre de travail** de la demande y renvoie. - **Rejeté** — ne sera pas fait ; un motif est exigé. Terminal. Un planificateur peut trier plusieurs demandes en une fois (le même équipement signalé par trois opérateurs dans le même poste) — en les acceptant, en les différant ou en les rejetant d'un coup. Le parcours de `Nouvelle` à `Convertie` court en bas de la page de la demande. Chaque étape dit si elle est franchie, laquelle vous occupe et lesquelles restent ; survolez une étape déjà passée pour lire quand elle a été franchie et par qui. Différer et rejeter demandent d'abord ce qu'il leur faut — le report, le motif et la date de nouvelle revue ; le rejet, le motif — et convertir ouvre la fenêtre ci-dessous. Sur une demande qu'un planificateur a convertie directement depuis sa boîte, `Acceptée` s'affiche enjambée plutôt qu'absente : le parcours se lit toujours d'un seul tenant. ## Conversion en ordre de travail Faire passer la demande à **Converti** ouvre une fenêtre qui hérite de l'équipement, du poste technique, du code problème, de la gravité et de l'équipe par défaut de la demande. Une demande peut donner plusieurs ordres de travail — une réparation puis une inspection de contrôle, par exemple — la fenêtre prend donc une ligne par ordre, et chaque ligne peut forcer la nature (d'ordinaire `Corrective` ou `Panne`), la gravité, la priorité, l'équipe affectée et les détails. Un champ laissé vide hérite de la demande et de l'équipement. **Lancer immédiatement** fait sauter le brouillon à chaque nouvel ordre : les pièces sont mises de côté, le coût attendu est figé et la machine est sortie de la production, en une seule fois. Laissez la case décochée pour relire chaque ordre au brouillon d'abord. L'ordre de travail généré porte l'origine **Demande d'intervention** et renvoie à la demande, pour que la piste d'audit reste entière. ## Détection des doublons Quand vous commencez une nouvelle demande sur un équipement qui a déjà une demande ouverte (`Nouveau` / `Accepté` / `Différé`) pour le même code problème, l'écran vous prévient et renvoie vers la demande existante plutôt que de bloquer — parfois la deuxième personne a du contexte utile à ajouter, parfois elle n'avait pas vu la première et s'y ralliera volontiers. Source: https://docs.beelocity.com/fr/maintenance/work-requests/index.mdx