A13 — Brique TMA : ticketing de tierce maintenance applicative

🆕 Évolution proposée — nature différente des fiches A1 à A12

Statut : 🟠 à cadrer. Origine : demande orale du responsable de projet du 26/07/2026, distincte de la demande de juillet 2026 qui a produit A1 – A12 — discussion de cadrage prévue le 27/07/2026. Contrairement aux fiches précédentes, ce n'est pas un ajustement du cœur recette : c'est une brique optionnelle, activable indépendamment, pas fondue dans l'existant.

En une phrase

Ajouter un module de gestion de tickets façon TMA (Tierce Maintenance Applicative — incidents, anomalies de production, demandes d'évolution), inspiré des meilleures solutions du marché, construit comme une brique indépendante activable par client : « brique 1 : recette, brique 2 : TMA », pour reprendre les mots du responsable de projet.

Constat — d'où vient la demande, et pourquoi elle est différente

Transcription de la demande (note vocale, 26/07/2026) : ajouter une fonctionnalité de gestion de ticketing, en s'inspirant des meilleures solutions du marché de la TMA, mais l'intégrer avec une logique de briques — la solution de recette est la brique 1, la solution de TMA la brique 2, indépendante, activable en option. Le sujet doit être rediscuté le lendemain (27/07/2026) : rien n'est encore arbitré.

Deux différences structurantes avec A1 – A12 :

1. Ce n'est pas un manque du référentiel de tests. A1 – A12 comblent un écart entre notre outil et TestRail/Xray/Zephyr sur le même métier (gérer une campagne de recette). A13 introduit un métier adjacent : le suivi d'un défaut ou d'une demande après la mise en production, sous contrat de maintenance — un métier que ni v1 ni les 12 fiches précédentes ne couvrent.
2. Ce n'est pas une fonctionnalité de plus dans le cœur. C'est une brique au sens de CLAUDE.md : un module qui doit pouvoir être absent chez un client qui n'achète que la recette, sans que son absence laisse un trou dans l'app (lien mort, écran vide, table orpheline).

Aujourd'hui, le seul point de contact entre recette et post-production est le champ texte jiraLink sur anomalies (F5) — jamais une intégration API (Hors périmètre, C37 de l'Inventaire). Q10 a tranché : pas d'intégration Jira réelle pour la recette elle-même. A13 pose une question différente : pas « router vers Jira », mais « construire notre propre brique de suivi post-prod ».

A13.1 Aligné marché — comparatif de trois solutions TMA / ITSM

🆕 Section prospective

Marché différent de celui de l'Analyse du marché (TestRail/Xray/Zephyr, gestion de tests) : ici, gestion de tickets de support/maintenance. Les deux études sont indépendantes, sans recouvrement de sources.

Solution	Pourquoi elle est pertinente pour nous
GLPI	Seule solution open-source et auto-hébergeable des trois — pertinente si l'exigence de portabilité déjà posée pour l'app recette (Q32) doit s'étendre à la brique TMA. Conforme ITIL v3 dès la base.
Freshservice	Référence SaaS ITIL-aligned mid-market — la plus proche de ce qu'un client type de L&Z attend « prêt à l'emploi » : matrice de priorité, portail self-service, automatisations.
Jira Service Management	Référence côté couplage développeur — pertinente parce que le champ jiraLink existant montre que l'écosystème Jira est déjà présent chez nos clients, côté éditeur ou intégrateur.

Axe	GLPI	Freshservice	Jira Service Management
Modèle	Open-source (GPL v3), coût de licence nul, auto-hébergeable, extensible par plugins	SaaS, ITIL-aligned, configuration par règles (pas de code)	SaaS, couplé à l'écosystème Jira (issues, projets)
Catégorisation des demandes	Catégories ITIL configurables, communes à Tickets / Changes / Problems	Incident vs Service Request en types distincts, chacun avec son propre SLA	Request types configurables par projet, priorités standard Lowest → Highest
Priorité / criticité	SLA et OLA configurables par classe de service, notifications d'escalade	Priority Matrix : la priorité est dérivée d'urgence × impact, pas saisie librement par l'agent	SLA construits par condition (JQL) sur priorité / type de demande
Portail demandeur	Formulaires + catalogue de services, collecteur d'e-mails (ticket créé par simple e-mail, sans compte)	Portail self-service dédié, catalogue de services	Portail Jira Service Management, formulaires par type de demande
Suivi du temps / forfait	Planification technicien + tâches liées au ticket, pas de notion de forfait contractuel nativement	Pas de notion de forfait d'heures contractuel nativement	Pas de notion de forfait d'heures contractuel nativement

Le volet spécifiquement français — TMA, SLA GTI/GTR, forfait d'heures

Aucun des trois outils étudiés ne modélise nativement les mécanismes contractuels propres à la TMA à la française :

• Quatre types de maintenance distingués par la pratique : corrective (bugs/anomalies en production), préventive (mises à jour de sécurité, dépendances, supervision), adaptative (suivre l'évolution de l'environnement technique), évolutive (nouvelles fonctionnalités — jamais couverte par le forfait socle, facturée à part sur devis).
• Criticité à 3-4 paliers avec double engagement de délai : GTI (Garantie de Temps d'Intervention — délai de prise en charge) et GTR (Garantie de Temps de Rétablissement — délai de résolution), différents par palier. Exemple observé : P1/Critique → GTI ≤ 1 h ouvrée, GTR ≤ 4 h ; P2/Majeur → GTI ≤ 4 h ouvrées, GTR ≤ 1 jour ouvré ; P3/Mineur → GTI ≤ 1 jour ouvré, GTR à la prochaine release.
• Facturation hybride : forfait socle fixe pour le correctif (les paliers SLA sont dedans), budget variable sur devis pour l'évolutif — parfois décliné en formules mensuelles graduées (« Essentiel / Business / Premium / Sur mesure »).

Rien de tout ça n'est un standard produit qu'on peut acheter : c'est un paramétrage contractuel à construire dans notre propre modèle de données, pas une fonctionnalité prête à l'emploi chez GLPI, Freshservice ou Jira Service Management.

A13.2 Ce qu'on en retient pour la brique

1. Le type de demande et la criticité sont deux choses différentes. Une demande d'évolution n'a structurellement pas de SLA de résolution — elle part sur devis, pas sur un chronomètre. Fusionner les deux dans un seul statut est l'erreur la plus fréquente relevée en revue (même symptôme déjà identifié côté anomalies de recette, Q12).
2. La priorité doit être calculée, pas saisie librement. Freshservice et Jira Service Management dérivent la priorité d'une matrice urgence × impact — ça évite qu'un demandeur mette systématiquement « urgent ».
3. Le forfait d'heures est le point le plus spécifique et le moins couvert par le marché généraliste — c'est là que notre valeur ajoutée réelle se situe si on construit cette brique, pas dans la re-fabrication d'un GLPI ou d'un Freshservice.
4. Le portail demandeur est un profil d'accès à part, pas un rôle recette existant — voir Droits (A13.5, plus bas).
5. GLPI confirme qu'un modèle auto-hébergeable existe pour ce type de brique, cohérent avec la question de portabilité déjà ouverte pour le cœur recette (Q32).

A13.3 Proposition fonctionnelle (à valider — voir « À trancher », A13.6 plus bas)

• Types de ticket : Incident / Anomalie de production / Demande d'évolution / Question — périmètre exact à confirmer (Q41).
• Criticité dérivée d'une matrice urgence × impact, pas saisie libre.
• SLA par criticité : GTI (prise en charge) + GTR (résolution), échéance affichée, alerte de dépassement — paliers réels à définir par contrat client (Q42).
• Workflow : Nouveau → Qualifié → En cours → En attente client → Résolu → Clôturé.
• Portail demandeur self-service, distinct du back-office technicien TMA.
• Suivi de forfait : temps passé par ticket, consommé/restant sur le forfait contractuel du mois ou de l'année — modèle de facturation à confirmer (Q43).
• Lien optionnel vers une anomalie de recette existante, pour la traçabilité recette → production, sans fusionner les deux modèles (Q44).

Le lien avec une anomalie de recette reste optionnel et non automatique : une anomalie trouvée en recette et jamais corrigée avant mise en production peut devenir un ticket TMA à l'ouverture du contrat de maintenance, mais ce n'est pas un pipeline automatique — quelqu'un décide de créer le ticket, comme aujourd'hui quelqu'un décide de créer un ticket Jira depuis une anomalie.

A13.4 Impact modèle — une brique, au sens de CLAUDE.md

Ce que « brique indépendante » impose concrètement, si on respecte les règles de dépendance déjà posées (CLAUDE.md §5) :

Décision	Ce qu'elle implique
Nouveau domaine Convex isolé	packages/backend/convex/tickets.ts (+ slaPolicies.ts), nouvelles tables tickets, ticketComments, slaPolicies, maintenanceContracts — aucune ne dépend des tables recette (anomalies, tests, campaigns)
Nouvelles features client, pas une extension de features/anomalies	features/tickets/ (+ features/tickets-admin/ si le back-office technicien diffère assez du portail demandeur), chacune avec son ARCHITECTURE.md dès sa création (règle 4bis)
features/tickets n'importe jamais features/anomalies, ni l'inverse	Règle 5, non négociable. Le lien optionnel ticket ↔ anomalie (A13.3) passe par une table de liaison neutre côté packages/backend (ex. ticketAnomalyLinks), jamais par un import cross-feature
Activation par organisation	Réutilise le hook multi-tenant déjà posé au schema (organizationId + ABAC, CLAUDE.md §D) : un champ organizations.enabledModules: string[] (ex. ["recette", "tma"]), vérifié dans canInContext et côté navigation. C'est exactement le type de décision que le hook ABAC a été posé pour absorber à coût quasi nul
Une app ou deux ?	Ouvert : brique dans apps/recette-erp derrière un groupe de routes + flag, ou app séparée apps/tma partageant packages/ui / packages/backend — dépend du volume et de l'autonomie de déploiement voulue (Q40)

💡 Un point à coût quasi nul, dans l'esprit de CLAUDE.md §D. Si la brique TMA est confirmée comme un besoin réel — même pour plus tard — réserver dès maintenant le champ organizations.enabledModules (tableau vide au départ, aucune UI) coûte presque rien pendant que le schéma est encore vide. Contrairement aux quatre décisions déjà actées en 27.5 (A2/A4/A6/A3bis), celle-ci n'est pas encore tranchée comme faisant partie du périmètre — voir Q40.

A13.5 Droits

Vocabulaire de rôles différent du cœur recette (admin / consultant / testeur) :

• Technicien TMA : qualifie, résout, saisit le temps passé — pas nécessairement un rôle recette.
• Demandeur : côté portail, potentiellement un utilisateur externe au projet recette (contact client final), pas forcément un compte Better Auth interne à l'organisation — GLPI couvre ce cas par simple collecteur d'e-mail, sans compte.

Rien de tranché : périmètre exact des rôles à définir avec le modèle d'autorisation existant (RBAC → Permissions → ABAC) une fois la brique confirmée — voir Q45.

A13.6 À trancher — Q40 – Q45

#	Question
Q40	Besoin confirmé à court terme, ou piste à cadrer maintenant (schéma) sans l'activer tout de suite — comme A5 ?
Q41	Portée exacte : ticketing interne seulement, ou portail client externe self-service ?
Q42	SLA contractuels réels : combien de paliers de criticité, quels GTI/GTR — standard L&Z ou par client ?
Q43	Modèle de facturation à outiller : forfait socle + régie sur l'évolutif (comme observé sur le marché), ou autre montage ? Faut-il suivre la consommation du forfait dans l'outil ?
Q44	Une anomalie de recette peut-elle être requalifiée en ticket TMA à la mise en production, ou les deux mondes restent-ils étanches ?
Q45	Les rôles recette (admin/consultant/testeur) suffisent-ils côté back-office TMA, ou faut-il une population nouvelle avec ses propres droits ?

⚠️ Rien de cette fiche n'est engagé. Discussion de cadrage prévue le 27/07/2026 — cette page sera mise à jour à l'issue de cet échange, comme le reste de la section 27 l'a été après l'atelier du 23/07 (voir Synthèse de l'atelier de cadrage).

Sources

Consultées le 26/07/2026.

GLPI — GLPI Helpdesk Software · Categories (documentation)

Freshservice — Understanding Due By time & SLA Policy · Priority Matrix

Jira Service Management — Service Level Agreements (SLAs) overview · What are priority levels in Jira Service Management? · Create and edit an SLA

TMA à la française (SLA GTI/GTR, types de maintenance, facturation) — Tierce maintenance applicative — comment ça marche · Contrat TMA : ce que la maintenance applicative couvre vraiment