Bonnes pratiques Jira
sur un projet DevOps Ma vision, après huit ans de QA

01Un defect qui n'a jamais vraiment existé

Je déroule une campagne de tests. Un comportement ne colle pas avec ce que j'attendais. Je vais voir le développeur concerné, on regarde ensemble, il fouille ses logs deux minutes et me dit : « ok, je vois ce que c'est, ouvre-moi un defect. »

Alors j'ouvre un defect. Titre : « KO sur la page de résultats ». Description : vide. Pas par négligence — parce que je n'ai rien à y mettre. Ce que le dev a compris, il l'a compris seul devant sa console, et ça n'est jamais sorti de sa tête. Moi je sais qu'il y a un problème quelque part. Je ne sais pas lequel.

Le ticket part en développement. Il revient en « à tester » trois jours plus tard. Pas de commentaire, pas de lien vers la merge request, pas de version de correction renseignée.

Et c'est à moi de le fermer. Sur mon projet, c'est la QA qui clôture les defects, et j'y reviendrai parce que c'est la bonne règle. Sauf que pour clôturer celui-là, il faudrait que je sache quoi vérifier. Je repasse mon scénario, il passe. Est-ce que ça valide le correctif ? Aucune idée. Je ne sais ni ce qui a été modifié, ni ce que la modification a pu déplacer ailleurs. Je ferme quand même, parce qu'il faut avancer et que la livraison est vendredi.

Vert dans Jira, creux dans les faits.

Six mois plus tard, le même comportement réapparaît. On reprend le sujet de zéro. Le ticket d'origine est toujours là, retrouvable en dix secondes, avec son titre de cinq mots et ses trois transitions de statut. Il ne nous apprend rien du tout.

J'ai vu cette scène se rejouer sur presque tous les projets où je suis passé, en huit ans. Ce n'est pas une anecdote, c'est un motif. Pas vous ?

02Le vrai problème n'est pas la rigueur des gens

La lecture facile, c'est de dire que le dev n'a pas fait son travail de documentation, ou que la QA a ouvert un ticket bâclé. Elle est confortable, cette lecture. Elle est aussi fausse. Sur ce projet, tout le monde travaillait bien : le code était propre, les corrections pertinentes, l'ambiance excellente.

Ce qui manquait, c'est qu'aucune règle n'avait jamais été posée. Personne n'avait écrit ce qu'un defect devait contenir pour être recevable. Personne n'avait dit qui renseignait quoi, ni à quel moment. Personne n'avait expliqué à quoi servaient les champs qu'on laissait vides. Dans ce vide, chacun fait au plus court. C'est le comportement rationnel de n'importe quel humain sous pression, moi compris.

Et la QA, dans cette situation, s'adapte. C'est même sa fonction : absorber le flou pour que le flux continue. Je crée le ticket que le dev me demande de créer, avec les informations dont je dispose, c'est-à-dire aucune. Je le clôture parce qu'il faut bien le clôturer. Ce travail d'absorption est invisible, donc il n'est jamais mesuré, donc rien ne change.

Ce n'est pas à moi d'instaurer ces règles, soyons clairs. Un Lead QA n'est ni le chef de projet, ni le scrum master, ni le responsable de la gouvernance de l'outil. Mais c'est à moi de les remonter, avec des exemples précis et le coût associé. C'est exactement l'objet de cet article : ce que je remonte désormais dès les premiers jours, avant qu'un seul ticket n'existe.

03Pourquoi c'est spécifiquement un sujet DevOps

En cycle en V, la lenteur du processus absorbait une bonne partie de ce flou. On avait des phases, des jalons, des documents rédigés à un moment donné. C'était lourd, mais l'information finissait par se déposer quelque part.

En flux continu, il n'y a plus de moment où l'information se dépose. Il n'y a que le ticket. Et selon moi cette dette-là se paie plus vite que la dette technique, pour quatre raisons très concrètes.

On n'automatise pas un déploiement sans savoir quel composant est réellement impacté. On ne génère pas une release note sans version de correction fiable. On ne cible pas une campagne de non-régression sans périmètre d'impact identifié. Et on ne fait pas de post-mortem sur un incident dont le correctif n'a laissé aucune trace écrite.

Autrement dit : plus le rythme de livraison augmente, plus le flou devient un goulot d'étranglement mécanique. Ce n'est pas une question de confort, c'est une question de capacité à livrer.

04Avant de poser des règles, challenger celles qui existent

Le cas du projet vierge est rare. La plupart du temps on arrive chez un client qui a déjà des habitudes, des gabarits, un workflow hérité d'un projet précédent, et une phrase toute prête : « chez nous, on fait comme ça ». Parfois c'est excellent et il faut se garder de tout réinventer. Parfois c'est un empilement de contournements dont plus personne ne connaît la raison d'origine.

Selon moi, la première chose à faire n'est donc pas de proposer des règles, c'est de mettre les anciennes sur la table. Concrètement : une séance de retour d'expérience, deux heures, avec les gens qui ont vécu les projets précédents. Trois questions, pas plus. Qu'est-ce qui a bien fonctionné et qu'on garde ? Qu'est-ce qui nous a coûté du temps ? Et surtout : quelle règle appliquez-vous sans savoir pourquoi ?

Cette dernière question est la plus productive de toutes. C'est celle qui fait ressortir le champ obligatoire ajouté en 2019 pour un besoin de reporting disparu depuis, ou l'étape de validation qui n'existe que parce qu'un incident a fâché quelqu'un il y a quatre ans.

Deux bénéfices à cet exercice. On évite de proposer une organisation déjà tentée et déjà rejetée, ce qui grille un capital de crédibilité difficile à reconstituer. Et surtout, on transforme un discours descendant — « voici comment il faut travailler » — en une décision d'équipe. Les règles qui tiennent sont celles que les gens ont contribué à écrire. Celles qu'on impose ont une durée de vie de trois semaines.

05Les fondations, avant la première story

Voilà ce que je réclame au démarrage. Une demi-journée à quatre ou cinq personnes, et des mois de rattrapage évités.

Les droits d'administration sur son propre projet

Une équipe DevOps qui doit ouvrir un ticket au support interne pour obtenir un nouveau composant attendra trois semaines. Pendant ces trois semaines, les tickets seront rangés dans le composant le plus approchant, et cette approximation deviendra la norme définitive.

L'équipe a besoin d'autonomie réelle sur les types de tickets, les champs, les composants, les workflows et les automations. Si l'outil ne suit pas le rythme du projet, l'équipe cesse simplement de s'en servir sérieusement. Elle bascule sur un tableur partagé, et là c'est fini.

Un modèle de données décidé, écrit, et visible

Qui porte quoi, sur une page. L'Epic porte une intention métier de plusieurs mois. La Feature porte un ensemble cohérent livrable. La Story porte une valeur métier vérifiable. L'Enabler porte du travail technique nécessaire mais sans valeur métier directe. Le Defect porte une anomalie détectée avant la mise en production. L'Incident porte une anomalie subie par les utilisateurs.

Le point important est moins la liste que le fait qu'elle soit tranchée et écrite quelque part. Deux personnes qui n'ont pas la même définition d'une Story ne s'accorderont jamais sur son contenu, et elles passeront des mois à se demander pourquoi elles ne se comprennent pas.

Defect et Incident : deux types, deux circuits

C'est la distinction que je vois le plus souvent écrasée dans un type unique appelé « Bug », et selon moi celle qui coûte le plus cher en lisibilité.

Le Defect naît en interne, pendant la phase de vérification, avant que le code ne parte en production. L'Incident naît chez l'utilisateur. Il est remonté par le support métier dans son propre outil de ticketing, et il arrive côté fabrication avec une qualification déjà faite : quelqu'un a constaté un impact réel, sur des données réelles, et l'a déclaré.

Le circuit que je considère comme sain tient en quelques points.

C'est à l'équipe de fabrication d'ouvrir le ticket Incident dans Jira, pas au support. Le support travaille dans son outil, avec ses codes et ses délais ; il ne connaît ni notre modèle de données, ni nos composants. Lui demander de créer nos tickets produit des Incidents inexploitables — et une friction inutile entre deux équipes qui ont déjà assez à faire.

La référence du ticket support est renseignée systématiquement, dans un champ dédié ou un lien externe. C'est le seul moyen de refermer la boucle. Sans elle, personne ne peut répondre à « où en est le signalement que j'ai transmis la semaine dernière », et le support finit par relancer par courriel. Ce qui échappe à toute traçabilité, évidemment.

La priorité de l'Incident hérite de celle du ticket support. Elle ne se renégocie pas côté technique. C'est le métier qui a constaté l'impact et qui est légitime pour en juger l'urgence. La sévérité, elle, reste une évaluation interne — j'y reviens juste après.

Et l'Incident n'entre pas dans le sprint en cours comme une story de plus. Il passe par le circuit d'urgence, avec la capacité réservée pour cela. Un Incident traité « quand on aura le temps » n'est pas un Incident, c'est un Defect mal nommé.

Le bénéfice de cette séparation dépasse largement la propreté du backlog : c'est le seul moyen de savoir ce qui a échappé aux vérifications internes. Quand Defects et Incidents sont mélangés, plus personne ne peut mesurer ce qui fuit vers la production. Et donc plus personne ne peut l'améliorer.

Sévérité et priorité sont deux champs distincts

La sévérité décrit la gravité technique et fonctionnelle du problème. Elle appartient à la QA, bien souvent la seule à avoir observé le comportement. La priorité décrit l'urgence de traitement au regard des enjeux métier. Elle appartient au product owner, ou au support dans le cas d'un Incident.

Les deux notions se recoupent souvent, jamais toujours. Un défaut d'affichage sur l'écran que le client montre à ses propres clients est faiblement sévère et hautement prioritaire. À l'inverse, une corruption de données silencieuse sur une fonction peu utilisée est gravissime et peut attendre la semaine prochaine.

Quand on n'a qu'un seul champ pour les deux, il devient le terrain d'une négociation permanente et il finit par ne plus rien décrire du tout.

06Composants et produits : la confusion qui coûte le plus cher

Voici le point sur lequel j'insiste le plus, parce que ses conséquences sont les plus larges et qu'il est presque toujours mal fait.

Le schéma que je rencontre : un portefeuille de deux ou trois produits, disons Horizon et Méridien, et un champ Composant qui propose exactement ces valeurs. Sur un ticket du projet Horizon, le champ vaut donc systématiquement « Horizon ».

Un champ qui a toujours la même valeur, ce n'est pas un champ. C'est un décor.

Un composant est une unité technique identifiable et, idéalement, déployable séparément : api-traitement, worker-indexation, front-administration, schema-bdd, pipeline-ci, connecteur-referentiel. Renseigner correctement ce champ débloque quatre choses.

Le déploiement ciblé d'abord : on ne construit pas une chaîne de livraison par composant si l'outil de suivi ignore de quels composants le produit est fait. L'analyse d'impact ensuite, et c'est le bénéfice direct pour la QA : quand je vois qu'une livraison touche l'API de traitement et le schéma de base, je sais quels scénarios repasser et lesquels je peux laisser tranquilles. Sans cette information il me reste deux options, tout revérifier ou deviner. Les deux sont mauvaises.

Vient l'ownership : un composant a un ou deux référents identifiés, ce qui répond en une seconde à la question « qui je vais voir ». Et enfin les métriques : quand on sait d'où viennent les anomalies, l'arbitrage sur la dette technique cesse d'être une intuition. On ne dit plus « on sent que ce module est fragile », on dit « le tiers des anomalies du trimestre vient de ce composant ». Et cette phrase-là, contrairement à la première, obtient des budgets.

Un dernier point de méthode. Le composant se renseigne au mieux à la création, par celui qui ouvre le ticket, et se corrige par le développeur quand il découvre le périmètre réel de son intervention. C'est un champ vivant, pas une déclaration d'intention figée. Mieux vaut un composant approximatif corrigé en cours de route qu'un champ laissé vide par excès de prudence.

07Les étiquettes, ce champ qu'on laisse pourrir

L'étiquette est le champ le plus souple de Jira, donc le premier à devenir inutilisable. Au bout de deux ans, on trouve bug, Bug, bugs, BUG-prod et bug_prod. Bon courage pour construire un filtre là-dessus. C'est le champ que j'ai vu se dégrader le plus vite sur chaque projet, et celui qu'on renonce le plus tôt à utiliser.

La règle qui clarifie tout : le composant est structurel et permanent, l'étiquette est transverse et souvent temporaire. Si une étiquette est utilisée par tout le monde depuis dix-huit mois, ce n'est plus une étiquette, c'est un champ qu'on n'a pas créé.

Les familles qui servent vraiment se comptent sur les doigts d'une main. La qualité, avec regression, flaky, non-reproductible. La nature du travail, avec tech-debt, securite, perf. Le signal de blocage, avec needs-spec ou attente-client, qui rend visible dans un filtre ce qu'on répète chaque matin en stand-up. Et le contexte de livraison, avec hotfix ou carry-over.

La contrepartie n'est pas négociable : une revue de nettoyage, une fois par trimestre, un quart d'heure. Sans elle, la liste enfle jusqu'à l'inutilité et on recommence à créer des doublons.

08La fix version, le champ qui met de l'ordre partout

S'il fallait n'en garder qu'un seul de tout cet article, ce serait celui-là. La fix version — la version corrigée — est le champ qui coûte le moins cher à renseigner et qui rend le plus de services. C'est aussi, statistiquement, celui que je trouve le plus souvent vide.

Il répond d'abord à la question la plus banale et la plus fréquente d'un projet : qu'est-ce qui est parti dans cette version ? Sans fix version, on reconstruit la réponse à la main, de mémoire, la veille de la mise en production, avec les oublis que ça suppose. Avec, c'est un filtre et trois secondes.

Il donne ensuite un périmètre de recette. Quand je prépare ma campagne, je ne pars pas d'une liste de tickets glanée dans un fil de discussion : je pars de ce que porte la version. Ce qui n'y est pas n'est pas à vérifier, et ce qui y est ne peut pas passer à la trappe.

Il rend surtout les exécutions de tests lisibles, et c'est là que ça devient vraiment précieux. Sur les projets où j'utilise Xray, une exécution de test est rattachée à une version : je sais quels tests ont été passés sur quelle livraison, avec quel résultat, et je peux comparer d'une version à l'autre. Sans le champ, l'historique d'exécution devient une accumulation de campagnes sans repère, et on perd la seule chose qui m'intéresse vraiment là-dedans : l'évolution.

Il permet enfin de répondre à « est-ce que le correctif est disponible ? » sans aller demander à quelqu'un, et il rend la release note générable plutôt que rédigée.

Son pendant mérite le même soin : la version affectée, qui indique depuis quand le problème existe. C'est ce qui permet de dire « cette anomalie est apparue en 2.3 » plutôt que « ça a toujours plus ou moins déconné ».

09Ce que doit contenir un ticket

Deux gabarits courts valent mieux qu'une charte de dix pages que personne ne lira.

Ces deux listes paraissent longues, et une équipe sous pression finira par les rogner. Le problème, c'est qu'elle rogne toujours sur les deux mêmes lignes — celles qui coûtent le plus cher à l'année. Je m'y arrête donc un instant.

Sur un defect : le lien vers la règle de gestion

Prenons un cas ordinaire. Un formulaire accepte une date de traitement dans le passé. Pour moi c'est une anomalie, pour le développeur c'est le comportement attendu puisque rien ne l'interdit. À ce stade, c'est une opinion contre une autre, et ça se tranche à l'ancienneté ou à l'insistance. Personne n'a tort, personne ne peut le prouver, et l'un des deux repartira avec le sentiment d'avoir perdu un arbitrage plutôt qu'un désaccord.

Le lien vers la règle change complètement la nature de l'échange. Si la spécification indique que la date doit être postérieure au jour de saisie, il n'y a plus de débat, juste une correction à faire. Et si aucune règle n'existe sur ce point, c'est une information au moins aussi utile : le ticket cesse d'être un bras de fer entre deux personnes et devient une question posée au product owner.

Dans les deux cas, le sujet sort du registre affectif. C'est pour cette raison que je considère ce champ comme celui qui protège le plus la relation entre développeurs et QA. Ce qui n'est absolument pas la raison pour laquelle on le met en place, d'ailleurs.

Sur une story : ce qui est hors périmètre

Une story demande un export des dossiers clients. Personne n'écrit si les dossiers archivés sont concernés. Le métier suppose que oui, parce que pour lui un dossier reste un dossier. Le développeur suppose que non, parce que ça n'a pas été demandé. Les deux ont raisonné correctement.

Et on découvre l'écart en démonstration de fin de sprint. Le pire moment possible.

Écrire « hors périmètre : les dossiers archivés » prend cinq mots, et supprime à lui seul une bonne moitié des malentendus de fin de sprint. La règle générale derrière l'exemple mérite d'être affichée quelque part : ce qui n'est pas écrit est présumé inclus par ceux qui expriment le besoin, et présumé exclu par ceux qui le réalisent.

« Et qui a le temps de remplir tout ça ? »

L'objection tombe systématiquement à ce moment-là, et elle est légitime. Ma réponse tient en une comparaison. Renseigner correctement un ticket prend trois à cinq minutes, une fois, au moment où l'on a toutes les informations en tête. Reconstituer ces mêmes informations six mois plus tard prend une demi-journée à deux ou trois personnes, et le résultat est incomplet. C'est le même arbitrage que pour les tests automatisés, et selon moi il se tranche dans le même sens.

Ce qui aide, c'est de se demander pour qui on écrit. Spontanément, on écrit pour le collègue avec qui on vient d'en parler, celui qui a tout le contexte en tête et à qui trois mots suffisent. Sauf que ce n'est pas lui, le vrai lecteur. Le vrai lecteur arrive dans six mois, il n'a rien suivi, et il pourrait très bien être toi.

Et si ce raisonnement ne suffit pas, c'est à cause d'une asymétrie que la bonne volonté individuelle ne peut pas résoudre : celui qui remplit mal un ticket n'en paie jamais le prix. Il le fait payer à quelqu'un d'autre, plus tard, sans le savoir. Une règle collective n'est pas là pour discipliner les gens, elle est là pour corriger ce déséquilibre.

10Le workflow : peu d'états, mais des états qui ne mentent pas

Le workflow est le sujet sur lequel j'ai le plus insisté sur un projet. C'est aussi celui qu'on traite le plus tard, alors qu'il devrait être arbitré dans la première semaine. Une fois que trois cents tickets circulent, y toucher devient un chantier.

Ma conviction, et elle est ferme : un workflow simple bat un workflow exhaustif, à tous les coups. J'ai vu passer des workflows à quatorze statuts, validés en comité, avec des sous-états de sous-états. Personne ne les respecte. Les tickets stagnent trois semaines dans « En cours », le tableau devient décoratif, et on ajoute un fichier de suivi à côté pour savoir ce qui se passe vraiment. L'usine à gaz produit toujours le même résultat : deux sources de vérité, dont aucune n'est fiable.

Cinq ou six états dont la signification est partagée par tout le monde, ça suffit à couvrir la vie d'un ticket.

Lorsque j'ai passé mon DUT Services et Réseaux de Communication, on m'a appris qu'un logo qu'on ne peut pas reproduire après l'avoir vu une seconde est un mauvais logo. J'y vois un parallèle assez direct avec le workflow : si on ne peut pas retenir facilement l'ensemble des transitions possibles, c'est qu'il est trop complexe.

Le levier le plus efficace que je connaisse, et le plus rarement utilisé, tient dans une nuance : les champs obligatoires doivent l'être à la transition, pas à la création. Rendre la création contraignante tue le réflexe de créer, et un problème non tracé coûte bien plus cher qu'un problème mal tracé. La contrainte doit arriver au moment où l'information existe, pas avant.

Un exemple concret de ce que ça donne. Sur un de mes projets, nous utilisons une Smart Checklist dans le ticket. Quand une Story porte sur des évolutions métier, elle comporte une ligne « documentation produit mise à jour ». Tant que la case n'est pas cochée, la transition est refusée. Ça discipline sans jamais frustrer, parce que la contrainte tombe pile au moment où la case peut être cochée honnêtement.

Qui clôture un defect

Précision de vocabulaire avant tout, parce qu'elle change complètement la réponse. Je parle ici des defects de recette, ceux qui apparaissent une fois le développement terminé et le ticket passé en vérification. Ce qu'un développeur trouve et corrige pendant qu'il code sa Story n'est pas un defect : c'est son processus de fabrication normal. Ouvrir un ticket pour ça n'apporte rien à personne et pollue les indicateurs.

Pour les defects de recette, donc, une seule réponse selon moi : la QA. Pas celui qui a corrigé, pas celui qui a ouvert le ticket (sauf si c'est la QA, bien entendu), pas le product owner qui a vu la démonstration. Cette règle ne se négocie pas, et c'est justement parce qu'elle paraît rigide qu'elle fonctionne. Dès qu'on autorise une exception, elle devient le cas courant en un trimestre.

La raison de fond est un problème de responsabilité, pas de confiance. Un développeur qui détecte une anomalie, la corrige et la clôture lui-même n'a rien fait de malhonnête. Mais il a validé son propre travail avec le raisonnement qui l'a produit. S'il s'est trompé sur la cause, il se trompera sur la vérification. Une clôture par un tiers n'ajoute pas de la défiance, elle ajoute un autre regard — ce qui est tout l'objet d'une démarche qualité.

Il y a une contrepartie, et j'ai appris à mes frais qu'elle n'est pas optionnelle. Sur mon projet actuel, c'est bien la QA qui clôture, et je me retrouve régulièrement à devoir valider une correction que je suis incapable de caractériser. Soit parce que le ticket a été ouvert par un développeur sans passer par moi, soit parce que le correctif n'a laissé aucune trace de ce qui a été modifié. Dans ces cas-là je ne fais pas un contrôle, je pose une signature à l'aveugle.

La règle a donc besoin de son symétrique, sinon elle transforme la QA en tampon administratif : celui qui corrige écrit ce qu'il a changé et comment le vérifier. Trois lignes en commentaire suffisent. La cause identifiée, le périmètre technique touché, le chemin de vérification. Et lorsque l'anomalie n'est pas observable depuis l'interface — une correction d'infrastructure, un traitement nocturne, une contrainte en base — c'est au correcteur de fournir la preuve exploitable, log ou requête, sur laquelle la QA s'appuiera.

Les automations qui rentabilisent leur mise en place

Trois règles suffisent à démarrer, et aucune ne demande d'outillage particulier.

La relance sur les tickets sans activité depuis un nombre de jours donné, qui rend visible ce que le tableau masque : un ticket immobile depuis trois semaines n'est pas en cours, il est bloqué, et personne ne l'a dit à voix haute.

La notification de la QA dès qu'un ticket entre en « À tester », pour que la vérification ne dépende pas de quelqu'un qui rafraîchit un filtre.

Et celle que je mets en place systématiquement : le signalement de tout defect clôturé sans fix version renseignée. À elle seule, cette règle traite une bonne partie du problème décrit en ouverture de cet article. Pour un quart d'heure de configuration.

11Le lien entre Jira, Git et la chaîne de livraison

C'est le maillon le plus souvent négligé, et pourtant celui qui coûte le moins cher, parce qu'il ne relève d'aucune technique. Uniquement de trois conventions.

La clé du ticket figure dans le nom de la branche et dans les messages de commit. La merge request est référencée dans le ticket, pas ailleurs. Et le ticket indique explicitement quand la correction est mergée et sur quel environnement elle est disponible.

Ce point est celui qu'on oublie le plus, et c'est celui qui me bloque le plus souvent. Un ticket passé en « À tester » ne dit pas si la correction est effectivement déployée sur l'environnement où je vais la vérifier. J'ai passé un nombre déraisonnable de demi-journées à revérifier des correctifs qui n'étaient pas encore livrés, à conclure que le problème persistait, et à rouvrir des tickets qui n'avaient jamais été faux. C'est chiant et frustrant.

Une ligne de commentaire suffit à supprimer entièrement cette perte : « mergé, disponible sur l'environnement de qualification depuis ce matin ». C'est tout.

Rien dans tout cela n'est automatique chez moi. C'est un accord entre adultes, tenu parce que chacun voit ce qu'il y gagne, et ça fonctionne raisonnablement bien.

Je sais qu'on peut aller beaucoup plus loin. Les connecteurs entre Jira et les plateformes Git permettent d'afficher branches, commits et merge requests directement dans le ticket, et de déclencher des transitions de statut sur les événements du dépôt : passage en cours à la création de la branche, passage à tester au merge. Sur le papier, ça supprime la dépendance à la discipline individuelle et ça règle mécaniquement le problème que je viens de décrire.

12Documentation : une page vivante par produit

Chaque produit a besoin d'une page de référence unique : architecture, spécificités techniques, règles de gestion, exigences métier. Et il faut lever tout de suite l'objection qu'on va me faire, celle du retour au cycle en V.

La distinction est la suivante : le ticket raconte un changement daté, la page décrit l'état actuel du système. Deux objets différents, deux usages différents. Les confondre revient à produire deux documentations fausses au lieu d'une seule vraie. Une page produit n'est pas un doublon des tickets, c'est leur résultat consolidé.

Toute Story, tout Enabler, tout Defect ou Incident qui modifie une règle de gestion met la page à jour. Cette obligation figure dans la définition du fini, pas dans les bonnes intentions. Dans les bonnes intentions, ça ne se fait jamais.

Le test que je fais passer à une équipe pour savoir où elle en est : combien de temps faut-il à un nouvel arrivant pour répondre seul à la question « que doit faire le système dans ce cas de figure ? ». Si la réponse est « il faut demander à Untel », alors la documentation n'existe pas, quel que soit le nombre de pages publiées. Et le corollaire est franchement inconfortable : le projet ne survit pas au départ d'Untel.

13La dimension humaine, qui est le vrai sujet

Tout ce qui précède est de l'outillage. Rien ne tient si les rôles ne sont pas explicites — et selon moi c'est là que se joue 80 % de la réussite d'une organisation projet, pas dans la configuration de l'outil.

Poser un RACI, même léger

Je sais, l'acronyme sent le comité de pilotage et le classeur à onglets. Mais l'exercice est utile, à condition de le garder minuscule : une page, une demi-journée, et surtout appliqué au cycle de vie du ticket plutôt qu'à l'organigramme.

Pour chaque étape — expression du besoin, découpage technique, réalisation, vérification, clôture, mise en production, mise à jour de la documentation — on répond à quatre questions. Qui réalise ? Qui approuve ? Qui doit être consulté avant ? Qui doit être informé après ?

Ce que ça donne dans les grandes lignes, chez moi. Le product owner porte le besoin et la priorité. Le tech lead porte l'impact technique et le découpage. Le développeur porte la réalisation et la trace de ce qu'il a fait. La QA porte la vérifiabilité, la sévérité, et la clôture. L'exploitation porte les contraintes de mise en production et de supervision. Le support porte la qualification de ce que vivent les utilisateurs.

L'intérêt de l'exercice n'est pas le tableau final, franchement personne ne le relira. C'est la discussion qui le produit. C'est pendant cette demi-journée qu'on découvre que trois personnes se croyaient responsables du même arbitrage, ou qu'une étape entière — typiquement la mise à jour de la documentation — n'avait tout simplement pas de propriétaire. Ce sont ces trous-là qui produisent les tickets vides six mois plus tard.

Et il faut le revisiter. À chaque arrivée dans l'équipe, à chaque changement de périmètre. Un RACI de démarrage jamais relu est un document mort au bout d'un trimestre.

La rétrospective, ce rendez-vous qu'on a laissé se vider

Je vais être direct : j'ai l'impression de vivre la même rétrospective depuis huit ans. Même format, mêmes colonnes, mêmes sujets qui reviennent toutes les trois semaines parce que personne n'a été nommé pour les porter. On note, on vote, on repart. Trois semaines plus tard, on renote la même chose. C'est une routine qui ramollit tout le monde, moi le premier.

Posez la question autour de vous : « est-ce qu'il y a une rétro qui t'a marqué ? ». Je parie que la plupart des gens n'auront rien à répondre. Ce n'est pas un problème d'animation, c'est que le rendez-vous s'est vidé de sa raison d'être.

Moi, je peux y répondre. Il y a un an et demi, une rétro a été consacrée à 100 % à autre chose : comment on allait, notre fatigue, notre ressenti du moment. Une météo de l'équipe, sans un seul ticket à l'ordre du jour. J'y ai remonté une difficulté relationnelle avec mon product manager, qui me bouffait depuis des mois et que je n'avais jamais formulée à voix haute. Ça m'a fait un bien fou. Le soutien des collègues a compté autant que le fait de le dire, et surtout ça a libéré la parole : d'autres ont enchaîné sur des sujets voisins qu'ils gardaient également pour eux.

Deux enseignements que j'en tire. Une action sans porteur nommé n'est pas une action, c'est un vœu — et une rétro qui n'en produit que des vœux finit par ne plus rien produire du tout. Ensuite, l'alternance des formats n'est pas un gadget d'animateur : une rétro sur trois consacrée à l'humain plutôt qu'au processus change complètement la nature de ce qui se dit.

Dernier point, plus délicat, mais il faut le poser : la composition. Une rétrospective appartient à l'équipe. La présence par défaut d'un manager ou d'un product manager suffit à faire disparaître la moitié des sujets, sans que personne ne le décide consciemment. Ça ne veut pas dire jamais. Ça veut dire que sa venue se planifie, s'annonce à l'avance, et répond à un objectif précis.

La QA n'est pas le secrétariat du projet

Ce qui arrive quand la répartition n'est pas posée, je l'ai décrit en ouverture : la QA reconstitue les informations manquantes, complète les tickets des autres, relance, recoupe, traduit. Ce travail est invisible dans les indicateurs, donc il n'est jamais valorisé, donc il n'est jamais corrigé. Et il consomme exactement le temps qui devrait aller à la stratégie de test.

Je le dis sans amertume : c'est un rôle que j'ai longtemps accepté sans le nommer, en pensant rendre service. C'est en le nommant que les choses ont commencé à bouger.

Faire adopter des règles

Sur ce point, j'ai fini par retenir trois choses.

Une règle sans son « pourquoi » se contourne en une semaine. Il faut expliquer à quoi sert chaque champ, sinon il est perçu comme une formalité — et une formalité se remplit n'importe comment.

Rien ne convainc mieux qu'un bénéfice visible. Montrer une release note générée en trois secondes, ou ressortir un ticket de trois ans qui permet de trancher un débat immédiatement, vaut mieux que dix rappels à l'ordre en rétrospective.

Enfin, il existe un piège inverse qu'il faut nommer. Dès que Jira devient un instrument de contrôle managérial, dès que la vélocité devient une note individuelle, les données deviennent fausses. Les tickets sont alors dimensionnés pour bien paraître, pas pour décrire le réel. Un projet où l'on a peur de rouvrir un defect est un projet où les indicateurs sont irrécupérables. Et à ce stade, plus aucune bonne pratique ne sauvera quoi que ce soit.

14Les objections qu'on me fait

« On perd du temps à documenter. » On perd surtout le temps de tous ceux qui chercheront l'information ensuite. Et ils sont plus nombreux que celui qui l'écrit.

« On est en agile, la documentation c'est du cycle en V. » Le manifeste agile place le logiciel fonctionnel au-dessus de la documentation exhaustive. Exhaustive, pas utile. Ce n'est pas la même chose, et l'amalgame arrange beaucoup de monde.

« On se parle, ça suffit. » Jusqu'au premier départ dans l'équipe. Ou au premier audit. Ou à la première question d'un client sur une décision prise il y a deux ans.

« Notre Jira est trop rigide. » Un Jira vécu comme rigide est presque toujours un Jira sur-configuré : trente champs personnalisés dont quatre sont réellement remplis. La solution est de supprimer, pas d'ajouter.

15Si je démarrais un projet demain

Rien de tout cela ne demande de budget. Uniquement des décisions collectives, prises avant que les habitudes n'aient eu le temps de s'installer — parce qu'elles s'installent en trois semaines et se désinstallent en un an.

Le ticket vide dont je parlais au début, je ne l'ai pas mal rempli. Je l'ai rempli exactement à la hauteur de ce que le projet attendait de lui. C'est peut-être ça, la seule leçon de cet article.

J'avais tant de choses à dire, tant de sujets à aborder. Il a été difficile de structurer, j'ai fait du mieux possible et si vous lisez ces mots c'est que ça a dû aller à peu près.

J'ai forcément oublié des éléments, peut-être capitaux, mais je suis déjà content d'avoir pu poser à l'écrit tout ce que j'avais dans ma tête et sur le cœur. Les thèmes purement liés au testing n'étaient pas recherché volontairement (stratégie de test, pratiques de test, recettes...).

C'était mon premier article, peut-être que j'en ferai d'autres justement plus axés sur le testing, ou pas.

Marc Lurthy

Lead QA freelance — Nantes

Disponible à partir de 2027

J'interviens depuis près de huit ans sur des projets d'automatisation de tests et d'organisation de la qualité. Je peux aussi réaliser des audits, pour vous apporter un œil neuf sur vos méthodes de travail, vos pratiques quotidiennes et votre organisation.

Me contacter LinkedIn