Yaravan — le design de services d’une opération d’après-vente que personne n’avait décrite

01Contexte

Une identité en sommeil, une opération non documentée

Yaravan est la marque de garantie et d’après-vente d’un distributeur iranien de téléphones mobiles. Une agence extérieure a rédigé son identité de marque en 2024, puis rien n’a été construit dessus. À partir de juillet 2026, il s’agissait d’en faire un service qui fonctionne : un site public, un espace client et un espace collaborateurs — et, en dessous, l’opération qui devrait tenir les promesses de la marque.

Le système de support existant conserve la file de tickets et l’opération de réparation. Pour les processus que possède Yaravan, la relation s’inverse : Yaravan fait référence pour l’opération, et le système de support enregistre le processus au lieu de le piloter. Cette étude de cas porte sur cette opération ; le produit bâti dessus fait l’objet d’une étude de cas à part entière.

02Problème

Le design de l’état souhaité, pas le relevé de l’état actuel

L’opération n’avait jamais été consignée par écrit. Les exigences comme la spécification fonctionnelle citaient deux documents sources — un document d’exigences d’après-vente et un rapport sur les processus CRM — comme origine des vrais processus de ticketing, de réparation et de garantie. Aucun des deux n’existait dans le moindre dépôt.

Chaque carte de processus devait donc être le design de l’état souhaité, et non le relevé de l’état existant, et l’ensemble des processus porte cet avertissement en première page. Entre-temps, les promesses publiques de la marque avaient déjà dépassé l’opération : le travail sur les exigences a montré que les promesses phares de l’ancien site ne correspondaient pas à la réalité opérationnelle, et qu’aucune véritable base de données de garanties n’existait.

D’où la question de design posée à l’opération : comment dessiner un processus que personne ne peut encore confirmer, sans l’inventer ?

03Mon rôle

Mener le travail, avec l’équipe du client

J’ai mené le design de services — l’audit de préparation, l’architecture des processus, le modèle des rôles et l’économie de la garantie. La responsabilité métier est restée au client : son responsable métier portait les décisions commerciales, et son responsable après-vente portait l’opération de support et relisait les cartes.

Responsable

Exigences et périmètre
L’audit de préparation des intrants
Architecture des processus, de la carte macro à l’instruction de travail
Rôles, responsabilités et matrice RACI
Économie de la garantie

Coresponsable

Le développement de la plateforme dont les cartes sont tirées, avec l’équipe d’ingénierie du client

Collaboration

Les décisions commerciales (le responsable métier)
L’opération de support et ses notes de revue (le responsable après-vente)

Le fichier a été construit avec l’aide de l’IA : les corrections issues des revues ont été appliquées par un agent passant par l’intégration Figma, et consignées fil par fil. Les règles de dessin et les niveaux de preuve auxquels il devait obéir avaient été rédigés en premier.

04Approche

Des jalons, pas des livrables

Chaque étape se terminait par un jalon plutôt que par un document. Les exigences sont issues de cinquante questions directes à choix multiples posées au responsable métier, d’un examen de la marque et des documents sources, et d’un benchmark de neuf concurrents, avec un seul critère de réussite : l’ingénierie peut démarrer sans avoir à reposer la moindre question fondamentale.

Puis un audit de préparation a été mené — et a échoué. Sur 59 sources et 31 processus, il a rendu NOT_READY, avec 12 points bloquants, 4 conflits non résolus et des rôles répartis dans trois taxonomies incohérentes. Le second tour n’a pas contesté le verdict : il a réduit le périmètre aux 13 processus que la marque possède réellement, et un amendement ultérieur l’a élargi à 22, en ajoutant la réception, le diagnostic, la réparation, la livraison de retour et les pièces.

Réduire le périmètre a fait passer la préparation structurelle de 49 % à 78 % et la confiance dans les preuves de 58 % à 92 % — parce que les processus restés dans le périmètre pouvaient être lus dans du code exécutable et des tests qui passent.

« NOT_READY ne doit être remplacé par aucun pourcentage positif ni par aucun récit optimiste. »
— L’audit de préparation des intrants, premier tour · Une règle inscrite dans l’audit avant son exécution

Six jalons, dans l’ordre

01
ExigencesCinquante questions au responsable métier ; neuf concurrents comparés
02
Audit de préparationNOT_READY : 12 points bloquants, 4 conflits, des rôles répartis dans trois taxonomies

05Recherche

Dessiner les règles avant les diagrammes

Le fichier Figma ne contient aucun écran : l’interface a été spécifiée par écrit, et l’effort de design s’est porté sur la partie que personne ne savait décrire — l’opération. Sa première page n’est pas une couverture mais une page de règles : une bibliothèque de composants en quatorze parties et six règles maison. Le flux se lit de droite à gauche, comme la langue. Les blancs sont marqués « à déterminer », jamais remplis par un nom ou un chiffre deviné. Les conflits sont consignés, pas résolus. La couleur ne porte jamais seule un sens ; elle va toujours avec une forme et une icône.

Une règle détermine la forme de tout le fichier : ce qui peut être dessiné dépend des preuves qui l’étayent, affirmation par affirmation. Cinq niveaux de preuve vont du code exécutable, qui autorise un diagramme en couloirs complet, à l’absence totale de source, pour laquelle le dessin est interdit et seul un avis peut apparaître. Plus le niveau est bas, moins on peut dessiner.

Le fichier est donc honnête sur ses absences. Là où un niveau s’arrête court, un panneau d’avis nomme ce qui manque et pourquoi, et les avis de la carte des services et des diagrammes en couloirs bouclent leur propre calcul pour retomber sur 22. Un diagramme d’une séquence non documentée serait la même invention que les règles interdisent — seulement plus convaincante.

Yaravan — la section des règles du guide de design, en persan : six règles maison, l’amendement de périmètre et les cinq niveaux de preuve — Figure 02Les règles de la page 00 : six règles maison, l’amendement qui a élargi le périmètre à 22 processus, et les cinq niveaux de preuve qui décident de ce qui peut être dessiné. Les lignes qui nomment le distributeur ou le système de support sont retirées.

Yaravan — la bibliothèque de composants des diagrammes : sept formes de flux, une pastille de statut à quatre états, des en-têtes de couloir, un fil d’Ariane et des cartes de processus

06Six niveaux

Un processus, suivi jusqu’au dernier niveau

L’architecture compte six niveaux, et chacun répond à une question différente. L’activation de la garantie par le client fait partie des rares processus dessinés à chacun d’eux ; elle montre donc toute la pile. Sur la carte macro, c’est une carte avec un responsable, un livrable et un statut. Au niveau 1, elle devient une carte de bout en bout : déclencheur, responsable, événements de début et de fin, quatre phases, les points de décision, ce qu’elle reçoit et ce qu’elle transmet, les contrôles que le code applique — et un KPI et un SLA marqués « à déterminer », parce qu’aucune source ne contient de formule ni de délai approuvés.

Le niveau 2 est un blueprint de service : les actions du client, les points de contact, et ce que font le personnel et les systèmes de part et d’autre des lignes d’interaction, de visibilité et d’interaction interne, jusqu’aux enregistrements et aux contrôles que laisse chaque étape. Ici, il montre que l’étiquette imprimée dont part le client est un point de contact que le système ne contrôle pas — l’impression se fait en dehors de lui. Le fichier dessine aussi ce point de contact : une carte de garantie imprimable, recto et verso, en dix variantes. Le niveau 3 transforme la même séquence en diagramme en couloirs, avec un couloir par acteur.

Les niveaux 4 et 5 s’adressent aux personnes qui l’exécutent. La procédure couvre quatre processus à la fois — procédures et processus ne se correspondent pas un à un — et porte le tampon « non approuvé », avec son approbateur et sa date de revue laissés « à déterminer ». L’instruction de travail, ce sont les sept étapes du client lui-même, avec une liste de contrôle rédigée pour lui : l’alphabet des codes ne contient ni zéro, ni O, ni un, ni I, ni L, si bien que rien sur l’étiquette imprimée ne peut être mal lu.

Chaque niveau a le droit de s’arrêter. Seuls quatorze des 22 processus ont un diagramme en couloirs, et seuls six ont un blueprint ; les autres ont un avis qui dit pourquoi, et les avis bouclent leur propre décompte pour retomber sur 22.

Yaravan — le recto de la carte de garantie imprimable, en persan : modèle de l’appareil, code de garantie, date d’expiration, un champ de contact vide et un QR code flouté — Figure 04Là où commence l’activation : le recto de la carte de garantie imprimable de la page 11, l’une des dix variantes. L’entité juridique, l’adresse et le téléphone sont retirés, et le QR code est flouté.

Yaravan — la carte de bout en bout de l’activation de la garantie par le client, en persan : déclencheur, responsable, phases, points de décision, entrées et sorties, contrôles, et un KPI et un SLA marqués « à déterminer » — Figure 05Niveau 1 — l’activation de la garantie par le client de bout en bout : déclencheur et responsable, quatre phases qui s’enchaînent de droite à gauche, les points de décision, et un KPI et un SLA qu’aucune source ne définit encore.

Yaravan — le blueprint de service de l’activation de la garantie par le client, en persan : quatre étapes à travers les couches, des actions du client jusqu’aux preuves, séparées par les lignes d’interaction, de visibilité et d’interaction interne — Figure 06Niveau 2 — le blueprint de service : quatre étapes, de la lecture de l’étiquette à une garantie active, à travers les lignes d’interaction, de visibilité et d’interaction interne.

Yaravan — le diagramme en couloirs de l’activation de la garantie par le client, en persan : couloirs client, système et SMS, une décision et deux états finaux — Figure 07Niveau 3 — le diagramme en couloirs : le client, le système et la passerelle SMS sur trois couloirs, avec l’unique décision qui envoie un code déjà utilisé vers le rejet.

Yaravan — la fiche d’identité de la procédure des codes d’activation, en persan : version 0.3 en brouillon, approbateur et date de revue à déterminer, et le statut « non approuvé »

Yaravan — l’instruction de travail pour activer un code de garantie, en persan : identité, prérequis, le chemin dans l’espace client et sept étapes numérotées

07Ce que les cartes ont révélé

Une carte autorisée à revenir incomplète est un instrument de recherche

Dessiner l’opération a produit des constats qu’aucun document ne contenait. Sur les quatorze processus dessinés en couloirs, deux seulement envoient un SMS — le code de connexion et l’activation de la garantie —, si bien que les brouillons des textes de messages sont allés exactement dans ces deux cartes. Quatre processus de la carte macro n’ont pas de carte, parce que les sources citées pour eux n’existent pas.

Là où un niveau ne peut pas être dessiné honnêtement, un avis prend sa place. Six instructions de travail ne peuvent pas encore être rédigées, chacune pour une raison nommée : pas de mécanisme de réinitialisation, pas de procédure pour les litiges de propriété, pas de format de numéro de facture, un conflit ouvert, pas de norme pour les photos, pas de politique pour les biens non réclamés. La procédure de qualité des réparations n’a reçu aucun numéro d’instruction de travail — en réserver un pour une procédure dont l’exécutant n’est pas encore déterminé serait déjà une affirmation.

Le fichier s’audite aussi lui-même. Une matrice de couverture met chacun des 22 processus en regard de sa source, des niveaux existants et de ce qui manque : six complets, six incomplets, un en conflit, neuf à déterminer. Elle rouvre trois lacunes qui avaient été marquées comme closes — clos ne veut pas dire résolu par l’organisation — et retire ses propres citations là où une source s’est révélée ne pas dire ce pour quoi elle avait été citée.

Yaravan — trois panneaux d’avis en persan, tirés des pages de la carte des services, des diagrammes en couloirs et des instructions de travail, chacun énumérant ce qui n’est pas dessiné et pourquoi — Figure 09Des absences, dessinées : les avis des pages de la carte des services, des diagrammes en couloirs et des instructions de travail, chacun nommant ce qui manque et pourquoi. Les lignes qui nomment le distributeur sont retirées.

Yaravan — la matrice de couverture en persan : un tableau de 22 lignes qui met les processus en regard de leurs sources, de leurs niveaux et de leurs lacunes, avec le décompte des statuts en dessous — Figure 10Page 08 : la matrice de couverture — chacun des 22 processus mis en regard de sa source, des niveaux existants et de ce qui manque, avec le décompte des statuts en dessous. Les cellules qui nomment des personnes, le système de support ou une faiblesse du code sont retirées.

08Rôles

La redevabilité est un fait organisationnel, pas technique

Huit fiches de rôle exposent, pour chaque rôle, sa finalité, ses tâches, ses droits exclusifs, ses exclusions délibérées et ses lacunes, avec le KPI et le SLA marqués « à déterminer » sur chaque fiche. Certaines fiches sont surtout des questions. Un rôle existe dans le code et dispose d’accès, mais aucun document métier, organigramme ou procédure ne le définit ; son couloir est donc dessiné en pointillés jusqu’à ce que l’entreprise décide s’il est réel ou s’il n’est qu’un autre nom d’un rôle existant.

La matrice des responsabilités ne pouvait être dérivée qu’aux trois quarts. Réalisation, consultation et information sont sorties du code ; l’approbation (le A de RACI) ne le pouvait pas, car le code dit qui peut exécuter une action, pas qui répond de son résultat. La matrice est livrée avec cette colonne ouverte et un bandeau qui le signale, et elle marque en rouge les exclusions délibérées — la séparation des tâches — pour qu’on ne puisse pas les prendre pour des lacunes : le rôle qui fixe le plafond d’annulation ne peut pas approuver d’annulations, car il pourrait relever son propre plafond.

Le modèle d’accès a reçu le même traitement. Une page expose huit contrôles structurels que le code applique — refus par défaut, un 404 plutôt qu’un 403 pour qu’un rôle ne puisse pas apprendre qu’une page existe, et aucune valeur par défaut inventée : « inventer une valeur par défaut, c’est publier en silence une politique que personne n’a approuvée. » À côté, la proposition de rôles émanant du personnel de l’après-vente lui-même — huit rôles, 76 éléments — est confrontée au code élément par élément, côte à côte, « ni fusionnée, ni réconciliée ». Trois des 76 éléments sont entièrement construits et vingt entrent en conflit avec une décision d’architecture approuvée, et la page énonce sa propre limite : elle ne rend aucun verdict sur la justesse de la proposition.

Yaravan — la fiche de rôle des opérations de garantie, en persan : un bandeau rouge indiquant que le rôle existe dans le code mais dans aucun document métier, et chaque champ marqué « à déterminer » — Figure 11Un rôle qui n’existe que dans le code : chaque champ de sa fiche indique « à déterminer », et le bandeau pose la question à l’entreprise.

Yaravan — la matrice RACI en persan, avec un bandeau rouge signalant que la colonne A (approbateur) reste ouverte, et des cellules rouges pour les exclusions délibérées — Figure 12Les onze premières lignes de la matrice des 22 processus. La colonne principale est livrée vide, et dit pourquoi. Le bandeau énonce la lacune et qui détient la décision ; le nom est masqué ici.

Yaravan — deux planches en persan : huit contrôles d’accès structurels appliqués dans le code, et l’en-tête de la comparaison entre le modèle actuel et la proposition du personnel — Figure 13Page 10 : les huit contrôles structurels que le code applique — refus par défaut, 404 au lieu de 403, un seul module derrière le menu, la page et le serveur — au-dessus de l’en-tête de la comparaison côte à côte avec la proposition émanant du personnel lui-même.

09Décisions clés

Six règles pour dessiner ce que personne ne pouvait confirmer

L’essentiel de la méthode porte sur ce que le fichier refuse de dessiner.

01
Ne dessiner que jusqu’où vont les preuves
Cinq niveaux de preuve, fixés par affirmation plutôt que par document, décident de ce qui peut être dessiné : le code exécutable autorise un diagramme en couloirs complet, et l’absence totale de source n’autorise qu’un avis. Un diagramme prétend connaître la séquence, les conditions, les chemins d’erreur et les frontières entre couloirs — en dessiner un sans preuves, c’est une invention qui a seulement l’air plus convaincante.
Alternatives
Dessiner chaque processus à la même profondeur, à partir d’entretiens et d’intentions
Compromis
Le fichier paraît inégal : certains processus s’arrêtent à une carte.
02
Signaler les blancs, ne jamais les deviner
Aucune information métier n’a été inventée. Là où manquait un nom, un chiffre ou un délai, le champ indique « à déterminer » — sur chaque KPI, chaque SLA et la plupart des approbateurs —, afin que les lacunes puissent être comptées et attribuées.
Alternatives
Des valeurs provisoires plausibles
Compromis
Les parties prenantes voient beaucoup d’orange.

10Économie

Une garantie est un passif, pas un service

L’opération devait aussi dire ce que coûte sa promesse centrale. Une garantie ne fournit aucun service le jour de son émission — seulement la promesse que, si l’appareil tombe en panne pendant une certaine période, quelqu’un paiera. Si une réclamation viendra, quand, et combien elle coûtera : tout cela est inconnu ce jour-là ; il faut donc mettre de l’argent de côté dès maintenant, sinon la promesse ne repose sur rien.

Le document suit l’engagement de son émission à sa clôture et expose qui pourrait le financer — et chaque réponse dit ce qu’est la marque : si le distributeur absorbe le coût, un centre de coûts ; si les vendeurs achètent les codes, une activité indépendante ; si l’importateur paie, un partenaire qui gère le réseau. La recommandation porte la mention « une proposition, pas une décision ».

Il se termine par des leviers de contrôle classés par coût — le moins cher est un simple champ — et par dix décisions avec leurs responsables et leurs options, dont huit peuvent être prises dès aujourd’hui sans le moindre chiffre.

Les seuls chiffres admis dans le document sont ceux extraits du code, une hypothèse présentée comme telle, ou un benchmark externe avec sa source, sa population, sa date et son niveau de confiance — et chaque diapositive porte une pastille qui indique lequel.

Économie de la garantie Yaravan — une diapositive en persan : une garantie est une promesse, avec trois inconnues au moment de son émission — si elle jouera, quand et pour combien — Figure 14Le document s’ouvre sur le concept : le jour de son émission, une garantie, ce sont trois inconnues — si une réclamation viendra, quand, et à quel coût.

Économie de la garantie Yaravan — cinq leviers de contrôle en persan, classés du moins cher au plus coûteux, chacun avec son statut actuel — Figure 15Cinq leviers de contrôle, classés du moins cher au plus coûteux, chacun rattaché au facteur de l’équation de coût sur lequel il agit.

Économie de la garantie Yaravan — la carte des planches du document, en persan : l’arc narratif et un tableau de toutes les diapositives, chacune avec son message et sa pastille de preuve

Économie de la garantie Yaravan — l’annexe du glossaire, en persan : un terme persan fixe pour chaque concept, avec sa définition

11Résultats

Une opération dessinée, chaque lacune avec son responsable

Il n’y a pas d’indicateurs métier, et il ne devrait pas y en avoir : le produit est en préproduction, et les mesures convenues n’ont encore ni formule validée ni source de données. Ce que le travail a changé, c’est ce que l’organisation sait d’elle-même. En juillet, il n’existait aucune description écrite de l’opération d’après-vente ; il en existe désormais une description dessinée, où chaque lacune est signalée, comptée et attribuée — et les trois points qui bloquent l’intégration sont nommés comme des décisions, pas comme de l’ingénierie.

22 processus sur six niveaux: Carte macro, cartes de bout en bout, blueprints de service, diagrammes en couloirs, procédures et instructions de travail — 145 planches sur 13 pages.; Livrable
Un modèle des rôles et une matrice RACI: Huit fiches de rôle et une matrice de 22 processus, avec les exclusions délibérées signalées et la colonne ouverte reconnue comme telle.; Livrable
Une matrice de couverture qui s’audite elle-même: Chaque processus mis en regard de sa source, de ses niveaux et de ce qui manque ; des lacunes closes rouvertes et des citations corrigées.; Livrable
Un modèle d’économie de la garantie: Passif, financement et leviers de contrôle, exposés sans un seul chiffre inventé.; Livrable

Ce qui a été livré

Audit de préparation
Carte macro des processus

12Ce que j’ai appris

Une seule discipline, sur chaque planche

01
Publier la lacune vaut mieux que la masquer
Le même réflexe traverse chaque livrable : NOT_READY au lieu d’un pourcentage, « à déterminer » sur les cartes de processus, une colonne A (approbateur) vide avec un bandeau qui le signale, et une pastille de preuve sur chaque diapositive.
02
Une carte autorisée à revenir incomplète est un instrument de recherche
Dessiner ce que personne ne savait décrire a produit des constats qu’aucun document ne contenait : quels processus envoient réellement des messages au client, quels rôles n’existent que dans le code, quelle colonne ne peut pas être remplie à partir des permissions. Une carte qui doit paraître finie est une décoration.
03
Un score de préparation ne veut rien dire tant que le périmètre n’est pas honnête
Le premier audit a échoué parce qu’il mesurait une opération que ce produit ne possède pas. Le restreindre aux processus que possède la marque n’a pas abaissé l’exigence — cela a porté la confiance dans les preuves à 92 %.
04
Transformer chaque commentaire de revue en règle
Répondre à un commentaire corrige un nœud ; nommer la règle qui le sous-tend corrige tous les suivants. Une remarque sur l’orthographe persane est devenue une règle nommée et une passe unique sur 1 088 nœuds de texte, sur les treize pages.

Langue

Yaravan — le design de services d’une opération d’après-vente que personne n’avait décrite

Une identité en sommeil, une opération non documentée

Le design de l’état souhaité, pas le relevé de l’état actuel

Mener le travail, avec l’équipe du client

Responsable

Coresponsable

Collaboration

Des jalons, pas des livrables

Six jalons, dans l’ordre

Dessiner les règles avant les diagrammes

Un processus, suivi jusqu’au dernier niveau

Une carte autorisée à revenir incomplète est un instrument de recherche

La redevabilité est un fait organisationnel, pas technique

Six règles pour dessiner ce que personne ne pouvait confirmer

Ne dessiner que jusqu’où vont les preuves

Signaler les blancs, ne jamais les deviner

Une garantie est un passif, pas un service

Une opération dessinée, chaque lacune avec son responsable

Ce qui a été livré

Une seule discipline, sur chaque planche

Publier la lacune vaut mieux que la masquer

Une carte autorisée à revenir incomplète est un instrument de recherche

Un score de préparation ne veut rien dire tant que le périmètre n’est pas honnête

Transformer chaque commentaire de revue en règle

Consigner les conflits, ne pas les résoudre

Laisser la colonne A (approbateur) ouverte

Le CRM comme verdict par processus, pas comme fonctionnalité

Le persan sur le canevas, l’alphabet latin dans le nom du cadre