Du centre de coûts au convertisseur de valeur : la conversion de l'antivaleur dans le support technique

Texte intégral

1 Introduction

Dans la plupart des organisations produit, le support technique est comptabilisé comme un centre de coûts. Son budget est visible, sa production se mesure en tickets clos, et la question habituelle est de savoir comment le rendre moins cher. Cet article soutient que cette présentation est incomplète, et que ce qu'elle omet est la part du support qui compte le plus pour le produit.

L'argument emploie le vocabulaire de la Théorie de la gestion de la valeur (VMT) et de la méthodologie Æilus. La valeur (value), l'antivaleur, le flux de valeur, le système de valeur, le transformateur de valeur ainsi que la valeur planifiée, réalisée et rétrospective sont utilisés tels que définis dans le premier article de cette série. Le traitement formel de Æ, la monnaie de valeur, est donné dans Bolshakov (2026) et n'est pas repris ici.

La source principale est l'article d'Æilus "Technical Support Service - Anti-Value Conversion" (Bolshakov, 2025). Il décrit le support comme une chaîne de transformateurs de valeur qui reçoivent l'antivaleur du client et la convertissent en valeur, avec des coefficients qui croissent à chaque ligne, et il propose deux coefficients à mesurer à chaque étape. Le présent article reformule le modèle, rend les coefficients opérationnels, précise de quelle valeur ils sont la mesure et propose un protocole de mesure. Il ne contient aucune donnée de terrain ; tous les chiffres de l'exemple détaillé sont illustratifs.

L'article s'appuie sur les axiomes A1 (contextualité), A2 (interprétations multiples), A4 (asymétrie du plan et du fait), A5 (indépendance de l'antivaleur), A6 (réalisation à la consommation), A7 (transformation), A12 (non-conservation de la valeur) et A13 (commensurabilité partielle) de la VMT, ainsi que sur les théorèmes T2 (inversion du flux), T4 (accumulation de la résistance), T5 (optimisation locale), T9 (flux cachés), T14 (la valeur non interprétée est perdue), T15 (dépendance aux frontières) et T16 (mise à l'échelle par interprétation sans réalisation).

2 Pourquoi le support est traité comme un centre de coûts, et ce que cela dissimule

2.1 La vision par les coûts est un choix de frontière

La vision du centre de coûts résulte du tracé de la frontière du système de valeur autour des flux financiers de l'entreprise. À l'intérieur de cette frontière, le support consomme des salaires et des outils et ne produit aucune ligne de revenu. Selon A1, la valeur n'existe qu'à l'intérieur d'un système de valeur, et selon T15, changer la frontière change la conclusion sans changer la réalité. La vision par les coûts est une lecture correcte d'un système de valeur, et non une description de ce que fait le support.

T2 énonce qu'un même flux peut porter des interprétations opposées dans des systèmes différents. Une interaction de support comptabilisée comme un coût par l'entreprise est, pour le client, la suppression d'une antivaleur : une défaillance qui cesse de nuire, une question qui cesse de bloquer le travail. La source énumère dix types de valeur client que le support apporte, de la réduction de l'antivaleur des incidents et du gain de temps à la réduction des risques et à la confiance. Aucun n'apparaît dans un rapport de coûts.

2.2 Ce que la vision par les coûts dissimule

• Valeur côté client. Le support rétablit le flux de valeur du client. S'il cesse de le faire, la condition de participation du client (A8) est menacée, et T7 prédit que le client part ou change la forme de sa participation.
• Valeur interne. La source nomme trois flux internes : l'information sur les incidents, les demandes de fonctionnalités que possèdent les concurrents et les suggestions originales des clients. Selon T9, une structure entretenue par des flux que le modèle ne montre pas est mal modélisée ou mal délimitée. Un modèle de coûts du support est un tel modèle.
• Conversion. La source affirme que le support convertit l'antivaleur en valeur, et que le résultat peut dépasser l'antivaleur initiale de plusieurs ordres de grandeur lorsqu'un problème atteint les lignes plus profondes et le produit. A12 le permet : une cause racine corrigée supprime l'antivaleur pour chaque client, et pas seulement pour celui qui l'a signalée.

3 Le support comme point d'entrée du flux d'antivaleur

Tout produit apporte à la fois de la valeur et de l'antivaleur. Selon A5, l'antivaleur est une catégorie indépendante : un client peut recevoir une valeur réelle d'un produit et, la même semaine, une antivaleur réelle d'une panne. Le support est l'endroit où la plus grande part de cette antivaleur entre dans l'entreprise sous forme de flux observable. Cet article la regroupe en quatre types, conformément à la description de la prise en charge de première ligne dans la source :

• Incidents. Quelque chose fonctionnait et a cessé de fonctionner.
• Défauts. Quelque chose n'a jamais fonctionné comme prévu ; l'antivaleur devient visible lorsqu'un client la rencontre.
• Confusion. Le produit fonctionne, mais le client ne parvient pas à en tirer de la valeur.
• Attentes déçues. La valeur planifiée et la valeur réalisée diffèrent. A4 énonce que c'est normal ; le support est l'endroit où cet écart est signalé.

Une cinquième entrée est la valeur potentielle : demandes et suggestions. La source la traite séparément et décrit son volume comme non limité. Elle partage le même canal, de sorte que la mesure doit la distinguer de l'antivaleur pour éviter de mélanger deux dénominateurs.

Le point d'entrée importe en raison de T4 : la résistance s'accumule. L'antivaleur laissée dans une file d'attente se compose en perte de confiance et, selon T6, en capacité réduite de réaliser la valeur future. La dynamique des files d'attente dans le développement de produit est bien décrite (Reinertsen, 2009) ; la lecture VMT ajoute que ce qui attend dans une file de support est de l'antivaleur qui s'accumule dans le système de valeur du client.

4 La chaîne de conversion

Selon A7, la transformation signifie qu'un acteur réalise une valeur entrante, ou ici absorbe une antivaleur entrante, et produit une nouvelle valeur planifiée. La source traite chaque ligne de support comme un tel transformateur, chacun avec son propre Responsable du transformateur de valeur (VTO).

4.1 Première ligne

La source attribue à la première ligne la prise en charge du flux d'antivaleur sous forme de tickets structurés, l'amortissement rapide de l'antivaleur dès le premier contact, le maintien du flux de valeur continu, l'acheminement, la collecte de données, la gestion des attentes du client et l'évaluation de la profondeur de l'antivaleur. Son rôle est celui d'un filtre, d'un amortisseur et d'un accélérateur. Elle rétablit surtout l'état antérieur du client, ce qui explique pourquoi la source lui attribue le coefficient le plus faible. La gestion des attentes mérite d'être notée : les mises à jour de statut ne corrigent rien, mais elles réduisent l'antivaleur de l'incertitude, cas direct de A5.

4.2 Deuxième ligne

La deuxième ligne prend en charge l'antivaleur complexe : bogues difficiles, intégrations, performance. Le changement clé de la source consiste à passer de la suppression d'un problème à l'élimination de sa cause racine, et d'un client à tous les clients, puisque les correctifs et les instructions mises à jour se propagent dans toute la base de clients. La deuxième ligne construit aussi la base de connaissances qui augmente la capacité de la première ligne, alimente le backlog avec les incidents récurrents et réduit l'antivaleur cachée telle que la dette technique.

4.3 Troisième ligne

La source qualifie la troisième ligne de transformateur de niveau stratégique travaillant sur l'antivaleur enracinée dans l'architecture, le code, les protocoles et la logique centrale. Ses sorties sont des modifications de la fonctionnalité et de l'architecture, ainsi que de nouveaux transformateurs : outils, scripts, supervision et contrôles automatisés qui continuent à convertir l'antivaleur. Elle fixe aussi les règles des lignes inférieures, y compris la manière dont la valeur et l'antivaleur sont mesurées dans les cas complexes. La source note que le gain est difficile à quantifier tant que les changements n'ont pas atteint le client, ce qui est A6 en termes opérationnels.

4.4 Product Owner

La source place l'équipe Product Owner comme transformateur suivant et comme synthétiseur de valeur. Elle priorise le flux issu de toutes les lignes, l'aligne sur la stratégie, évalue où la valeur client est la plus élevée pour la plus faible antivaleur en coût, en délai et en risque, et ajoute la valeur potentielle issue des besoins du marché. La sortie est un plan de livraison qui met à l'échelle la valeur existante et crée de la valeur nouvelle. La source relie cela au PDCA : Plan à partir des données du support, Do par les équipes de livraison, Check sur les incidents et les métriques de valeur, Act sur la stratégie et le produit. Le produit mis à jour apporte alors de nouveau de la valeur, le support capte le flux suivant et la boucle se referme.

5 Les coefficients proposés dans la source

5.1 Coefficients nominaux par ligne

Le résumé de la boucle fermée dans la source énonce que l'antivaleur captée en première ligne peut être transformée en valeur avec un coefficient de x1 à x1.5 ; en deuxième ligne, x10 ; en troisième ligne, x100. Les suggestions des clients passent à la deuxième et à la troisième ligne avec un volume décrit comme non limité, et la valeur que le Product Owner restitue au client est décrite comme potentiellement quasi illimitée. Le schéma : plus le problème est grand, plus la ligne qu'il atteint est haute, et plus la ligne est haute, plus le coefficient est élevé. La source les propose comme des ordres de grandeur, et non comme des mesures. Le présent article les traite comme des hypothèses.

5.2 VAM et ACM

La source conclut que deux paramètres doivent être mesurés à chaque étape :

• Value Amplification Multiplier (VAM), le coefficient de transfert de valeur : "Quelle quantité de valeur a été reçue et livrée au Client".
• Anti-Value Conversion Multiplier (ACM), le coefficient de conversion d'antivaleur en valeur : quelle quantité d'antivaleur a été reçue et quelle part en a été transformée en valeur pour le Client.

La source énonce ces coefficients en mots et ne donne aucune formule. La lecture minimale en termes de ratio proposée ici, pour une étape s (première ligne, deuxième ligne, troisième ligne, Product Owner) sur une période d'évaluation, est la suivante :

VAM_s = V_delivered,s / V_received,s

ACM_s = V_converted,s / AV_received,s

V_received,s est la valeur entrant dans l'étape (suggestions ou valeur potentielle partiellement transformée) ; V_delivered,s est la valeur client réalisée attribuable à la production de l'étape ; AV_received,s est l'antivaleur entrant dans l'étape ; V_converted,s est la valeur client réalisée qui en est issue. Tous les termes sont exprimés en Æ.

Deux lectures découlent de la formulation de la source. Les numérateurs sont de la valeur pour le client, de sorte que les plans, les tickets et les éléments de backlog ne comptent qu'une fois réalisés par le client (A6). Et les deux coefficients ont des dénominateurs différents : l'un suit l'amplification de la valeur, l'autre la conversion de l'antivaleur. Un coefficient au niveau de la chaîne est ACM_chain = sum of V_converted,s / AV_received,1, avec l'antivaleur à l'entrée comme dénominateur et chaque unité de valeur réalisée attribuée à une seule étape.

6 Quelle valeur est mesurée

Selon A1 et A2, un coefficient sans système de valeur nommé n'a aucun sens. La chaîne touche quatre systèmes de valeur :

Cet article fixe la mesure comme suit. Les numérateurs de VAM et d'ACM sont mesurés dans le système de valeur du client, car la valeur réalisée est l'interprétation du récepteur. Les dénominateurs sont mesurés à la frontière client-support : l'antivaleur telle que le client la vit et la signale, enregistrée par la première ligne. Les systèmes de support et de produit utilisent les coefficients ; le système de l'entreprise les met en balance avec le coût. Le VSO est responsable de la politique d'agrégation permettant de comparer ces lectures, qui ne sont que partiellement commensurables (A13). Si le support se mesurait depuis son propre système de valeur, il rendrait compte de l'effort et de la valeur planifiée. Les définitions de la source sont tournées vers l'extérieur, et le protocole les y maintient.

7 Un protocole de mesure

Le protocole ci-dessous est une proposition, non testée sur le terrain, conçue pour fonctionner avec les outils existants de gestion de tickets et de backlog.

7.1 Données à consigner

• À l'entrée : le client et l'usage du produit ; le type d'entrée (incident, défaut, confusion, attente déçue, suggestion) ; une estimation de l'antivaleur en Æ sur une échelle partagée, confirmée avec le client lorsque c'est possible ; les domaines concernés.
• À chaque transmission : l'étape destinataire et le motif ; le type de résolution (état rétabli, corrigé pour ce client, cause racine supprimée, nouveau transformateur créé, élément de backlog créé) ; les liens entre tickets, éléments de backlog et versions ; la valeur planifiée des changements proposés, tenue séparée de la valeur réalisée.
• Après la livraison : la valeur réalisée en Æ confirmée par le client ou par un indicateur de substitution convenu ; le nombre de clients touchés ; une réévaluation rétrospective ultérieure.

7.2 Qui valide la valeur réalisée

Le transformateur qui revendique le mérite ne valide pas lui-même sa valeur réalisée. Le client l'interprète, par une confirmation explicite ou par des indicateurs de substitution convenus à l'avance (l'incident ne se reproduit pas, la fonctionnalité est utilisée). Le VTO de chaque ligne propose des estimations et est responsable de la qualité du journal. Le VTO du produit confirme quels changements livrés sont rattachés à quelles entrées du support. Le VSO tranche les litiges d'attribution. La valeur planifiée est enregistrée mais n'entre jamais dans un numérateur, conformément à A4 et T16 : mettre à l'échelle une revendication de valeur par la seule interprétation est structurellement instable. Le x100 de la troisième ligne dans la source est une telle revendication tant que le changement n'a pas atteint les clients.

7.3 Cadence de revue

• Par ticket, à la clôture : estimation à l'entrée, type de résolution, valeur réalisée de la première ligne.
• Par ligne, sur un cycle régulier court : ACM et VAM pour les éléments terminés, âge de l'antivaleur ouverte dans les files d'attente (T4), motifs d'escalade.
• Par système, sur un cycle plus long : le VSO et le VTO du produit examinent les changements livrés, les réévaluations rétrospectives, le flux total d'antivaleur entrant, et si les coefficients par ligne suivent l'ordre prédit par la source.

Comme la réalisation est différée, les coefficients doivent être rapportés par cohorte (cohort), c'est-à-dire par période au cours de laquelle l'antivaleur a été reçue.

7.4 Pièges

Goodhart (1975) a observé qu'une régularité statistique tend à s'effondrer dès qu'elle est utilisée à des fins de contrôle. En termes de VMT, c'est T5 : l'optimisation locale ne garantit pas l'amélioration globale.

• Manipulation du nombre de tickets. Scinder un problème en plusieurs tickets gonfle le débit. VAM et ACM sont des ratios en Æ, non des comptages, mais le nombre de tickets ne devrait pas être fixé comme objectif à côté d'eux.
• Dégonflage de l'entrée. Sous-estimer l'antivaleur augmente l'ACM. Les estimations à l'entrée exigent une échelle partagée et une confirmation client par échantillonnage.
• Sur-escalade. Si les lignes supérieures affichent des coefficients plus élevés, l'escalade devient tentante. Elle doit être jugée à l'aune des règles d'escalade fixées par la troisième ligne.
• Double comptage. La même valeur réalisée peut être revendiquée par plusieurs étapes. Chaque unité est attribuée une seule fois.
• Dissimulation du flux entrant. Le meilleur résultat est qu'il parvienne moins d'antivaleur au support, ce que l'ACM ne peut pas voir. Le flux total entrant doit être rapporté à côté des coefficients, et une baisse lue comme un résultat.
• Perte de signaux. Selon T14, la valeur sans interprétation est perdue. Le journal devrait montrer combien de suggestions et de schémas ont abouti à une décision produit.

8 Relation avec les domaines de service

La méthodologie Æilus définit un domaine comme un contexte d'interprétation de la valeur qui impose des exigences aux pratiques et aux résultats admissibles. Les domaines ne créent pas de valeur ; ils préviennent l'antivaleur non admissible. Le support touche plusieurs domaines typiques :

• Disponibilité et Continuité. Un incident constitue une violation de ce contexte pour le client. L'obligation de la première ligne de maintenir un flux de valeur continu en est le versant opérationnel, et le routage devrait suivre la politique du domaine en matière de criticité.
• Sécurité. La méthodologie note que la valeur peut être rejetée parce qu'elle viole le contexte requis pour une participation sûre. Un contournement qui affaiblit la sécurité est consigné comme une nouvelle antivaleur, et non comme une conversion.
• Architecture. La source exige que les décisions de la troisième ligne soient vérifiées quant à l'intégrité architecturale, l'évolutivité, la performance et la sécurité.
• Gestion des connaissances et Amélioration continue. La base de connaissances de la deuxième ligne et la boucle PDCA sont des pratiques de ces domaines.

Deux conséquences en découlent. La valeur réalisée comptée dans l'ACM doit être admissible dans chaque domaine pertinent. Et l'ACM agrège de la valeur à travers des domaines partiellement commensurables (A13), il lui faut donc la politique d'agrégation explicite que la méthodologie confie au VSO, les politiques de domaine étant détenues par les Domain Owners. Sans elle, avertit la méthodologie, l'optimisation dégénère en préférence locale ou en manipulation des métriques.

9 Exemple illustratif détaillé

Cet exemple est hypothétique. Le produit, les clients et les chiffres sont inventés et volontairement arrondis. Ce ne sont pas des résultats et ils ne mettent pas à l'épreuve les coefficients de la source.

Un produit présente une défaillance récurrente dans une intégration d'import de données. Au cours d'une période, dix clients la signalent.

• Réception. L'antivaleur de chaque client est estimée à 10 Æ, donc AV_received,1 = 100 Æ.
• Première ligne. Une solution de contournement connue et des mises à jour de statut rétablissent le travail ; les clients confirment 120 Æ de valeur réalisée. ACM_1 = 120 / 100 = 1.2, dans la plage nominale de la source.
• Deuxième ligne. Une cause racine de configuration est trouvée ; une valeur par défaut corrigée et un article de base de connaissances parviennent aux clients ayant signalé le problème et à d'autres. Valeur réalisée confirmée : 400 Æ. ACM_2 = 400 / 100 = 4, en dessous du x10 nominal. Dans le protocole, c'est un résultat à examiner, et non une erreur à corriger.
• Troisième ligne et produit. Le protocole d'import s'avère fragile ; une refonte et un contrôle automatisé sont inscrits dans la feuille de route avec une valeur planifiée de 5 000 Æ. Rien n'a été livré, donc ACM_3 = 0 pour cette cohorte. Les 5 000 Æ sont enregistrés et exclus.
• Suggestions. Deux clients demandent des imports planifiés. Il s'agit de valeur potentielle sur la piste VAM, qui n'entre pas dans l'ACM.

Lors de cette revue, ACM_chain = (120 + 400 + 0) / 100 = 5.2. Si la refonte est livrée par la suite et que les clients confirment la valeur, la cohorte de la troisième ligne est mise à jour rétrospectivement ; si elle provoque une régression, cette antivaleur est imputée à la troisième ligne. L'exemple révèle ce qu'un pilote doit observer : l'écart entre plan et réalité à l'étape la plus profonde (A4, A6), le décalage de réalisation et l'éventuelle divergence par rapport aux coefficients nominaux.

10 Limites

Il n'existe ici aucune donnée de terrain, pas plus que dans la source. Les coefficients x1 à x1.5, x10 et x100 sont des ordres de grandeur proposés, plausibles au regard du mécanisme décrit (un correctif étendu à de nombreux clients, de nouveaux convertisseurs créés) mais non mesurés. Les formules sont la lecture que fait cet article de définitions verbales ; d'autres lectures sont possibles. Les estimations en Æ dépendent de l'interprétation, qui est, selon A2, une propriété de la valeur, mais la comparaison entre équipes exige tout de même une échelle commune calibrée que cet article ne fournit pas. L'attribution entre les étapes est assignée au VSO sans règle.

Un pilote capable de confirmer ou d'affaiblir le modèle devrait montrer :

• que différentes personnes produisent des estimations en Æ cohérentes pour les mêmes tickets ;
• que l'ACM des cohortes sur plusieurs cycles de revue suit l'ordre prévu par ligne, quelles que soient les valeurs absolues ;
• que la valeur réalisée a été confirmée par les clients ou par des substituts convenus, et non par les lignes qui la revendiquent ;
• que l'usage des coefficients a été suivi d'une baisse du flux total d'antivaleur entrant, sans les manipulations énumérées à la section 7.4 ;
• que les coefficients apportent une information supplémentaire par rapport aux mesures conventionnelles telles que le délai de rétablissement du service (Forsgren, Humble et Kim, 2018).

11 Conclusion

Ne considérer le support que comme un centre de coûts est un choix de frontière. Dans le système financier de l'entreprise, le support est un coût ; dans le système du client, il est la suppression de l'antivaleur ; dans le système du produit, il est l'information la plus directe sur les points où le produit échoue. Le modèle source décrit une chaîne de convertisseurs dont l'effet de levier croît de la première ligne à la troisième ligne et jusqu'à l'équipe du Product Owner, bouclant une boucle PDCA vers le client, et propose VAM et ACM pour la mesurer. Cet article a donné aux coefficients des formules minimales, a ancré leurs numérateurs dans le système de valeur du client, n'a compté que la valeur réalisée et admissible dans le domaine, et a proposé un protocole d'enregistrement, de validation, de revue et de protection contre les manipulations. Savoir si les ordres de grandeur de la source se vérifient est une question à laquelle seul un pilote peut répondre.

Références

• Bolshakov, V. Technical Support Service - Anti-Value Conversion. aeilus.tech, 2025.
• Bolshakov, V. Domains and Policies. Æilus methodology, aeilus.tech, 2026.
• Bolshakov, V. Roles. Æilus methodology, aeilus.tech, 2026.
• 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.
• Forsgren, N., Humble, J. and Kim, G. Accelerate: The Science of Lean Software and DevOps. 2018.
• Goodhart, C. A. E. Problems of Monetary Management: The U.K. Experience. 1975.
• Reinertsen, D. G. The Principles of Product Development Flow. 2009.