Mesurer les flux de valeur dans la livraison de logiciels avec le Schéma de système de valeur

Texte intégral

1 Introduction

Les équipes logicielles sont mesurées de près : la vélocité, le débit, le délai de livraison, la fréquence de déploiement et le taux d'échec des changements sont collectés automatiquement. Pourtant, ces chiffres laissent une question ouverte : quelle valeur l'équipe a-t-elle livrée, à qui, et à quel coût en pertes ?

Cet article propose une méthode pour répondre à cette question avec le Schéma de système de valeur (Value System Schema, VSS), la notation de modélisation de la méthodologie Æilus, telle qu'elle est mise en œuvre dans le VSS Editor publié sur aeilus.tech. Il s'agit du cinquième article de la série "Æilus for Business". Il utilise le vocabulaire défini dans le premier article de la série, "Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners" (Bolshakov, ÆVRI, 2026), et ne répète pas ces définitions. Le traitement formel de la valeur comme monnaie mesurable (Æ) est présenté dans "Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective" (Bolshakov, ÆVRI, 2026).

L'article décrit comment une organisation de livraison peut construire un schéma de son système de valeur, associer la valeur planifiée et la valeur réalisée aux versions, localiser la résistance du flux et les fuites, évaluer les nœuds techniques partagés, et faire fonctionner le cycle avec des rôles et un rythme clairs. Il s'appuie sur les axiomes A1, A2, A4, A5, A6, A7, A11 et A13 de la VMT et sur les théorèmes T3, T4, T5, T6, T8, T9, T15, T16 et T17. Il ne contient aucune donnée mesurée. L'exemple détaillé de la section 9 est synthétique.

2 Ce que les métriques de livraison mesurent et ce qu'elles ne mesurent pas

Les métriques de livraison décrivent le mouvement du travail. La vélocité compte l'effort estimé achevé ; le débit compte les éléments terminés. Les quatre métriques clés popularisées par Forsgren, Humble et Kim (Accelerate, 2018), à savoir la fréquence de déploiement, le délai de mise en œuvre des changements, le temps de rétablissement du service et le taux d'échec des changements, décrivent la rapidité et la stabilité du pipeline de livraison. Cette recherche relie ces capacités à la performance organisationnelle, et le présent article ne la conteste pas. Son affirmation est plus étroite : ces métriques décrivent le pipeline, et non la valeur qui le traverse.

Trois lacunes en découlent.

• L'effort n'est pas la valeur. Un sprint à forte vélocité peut livrer des fonctionnalités que personne n'utilise. Dans le langage du support Product Value System, "les fonctionnalités ne sont pas la valeur" et "les métriques ne sont pas la valeur" : une fonctionnalité est une hypothèse sur la valeur, et une métrique en est une interprétation.
• La vitesse n'est pas la direction. Un délai de livraison court livre plus vite une hypothèse erronée.
• La stabilité n'est pas l'absence d'antivaleur. Un faible taux d'échec des changements ne dit rien des retards, de la confusion, des reprises côté utilisateur ni de la perte de confiance causée par un changement qui a fonctionné exactement comme prévu.

Du point de vue de la Théorie de la gestion de la valeur (Value Management Theory, VMT), la lacune est structurelle. La valeur n'existe qu'au sein d'un système de valeur défini et est interprétée par ses acteurs (A1, A2). Elle est réalisée au moment de la consommation (A6), et la valeur planifiée et la valeur réalisée diffèrent généralement (A4, T3). Les métriques du pipeline sont collectées avant la consommation, du côté de l'émetteur ; elles décrivent donc tout au plus la livraison de la valeur planifiée. Lorsque ces métriques deviennent des objectifs, l'effet décrit par Goodhart (1975) apparaît : les équipes optimisent le compteur. La VMT énonce le même risque en termes systémiques : l'optimisation locale ne garantit pas l'amélioration globale (T5).

3 La notation du Schéma de système de valeur

3.1 Éléments de la notation

Dans la méthodologie Æilus, le Schéma de système de valeur est le premier artefact central : une description formelle du système de valeur, de ses acteurs, de ses flux, de ses transformateurs et de ses échanges clés, utilisée pour établir les frontières du système et empêcher les dépendances externes invisibles. Un VSS peut être dessiné au niveau des transformateurs ou au niveau du système.

Le VSS Editor, publié sur aeilus.tech en décembre 2025, est un éditeur visuel en ligne, fonctionnant dans le navigateur, destiné à ces schémas. Sa notation comporte un petit nombre d'éléments.

• Convertisseurs. Un convertisseur est le nom donné dans Æilus à un rôle de transformateur dans un schéma : un bloc fonctionnel, tel qu'une équipe, un service ou un sous-système, qui reçoit des éléments de valeur, les transforme et en produit de nouveaux. Les convertisseurs sont les lieux où la valeur est créée, amplifiée ou détruite.
• Flux. Un flux est une connexion orientée entre des convertisseurs, ou entre un convertisseur et le monde extérieur. Il transporte une quantité de valeur ou d'antivaleur en Æ. Un flux est externe entrant (valeur entrant dans le système), externe sortant (valeur quittant le système) ou interne (valeur entre convertisseurs).
• Entrées et sorties. Les flux externes entrants et sortants marquent les points où la valeur entre et sort. Ensemble, ils définissent la frontière du système.
• Éléments de valeur. Les types d'éléments décrivent ce qui circule exactement dans un flux : valeur client, revenus, coûts, risques, dette technique et éléments similaires. Dans un schéma enregistré, chaque élément a une nature (valeur ou antivaleur), un signe, une quantité et une unité (Æ).
• Antivaleur. L'antivaleur représente les pertes et les effets négatifs : retards, reprises, défauts, bureaucratie, risque, épuisement professionnel, efforts gaspillés. Dans le schéma, c'est un élément explicite de signe négatif, et non l'absence de valeur (A5).

3.2 Le schéma comme modèle lisible par machine

L'éditeur enregistre un schéma sous forme de JSON structuré comportant des nœuds (convertisseurs), des flux et des éléments. Le schéma peut donc être versionné avec le produit, puis lu par des outils d'analyse qui comparent les quantités planifiées et réalisées pour chaque flux. Ces analyses sont annoncées comme un travail futur et ne sont pas supposées ici.

3.3 Ce que le schéma n'est pas

Le VSS Editor n'est explicitement ni un tableau de bord d'indicateurs clés, ni un outil de BI, ni un moteur de simulation, ni un substitut à la comptabilité financière. Il place la clarté avant le calcul. L'ordre de modélisation recommandé suit : définir la frontière, ajouter uniquement les convertisseurs principaux, les relier par des flux nommés (les noms avant les chiffres, la direction avant la précision), puis marquer l'antivaleur, l'étape qui produit souvent le plus d'enseignements.

4 La valeur de qui : le système et sa frontière

Une mesure de valeur n'a aucun sens tant qu'elle n'indique pas de la valeur de qui il s'agit (A1, T1). La frontière choisie modifie aussi les conclusions sans aucun changement de la réalité (T15). Cet article fixe donc le système de valeur avant toute mesure.

Le système de valeur modélisé ici est le système de valeur du produit d'un seul produit logiciel au sein d'une organisation produit. Selon le support Product Value System, ses acteurs sont la fonction produit, l'équipe de développement, les opérations, le produit en production, les utilisateurs et l'entreprise en tant que destinataire de la valeur retournée par les utilisateurs. La finance est un flux entrant externe habilitant (salaires).

Deux interprétations réalisées sont mesurées : la valeur pour les utilisateurs, interprétée par les utilisateurs ou par leur comportement observable, et la valeur pour l'entreprise, interprétée par l'entreprise en tant que destinataire du flux de retour (revenus, rétention, réduction des coûts ou des risques). La valeur planifiée est l'interprétation de l'émetteur avant la version. La valeur de la même version pour un partenaire ou un régulateur est hors de la frontière, sauf extension explicite.

5 De l'hypothèse produit à la valeur réalisée : la boucle de valeur

Le support Product Value System présente le travail produit comme une boucle dans laquelle les hypothèses de valeur sont créées, mises en œuvre, validées et maintenues. En termes de schéma, la boucle comporte les convertisseurs et les flux suivants.

1. Investissement vers la fonction produit. La fonction produit convertit les ressources et les signaux des utilisateurs en hypothèses porteuses de valeur planifiée.
2. De la fonction produit au développement. Les hypothèses deviennent des éléments de backlog avec une valeur planifiée. Le support énonce deux attentes : la valeur planifiée d'une hypothèse ne doit pas diminuer pendant sa construction, et la valeur livrée ne doit pas beaucoup différer de la valeur planifiée.
3. Du développement aux opérations. Le développement consomme de l'effort et produit des changements fonctionnels, ainsi que de l'antivaleur (dette technique, défauts, retards).
4. Des opérations à la production. Les changements deviennent un logiciel en exécution ; les erreurs de version et les interruptions de service apparaissent comme de l'antivaleur.
5. De la production aux utilisateurs. La valeur n'est réalisée qu'à l'usage (A6) ; c'est donc le premier point où la valeur réalisée peut être observée.
6. Des utilisateurs à l'entreprise. Les utilisateurs retournent des revenus, de la rétention et de la confiance. Le message de l'auteur sur sa chaîne en janvier 2022 appelle cela un flux fermé : la valeur livrée au client est équilibrée par la valeur qui revient, souvent mais pas uniquement sous forme d'argent.

La boucle rend concret l'axiome de transformation (A7) : chaque convertisseur réalise ce qu'il reçoit et produit une nouvelle valeur planifiée pour le suivant. Elle montre aussi pourquoi les métriques du pipeline ne couvrent que les étapes 3 et 4. Les étapes 1, 2, 5 et 6, où la valeur est planifiée, réalisée et retournée, se situent en dehors du pipeline.

Le support présente également des types d'éléments observables pour les produits internes et externes. Les éléments de valeur comprennent le temps gagné, la diminution des erreurs opérationnelles, les flux de trésorerie, la réduction des risques, une charge cognitive plus faible, la prévisibilité, de nouvelles capacités et la confiance. Les contreparties en antivaleur comprennent le temps perdu, la reprise de travail, la hausse des coûts d'exploitation, la dette technique, l'imprévisibilité, les contournements manuels, la perte de confiance et la dégradation du service client. Cette typologie constitue le point de départ d'un Registre des éléments de valeur pour la livraison.

6 Valeur planifiée et valeur réalisée par version, résistance et fuite

6.1 La version comme unité de comparaison

L'unité de comparaison est la version (release), ou l'élément du backlog lorsque les versions sont petites. Pour chacune, la méthode enregistre dans Æ :

• la valeur planifiée : l'estimation de l'émetteur, enregistrée avant le début du développement et mise à jour uniquement par une décision explicite et consignée ;
• la valeur réalisée et l'antivaleur réalisée : l'interprétation du récepteur après que la version a été utilisée pendant une période d'observation convenue ;
• la valeur rétrospective : une réévaluation ultérieure, une fois que les effets de second ordre (charge du support, attrition, dette technique) sont devenus visibles.

Le support propose une introduction par étapes : d'abord la valeur planifiée sur chaque élément du backlog, puis la valeur réalisée et l'antivaleur sur chaque élément livré, puis la valeur rétrospective. Sans valeur planifiée, il n'y a pas d'écart à mesurer ; sans valeur réalisée, le plan reste une hypothèse.

6.2 La résistance du flux dans la livraison

La résistance du flux (flow resistance) est l'écart entre la valeur planifiée et la valeur réalisée, auquel s'ajoute l'antivaleur qui apparaît dans un flux. La VMT considère qu'un écart non nul est normal (T3), mais soutient que la résistance s'accumule historiquement (T4) et réduit la capacité à réaliser de la valeur future (T6). Dans la livraison, la valeur se perd lors de l'implémentation (périmètre réduit, hypothèse mal comprise), lors de la mise en production (défauts, retours en arrière), lors de l'adoption (les utilisateurs ne trouvent pas ou n'utilisent pas le changement) et à cause des retards. Conformément au concept de coût du retard (Reinertsen, 2009), le retard est modélisé comme une antivaleur sur le flux en retard, et non comme une métrique distincte.

Si chaque flux porte ses propres quantités planifiées et observées, le schéma montre dans quel convertisseur la perte s'est produite. Tel est l'objet du Registre de résistance des flux et du Rapport d'écart entre valeur planifiée et valeur réalisée dans l'ensemble d'artefacts d'Æilus.

6.3 La fuite

La fuite (leakage) est un excédent durable de valeur réalisée quittant le système par rapport à la valeur qui y entre (A11). Dans un système de valeur de produit, deux formes sont courantes. Dans la première, les utilisateurs en tirent profit, mais le flux de retour ne couvre pas le flux entrant habilitant. Dans la seconde, l'équipe consomme de l'investissement pendant que des hypothèses sont élaborées sans jamais être réalisées. Le débit peut sembler sain dans les deux cas ; le schéma met en évidence les deux, car les flux entrants et sortants se situent sur une même frontière.

7 Nœuds partagés : évaluation sur l'ensemble des flux

Certains convertisseurs d'un système logiciel ne produisent aucune valeur qu'un utilisateur nommerait, et pourtant chaque flux de valeur passe par eux. Le message de l'auteur sur sa chaîne de septembre 2025 et l'article associé d'aeilus.tech prennent l'autorisation comme exemple : elle ne génère aucune valeur par elle-même, mais sans elle chaque scénario s'arrête. Une passerelle d'API ou un pipeline d'intégration continue (CI) est du même type.

Évalué isolément, un tel nœud montre un coût et aucune production, et incite à réduire les coûts. Dans le schéma, il apparaît sur de nombreux flux à la fois, et son efficacité ne devient claire qu'à travers la valeur agrégée de tous les flux qu'il soutient. La méthode attribue donc à un nœud partagé :

• l'ensemble des flux qui le traversent, lu dans le schéma ;
• l'antivaleur qu'il ajoute à chacun de ces flux (latence, pannes, échecs de connexion, défauts d'intégration) ;
• sa valeur consommée (effort de l'équipe, infrastructure).

Son efficacité est la valeur délivrée moins l'antivaleur sur l'ensemble de ses flux, rapportée à la valeur consommée, conformément à la définition de l'efficacité des processus du même article. Une dégradation d'un nœud partagé n'est jamais un incident local ; c'est une résistance ajoutée à chaque flux qu'il dessert. Le théorème T8 ajoute un argument de durabilité : la stabilité est perdue lorsqu'un rôle de transformation ne peut plus être assuré, et la redondance du rôle accroît la stabilité.

8 Ce que gagne un chef d'équipe

Le message de l'auteur sur sa chaîne de février 2022 énumère ce que l'approche apporte à une équipe et à son responsable. Reformulé dans les termes du présent article :

• La valeur délivrée comme retour d'information. Pour toute période, l'équipe voit la valeur qu'elle a délivrée, en Æ, confirmée par les destinataires, au lieu du signal indirect de la vélocité.
• Une mesure d'efficacité indépendante de la méthodologie de processus. Quelle que soit la pratique, la mesure est la valeur réalisée par valeur consommée, et les pratiques sont retenues ou abandonnées selon leur effet sur celle-ci (P7).
• La transparence pour l'entreprise. Le travail technique devient explicable à travers les flux qu'il soutient.
• Une priorité du backlog fondée sur la valeur. La priorité peut être déduite de la valeur planifiée, de son niveau de confiance et de son coût du retard, plutôt que de la partie prenante la plus bruyante.
• Le coût du retard et les erreurs en production comme antivaleur. L'entreprise peut montrer comment la valeur diminue lorsqu'un changement est tardif ou défectueux, et l'équipe voit comment l'utilité de son travail dépend du calendrier et de la qualité de la production.
• Des arguments pour les ressources partagées. Lorsque les administrateurs et les ingénieurs DevOps sont partagés, la priorité fondée sur la valeur explique pourquoi le travail d'une équipe a été reporté au profit de celui d'une autre, dans les deux sens.

Ces gains ne tiennent que si la valeur réalisée est validée par ses destinataires. Si l'équipe estime et confirme elle-même sa propre valeur, la mesure devient un compteur auto-déclaré de plus, et T17 s'applique : les interprétations issues de sources influentes qui ne sont pas confirmées par la réalisation accumulent de l'antivaleur.

9 Un schéma élaboré d'un produit synthétique

Cette section décrit un produit synthétique, à titre d'illustration. Il ne s'agit pas d'une étude de cas, elle ne décrit aucune organisation réelle et ne contient aucun chiffre mesuré.

Le produit synthétique est une application web par abonnement grâce à laquelle de petites entreprises de services acceptent les réservations de leurs clients. Son système de valeur suit la frontière définie à la section 4. Deux nœuds partagés, un service d'autorisation et une passerelle d'API, desservent tous les flux orientés utilisateur. La finance fournit le flux entrant habilitant. L'entreprise reçoit les revenus d'abonnement et la fidélisation comme flux de retour.

Le schéma est construit dans l'éditeur VSS (VSS Editor) en quatre passes : la frontière avec un flux entrant externe (investissement et salaires) et les flux sortants externes vers les utilisateurs ; sept convertisseurs ; des flux nommés d'après les éléments de valeur qu'ils portent ; et les éléments d'antivaleur. Les quantités restent vides jusqu'à la première session d'estimation.

Considérons une version hypothétique : une fonctionnalité de rappel destinée à réduire les rendez-vous manqués. Avant le développement, le product owner consigne la valeur planifiée par élément (temps gagné, moins de réservations manquées, effet attendu sur la rétention). Après une période d'observation convenue, l'analytique produit et un échantillon d'utilisateurs métier fournissent la valeur réalisée, et l'équipe consigne l'antivaleur réalisée : une livraison tardive, un défaut qui a envoyé des rappels en double, une charge supplémentaire sur la passerelle d'API. La différence constitue la résistance de cette version. Le défaut et la charge de la passerelle se situent aussi sur des flux qui servent d'autres scénarios, ils sont donc également affectés aux nœuds partagés. Un trimestre plus tard, la valeur rétrospective indique si la rétention a changé ou non. Dans une application réelle, les grandeurs proviendraient des sessions décrites ci-après.

10 Comment la mettre en œuvre

10.1 Qui estime et qui valide

La règle d'Æilus issue de l'article de 2025 est brève : la valeur de sortie d'un processus doit être évaluée par celui qui la consomme, et quelqu'un d'autre doit vérifier cette évaluation. Appliquée à la livraison, elle donne une répartition claire.

• La valeur planifiée est estimée par l'émetteur. Pour les hypothèses, il s'agit du product owner, agissant en tant que Responsable du transformateur de valeur (Value Transformer Owner, VTO) du convertisseur produit. Pour le convertisseur de développement, il s'agit du chef d'équipe en tant que VTO.
• La valeur réalisée est interprétée par le récepteur : les utilisateurs, observés au moyen de l'analytique produit ou web, et l'entreprise pour le flux de retour. La présentation propose, à titre provisoire, que l'analytique produit représente le côté utilisateur jusqu'à ce qu'une validation directe soit établie.
• La validation de l'interprétation est effectuée par une seconde partie : le Responsable du système de valeur (Value System Owner, VSO), qui est responsable de la pérennité au niveau du système, ou un Responsable de flux pour un flux critique.
• L'intégrité méthodologique est assurée par un Æilus Master (dans la présentation, un champion d'Æilus tenu par un chef de projet), qui prépare les rapports de livraison de valeur, de plan par rapport au réel et de résistance des flux.

10.2 Cadence

Æilus ne prescrit pas de calendrier. Une cadence minimale pour une équipe de livraison, conforme aux événements recommandés par la méthodologie, est la suivante.

• À chaque affinage du backlog : la valeur planifiée est attribuée aux nouveaux éléments, à l'aide du registre des éléments.
• À chaque version, après la période d'observation : la valeur et l'antivaleur réalisées sont consignées et validées ; une brève rétrospective de la valeur examine l'écart.
• Chaque mois ou chaque trimestre : une Revue de la résistance des flux sur le schéma, nœuds partagés compris ; la valeur rétrospective des éléments livrés précédemment.
• Chaque trimestre ou lors d'un changement structurel : une Revue du système de valeur portant sur les frontières, les convertisseurs et les dépendances, avec le fichier du schéma mis à jour et versionné.

10.3 Discipline

Chaque artefact requiert un responsable, une boucle de mise à jour et un objectif décisionnel ; sinon il crée de l'antivaleur par son coût de maintenance et par une fausse confiance. Pour cette méthode, les objectifs décisionnels sont la priorité du backlog, l'allocation des ressources partagées, le calendrier des versions et l'investissement dans les nœuds partagés. L'augmentation de la valeur planifiée n'est admissible que si la capacité de l'équipe à la réaliser est confirmée (P9). Accroître la valeur planifiée plus vite que la valeur réalisée est le mode de défaillance décrit par T16.

11 Limites et ce que nécessiterait une étude empirique

Cet article est conceptuel et n'a pas été testé sur des données mesurées. Plusieurs limites en découlent.

• Qualité de l'estimation. Les valeurs dans Æ sont des interprétations dont la fiabilité dépend des estimateurs et de leur calibrage.
• Commensurabilité partielle. Le temps gagné, le revenu et la confiance ne sont que partiellement commensurables (A13). Les exprimer dans une même monnaie exige une Politique d'agrégation de la valeur, que cet article suppose mais ne définit pas.
• Attribution. La valeur réalisée résulte souvent de plusieurs versions et de facteurs externes ; le schéma montre la structure mais ne peut pas isoler la contribution d'une seule version.
• Flux cachés. Si le schéma ne peut pas expliquer la stabilité ou le déclin observés du système, il existe des flux latents ou la frontière est erronée (T9). Un schéma est une hypothèse sur la structure et doit être révisé.
• Coût de la méthode. Des sessions qui ne produisent aucune décision font de la méthode elle-même de l'antivaleur.

Une étude empirique exigerait, au minimum : plusieurs équipes de livraison appliquant la méthode pendant une période assez longue pour consigner la valeur rétrospective ; un registre d'éléments stable et une politique d'agrégation convenus avant la collecte des données ; une validation indépendante de la valeur réalisée par les destinataires plutôt que par les équipes ; une collecte parallèle des métriques de livraison conventionnelles, afin d'examiner la relation entre ces métriques et la valeur réalisée ; et une comparaison des décisions prises avec et sans le schéma. Seule une telle étude pourrait montrer si la priorisation fondée sur la valeur modifie la valeur livrée, et dans quelles conditions.

12 Conclusion

Les métriques de livraison décrivent comment le travail circule dans un pipeline, et non ce qu'il a changé pour ses destinataires ; sous la VMT, elles ne le peuvent pas, car la valeur est contextuelle, réalisée uniquement à l'usage, et la valeur planifiée et la valeur réalisée divergent. Le Schéma de système de valeur, tel qu'implémenté dans le VSS Editor, permet aux équipes logicielles de dessiner la boucle de valeur du produit depuis l'hypothèse jusqu'à la valeur réalisée, puis de retour vers l'entreprise. Consigner la valeur planifiée, réalisée et rétrospective pour chaque version transforme la boucle en mesure : la résistance et la fuite deviennent visibles, les nœuds partagés sont évalués sur chacun des flux qu'ils servent, et les chefs d'équipe obtiennent la valeur livrée, la priorité fondée sur la valeur et le coût du retard et des erreurs comme retour d'information. La méthode ne reste honnête que si la frontière du système est énoncée, si les destinataires valident la valeur réalisée et si chaque artefact sert une décision. Savoir si elle améliore en pratique la valeur livrée est une question empirique que cet article formule sans y répondre.

Références

• Bolshakov, V. Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective. ÆVRI, 2026.
• Bolshakov, V. Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners. ÆVRI, 2026.
• Bolshakov, V. Value Management Theory (VMT), version 1.4. 2026.
• Bolshakov, V. Value Management Methodology Æilus, v2.0. 2026.
• Bolshakov, V. VMT, Æilus v2.0 and the Product Value System (presentation). 2026.
• Bolshakov, V. New Tool Released: Value System Schema Editor (VSS Editor). aeilus.tech, 2025.
• Bolshakov, V. Assessing the Value of Processes: Efficiency, Risks, and Anti-Value. aeilus.tech, 2025.
• Bolshakov, V. Artifacts and Reports. Æilus methodology, aeilus.tech/methodology/artifacts-and-reports/. 2026.
• Bolshakov, V. Æilus channel posts on value flows, team leadership and the VSS Editor (in Russian). 2022-2025.
• Forsgren, N., Humble, J., Kim, G. Accelerate: The Science of Lean Software and DevOps. 2018.
• Goodhart, C. Problems of Monetary Management: The U.K. Experience. 1975.
• Reinertsen, D. The Principles of Product Development Flow. 2009.