Zéro Ticket Perdu : Exploitation Kanban (Gitea/Taiga)

Pourquoi on « perd » des tickets en exploitation (et pourquoi Kanban règle vraiment le problème)

En exploitation, les tickets ne se perdent pas parce que les gens sont incompétents. Ils se perdent parce que le système est flou.

Un incident arrive. Quelqu’un ping sur Slack. Un mail « urgent ». Un appel. Un collègue te chope dans le couloir. Et tu fais ce que tout le monde fait en vrai vie. Tu gères. Tu réponds. Tu passes à autre chose. Et comme il n’y a aucune traçabilité, aucun fichier unique, l’oubli devient inévitable.

Le vrai problème, ce n’est pas « on n’a pas d’outil ». On a souvent trop d’outils. Le vrai problème, c’est « on n’a pas de workflow ». Un Kanban, quand il est bien posé, impose une source unique de vérité. Une file unique. Un endroit où tout passe, et où tout se voit.

L’objectif ici est simple. Zéro ticket perdu. Visibilité en temps réel. Priorisation claire. Et une boucle de feedback qui évite de revivre les mêmes incidents tous les mois.

Ce que vous allez mettre en place, c’est un tableau Kanban exploitation, mais pas juste un tableau. Des règles. Des limites WIP. Des SLA et des SLO. Des rituels courts. Et des intégrations selon votre contexte, avec Gitea ou Taiga.

Le prérequis n°1 : une seule porte d’entrée (sinon Kanban ne sert à rien)

Avant même de parler colonnes, couleurs, labels, il faut régler un truc presque politique. Les canaux parasites.

Typiquement, on voit ça partout :

• mails directs à une personne « parce que toi tu sais »
• messages privés Slack ou Teams
• demandes orales, au standup, à la machine à café
• alertes de monitoring qui déclenchent des actions, mais sans ticket
• « j’ai fait un truc vite fait hier soir », sans trace

Si vous gardez ça, votre tableau sera joli, mais il mentira. Vous aurez des tickets dedans, mais pas tous les tickets. Donc vous continuerez à perdre des sujets. Pas par malveillance. Juste par structure.

La règle à décider, et à assumer, c’est : « Pas de ticket = pas de travail ». Oui, c’est dur les deux premiers jours. Ensuite c’est libérateur.

Il y a une exception raisonnable : incident majeur en cours. On gère d’abord, évidemment. Mais même là, on crée le ticket pendant ou juste après la stabilisation. Le but n’est pas de faire de la paperasse. Le but est d’éviter que l’incident se transforme en folklore.

Ensuite, facilitez l’entrée. Un formulaire ou un issue template, c’est ce qui fait la différence entre « on veut des tickets » et « on va vraiment les avoir ».

Dans ce template, vous voulez capter, toujours, les infos qui évitent les aller retours :

• qui demande, pour qui
• impact métier
• urgence ressentie
• service concerné
• environnement (prod, préprod, dev)
• preuves (logs, captures, lien vers alerte)
• quoi a changé récemment, si connu

Astuce adoption, très terrain. Quand on vous écrit hors process, vous ne moralisez pas. Vous répondez avec un lien et une phrase standard, toujours la même.

« Tu peux me créer un ticket ici avec ces infos ? Comme ça je le mets dans la file et je te donne une date. »

Et si la personne est pressée, vous faites le ticket vous même en 30 secondes, en copiant son message. Le point important, c’est que le travail commence dans le flux, pas dans le chat.

Le tableau Kanban « Exploitation » minimal (qui marche dans la vraie vie)

Un Kanban d’exploitation qui marche, c’est rarement celui avec 12 statuts et trois niveaux de validation. C’est celui qui est lisible d’un coup d’œil, même quand ça brûle.

Le principe. Des colonnes simples, explicites, orientées action. Et surtout, des critères d’entrée et de sortie clairs. Sinon une colonne devient juste un parking.

Proposition de colonnes, volontairement minimaliste :

1. À qualifier
2. Prêt
3. En cours
4. En attente (bloqué)
5. À valider
6. Fait

Ça couvre 95 % des situations en exploitation.

Maintenant, le détail qui change tout. Chaque colonne doit avoir une définition. Un « Definition of Ready » et un « Definition of Done » à votre échelle. Pas besoin d’un roman, mais il faut des critères.

Exemple concret.

• À qualifier : la demande est arrivée, mais il manque des infos, ou l’impact n’est pas clair, ou c’est possiblement un doublon. Sortie quand on sait ce que c’est, sur quel service, et quelle classe de service.
• Prêt : le ticket est complet, priorisé, avec critères d’acceptation, et quelqu’un peut le prendre sans re poser 5 questions.
• En cours : un seul propriétaire, travail actif.
• En attente (bloqué) : blocage externe, dépendance, attente de réponse, fenêtre de changement. Sortie dès que le next step est possible.
• À valider : le fix est fait, on attend confirmation, test, ou validation métier. Sortie quand validé, ou quand le délai de validation est expiré et que vous avez une règle.
• Fait : clôturé proprement, avec la trace.

La règle clé, c’est la colonne En attente. Elle ne doit jamais contenir juste « en attente ». Chaque ticket bloqué doit afficher :

• la raison du blocage
• le next step
• une date de relance
• et qui relance

Sinon, vous venez de recréer le vieux problème, mais dans une colonne. Un cimetière poli.

Pour les tâches récurrentes, genre maintenance, patching, rotation de certificats. Deux approches.

• Si c’est planifié, traçable, avec un vrai résultat attendu, faites des tickets planifiés (mensuels, trimestriels).
• Si c’est une routine simple, une checklist peut suffire, mais uniquement si elle est visible et revue. Sinon elle finit dans un dossier « TODO » oublié.

Des classes de service (pour prioriser sans débats infinis)

La priorité en exploitation, c’est souvent un débat sans fin. Parce qu’on mélange urgence, importance, bruit, et stress.

Une astuce simple, c’est d’introduire des classes de service. Quatre suffisent largement :

1. Incident critique
2. Urgent
3. Standard
4. Amélioration / dette

Pour chaque classe, vous définissez deux choses.

• SLA de prise en charge (temps avant que quelqu’un commence vraiment)
• SLO de résolution (objectif de temps pour livrer une solution ou un contournement)

Et une règle d’escalade. Qui est notifié, à quel moment, et comment.

Exemple très pragmatique, à ajuster selon vos réalités :

• Incident critique : prise en charge < 15 min, contournement < 1 h, escalade immédiate on call.
• Urgent : prise en charge < 4 h, résolution < 2 jours ouvrés.
• Standard : prise en charge < 2 jours ouvrés, résolution < 10 jours ouvrés.
• Amélioration / dette : pas de SLA strict, mais revue hebdo et capacité dédiée.

Le piège à éviter, c’est la « priorité 1 » permanente. Si tout est critique, plus rien ne l’est. Donc vous mettez une limite. Par exemple : pas plus de deux tickets « incident critique » simultanés dans En cours. Au delà, vous faites une décision explicite, visible, commentée.

Rendez la priorité visible via labels, couleurs, et surtout une règle de tri dans Prêt. La colonne Prêt doit être votre file d’exécution. La vérité du moment.

Limiter le WIP : la règle anti chaos la plus sous estimée

Le multitâche en exploitation a un coût énorme, et on le sous estime tout le temps. Vous commencez dix trucs. Vous finissez rien. Vous perdez le fil. Vous oubliez des détails. Et vous augmentez la latence moyenne, ce qui est exactement ce que tout le monde vous reproche ensuite.

Limiter le WIP, c’est mettre une contrainte volontaire. Une contrainte qui protège la qualité.

Exemples de limites simples :

• En cours : 1 à 2 tickets par personne max
• À qualifier : 5 tickets max
• À valider : 5 max, sinon c’est que la validation est un goulet

Politique de débordement : si le WIP est atteint, on finit avant de commencer. Point.

Et un indicateur très utile : si En attente grossit, ce n’est pas un problème de productivité. C’est un problème de dépendances, d’inputs, de décisions manquantes. Donc vous traitez ça en priorité, sinon votre tableau devient une fiction.

Workflow détaillé : de la demande au « Fait » sans trou dans la raquette

Le workflow doit être assez précis pour éviter les trous, mais assez léger pour être suivi quand ça chauffe.

Étape 1 : à qualifier

Objectif : comprendre ce qu’on a devant soi, et éviter de lancer du travail sur du flou.

Checklist rapide :

• infos minimales présentes ?
• reproduction possible ou au moins symptômes clairs ?
• service, environnement, impact ?
• classe de service proposée ou à définir ?
• doublon existant ?

Si ça manque, on demande, directement dans le ticket. Pas dans Slack. Toujours dans le ticket.

Étape 2 : prêt

Le ticket est « prêt » quand quelqu’un peut le prendre et avancer sans séance de ping pong.

Ce que j’aime mettre explicitement dans Prêt :

• priorité validée (classe de service)
• critères d’acceptation écrits, même simples
• owner du service, si besoin d’arbitrage
• fenêtre de changement si ça touche la prod

Étape 3 : en cours

Un propriétaire unique. Même si plusieurs personnes contribuent, il faut un pilote. Sinon personne ne relance, et tout traîne.

Le ticket doit vivre. On met des notes, des hypothèses, des liens, des extraits de logs. Pas besoin d’être littéraire. Juste traçable.

Étape 4 : en attente (bloqué)

On y va quand on ne peut plus avancer sans un input externe.

Et on respecte la règle : raison, next step, date de relance, responsable de relance.

Exemple : « bloqué par attente de validation réseau ; next step : ouvrir flux TCP 443 vers X ; relance le 03/07 par Alice ».

Étape 5 : à valider

Le correctif est en place. Il faut un test, une vérification, une validation utilisateur, ou une observation sur une fenêtre.

Si la validation traîne souvent, vous avez deux options. Soit vous mettez une règle de validation automatique après X jours sans retour. Soit vous clarifiez qui valide et sous quel délai. Mais vous ne laissez pas cette colonne devenir une « quasi fin ».

Étape 6 : fait

La clôture exploitation, c’est là où on perd beaucoup de valeur. On ferme vite, on oublie la doc, on oublie le monitoring, et on se retrouve avec le même incident deux semaines plus tard.

Le « Done » d’exploitation, idéalement, inclut :

• doc mise à jour si nécessaire
• monitoring ajusté si l’incident aurait dû être détecté autrement
• runbook ou KB créé si c’est nouveau
• lien vers PR, change, ou action réalisée
• et un résumé clair de la cause et de la solution

Les champs indispensables d’un ticket d’exploitation (pour éviter les aller retours)

Voici le minimum viable que je recommande, que ce soit dans Gitea ou Taiga.

• Résumé
• Description
• Impact
• Urgence
• Service
• Environnement
• Étapes pour reproduire ou symptômes
• Résultat attendu

Preuves :

• logs pertinents
• horodatage
• alertes associées
• métriques
• screenshot si utile

Contexte :

• changement récent
• version
• dépendances
• propriétaire du service

Et un petit check « Done » :

• doc à jour
• monitoring ajusté
• runbook ou KB créé si besoin

Oui, ça fait une liste. Mais c’est précisément cette liste qui évite 40 messages « tu peux me donner l’heure exacte ? », « c’était quel environnement ? », « t’as un log ? ».

Choisir l’outil : Gitea ou Taiga (et quand utiliser lequel)

Avant de choisir, clarifiez l’intention.

• Gitea : issues proches du code, intégration naturelle avec commits et pull requests. Très bien si votre exploitation est « infra as code », si beaucoup de sujets finissent en repo, en PR, en release.
• Taiga : gestion de flux plus visuelle, plus orientée process, plus ergonomique pour des demandes non code. Support interne, organisation, opérations transverses, suivi d’attentes, champs personnalisés.

Mais le point important, vraiment. L’outil ne remplace pas les règles. Une mauvaise porte d’entrée dans Taiga restera mauvaise. Un Kanban sans WIP dans Gitea restera chaotique. C’est le workflow qui sauve, l’outil ne fait que l’héberger.

Mise en place avec Gitea : issues, labels et vue Kanban

Configuration simple qui marche.

1. ops
2. Ajoutez des issue templates pour chacun des types suivants : Incident, Demande standard, Changement, Problème récurrent.
3. Définissez des labels cohérents en suivant les catégories ci-dessous.

Labels par classe de service

• critique
• urgent
• standard
• dette

Labels par service

• service:auth
• service:billing

Labels par environnement

• env:prod
• env:preprod

Labels par type

• type:incident
• type:change
• type:request

Pour le Kanban, selon votre version et vos modules activés, vous pouvez utiliser les Projects ou une vue basée sur labels et requêtes sauvegardées. L'idée reste la même : vos colonnes sont des états, et le déplacement doit être simple, presque mécanique.

Et l'avantage majeur de Gitea, c'est le lien au code. Un commit ou une PR peut référencer et fermer un ticket. Vous gardez l'historique complet. Et au moment d'une release, vous pouvez relire exactement ce qui a été fait et pourquoi.

Mise en place avec Taiga : tableau Kanban, rôles et champs personnalisés

Taiga est très agréable pour poser un Kanban exploitation propre, surtout si vous avez beaucoup de sujets hors repo.

1. Créez un projet « Exploitation » avec Kanban activé.
2. Créez les colonnes selon le workflow minimal : À qualifier, Prêt, En cours, En attente, À valider, Fait.
3. Ajoutez les champs personnalisés utiles listés ci-dessous.

Champs personnalisés recommandés

• Impact
• Service
• Environnement
• Fenêtre de changement
• Date de relance

Si vous avez besoin, vous pouvez ajouter des swimlanes. Par service critique, ou par type (incident vs standard). Mais attention, swimlanes trop tôt = complexité. Commencez simple.

Paramétrez aussi les rôles et permissions. Qui peut créer, qui peut prioriser, qui peut clôturer. En exploitation, c'est souvent là que ça part en conflit. Donc autant être clair.

Et profitez de l'automatisation possible : assignation par défaut, notifications, tags standard. Tout ce qui réduit la friction augmente l'adoption.

Rituels légers (mais non négociables) pour garantir « zéro ticket perdu »

Le tableau ne suffit pas. Il faut des moments où on le regarde ensemble, sinon il se dégrade.

Trois rituels, légers mais indispensables.

• Daily ops (10 min) : balayer À qualifier, débloquer En attente, vérifier le WIP, reprioriser si nécessaire. On ne résout pas tout au daily. On décide quoi faire et on enlève les obstacles.
• Revue hebdo (20 à 30 min) : analyser les tickets récurrents, la dette, les actions de prévention, et la qualité des descriptions. C’est souvent là que vous gagnez le plus à moyen terme.
• Post incident (si critique) : timeline, cause racine, actions correctives, mise à jour runbooks et monitoring. Pas pour blâmer. Pour apprendre.

Et une règle de communication simple : toute décision de priorité se voit sur le tableau. Commentaire + label. Sinon ça repart dans les discussions privées et vous perdez la cohérence.

Mesures simples à suivre (sans tomber dans la bureaucratie)

Pas besoin d’un dashboard de 40 KPI. Quelques mesures suffisent, si elles servent à agir.

• Lead time : temps entre Prêt et Fait. Objectif : le réduire.
• Cycle time : temps en En cours. Si ça explose, vous avez du multitâche ou des blocages mal gérés.
• Âge des tickets en En attente : indicateur direct de dépendances et de relances manquées.
• Débit hebdo : nombre de tickets terminés. Utile pour estimer la capacité, et calmer les attentes.
• Qualité : % tickets ré ouverts, incidents récurrents, respect des SLA.

Le but n’est pas de contrôler les gens. Le but est de voir le système. Et de l’améliorer.

Cas d’usage concrets : comment ce Kanban s’adapte à l’exploitation

Quelques scénarios classiques, et comment le Kanban aide vraiment.

Incidents

Un incident arrive, il devient un ticket, classé « incident critique » ou « urgent ». On applique la limite de WIP. On escalade selon la règle. Puis post incident si critique.

Le point clé : l’urgence ne doit pas cannibaliser tout le reste sans décision explicite. Si vous stoppez des tickets standards, vous le notez. Vous déplacez. Vous rendez visible. Sinon vous créez de la dette cachée.

Demandes standard

Templates + critères d’acceptation + validation rapide. Souvent, ces tickets devraient avoir un chemin fluide, presque industriel. Si vous voyez beaucoup de demandes standard qui bloquent, c’est un signal d’automatisation ou de documentation manquante.

Changements planifiés

Ajoutez une fenêtre, une approbation si nécessaire, un plan de rollback, et des vérifs post change. Le Kanban sert ici à rendre visible le risque, et à éviter les changements fantômes le vendredi soir.

Problèmes récurrents

Quand un incident revient, transformez le en « problème ». Même si vous traitez le symptôme, vous ouvrez une action préventive. Monitoring, automatisation, documentation, correction structurelle. Sans ça, vous faites du support éternel.

Erreurs fréquentes (et comment les éviter dès le début)

On peut ruiner un Kanban exploitation avec de bonnes intentions. Quelques pièges typiques.

• Trop de colonnes et statuts : on complique, on n’exécute plus. Restez sur le minimal.
• Priorités floues : tout devient urgent. Définissez des classes de service et des limites.
• Pas de WIP : tout le monde démarre tout, personne ne termine. Mettez une contrainte.
• « En attente » sans propriétaire : imposez relance + date + next step.
• Clôture bâclée : pas de doc, pas de runbook. Résultat : mêmes incidents, encore et encore.

Conclusion : le combo gagnant pour réellement atteindre « zéro ticket perdu »

La recette tient en une phrase. Une seule porte d’entrée, un tableau simple, des règles de WIP, une priorisation claire, et des rituels légers mais réguliers.

Côté outil. Prenez Gitea si votre exploitation est proche du code, des PR, des commits, et que vous voulez que dev et ops parlent dans le même espace. Prenez Taiga si vous avez besoin d’un Kanban ops plus orienté process, plus visuel, avec des champs personnalisés et des flux non code.

Votre prochaine action concrète, elle est simple. Créez le tableau aujourd’hui. Publiez les règles. Et donnez vous une semaine pour migrer toutes les demandes existantes dans la file unique. Même si c’est un peu sale au début. Ça se nettoie en avançant.

À la fin, vous gagnez quoi ? De la visibilité. Moins d’oublis. Une meilleure qualité de service. Et franchement, un quotidien moins stressant. Sans rajouter une couche de management inutile. Juste un système qui tient.

Questions fréquemment posées

Pourquoi les tickets se "perdent"-ils souvent en exploitation ?

Les tickets se perdent en exploitation non pas à cause d'incompétence, mais parce que le système est flou : absence de traçabilité, multiples canaux non centralisés (Slack, mails, appels), et aucun workflow clair, ce qui rend l'oubli inévitable.

Comment Kanban résout-il le problème des tickets perdus en exploitation ?

Kanban impose une source unique de vérité via une file unique où tous les tickets passent, offrant une visibilité en temps réel, une priorisation claire et une boucle de feedback pour éviter la répétition des incidents.

Quel est le prérequis essentiel avant de mettre en place un tableau Kanban en exploitation ?

Il faut établir une seule porte d'entrée pour toutes les demandes. Sans cela, les canaux parasites comme les messages privés ou les demandes orales continueront à faire perdre des tickets malgré l'existence du tableau Kanban.

Quelles règles doivent accompagner un tableau Kanban efficace en exploitation ?

Un tableau Kanban efficace inclut des règles claires telles que la limitation du travail en cours (WIP), des SLA et SLO définis, des rituels courts réguliers, et des intégrations adaptées au contexte (ex : Gitea ou Taiga).

Comment faciliter la création de tickets pour assurer leur traçabilité ?

Utiliser un formulaire ou un template d'issue standardisé qui capture toutes les informations clés (demandeur, impact métier, urgence, service concerné, environnement, preuves) permet d'éviter les allers-retours et encourage la création systématique de tickets.

À quoi ressemble un tableau Kanban minimaliste et efficace pour l'exploitation ?

Un tableau simple avec 6 colonnes : À qualifier, Prêt, En cours, En attente (bloqué), À valider et Fait. Chaque colonne doit avoir une définition claire avec des critères d'entrée (Definition of Ready) et de sortie (Definition of Done) adaptés à l'équipe.