« C’est terminé, il reste seulement à faire valider. » Cette phrase paraît rassurante. Pourtant, la personne qui attend le résultat ne peut parfois ni ouvrir le fichier, ni retrouver la bonne version, ni s’en servir pour son travail. La production est avancée ; la livraison reste incomplète. Le tableau de suivi, lui, affiche déjà une case verte.
Pour sortir de ce décalage, choisissez un résultat précis et convenez de ce qui permettra de le déclarer terminé. Voici une méthode proposée par la rédaction pour les projets courants : une fiche de fin, des preuves simples et une décision explicite. Elle ne remplace ni les exigences d’un métier réglementé ni les conditions d’un contrat.
Décrivez l’usage attendu avant la liste des tâches
Un livrable est un résultat remis à quelqu’un : dossier, page web, support de formation, installation ou tableau de suivi. Commencez par écrire qui doit l’utiliser et pour faire quoi. « Préparer le dossier » décrit votre activité. « Permettre à la responsable de comparer les options avant sa réunion » décrit l’usage qui donnera un sens à sa livraison.
Cette distinction aide à choisir les contrôles utiles. Un dossier destiné à être consulté sur téléphone ne se vérifie pas uniquement sur le grand écran de son auteur. Une fiche destinée à un remplaçant doit contenir les informations qu’il peut effectivement retrouver. Le destinataire apporte donc une connaissance que la personne chargée de produire ne possède pas toujours.
Choisissez un seul résultat pour commencer. Si le projet reste trop vaste, notre guide pour choisir le projet du prochain mois traite l’arbitrage préalable. Ici, nous examinons la fin d’un travail déjà engagé, sans refaire sa sélection.
Donnez un sens commun au mot « terminé »
Le Scrum Guide de novembre 2020, signé Ken Schwaber et Jeff Sutherland, définit une condition commune de qualité pour considérer un résultat comme achevé dans ce cadre de travail. Un travail qui ne la satisfait pas n’entre pas dans le résultat utilisable. Ce repère provient d’un document ancien ; il ne s’agit pas d’une nouveauté annoncée cette semaine.
Vous pouvez vous inspirer de cette exigence de clarté dans un projet ordinaire, sans prétendre pratiquer Scrum. Énoncez vos règles communes : bonne version identifiée, contrôles nécessaires réalisés, accès du destinataire vérifié et informations d’utilisation disponibles. Adaptez-les au risque réel. Une présentation interne et une application de paiement ne réclament évidemment pas le même niveau de vérification.
Atlassian distingue, dans son guide consacré à la définition de terminé, ces exigences communes des conditions propres à une fonctionnalité. Pour votre fiche, gardez deux rubriques : « règles de qualité applicables à ce type de travail » et « attentes de cette livraison ». Cette séparation évite de reconstruire toutes les règles à chaque tâche tout en conservant la spécificité du besoin.
Remplacez les adjectifs par des observations
« Clair », « complet » et « professionnel » expriment des attentes légitimes, mais restent difficiles à vérifier seuls. Demandez ce que le destinataire devrait pouvoir observer. Pour un tableau, cela peut être retrouver la période couverte, comprendre l’unité utilisée et distinguer une donnée manquante d’une valeur nulle. Pour une page, le bouton attendu doit conduire au bon endroit.
Chaque condition devrait pouvoir être accompagnée d’un contrôle et d’une preuve proportionnée. La preuve peut être une référence de fichier, une note de relecture ou le résultat d’un essai. Elle n’exige pas systématiquement une capture d’écran. Un simple « vérifié » sans indication de version devient fragile lorsque le document change après la vérification.
Ne transformez pas cette démarche en recherche de perfection. Une préférence esthétique peut rester discutable même lorsque les conditions prévues sont satisfaites. À l’inverse, un accès impossible bloque l’usage malgré une belle présentation. Écrivez ce qui est indispensable, ce qui reste souhaitable et qui peut décider de reporter un élément secondaire.
Un exemple fictif : livrer un dossier de comparaison
Imaginons une association qui doit choisir un lieu pour un atelier. Toute cette situation est fictive. Samira prépare un dossier comparant plusieurs salles ; Hugo doit le présenter au comité. Lorsqu’il reçoit le fichier, il découvre que les dates de disponibilité ne sont pas indiquées. Samira avait terminé la mise en page, mais Hugo ne peut pas encore prendre la décision attendue.
Ils conviennent alors de conditions concrètes pour la prochaine version : chaque salle comporte la date de vérification des informations, les contraintes connues sont visibles et les informations non confirmées sont signalées. Le dossier sépare les éléments recueillis des appréciations de l’équipe. Les pièces utilisées restent accessibles aux personnes autorisées, sans diffuser de coordonnées personnelles inutiles.
Hugo examine la version prévue pour la réunion. Une salle n’a pas confirmé sa disponibilité. Le dossier peut néanmoins être accepté comme comparaison provisoire si cette limite correspond à l’usage convenu ; il ne peut pas être présenté comme une réservation finalisée. Le statut doit décrire le résultat réellement livré, avec la réserve qui compte pour la décision.
Préparez la vérification dans le calendrier
Si la relecture n’apparaît pas dans le plan, elle se retrouve facilement coincée entre la fin de production et une échéance déjà promise. Identifiez qui peut examiner le résultat, les informations dont cette personne aura besoin et sa disponibilité. Vérifiez aussi qui remplace cette personne en cas d’absence. Un nom inscrit sans accord ne garantit aucune capacité.
Précisez la version à examiner et l’endroit où déposer les remarques. Évitez plusieurs fichiers joints portant presque le même nom. Un lien vers le support de référence, accompagné de sa version et de son état, rend l’échange plus simple. Si les accès doivent être accordés avant la revue, préparez-les avant d’annoncer que le résultat attend seulement un feu vert.
Une absence de réponse ne vaut pas automatiquement acceptation. Conservez « en attente de vérification » et signalez l’effet sur l’étape suivante. Pour une prestation soumise à une procédure contractuelle, appliquez les dispositions pertinentes avec les personnes compétentes. Cette méthode éditoriale ne fixe pas de règle juridique d’acceptation tacite.
Traitez les remarques sans rouvrir tout le projet
Lors de la revue, reliez chaque remarque à une condition convenue. Une erreur de formule demande une correction. Une nouvelle demande de graphique peut constituer un ajout. Une information attendue mais jamais définie révèle une ambiguïté à résoudre ensemble. La distinction évite de qualifier toute remarque de caprice ou, à l’inverse, d’absorber chaque idée dans la livraison initiale.
Lorsque la demande élargit le travail, notre dossier pour arbitrer les ajouts au projet explique comment examiner ses conséquences. Conservez la condition initiale, la remarque reçue et la décision retenue. Le contrôle de fin reste ainsi lié à une référence compréhensible, même si cette référence évolue avec un accord explicite.
Après correction, vérifiez ce qui a changé et les éléments directement touchés. Une modification de tableau peut affecter ses totaux ; une modification de lien peut affecter un parcours. Choisissez les contrôles selon cette conséquence, plutôt que de refaire mécaniquement toute la revue ou de considérer chaque correction comme sans effet sur le reste.
Gardez trois états faciles à comprendre
Pour ce circuit simple, vous pouvez utiliser « en production », « à vérifier » et « accepté pour l’usage convenu ». Ce sont des états proposés, pas une nomenclature universelle. Ajoutez un blocage visible lorsqu’une information, un accès ou une décision manque. Le blocage doit préciser la prochaine action et la personne concernée.
Le passage au dernier état demande une trace : version examinée, conditions contrôlées, décision et réserves éventuelles. Une réserve ne doit pas dissimuler un défaut indispensable à l’usage. Si le résultat ne peut pas servir, gardez-le à corriger ou définissez une livraison plus limitée avec l’accord du destinataire. Évitez une case verte accompagnée d’une note que personne ne lit.
Lorsque quelqu’un reprend ensuite le dossier, notre guide de passation avant une absence complète cette trace. Il traite la continuité du travail ; la fiche de fin établit ce qui a déjà été accepté. Les deux supports se rejoignent sans remplacer leurs objectifs respectifs.
Essayez la fiche sur votre prochaine livraison
Prenez un résultat attendu cette semaine et écrivez cinq éléments : destinataire, usage, conditions, manière de vérifier et décision de fin. Faites relire cette fiche par la personne qui utilisera le résultat. Si elle ne peut pas dire comment elle le contrôlera, reformulez une condition avant de poursuivre la production.
Après la livraison, examinez ce qui a manqué ou demandé une clarification. Modifiez uniquement la règle qui répond à ce problème. Une longue liste copiée d’un autre métier peut créer des contrôles sans intérêt. Une fiche courte, comprise et appliquée apporte une référence commune ; elle ne garantit ni l’absence de défauts ni le respect automatique du calendrier.
Repère éditorial : guide durable fondé sur le Scrum Guide 2020 et une documentation Atlassian consultée le 3 octobre 2026. La fiche, les états et l’association sont des propositions pédagogiques originales. Aucun outil payant ni livre n’est nécessaire pour cet essai ; un document partagé existant suffit.
Relier cette méthode à votre organisation
Pour compléter ce dossier : Compétences IA : 40 questions pour faire le point et obtenir un certificat ; Vous repoussez toujours la même tâche ? Préparez une réponse à l’obstacle. Ces guides abordent des décisions complémentaires, du choix d’une prochaine action aux conditions de sa réalisation.
