Le programme finit, les passages restent cassés

Dans ce scénario pédagogique, sans référence à un résultat client de CYTIZEN, Élodie dirige un programme commercial et informatique. Le CRM est installé, le système de contrats fonctionne et les interfaces SAP ont été livrées. Chacun peut présenter sa réception. Pourtant, une nouvelle vente exige encore plusieurs échanges pour créer le client, valider le contrat et permettre la facturation. Le problème se situe entre les périmètres : aucun projet ne possède le parcours complet, et chaque équipe attend une information que l’autre considère avoir déjà fournie.

La proposition « moins de grands programmes » ne signifie pas moins de direction, moins d’architecture ou moins de discipline. Elle signifie organiser certains investissements autour d’un résultat traversant les applications, plutôt qu’autour de la livraison indépendante de chaque outil. Une chaîne de valeur devient utile lorsqu’elle permet de relier une demande, plusieurs décisions et une sortie reconnue par le métier. Renommer les projets en produits sans changer leurs responsabilités ne résoudrait pas le problème d’Élodie.

Dessiner une frontière qui n’oublie pas le résultat

Le parcours choisi va de la demande commerciale validée à la première facture correcte. Il comprend l’identification du client, la qualification de l’opportunité, le contrat, la création des données dans SAP et les conditions de facturation. La livraison attendue n’est pas « connecter le CRM à l’ERP ». Elle est « rendre une commande facturable avec les données et validations requises ». Cette formulation change les tests : un message d’interface réussi ne suffit plus si le client créé ne possède pas les paramètres nécessaires à la comptabilité.

Élodie note les exceptions avant de dessiner le parcours nominal. Un prospect peut signer un accord de confidentialité sans devenir immédiatement un client ERP. Un client existant peut appartenir à une autre entité juridique. Une adresse modifiée ne doit pas écraser des informations utilisées dans un contrat signé. Le groupe décide quelles données appartiennent à SAP, lesquelles restent dans le CRM et quels événements peuvent modifier chaque référentiel. Une carte utile montre aussi ce qui ne doit pas circuler.

Le périmètre reste volontairement limité. L’équipe ne reprend pas simultanément toute la relation client, le pricing, la supply chain et les achats. Elle choisit un segment commercial dont les exceptions sont observables, conserve les dépendances avec les autres parcours et nomme leurs responsables. Une chaîne de valeur qui englobe toute l’entreprise recrée simplement le grand programme sous un autre nom. Le bon périmètre permet de décider et de vérifier une amélioration en conservant la maîtrise des interfaces.

Un mandat transversal avec des droits de décision

Le responsable du parcours doit pouvoir arbitrer les priorités entre applications, sans devenir propriétaire de tous les systèmes. Son mandat décrit la finalité, les capacités affectées, les décisions qu’il peut prendre et celles qu’il doit escalader. Le propriétaire SAP conserve l’intégrité du référentiel ; le juridique conserve l’approbation contractuelle ; la finance conserve ses contrôles. Le responsable du parcours organise leur contribution et porte l’acceptation de bout en bout.

Le journal de décision du scénario est rempli ainsi : problème, création de clients en doublon ; options, création automatique depuis chaque opportunité ou validation centrale avant création ; décision, déclenchement après validation de l’identité et de l’entité juridique ; responsable, gestion des données clients ; preuve attendue, absence de duplication et capacité à facturer dans les tests du segment. La date et les exceptions sont enregistrées. Ce document vaut davantage qu’un organigramme où tous les participants apparaissent comme responsables conjointement.

La capacité de l’équipe est explicite. Les architectes, responsables métier, testeurs et spécialistes des interfaces ne sont pas disponibles simplement parce que leur nom figure dans la gouvernance. Le plan indique les créneaux réservés et les conflits avec les obligations d’exploitation. Si la capacité n’existe pas, le sponsor réduit le périmètre ou reporte un autre engagement. Ajouter une instance de comité ne crée pas la compétence ni le temps dont la chaîne dépend.

Financer une évolution plutôt qu’un backlog infini

Un financement durable ne dispense pas de rendre compte. Élodie propose une enveloppe destinée à améliorer le parcours choisi, avec une limite de capacité, des coûts récurrents et des critères de poursuite. Le comité compare le coût complet des changements au résultat observé : reprises évitées, délais réduits, erreurs financières maîtrisées. Il ne rémunère pas l’équipe au nombre de fonctionnalités ajoutées. Une règle de gestion supprimée peut avoir davantage de valeur qu’un nouvel écran.

Le coût de la chaîne comprend les adaptations des applications, les interfaces, les données, les tests, la conduite du changement et le support. Il distingue ce qui est spécifique au parcours de ce qui profite à plusieurs services, comme une gestion commune des identités. Une allocation compréhensible empêche qu’une plateforme centrale paraisse gratuite alors que les métiers supportent ses dépenses. Elle évite aussi d’attribuer tout son coût à la première équipe qui l’utilise.

Les effets sont mesurés sur des dossiers comparables. Le délai entre validation commerciale et première facture constitue une mesure utile, mais il est segmenté par type de contrat et entité. L’équipe compte séparément les dossiers interrompus pour une raison commerciale. Le taux de reprise sur données client donne un signal sur la qualité du passage CRM–SAP. Si le délai s’améliore seulement parce que les dossiers compliqués restent hors de la nouvelle chaîne, le comité doit le voir.

Architecture et tests : les frontières deviennent des produits de travail

La chaîne possède un contrat d’interface pour chaque échange : événement déclencheur, identifiant métier, champs obligatoires, contrôles, résultat attendu et traitement d’erreur. Une réponse technique positive n’équivaut pas à une acceptation métier. Si SAP rejette une création, l’information doit revenir au propriétaire capable de corriger le dossier, sans créer une boucle de tentatives silencieuses. L’idempotence permet de rejouer un événement sans créer un deuxième client ou une deuxième facture.

Les tests suivent les parcours et les exceptions. L’équipe vérifie une création, une modification autorisée, une modification refusée, un doublon, une interruption et une reprise. Elle contrôle les montants et identifiants dans les systèmes terminaux, pas uniquement les captures d’écran de chaque application. Une répétition de test après un changement de configuration vérifie qu’une amélioration locale n’a pas cassé la sortie du parcours. Les responsabilités de preuve sont distribuées, mais l’acceptation complète possède un signataire.

Le découpage en chaînes ne rend pas tous les programmes inutiles. Un remplacement ERP majeur, une séparation d’entreprise ou une échéance réglementaire peuvent exiger une direction temporaire fortement centralisée. Dans ces situations, la chaîne de valeur apporte des critères d’acceptation et une organisation de l’après-projet. Le programme garde la responsabilité des dépendances globales, du calendrier et de la transition. L’enjeu est de choisir l’organisation adaptée au risque, pas de déclarer une méthode supérieure par principe.

Dans la vraie vie : supprimer une transmission

Élodie observe un dossier avec les équipes. Les achats demandent une attestation déjà présente dans le contrat ; la finance demande ensuite la même information dans un autre formulaire. L’équipe pourrait automatiser trois transmissions. Elle commence par déterminer quel contrôle justifie chacune. Une transmission est supprimée, une autre devient un contrôle fondé sur la donnée source et la dernière reste manuelle pour les exceptions. La simplification précède l’intégration technique.

Le sponsor valide un pilote sur un segment, avec un propriétaire de parcours et un mécanisme de retour vers la procédure existante. La sortie du pilote dépend de la qualité des données et du traitement des erreurs, pas d’une date arbitraire. Au prochain comité, Élodie présentera les dossiers terminés, les exceptions et les coûts d’exploitation. Elle ne présentera plus la somme de trois réceptions applicatives comme la preuve d’une capacité commerciale nouvelle.

Des variations qui changent réellement la conduite

Dans une industrie réglementée, la chaîne doit conserver les validations qualité et le lien entre changement, lot et documentation approuvée. Dans une banque, les fonctions de contrôle et les habilitations imposent des séparations de tâches qui ne se dissolvent pas dans une équipe produit. Dans un groupe international, la chaîne peut partager un noyau de données tout en conservant des règles fiscales locales. Ces différences déterminent les exceptions, le périmètre des tests et les décisions centralisées.

Un premier pas pragmatique consiste à choisir une transmission actuellement coûteuse, identifier les dossiers concernés et réunir ceux qui produisent et consomment sa sortie. S’il devient possible de supprimer une attente sans supprimer un contrôle nécessaire, la chaîne a déjà produit un résultat. L’organisation peut ensuite étendre son mandat. Elle doit toutefois conserver le droit de s’arrêter si le coût de coordination dépasse l’amélioration obtenue.

Sources, méthode et limites

Sources consultées le 4 octobre 2026. Le scénario et les décisions sont pédagogiques. Les documents primaires ci-dessous apportent des repères sur une plateforme conçue pour ses utilisateurs et sur les mesures liées au service ; ils ne démontrent pas qu’une chaîne de valeur remplacerait universellement un programme.