La collaboration a besoin de limites : pourquoi « Qui dirige les projets de transformation » est la mauvaise question

Lorsqu’on évalue les approches des projets de transformation complexes, une vision de plus en plus répandue veut que l’entreprise dirige l’initiative, en détenant souvent l’autorité décisionnelle finale sur l’ensemble de l’effort de transformation. L’intention est compréhensible : ce sont les résultats qui devraient guider l’investissement, et non l’inverse. Mais dans la pratique, cette position se heurte souvent à une réalité plus difficile : lorsque vos systèmes sont imbriqués sur le plan architectural, chaque décision « pilotée par l’entreprise » devient une crise informatique. L’inverse est également vrai : chaque effort de stabilisation des TI donne l’impression de freiner l’entreprise.

Commençons par deux termes simplifiés. Les BSS (Business Support Systems) désignent ici des systèmes comme la gestion de la relation client (CRM), la configuration, tarification et soumission (CPQ) et la gestion commerciale des commandes (COM). Les OSS (Operations Support Systems) désignent les systèmes « back-office » ou opérationnels, tels que l’inventaire, l’approvisionnement et la gestion des commandes de service (SOM). Ces acronymes proviennent de l’industrie des télécommunications, mais les mêmes modèles apparaissent souvent dans les secteurs des médias, de l’énergie, des hautes technologies, des technologies médicales et d’autres industries tout aussi complexes. Le fil conducteur est la complexité : partout où les systèmes se sont enchevêtrés au fil du temps.

Avant d’examiner plus en profondeur les raisons derrière cette possible lutte de contrôle, il est important de se poser quelques questions directes :

1. Lorsque les équipes produit ou commerciales modifient une offre, l’effort requis entraîne-t-il des répercussions en cascade dans les systèmes BSS (CRM, CPQ, COM) et OSS (inventaire, approvisionnement, SOM) d’une manière que personne ne peut entièrement prévoir?
2. Lorsque les TI stabilisent une plateforme ou corrigent le comportement d’une intégration, l’entreprise est-elle tout de même surprise par les impacts, les retards ou les « nous ne pouvons pas lancer cela avant que… »?
3. Les équipes sont-elles parfois tentées d’expliquer les échéances manquées et la frustration croissante par la « culture » ou « l’alignement », alors que le problème de fond est que tout touche à tout?

Si cela vous semble familier, il est possible que nous ne soyons pas d’abord confrontés à un problème de motivation. Le véritable responsable est plus probablement enfoui dans l’architecture elle-même, avec ses racines dans un manque de séparation des responsabilités qui permet aux décisions prises dans un domaine de modifier le comportement d’un autre.

L’argument ici n’est pas que l’entreprise devrait abandonner la stratégie. C’est plutôt que débattre de qui « dirige » est une distraction tant que les limites ne sont pas réelles. Ce qui compte, ce n’est pas tant une hiérarchie que des résultats partagés, une propriété claire des domaines et des interfaces qui empêchent les perturbations mutuelles constantes.

Quand l’architecture fait de chaque changement le problème de quelqu’un d’autre

Dans les environnements complexes de type BSS et OSS, souvent construits sur des applications assemblées par des fournisseurs de l’écosystème avec une logique d’intégration importante, la synchronisation constante des données est la norme. C’est là que l’absence de séparation adéquate des responsabilités devient une réalité opérationnelle : la vérité produit, la logique de traitement des commandes, l’état de l’exécution des services et les configurations de facturation sont dupliqués, partiellement synchronisés ou réconciliés tardivement. Des changements qui semblent mineurs sur une feuille de route (« ajouter un forfait », « lancer une promotion » ou « effectuer une mise à niveau massive d’équipements ») se propagent à travers des couches qui n’ont jamais été conçues pour accueillir le changement.

Dans cet univers, les changements du côté de l’entreprise entraînent un coût réel pour les TI, et les changements du côté des TI entraînent également un coût réel pour l’entreprise. Ce n’est pas un échec de la « culture » ou de « l’alignement ». C’est le couplage architectural qui se manifeste sous forme de friction organisationnelle.

Par réflexe, les équipes de transformation résistent parce que cela les aide à gérer les risques. Les échéanciers glissent parce que les tests de régression et les cycles d’intégration prennent de l’ampleur. Les plateformes héritées deviennent essentielles parce que remplacer un seul élément a d’innombrables répercussions sur l’écosystème. Tout cela est présenté comme un problème de résistance ou d’alignement. En réalité, c’est l’enchevêtrement architectural qui transforme toute proposition de collaboration en prudence.

Pourquoi un modèle où « l’entreprise est aux commandes » inquiète les TI lorsque l’architecture est imbriquée

Si l’entreprise est officiellement « aux commandes » alors que l’environnement technologique est fortement couplé, les TI doivent assumer une responsabilité sans véritable contrôle. Une priorité n’est pas simplement une exigence; elle déclenche une cascade de travaux touchant les systèmes, les intégrations et les opérations. Les TI ne réagissent pas ainsi de manière irrationnelle; elles évaluent simplement le coût.

C’est pourquoi la collaboration est essentielle : elle fonctionne mieux lorsque la responsabilité correspond au contrôle. Si les décisions d’affaires continuent de remodeler le domaine des TI parce que l’architecture ne respecte pas la séparation des responsabilités, le « partenariat » se transforme rapidement en recherche de coupables lorsque les mises en production tournent mal.

À quoi ressemble une bonne approche : démêler, puis donner de l’autonomie

La solution n’est pas de créer deux silos qui fonctionnent comme s’ils n’avaient pas besoin l’un de l’autre. La solution est de démêler l’architecture tout en établissant une collaboration explicite :

• Être responsable de son propre domaine, pas du travail de l’autre. Les données commerciales et orientées client devraient résider dans une couche commerciale clairement définie; les données techniques et liées à l’exécution des services devraient se trouver là où elles appartiennent, avec des règles claires sur l’emplacement de chaque source de vérité et sur la façon dont les changements sont introduits. À titre d’exemple simple, nous avons souvent vu des catalogues de produits commerciaux exposer des attributs techniques aux représentants du service à la clientèle (CSR), les submergeant d’information et créant des répercussions en aval dans la couche OSS.
• Les données maîtres et les règles doivent être gérées là où elles appartiennent. Les validations dupliquées et les approches du type « corriger dans la couche d’intégration » sont des signes que la séparation a échoué. L’intégration devrait connecter les domaines, et non masquer une logique contradictoire. Dans cette même architecture, le catalogue commercial lui-même se trouvait dans la couche OSS, ce qui obligeait des synchronisations lourdes et répétées pour diffuser les configurations commerciales vers tous les systèmes qui en avaient besoin, y compris le CRM.
• Des interfaces, pas des accidents. Lorsque les limites sont explicites, un changement peut être défini, testé et communiqué facilement, avec des résultats prévisibles.

Lorsqu’elle est bien exécutée, l’entreprise et les TI continuent de débattre des priorités. C’est sain. Ce qui change, c’est la nature du débat : on discute des compromis (vitesse, coût, risque, impact client), plutôt que de l’incertitude entourant ce qu’un changement pourrait briser ailleurs.

Bien sûr, rien de tout cela n’est simple. Personne ne remplace une architecture enchevêtrée en une seule mise en production. Cela se fait progressivement, un élément à la fois, sur plusieurs années, pendant que l’entreprise continue de fonctionner et que les clients continuent d’être servis. C’est le véritable travail.

Des objectifs communs sans chaos partagé

C’est également là que la discipline classique de gestion de programme démontre sa valeur. Les objectifs, la mobilisation, la documentation, la gouvernance et la gestion du changement font tous partie de ce que la pensée « pilotée par l’entreprise » met justement de l’avant, et ces éléments demeurent essentiels. Ce qui change, c’est qu’ils fonctionnent mieux dans un modèle opérationnel partagé plutôt que lorsqu’une fonction cherche à dominer l’autre.

Un modèle pratique :

• Des résultats communs qui incluent l’opérabilité : une mise en production n’est pas un succès si l’entreprise et les TI ne peuvent pas ensuite évoluer de manière indépendante.
• La faisabilité évaluée tôt comme intrant stratégique, plutôt qu’un refus de dernière minute. Les contraintes techniques influencent ce qui peut être réalisé de façon réaliste.
• Une gouvernance avec des droits décisionnels aux points de rencontre entre les domaines : qui tranche lorsque les définitions commerciales et les définitions de services sont en contradiction, et comment empêcher que des exceptions « temporaires » ne deviennent un couplage permanent?

La thèse en une phrase

Les débats sur la question de savoir qui devrait « diriger » ignorent souvent le véritable problème : une architecture enchevêtrée force l’entreprise et les TI à se retrouver constamment dans les jambes l’une de l’autre. La collaboration devient viable lorsque la séparation des responsabilités est atteinte, permettant à chaque partie de diriger son propre domaine avec clarté, de s’aligner sur des objectifs communs et de se rencontrer aux bonnes interfaces.

Si ce modèle vous semble familier, la question la plus utile n’est pas de savoir qui dirige, mais plutôt où, dans votre propre architecture, un changement d’un côté entraîne encore un coût imprévisible de l’autre. C’est généralement là que le véritable travail commence : démêler d’abord, puis donner à chaque partie l’autonomie nécessaire pour diriger son propre domaine avec clarté.

Si cela vous interpelle, communiquez avec Ateko pour poursuivre la conversation.