Suivi des items

Objectif

Le BABOK pose l'objectif de la technique: capter les problèmes et les préoccupations des parties prenantes qui pèsent sur la solution et en attribuer la responsabilité. Une préoccupation exprimée en atelier et non consignée revient plus tard, à la validation des exigences, au test d'acceptation (UAT) ou en production, et elle revient plus chère. Consigner sans attribuer produit une liste que personne ne fait avancer; attribuer sans consigner produit un engagement dont personne ne retrouve la trace six semaines plus tard.

La technique est le contenant générique de tout ce qu'une partie prenante soulève. Le BABOK nomme sept types d'items: l'action à mener, l'hypothèse posée faute d'information et qui reste à confirmer, la contrainte imposée de l'extérieur, la dépendance envers un tiers, le défaut constaté, l'amélioration demandée et le problème (issue) qui bloque. Cette généralité est délibérée: elle donne un seul endroit où atterrit toute préoccupation, quelle que soit sa nature, et le tri décide ensuite du processus dans lequel l'item entre.

Le livrable est un registre d'items renseigné, partagé et tenu à jour: un tableau dont chaque ligne porte une préoccupation, la personne qui l'a soulevée, un impact évalué, une priorité, un propriétaire, un résolveur, une stratégie convenue, un statut et une échéance de résolution. Le BABOK ajoute que le registre peut être partagé avec les parties prenantes: elles voient l'état et l'avancement des items et classent par importance ce qui reste ouvert.

Le registre tranche une question: qui répond d'une préoccupation ouverte et pour quand. On le montre à la partie prenante qui vient demander ce qui a été fait de ce qu'elle a dit. Le BABOK énonce d'abord cette force: les préoccupations des parties prenantes sur les exigences sont captées, suivies et résolues à leur satisfaction. La technique produit un tableau. Son effet est une partie prenante qui cesse de répéter sa préoccupation à chaque séance parce qu'elle la voit inscrite, avec une échéance et un nom en face.

Usage

Quand l'utiliser

• Atelier ou entretien d'élicitation: consigner sur-le-champ chaque préoccupation soulevée, dans les mots de celui qui la soulève.
• Exigences en attente de validation: un point bloquant nommé, doté d'un propriétaire et d'une échéance, rend la signature possible.
• Parties prenantes nombreuses aux intérêts divergents: rendre visible ce qui reste ouvert et qui doit trancher.
• Hypothèse posée faute d'information: la consigner comme item à confirmer, avec la date où elle devra l'être.
• Dépendance envers un tiers hors du périmètre de l'équipe: la suivre avec une échéance et une route d'escalade convenue.
• Équipe distribuée ou travail asynchrone: le registre partagé remplace la mémoire de la salle, qu'aucun fil de discussion ne tient.
• Engagement long avec rotation des personnes: le registre est la mémoire qui survit au départ de celui qui savait.
• Confiance dégradée avec le métier: un registre partagé rétablit la visibilité plus vite qu'un rapport d'avancement.
• Contexte audité ou réglementé: la trace de qui a soulevé quoi, qui a décidé et quand devient exigible.

Quand ne pas l'utiliser

• Préoccupation portant sur un événement futur et incertain: la traiter comme un risque (§10.38).
• Travail qui attend parce que la capacité manque: le placer dans le backlog (§10.2), qui ordonne par valeur.

Description

Ce que porte l'enregistrement d'un item

Le BABOK énumère quinze attributs et les introduit par une formule: chaque item enregistré peut porter tout ou partie de ces attributs. Un registre à quinze colonnes est un exercice de conformité pour la plupart des initiatives, et six colonnes tenues à jour valent mieux que quinze abandonnées au bout d'un mois. Le choix des colonnes se fait une fois, quand les règles du registre sont posées, en fonction de ce que l'initiative maintiendra.

Les attributs d'identification disent de quoi il s'agit et d'où cela vient. L'identifiant distingue un item de tous les autres et sert de référence dans les comptes rendus. Le résumé décrit l'item en une phrase, assez proche des mots de celui qui l'a soulevé pour qu'il s'y reconnaisse. La catégorie regroupe les items aux propriétés voisines. Le type est l'un de ceux que le BABOK nomme, et il commande le processus dans lequel l'item entre. La date d'identification et la mention identifié par ancrent l'item dans un moment et devant une personne. L'âge de l'item se calcule à partir de cette date.

Les attributs de qualification disent ce que l'item coûte s'il reste ouvert. L'impact énonce les conséquences possibles si l'item n'est pas résolu à son échéance, et le BABOK lui donne quatre axes: le délai, le coût, le périmètre, la qualité. Un impact s'exprime sur l'un de ces axes, avec une grandeur. La priorité est l'importance de l'item pour les parties prenantes affectées. C'est donc à elles de la fixer: l'analyste qui tient le registre la transcrit, et le résolveur, pour qui l'item est une corvée, avance dans l'ordre qu'elle fixe. L'échéance de résolution est la date à laquelle l'item doit être résolu ou clos.

Les attributs de responsabilité et de résolution disent qui fait quoi. Le propriétaire est la partie prenante chargée de mener l'item jusqu'à sa clôture; le résolveur est celle chargée de le résoudre. Le BABOK en fait deux attributs distincts, et cette distinction est la première que la pratique écrase. Le propriétaire relance, arbitre, escalade; le résolveur exécute. Les confondre produit des items appartenant à la personne qui a le moins d'autorité pour les faire avancer. La stratégie convenue énonce ce qui a été décidé, dans le vocabulaire dont le BABOK donne les exemples: accepter, poursuivre, ignorer, atténuer, éviter. Le BABOK laisse la liste ouverte. Un registre se trie et se compte mieux sur un vocabulaire fermé, et ces cinq valeurs suffisent à le fermer. Ignorer est une décision légitime, prise et consignée, et elle diffère d'un item qui cesse silencieusement d'avancer. Le statut situe l'item dans son cycle de vie. Le journal de résolution consigne l'avancement de la résolution et l'approbation de son achèvement. La matrice d'escalade définit enfin le niveau applicable si l'item n'est pas résolu à l'échéance: c'est un champ de l'enregistrement.

Le cycle de vie de l'item

Le BABOK donne les statuts à titre d'exemples: ouvert, assigné, résolu, annulé. La formulation est illustrative et l'organisation définit les siens; le BABOK pose en revanche une règle ferme dans son élément de gestion des items: chaque item est suivi jusqu'à sa résolution ou sa clôture. Un modèle à sept états en découle. Aux quatre statuts du BABOK il ajoute en cours, entre l'assignation et la résolution, parce que le travail engagé est une situation dans laquelle l'item demeure. Il sépare clos de résolu, parce que la clôture est un acte d'approbation distinct de la production d'une solution. Il sépare enfin rejeté d'annulé, là où le BABOK ne connaît qu'annulé: le rejet est un état lisible, distinct de l'annulation d'un item qui se périme, qui est retiré ou qui fusionne avec un autre. Quatre de ces sept états sont des étapes du traitement; trois terminent la vie de l'item: rejeté, annulé et clos.

Une préoccupation soulevée passe d'abord un examen de recevabilité, que le BABOK pose dès sa première expression. Le registre garde l'item rejeté: on le consigne comme rejeté et on ne le supprime pas, car celui qui l'a soulevé doit pouvoir voir ce qu'il est devenu. L'item recevable devient ouvert, puis assigné dès qu'il reçoit un propriétaire et un résolveur, en cours quand le travail commence, résolu quand une résolution est proposée et clos quand celui qui a soulevé la préoccupation ou la partie prenante affectée approuve cet achèvement. L'état annulé est terminal et reste accessible depuis les états ouvert, assigné et en cours.

L'escalade comme transition gardée

L'escalade se déclenche lorsque l'échéance de résolution passe et que l'item n'est pas résolu. Elle route l'item vers le niveau suivant de la matrice d'escalade et le ramène en cours, avec un nouveau décideur, une nouvelle échéance, un nouveau résolveur ou une décision d'annuler. L'item escaladé continue donc d'avancer.

Le vocabulaire standard de cette construction est celui des machines à états de l'UML (OMG, UML 2.5.1, clause 14): un état est une situation durant laquelle une condition invariante reste vraie, une transition fait passer l'exécution d'un état à un autre, un déclencheur l'amorce, une garde est une condition booléenne qui doit être vraie pour que la transition soit franchie et un effet est ce qui s'exécute au passage. L'escalade se lit ainsi: déclencheur, le passage de l'échéance; garde, [échéance dépassée ET statut différent de résolu]; effet, le changement de niveau de décision. Modéliser l'escalade comme un statut, en ajoutant un état « escaladé » où l'item séjournerait, est l'erreur intuitive: un item escaladé est toujours en cours de traitement, et le registre perd alors la distinction entre ce qu'un item est et ce qui vient de lui arriver.

L'analyste convient de la matrice d'escalade avec le sponsor avant l'ouverture du registre. La matrice nomme, pour chaque niveau, un déclencheur mesurable, l'instance qui décide et le mandat dont elle dispose. Le canal fait partie de la règle: un item critique se signale de vive voix ou par téléphone, un item de niveau courant passe par la revue périodique. Un déclencheur compté en jours ouvrables suppose un calendrier: en Suisse, il est cantonal, et le lundi du Jeûne fédéral n'est pas un jour ouvrable dans le canton de Vaud.

HERMES, la méthode de gestion de projet de la Confédération, loge cette transition dans une tâche unique. Traiter les problèmes et mettre à profit les expériences (5.4.3.29) pose que la personne responsable qui ne peut pas résoudre un problème, ou pas à temps, le transmet immédiatement aux responsables de l'organisation de projet. Le processus de règlement est fixé projet par projet dans le plan de gestion du projet. Les connaissances tirées de la résolution alimentent le résultat Expériences acquises (4.4.1.32), collecté sur toute la durée du projet. Là où le BABOK sépare le suivi des items des leçons apprises (§10.27), HERMES en fait les deux moitiés d'une même tâche.

Conduire la technique de la saisie à la clôture

1. Poser les règles avant d'ouvrir le registre
   Quels types d'items sont en usage, qui peut en soulever un, quels statuts existent, à quelle cadence la revue a lieu, quelle est la matrice d'escalade et où le registre vit. On saute cette étape, et la plupart des registres meurent au bout d'un mois. Elle se documente dans l'approche de business analyse ou dans le plan de gouvernance.
2. Saisir sur-le-champ
   Consigner la préoccupation dans l'atelier, l'entretien ou la revue: identifiant, résumé, date d'identification, identifié par.
3. Évaluer la recevabilité
   Rejeter ce qui est hors périmètre, fusionner ce qui est déjà consigné et consigner le rejet.
4. Classer
   Catégorie et type. Un défaut part vers le flux de correction de l'équipe de réalisation, une hypothèse part vers une activité de confirmation, une dépendance part vers celui qui tient l'autre bout.
5. Évaluer l'impact et fixer la priorité
   L'impact sur les quatre axes du BABOK, délai, coût, périmètre, qualité, avec une grandeur. La priorité auprès des parties prenantes affectées, selon le schéma de classement que l'initiative emploie déjà: la priorisation (§10.33) s'enclenche à cette étape. Fixer l'échéance de résolution.
6. Nommer un propriétaire et un résolveur
   Deux personnes désignées et un propriétaire dont le rang lui permet de relancer le résolveur.
7. Convenir de la stratégie
   Accepter, poursuivre, ignorer, atténuer, éviter. La stratégie est décidée avec la partie prenante affectée, puis consignée.
8. Suivre et revoir à cadence fixe
   Le journal de résolution consigne l'avancement au fil de l'eau. La revue passe le registre item par item, avec les parties prenantes, à intervalle convenu, et le registre reste partagé entre deux revues. Le BABOK prévient qu'un item peut en engendrer un autre et que les efforts de résolution ne doivent alors pas se dupliquer: la revue est le moment où cette coordination se fait.
9. Escalader ce qui stagne
   La matrice d'escalade se déclenche au passage de l'échéance. La route est définie d'avance, et elle mène à une instance qui peut décider.
10. Clore sur approbation
    Le BABOK place l'approbation de l'achèvement à l'intérieur du journal de résolution: la clôture est approuvée, normalement par celui qui a soulevé la préoccupation ou par la partie prenante affectée.

Les métriques du registre

Le registre produit des métriques, et le BABOK en fait un élément de la technique: elles disent si les items sont résolus par les bonnes ressources, si l'initiative progresse et si le processus de suivi est utilisé. Quatre ou cinq suffisent. Chacune se lit par rapport à un seuil, et un seuil franchi déclenche une action nommée: une métrique qui ne déclenche rien est un chiffre de rapport. L'âge se trie en premier à chaque revue; il se calcule à partir de la date d'identification. Une liasse d'indicateurs hebdomadaires coûte plus cher que les items qu'elle décrit.

Placer la technique parmi ses voisines

Le suivi des items est la technique générique, et deux techniques du BABOK la spécialisent chacune pour une nature d'item. L'analyse et la gestion des risques (§10.38) la spécialise pour les items qui sont des événements futurs et incertains. Elle garde le registre et lui ajoute une probabilité, un niveau de risque qui combine cette probabilité avec l'impact et un vocabulaire de traitement propre.

Les deux vocabulaires partagent un noyau: accepter, atténuer, éviter. Leurs écarts sont ceux qu'impose la nature de l'item. Le traitement du risque ajoute transférer et augmenter, qui n'ont de sens que devant un événement qui n'est pas encore survenu: on transfère une exposition à un assureur, on augmente une exposition pour saisir une opportunité. La stratégie convenue du suivi des items ajoute poursuivre et ignorer, qui n'ont de sens que devant une préoccupation déjà sur la table. Le passage de relais entre les deux registres suit la même logique: un risque qui se réalise cesse d'être un risque et devient un problème à gérer, c'est-à-dire un item. Le Teal Book du gouvernement britannique énonce la même bascule: un risque identifié demeure un risque résiduel, ou bien il survient et devient un issue.

La gestion du backlog (§10.2) spécialise la technique pour le travail qui attend parce que la capacité manque. Le BABOK le définit: un backlog apparaît quand le volume de travail à réaliser excède la capacité de le réaliser. Il ajoute donc un ordonnancement par la valeur et un mécanisme de tirage, où le sommet du backlog est ce qui sera fait ensuite. Un registre d'items priorise pour décider ce qui sera résolu en premier, là où un backlog, doté d'un modèle de capacité et d'un tirage, priorise pour décider ce qui sera construit ensuite. Un item qui se révèle être un morceau de produit part au backlog.

La priorisation (§10.33) fournit le schéma de classement que le champ priorité du registre utilise. Le suivi des items alimente en retour les leçons apprises (§10.27) à la clôture de l'initiative, avec les items qui se sont répétés et ceux qui ont dû être escaladés.

Reste à lever une confusion d'outil: le suivi des défauts de l'équipe de réalisation. Le défaut est l'un des sept types d'items du BABOK, donc un défaut peut être un item, mais l'outil de l'équipe est structuré par la version, l'environnement de test et le cas de test, et il est lu par des développeurs. Le registre du business analyst est structuré par la solution et par les exigences, et il est lu par les parties prenantes; faire passer les items du business analyst dans le schéma d'un outil de défauts force chaque préoccupation dans une forme de bogue.

La seconde confusion concerne le journal des problèmes du projet, tenu par la cheffe ou le chef de projet. Le glossaire de l'Association for Project Management définit un issue par le franchissement d'une tolérance déléguée, ce qui appelle le soutien du sponsor. Cette notion est plus étroite que l'item du BABOK, et elle cadre le journal du projet sur la livraison, ses délais, son budget et son périmètre. Le registre du business analyst est cadré sur les préoccupations des parties prenantes à propos des exigences et de la solution, et son critère de réussite est que la personne qui a soulevé la préoccupation la voie avancer. Là où un journal des problèmes existe déjà, on ouvre un type d'item ou une vue à l'intérieur de celui-ci et on y conserve les attributs du business analyst, à commencer par l'identification, le propriétaire, le résolveur et la stratégie convenue.

Sur les projets conduits sous HERMES, une voisine vient de la méthode: la Liste de l'état des modifications (résultat 4.4.1.3, Änderungsstatusliste), produite par la tâche Gérer les modifications (5.4.3.2). La méthode donne à l'item de type modification son propre document, requis au minimum au sens de HERMES, dans l'approche classique comme dans l'approche agile. En classique, chaque ligne porte le numéro de la demande de modification, le demandeur, la date de la demande, le responsable de la décision, l'état d'avancement, la date de la modification, le responsable de la modification, la charge de travail, les coûts et les conséquences; en agile, la liste documente au minimum l'identification de la demande, sa date, son état d'avancement et la date de la modification. Le registre d'items du business analyst renvoie donc à cette liste pour toute demande de modification.

HERMES tient de même les décisions dans deux résultats, un par niveau hiérarchique: la Liste Décisions de conduite (4.4.1.20) et la Liste Décisions de pilotage (4.4.1.21). Chacune documente les résultats des tâches décisionnelles de son niveau pendant toute la durée du projet, avec la décision, le jalon atteint ou non, les documents de base, les décideurs et la date. Le mandant décide au niveau du pilotage, le chef de projet au niveau de la conduite (§5.1.2.2 et §5.1.2.3).

Ce qui fait échouer le registre

Le registre que personne ne possède

Les items ont un propriétaire, le registre n'en a pas. Personne ne conduit la revue, personne ne relance les lignes qui vieillissent et le fichier n'est plus lu au bout de six semaines. Le registre a besoin d'un responsable, distinct des propriétaires d'items.

L'item sans propriétaire ou « l'équipe » comme propriétaire

Un item appartenant à tous n'appartient à personne. Le propriétaire du BABOK est une partie prenante, au singulier, et elle porte un nom.

L'item « ouvert » depuis un an

La matrice d'escalade absente est le défaut: une échéance sans conséquence attachée à son dépassement est un souhait. L'âge de l'item l'expose.

Le registre fantôme

Un registre d'items du business analyst tenu en parallèle de l'outil de suivi de l'équipe de réalisation ou du journal du projet. Deux registres font deux vérités, et les parties prenantes lisent celui que les développeurs n'alimentent pas.

Le suivi qui tient lieu de décision

L'item relu, rediscuté et repriorisé à chaque revue, jamais tranché. C'est le mode d'échec de la technique, et son mécanisme est que le registre fait ressembler l'indécision à du progrès: le journal de résolution se remplit, la revue paraît productive, la ligne paraît active. Le statut n'a pas bougé d'un cran. Un item vieillissant doté d'un journal de résolution fourni est donc le pire cas du registre. Le détecteur est déjà là, dans les métriques: l'âge, croisé avec un statut inchangé sur trois revues. Ce croisement appelle une décision, y compris la décision d'ignorer, consignée comme stratégie convenue.

L'enregistrement pléthorique

Le BABOK énonce la limite: le relevé abondant de données sur les items peut l'emporter sur les bénéfices, et les parties prenantes peuvent s'enliser dans les détails et les statistiques. La formule « tout ou partie » des quinze attributs permet d'en tenir six.

L'absence de tri de recevabilité

Tout ce qui est dit devient un item, le registre enfle et la priorité cesse de signifier quoi que ce soit puisque tout y figure.

L'impact écrit en adjectifs

« Élevé », sans échelle derrière. Un impact s'écrit sur un axe, avec une grandeur.

La clôture silencieuse

Clore un item auquel celui qui l'a soulevé tient encore ou effacer un item rejeté détruit la confiance que le registre a été ouvert pour construire. La clôture est approuvée, le rejet est consigné.

L'escalade modélisée comme un statut

Un état « escaladé » dans lequel l'item séjournerait mélange la situation de l'item et l'événement qui vient de lui arriver. L'escalade est une transition gardée: l'item escaladé reste en cours, et le niveau qui décide de lui change.

Considérations IA

Le suivi des items est une technique dont la moitié est cléricale. L'intelligence artificielle attaque cette moitié: l'IA rend l'enregistrement bon marché, et l'enregistrement bon marché est ce contre quoi le BABOK met en garde. Un registre passé à quatre cents items parce que la saisie est devenue gratuite est un registre que personne ne revoit. La seule question qui vaille devant un item est donc: quelqu'un agira-t-il?

La saisie à partir de la séance: un modèle de langage appliqué à la transcription d'un atelier propose, pour chaque préoccupation exprimée, un résumé, la date, l'auteur et un type. La rédaction d'après-atelier est le poste le plus coûteux de la technique: un travail de résumé, ce que ces modèles font bien. Le business analyst corrige, et celui qui a soulevé l'item confirme la formulation à la revue suivante. La classification dans les sept types du BABOK: un jeu d'étiquettes court et stable appliqué à un texte court, avec une erreur peu coûteuse puisque la revue corrige l'étiquette. La détection des doublons et des liens: la similarité sémantique retrouve, sur un registre de deux cents lignes, l'item déjà consigné avec d'autres mots, et une personne confirme le rapprochement avant que deux items n'en deviennent un seul. La détection de la stagnation: signaler les items dont le statut n'a pas bougé depuis un nombre de jours donné, dont l'échéance est passée ou dont le journal de résolution répète l'entrée précédente en d'autres termes. C'est la moitié mécanique de la matrice d'escalade. La rédaction de l'énoncé d'impact sur les quatre axes part de l'item et du plan de l'initiative; le propriétaire valide la proposition avant qu'elle n'entre au registre.

Désigner le propriétaire est un acte de responsabilité: un modèle peut proposer un nom à partir de la cartographie des parties prenantes, il ne peut rendre personne responsable. Un propriétaire attribué par un outil est un propriétaire qui n'a rien accepté. Fixer la priorité appartient aux parties prenantes affectées, et c'est une négociation entre des intérêts divergents: un modèle qui classe le registre par gravité inférée a substitué son jugement au leur et produit le classement que personne n'a approuvé. Convenir de la stratégie et clore l'item sont des décisions à portée politique, et la clôture n'est prononcée qu'une fois l'achèvement approuvé. Un item clos automatiquement parce qu'un modèle l'a jugé résolu est une clôture silencieuse, prononcée à l'échelle du registre entier.

La sensibilité des données est le point dur que le registre d'items apporte lui-même. Les résumés d'items nomment des personnes, consignent qui s'est plaint de qui et portent en clair les conflits de l'initiative. Verser un registre dans un modèle public revient à exporter la politique interne de l'organisation et des données personnelles avec elle. En Suisse, la nouvelle loi fédérale sur la protection des données (nLPD), en vigueur depuis le 1^er septembre 2023, s'applique: un registre d'items où figurent des noms est un traitement de données personnelles. La conséquence pratique: employer un modèle que l'organisation maîtrise ou retirer les noms avant le prompt.

Exemples

Une institution de prévoyance professionnelle (LPP) établie à Lausanne (NPA 1003), qui assure les salariés de quelque 120 employeurs affiliés, remplace son portail employeurs. Le registre porte les items soulevés au cours des deux premiers ateliers d'élicitation, tenus les 6 et 9 juillet 2026 avec la gestion des affiliations, l'exploitation, un groupe d'utilisateurs employeurs et la direction financière. Il est présenté tel qu'il se lit au 30.09.2026: à cette date, les statuts, les échéances et l'escalade se vérifient les uns par rapport aux autres.

Le registre tient douze des quinze attributs du BABOK. La catégorie et le journal de résolution vivent derrière chaque ligne, dans l'outil, et l'escalade vit dans sa propre matrice.

ITM-003 a été escaladé au niveau 3. À l'instantané du 30.09.2026, l'item est en cours: l'instance qui décide de lui a changé, passée du chef de projet au COPIL. Aucun état « escaladé » n'apparaît dans la colonne du statut.

Visualisations

Le registre, la matrice d'escalade et les métriques sont des objets à lignes et à colonnes, lus, triés et filtrés par des parties prenantes: douze attributs pour six items, quatre niveaux d'escalade, cinq métriques et leurs seuils. Ils se rendent en tableau.

Le cycle de vie de l'item est un objet spatial: sept états, des transitions dirigées, trois états terminaux, une garde posée sur une arête et une branche qui quitte l'état « en cours » et y revient. C'est une machine à états. Un tableau « statut courant, statut suivant » perdrait ce que la technique enseigne et qu'un tableur ne donne pas: la garde qui déclenche l'escalade et le retour de l'item en cours.

Le cycle de vie sert aussi au quotidien: posé à côté d'un registre réel, il en fait un instrument d'audit.

• Un item resté « ouvert » sans jamais passer à « assigné » n'a pas de propriétaire, et le registre l'a laissé passer.
• Un item dont le statut est « escaladé » révèle un modèle d'états mal posé, puisque l'escalade est une transition.
• Un item passé de « résolu » à « clos » sans trace d'approbation dans le journal de résolution a été clos par le responsable du registre: c'est la clôture silencieuse.

Coût

Outils

Le compte rendu avec tableau d'actions est la forme la plus économique: un identifiant, un résumé, un propriétaire, une échéance. Elle convient à un engagement court avec une poignée de parties prenantes, et elle vaut mieux qu'un registre en règle que personne ne maintient.

Le tableur fonctionne. Sa défaillance habituelle est la copie: cinq versions et un fil de courriels, là où un seul responsable et une seule copie partagée suffisent. Il offre en revanche le tri par âge en une formule, ce que la plupart des registres n'ont pas. Les pages et listes collaboratives (tableau Confluence, liste SharePoint, base Notion) corrigent ce défaut: partagées, versionnées, filtrables par statut et par propriétaire, sans installation. C'est le choix pragmatique quand l'équipe de réalisation n'a pas d'outil de suivi.

Les outils de suivi de tickets (Jira, Azure DevOps, GitLab, Redmine) donnent gratuitement ce que la technique demande de construire à la main ailleurs: le modèle d'états, l'attribution, le calcul de l'âge et l'escalade pilotée par une convention de service. Les sept types d'items du BABOK se traduisent directement en types de tickets. Ce choix s'impose là où l'équipe de réalisation travaille déjà, et il répond au piège du registre fantôme. Les plateformes de gestion des services et de conformité (ServiceNow et équivalents) se justifient lorsque la matrice d'escalade doit être appliquée par une convention de service plutôt que rappelée par une personne et lorsque les items franchissent des frontières d'organisation. Elles sont lourdes pour un registre à l'échelle d'une seule initiative.

Les outils de gestion des exigences dotés d'un objet item ou problème lié (Jama Connect, IBM DOORS Next, Polarion, Visure) offrent ce qu'un tableur ne donne pas: la traçabilité de l'item vers l'exigence qu'il menace, de sorte qu'une exigence bloquée apparaisse comme telle dans la matrice de traçabilité. Cela vaut son prix dans le travail réglementé, où l'auditeur demandera cette trace. Quel que soit l'outil, la règle ne change pas: un seul registre, partagé, dont une partie prenante peut lire le statut sans avoir à demander.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.26 Item Tracking: la source d'ancrage, l'objectif, les sept types d'items, les quinze attributs de l'enregistrement, les statuts donnés en exemples, la matrice d'escalade, la gestion des items, les métriques, les forces et les limites.
• UK Government Project Delivery Function, The Teal Book, chapitre 21: Issue management: la bascule du risque vers le problème (un risque qui survient devient un issue), les tolérances comme déclencheur d'escalade et la séquence identifier, évaluer, répondre, surveiller et rendre compte puis clore, avec un propriétaire nommé pour chaque issue.
• Association for Project Management, Glossary of project management terms: les définitions de issue, de issue log et de issue management par un organisme professionnel, fondées sur le franchissement d'une tolérance déléguée, plus étroites que l'item du BABOK.
• Object Management Group, Unified Modeling Language (UML) v2.5.1, clause 14 StateMachines et §13.3.4 pour le déclencheur: le vocabulaire normalisé des machines à états, état, transition, déclencheur, garde et effet, qui fonde la lecture de l'escalade comme transition gardée et la notation du cycle de vie.
• Confédération suisse, Chancellerie fédérale, HERMES 2022, Manuel de référence Gestion de projet, tâche 5.4.3.29 Traiter les problèmes et mettre à profit les expériences, résultat 4.4.1.32 Expériences acquises: la transmission immédiate du problème que la personne responsable ne peut pas résoudre ou pas à temps, le processus de règlement fixé dans le plan de gestion du projet et le recueil continu des enseignements comme unique résultat de la tâche.
• Confédération suisse, Chancellerie fédérale, HERMES 2022, Manuel de référence Gestion de projet, résultat 4.4.1.3 Liste de l'état des modifications, tâche 5.4.3.2 Gérer les modifications: le registre de suivi des demandes de modification, requis au minimum dans l'approche classique comme dans l'approche agile, avec le contenu exigé pour chacune des deux.
• Confédération suisse, Chancellerie fédérale, HERMES 2022, Manuel de référence Gestion de projet, résultat 4.4.1.20 Liste Décisions de conduite, résultat 4.4.1.21 Liste Décisions de pilotage: les deux registres de décisions, un par niveau hiérarchique, avec leur contenu (décision, jalon atteint ou non, documents de base, décideurs, date). Le manuel de référence répartit les niveaux au §5.1.2 Tâches décisionnelles: les décisions de pilotage sont celles du mandant, les décisions de conduite celles du chef de projet.