Une architecture d’entreprise bien conçue est le fruit d’une intelligence collective. Le déploiement des pratiques d’architecture doit aussi être considéré du point de vue humain. Tentative de démonstration en ré-exploitant quelques enseignements de la mobilisation en entreprise.

Pour concevoir et faire évoluer l’architecture du système d’information d’une entreprise, il faut tenir compte de nombreuses préoccupations hétéroclites : métiers, techniques, managériales, financières, réglementaires, etc.

Par leurs efforts, les différents métiers en charge de l’architecture parviennent à définir des architectures cohérentes, alignées avec les différents besoins, à la fois pérennes et évolutives. Une architecture bien conçue est finalement le fruit d’une mobilisation, par laquelle l’intelligence collective opère correctement. Pour aider les architectes d’entreprise, il existe un ensemble de bonnes pratiques permettant de concevoir une architecture adaptée à chaque entreprise, développé depuis plusieurs années. Ces bonnes pratiques sont une extension des pratiques architecturales à l’ensemble de l’entreprise : représenter (modéliser) pour concevoir et partager ; comprendre l’existant pour savoir d’où l’on part ; établir une cible ; établir des bibliothèques d’architectures-types ré-exploitables ; etc.

L’effort d’appropriation de ces bonnes pratiques est souvent focalisé sur la définition des outils de l’architecte (modélisation, patterns, concepts, livrables, etc.). L’appropriation et l’adoption des outils est longue et on la qualifie volontiers « d’évangélisation ». Aussi pertinents ces outils soient-ils, ils ne peuvent pas provoquer la mobilisation de l’intelligence collective à eux seuls. On doit compléter leur déploiement par une série d’initiatives visant à mobiliser les acteurs de l’architecture. Il faut rappeler ce qu’est la mobilisation.

Les différentes formes de la mobilisation

La mobilisation est l’acte intentionnel d’un collaborateur le conduisant à faire des efforts dans le sens d’un travail collectif. D’après Arnaud Bichon, sociologue, on trouve trois formes de comportement de mobilisation, classés par ordre de complexité croissante :

1. Les conduites relationnelles : ce sont les efforts favorisant la connaissance mutuelle des acteurs et divers types de partage entre eux. C’est le fameux « esprit de corps » des gens du (même) métier qui s’apprécient. Le collaborateur mobilisé est celui qui fait l’effort de tisser des liens, de vivre des expériences avec l’autre. L’inverse, c’est l’individu isolé qui n’engage aucune relation particulière.
2. Les conduites coopératives : ce sont les efforts spontanés de collaboration, avec des prises d’initiatives dépassant le cadre stricte des obligations. Le collaborateur mobilisé est celui qui travaille délibérément en interaction avec ses collègues et s’implique dans les décisions, qui « partage ». L’inverse c’est la non-collaboration.
3. Les conduites d’intercompréhension : ce sont les efforts pour construire des représentations communes, comme référence des actions collectives et individuelles.
   Le collaborateur mobilisé est celui qui développe une vision globale de l’activité contribuant à « construire avec autrui ». L’inverse, c’est celui qui veut rester dans son cadre de référence.

La mobilisation est provoquée selon deux modalités de natures très différentes, qui se complètent :

• Un processus managérial de mobilisation (pratiques RH, prescriptives et descendantes, sous forme d’injonctions) visant à déclencher la mobilisation.
• Un ensemble de comportements individuels, « autogènes », à l’initiative du collaborateur.

Plus les formes de mobilisation sont complexes (de 1 à 3 dans la liste plus haut), plus elles sont délicates à provoquer, car elles sont discrétionnaires. L’intelligence collective fait partie de celle-ci. Elle fait parfois dire à des patrons d’entreprises que « la collaboration se constate, mais qu’elle ne se mesure pas », comme une déclaration d’impuissance.

Application à l’architecture

Lorsque l’on déploie les outils de l’architecte (modélisation, patterns, concepts, livrables, etc.) on travaille sur une série d’injonctions visant à provoquer l’utilisation de nouveaux outils. A l’opposé d’une démarche par injonctions, pour que l’intelligence opère, il faut agir sur les comportements, afin de créer des réflexes de collaboration. Il s’agit de créer un contexte favorable.

Dans cette perspective, des actions prioritaires sont à mener en parallèle :

1. Faire reconnaître la pratique de l’architecture dans le cadre de référence RH de l’entreprise. Il paraît difficile de demander au équipes de réaliser des effort sur une discipline qui ne serait pas reconnue comme telle. Cela nécessité une réflexion, car il n’existe pas de cadre de référence publiée sur le sujet. On trouve n variantes sur le sujet « Architecte » dans le domaine SI. C’est dans le cadre de référence RH que l’on pourra définir les fonctions des « Architectes d’Entreprise » et des points de repère pour formuler des objectifs annuels individuels.
2. Créer une communauté des architectes, pour provoquer les rencontres et les « conduites relationnelles » qui ensuite seront poursuivies dans le cadre des activités courantes.
   Cette communauté peut prendre différentes formes : petits déjeuners débats réguliers, conférences animées par des intervenants internes ou des prestataires, groupes de travail à thème, outils de partage d’information (le « wiki » des architectes), etc.
3. Développer l’envie de faire de l’architecture, en recherchant et en agissant systématiquement sur les appétences et les freins des acteurs de l’architecture.
   On doit pouvoir établir un plan d’action de changement très pragmatique, impliquant les acteurs et leurs hiérarchies, en complément des habituelles réunions d’information. sur l’architecture.
4. Développer un réseau favorable à l’architecture en identifiant les alliés sur lesquels on peut compter et en leur confiant des initiatives concourant au déploiement de l’architecture.

Je n’ose pas rappeler qu’un soutien, dans les paroles et les actes, de la Direction des Systèmes d’Information, est indispensable pour que l’opération réussisse.

Le marché de l’externalisation est devenu plus mature et les DSI beaucoup plus expérimentées sur la base des différentes générations de leurs contrats d’externalisation. Les enjeux d’hier : préparer / lancer un appel d’offre et contractualiser les services sont aujourd’hui perçus comme moins sensibles en dépit de nouveaux enjeux tels que le multi-sourcing, les renouvellements de contrats forcément plus fréquents et les nouvelles approches de delivery (Cloud, Devops, Agilité, SDA/RPA,…).

Néanmoins et en dépit de la maturité du marché, les difficultés à capter toute la valeur ajoutée des projets d’externalisation informatique n’ont pas diminué et ce d’autant plus que les durées cumulées des différents contrats s’allongent … Au-delà du RFP et du contrat quels sont donc les écueils que l’on rencontre dans les projets d’externalisation informatique ? Sur la base de mon expérience et des échanges que je peux avoir avec mes clients, j’identifie quatre type d’écueils :

Ecueil n°1 : pas de stratégie de sourcing pertinente

Les motivations à externaliser un périmètre donné devraient théoriquement être toujours déterminées par l’objectif de le faire progresser dans différentes dimensions (coûts, qualité, flexibilité,..). Une fois tranchée la question des grands domaines susceptibles d’être externalisés, se posent des questions de stratégie de sourcing plus opérationnelle et leurs lots d’écueils potentiels :

• Les axes de progrès recherchés (organisation, finance, technique,…) ne sont parfois pas formalisés et/ou partagés : difficile dans ces conditions de mesurer la valeur de tels projets et surtout d’empêcher les différentes parties prenantes d’être en situation d’insatisfaction quasi-permanente,

• Dans certains cas, les leviers de progrès / d’optimisation indispensables et adaptés sont incompatibles avec la politique de l’entreprise ou bien les transformations organisationnelles à mener ne sont pas traitées dans le cadre du projet d’externalisation. En conséquence des projets souvent pertinents se retrouvent « plantés » en raison d’un modèle de sourcing inadéquat ou d’une gouvernance qui n’a pas été adapté. C’est dans ces situations que l’on voit des appels d’offres qui posent les mauvaises questions au marché,

• Pire encore, l’appel d’offre pose les bonnes questions mais aux mauvais acteurs … C’est la meilleure manière d’externaliser un périmètre à un fournisseur qui n’a pas les leviers (industriels, méthodologiques, humains,..) pour faire progresser ce périmètre. C’est un cas que l’on voit relativement souvent quand un donneur d’ordre n’est pas si mature que cela et finit par signer un contrat avec un fournisseur aussi peu mature que lui mais avec qui le niveau d’échange est très bon mais les promesses rarement tangibles …

Ecueil n°2 : un gouvernance contractuelle de la relation

Ou quand la relation client-fournisseur n’est vue qu’au travers du prisme du contrat signé – on parle alors de gouvernance contractuelle de la relation – tous les aspects de la relation client-fournisseur semblent régis par le contrat avec les écueils suivants :

• Sans surprise, les gestionnaires de contrats côté fournisseurs finissent assez rapidement par se prendre pour les gestionnaires de la relation client mais avec un niveau d’échange limité aux enjeux de delivery, des interlocuteurs côté client centrés sur le pilotage du contrat et une tendance à ne pas laisser approcher les commerciaux et autres gestionnaires de comptes de ce qu’ils considèrent être leur périmètre. En conséquence, aucune promesse implicite (non contractualisée) n’est généralement tenue (exemple l’innovation) et le dynamisme dans la gestion du contrat / de la relation n’est souvent pas au rendez-vous.

• Dans le contexte d’une gouvernance contractuelle de la relation le niveau des échanges conditionne le niveau des interactions. Ainsi l’on parle plutôt d’une relation de coopération et d’un partage des tâches que d’une relation de collaboration où ce sont les objectifs qui seraient partagés. Les incidences sont concrètes et directes, avec par exemple dans le cas de la coopération, un pilotage via un certain nombre de revues d’évaluation de la performance et pour la collaboration un certain nombre de revues de synchronisation … Ça fait toute la différence et c’est le début de relations client-fournisseur plus équilibrées / plus productives.

Ecueil n°3 : des services non centrés sur les utilisateurs

Si les utilisateurs sont souvent les derniers à découvrir ce qui a été prévu pour eux dans un contrat d’externalisation, ils sont généralement les premiers à être impactés quand les services ne leur conviennent pas. Autant l’équation de services centrés sur les utilisateurs est simple à poser « adéquation aux besoins + attitudes + performance + valeur ajoutée », autant la promesse est difficile à tenir dans le cadre des projets d’externalisation. Je ne connais pas de méthodes scientifiques pour réussir ce challenge mais recommande trois principes d’actions de bon sens :

1. Impliquer les utilisateurs dans la définition du catalogue de services. C’est simple quand la maîtrise d’ouvrage est structurée, c’est difficile et souvent inefficace quand c’est la maîtrise d’oeuvre qui s’en charge et présume des besoins des utilisateurs,
2. Ne pas trop stéréotyper les prestations et veiller à garder de la flexibilité dans le modèle de delivery,
3. Enfin, concevoir des services certes industriels mais sans jamais les déshumaniser.

Ecueil n°4 : modèle d’opération inadapté

Pour faire progresser les périmètres externalisés dans différentes dimensions (coûts, qualité, flexibilité,..), le fournisseur doit transformer le ou les modèles d’opération existants à l’aide de leviers de transformation dont son client ne dispose à priori pas.

Mais dans certains cas, le modèle d’opération cible n’est pas adapté aux progrès attendus et ce pour trois raisons principales :

1. Le projet d’externalisation a prévu une phase de transition des services vers l’infogérant mais n’a tout simplement pas prévu de phase de transformation.
2. Dans d’autres cas, un projet de transformation a bien été prévu dans le projet d’externalisation mais à l’usage, les leviers de transformation se révèlent inapplicables où bien le projet de transformation ne va pas au bout pour d’autres raisons (souvent des raisons de complexité, de coûts du projet ou de maturité de l’équipe en charge de la transformation).
3. Parfois c’est le client qui ne collabore pas suffisamment au projet de transformation avec son infogérant…. rarement volontairement mais souvent pour des raisons de gouvernance interne.

Dans les trois cas, le résultat est problématique car l’infogérant n’a tout simplement pas les moyens de tenir ses promesses avec un modèle d’opération inadapté / non transformé.

A titre d’illustration, on peut noter le cas de grands groupes qui externalisent – pour les faire converger – leurs différents Service Desk (filiales / pays) vers un infogérant unique. Dans de nombreux cas la « transformation » s’arrête à la transition des différents périmètres vers le fournisseur choisi. Très peu de rationalisations sont finalement menées et la capture des gains liés à la mutualisation de ressources et à l’utilisation de processus et d’outils communs demeure un vœu pieu.

Et pourtant tout s’annonçait si bien…

Syndrome du Titanic ?

Pour finir, les 4 écueils précédemment évoqués partagent avec l’histoire du Titanic et de son iceberg fatal, les 2 caractéristiques suivantes :

1. Ces écueils sont potentiellement dans le chemin critique du succès du projet d’externalisation avant le démarrage du projet,
2. Une fois le projet lancé, ces écueils sont difficiles à éviter / contourner.

En guise de conclusion : quelle que soit votre maturité en matière d’externalisation, il est toujours aussi crucial et difficile d’acheter les bonnes promesses et de faire en sorte qu’elles soient tenues dans la durée.