Quand le métier décide sans l'architecture : ce n'est pas un problème de pouvoir, c'est un problème de mandat

Le message arrive entre deux sujets. La direction commerciale a retenu une solution en ligne de gestion de la relation client ; le contrat est signé, le déploiement commence dans quelques semaines. Il est demandé à l’architecture de « voir comment la raccorder » au référentiel client, à la facturation et à l’annuaire. Personne ne lui a demandé son avis sur le choix. On lui demande de le rendre possible.

En quelques jours, l’architecte découvre ce que le dossier n’a jamais examiné. L’outil porte sa propre notion de client, qui ne correspond pas à celle du référentiel. Les données seront hébergées hors du périmètre prévu par la politique de l’entreprise. Les conditions de sortie du contrat ne disent rien de la restitution des historiques. Et une autre direction utilise déjà un outil qui couvre une partie du même besoin. Il le signale. On lui répond, poliment, que la décision est prise, que le métier dispose de son budget, et que l’architecture est là pour accompagner, pas pour refaire le match.

La lecture la plus répandue parmi les architectes est connue : le métier ne comprend pas le rôle de l’architecture, il a trop de pouvoir, il faudrait que la direction impose un passage obligé. Cette lecture est compréhensible. Elle est aussi presque toujours stérile. Le pouvoir du métier n’est pas le problème : il est légitime, puisque c’est lui qui porte la stratégie, le budget et le résultat. Le problème est que les conséquences d’architecture de ses décisions ne sont visibles nulle part au moment où il décide, et que personne n’en répond une fois la décision prise. Le métier ne contourne pas l’architecture ; il décide dans des lieux et à des moments où elle n’est pas. Ce qui manque n’est pas un pouvoir. C’est un mandat.

Une décision rationnelle, vue du métier

Il faut d’abord prendre au sérieux le point de vue de celui qui décide, parce qu’il est cohérent.

Le directeur commercial est évalué sur des résultats datés. Son besoin est réel, souvent ancien, parfois déjà promis à sa propre hiérarchie. La solution retenue y répond, l’éditeur est disponible, la dépense entre dans son périmètre. Tout, dans son environnement, récompense la décision rapide.

Les conséquences d’architecture, elles, ont trois propriétés qui les rendent invisibles depuis sa position. Elles sont différées : l’écart entre deux définitions du client ne coûtera rien avant le premier rapprochement de données, l’année suivante. Elles sont payées par d’autres : c’est la DSI qui maintiendra l’interface, la finance qui réconciliera deux chiffres d’affaires, la conformité qui répondra sur l’hébergement. Elles sont diffuses : aucune ne paraît décisive isolément, et c’est leur accumulation, décision après décision, qui fige le système d’information.

Face à cela, l’architecture se présente souvent dans les pires conditions : après la décision, en relecteur, et avec un vocabulaire — standards, conformité au cadre de référence, architecture cible — qui s’entend, depuis le métier, comme un délai et un coût. Elle demande à être consultée sur une décision dont elle ne partage ni le risque ni le bénéfice. Il n’est pas étonnant qu’on s’en passe.

C’est la même asymétrie que celle qui empêche d’éteindre une application ou de financer la dette technique : un bénéfice concentré, immédiat et porté par quelqu’un ; un coût dispersé, différé et sans propriétaire.

Où les décisions se prennent réellement

Le deuxième constat est plus structurel. Dans la plupart des organisations, les décisions qui déterminent le plus durablement le système d’information ne passent pas par le circuit où l’architecture est installée.

Elles se prennent dans l’arbitrage budgétaire, quand une enveloppe est accordée à une direction pour « un outil ». Elles se prennent dans le circuit des achats, quand un éditeur est retenu et un contrat négocié. Elles se prennent parfois dans une simple souscription en ligne, sous le seuil qui aurait déclenché une consultation. Le projet — seul circuit où l’architecture a généralement sa place, parce qu’elle est rattachée à la DSI — ne commence qu’après.

C’est ici que l’organigramme compte. Une fonction d’architecture rattachée à la DSI voit les projets ; elle ne voit ni les arbitrages budgétaires ni les engagements contractuels, qui relèvent d’autres directions. Elle peut être compétente, écoutée et bien outillée, et arriver pourtant, systématiquement, après les décisions qui comptent. Nous avons décrit le même mécanisme à propos des appels d’offres : l’architecture est convoquée au moment où il ne reste plus que la mise en œuvre à décider.

Une précision évite un faux débat : aucun rattachement n’est bon en soi. Placée auprès de la direction générale ou de la stratégie, l’architecture voit les arbitrages, mais elle s’éloigne de la réalité des systèmes et risque de devenir un exercice de présentation. Placée au sein de la DSI, elle connaît les systèmes, mais ne voit les décisions qu’une fois transformées en projets. La question utile n’est donc pas « où rattacher l’architecture ? », mais « à quels moments de décision doit-elle être présente, quel que soit son rattachement ? ».

Pourquoi réclamer du pouvoir ne marche pas

La réponse la plus fréquente à ce constat consiste à demander davantage d’autorité : un avis obligatoire, un droit de veto, un comité par lequel tout investissement devrait passer. Elle échoue pour trois raisons.

Elle se heurte à une légitimité supérieure. Une direction métier qui porte un résultat et un budget ne se laissera pas durablement bloquer par une fonction qui ne porte ni l’un ni l’autre. Le premier désaccord remonté en comité de direction se tranche presque toujours en faveur du métier — et chaque arbitrage perdu affaiblit le suivant.

Elle déplace les décisions au lieu de les éclairer. Un passage obligé perçu comme un obstacle apprend aux décideurs à l’éviter : découper la dépense sous le seuil, qualifier l’outil de « pilote », présenter le dossier une fois le contrat signé. La gouvernance voit alors moins de décisions qu’avant, pas davantage. C’est l’effet du comité qui dit non, face à un interlocuteur beaucoup plus puissant qu’une équipe projet.

Elle confond le droit de décider et la responsabilité des conséquences. Un veto donne à l’architecture le pouvoir d’empêcher, sans la rendre comptable de ce que l’empêchement coûte au métier. Il ne règle pas le problème de fond : il déplace seulement le côté où les conséquences restent sans propriétaire.

Le mandat : trois choses écrites

Un mandat n’est pas un pouvoir. C’est une délégation explicite, donnée par la direction, qui précise sur quoi l’architecture intervient, à quel moment, et avec quel effet. Il tient en trois éléments.

Les décisions qui déclenchent une instruction. Pas « tout investissement informatique », formule qui garantit à la fois l’engorgement et le contournement, mais une courte liste de critères dont chacun signale une conséquence durable : un nouvel outil qui porte des données de référence — client, produit, tiers ; des données qui sortent du périmètre d’hébergement maîtrisé ; un engagement contractuel pluriannuel ou difficile à dénouer ; un recouvrement avec une capacité métier déjà outillée ailleurs. En dessous de ces critères, le métier décide seul, et c’est très bien ainsi.

Le moment de l’instruction. Le mandat place l’architecture là où l’argent s’engage — à l’arbitrage budgétaire, puis avant le choix d’un fournisseur — et non au lancement du projet. C’est un changement de circuit plus qu’un surcroît de charge : une instruction menée au bon moment est plus courte, parce qu’elle porte encore sur des options et pas sur des réparations.

L’effet de l’instruction. C’est le point décisif, et il ne s’agit pas d’un veto. L’instruction produit un document court qui énonce les conséquences de la décision envisagée ; le décideur le lit, et décide. Il peut décider contre l’avis de l’architecture. Il ne peut pas décider sans que cet avis ait été rendu.

Parler en conséquences, pas en conformité

Un mandat ne sert à rien si ce qui est instruit reste illisible pour le décideur. « Non conforme au cadre de référence » n’est pas une information pour un directeur commercial ; c’est une objection.

L’instruction utile se formule dans les termes avec lesquels le métier arbitre déjà. Les capacités : cette décision crée-t-elle un deuxième outil pour une capacité déjà outillée, et qui arbitrera entre les deux ? La carte des capacités métier est le support naturel de cette conversation, parce qu’elle parle la langue de l’activité et non celle des applications. Le coût total : non pas le prix de l’abonnement, mais ce que coûteront l’intégration, la réconciliation des données, l’exploitation et la sortie — ce que recouvre le coût total de possession. La réversibilité : que faudra-t-il pour revenir en arrière, et le contrat le permet-il ? Le risque : quelles données, hébergées où, sous quelles obligations.

Formulées ainsi, les conséquences cessent d’être une opinion d’architecte. Elles deviennent des éléments du dossier de décision, au même titre que le budget et le calendrier, et le décideur les arbitre avec les mêmes outils que le reste.

Il existe une discipline symétrique, moins confortable pour l’architecture : instruire vite, et savoir dire oui. Une fonction qui met des semaines à rendre un avis, ou dont chaque avis se termine par une réserve, recrée le goulot d’étranglement qu’on lui reproche. Le mandat engage aussi l’architecture — sur un délai, et sur la proportion entre l’enjeu d’une décision et la profondeur de son examen.

Le droit de passer outre, à condition de signer

Reste le cas le plus fréquent et le plus frustrant : le métier connaît les conséquences, et décide quand même. C’est son droit. Un dispositif qui chercherait à l’en empêcher échouerait pour les raisons décrites plus haut.

Ce qui peut être exigé, en revanche, c’est que la décision ait un propriétaire pour ses conséquences. Concrètement, une dérogation explicite : ce qui a été décidé, ce qui avait été signalé, qui en porte la responsabilité, et à quelle date la situation sera réexaminée. Elle est signée par le décideur, pas par l’architecte, et consignée dans le même registre que les autres décisions d’architecture.

Le geste paraît administratif. Il change pourtant deux choses. D’abord, il donne du poids à l’avis sans créer de veto : signer qu’on a été averti d’un risque sur l’hébergement des données n’est pas un acte neutre, et bien des décisions sont amendées à ce moment précis — non parce qu’on les a bloquées, mais parce que le décideur mesure ce qu’il accepte de porter. Ensuite, il rend les conséquences adressables : le jour où la réconciliation de deux référentiels client commence à coûter, on sait à qui la question se pose, et elle ne retombe pas par défaut sur la DSI.

La date de réexamen est la partie la plus importante, pour une raison qui revient souvent en architecture : une exception sans échéance devient la règle. Ce qui a été consenti pour tenir un calendrier doit être réexaminé, puis soit régularisé, soit assumé à nouveau, en connaissance de cause.

Ce que l’architecture doit tenir

Le mandat vient de la direction ; l’architecture ne peut pas se l’attribuer. Elle peut en revanche le rendre possible, puis le faire tenir.

Proposer le mandat plutôt que le réclamer. Une courte liste de critères, un délai d’instruction, un format de dérogation : un dispositif qu’une direction générale peut examiner et valider en une séance a beaucoup plus de chances d’exister qu’une demande générale de passage obligé.

Se brancher sur les circuits existants. L’arbitrage budgétaire, le processus achats, la validation des souscriptions en ligne existent déjà. Ajouter une question à un formulaire que tout le monde remplit vaut mieux que créer une instance de plus.

Tenir le registre des dérogations, avec propriétaires et dates de réexamen, et le présenter régulièrement à ceux qui ont donné le mandat. C’est ce registre, bien plus que les avis rendus, qui rend la gouvernance visible au niveau où elle se décide.

Mesurer sa propre contribution, et pas seulement l’écart des autres. Les indicateurs utiles portent sur les deux côtés : quelle part des engagements répondant aux critères a été instruite avant signature ; combien de projets l’architecture a découverts au moment d’une demande d’intégration ; combien de dérogations ont un propriétaire et une date de réexamen, et combien de réexamens ont réellement eu lieu ; combien de temps prend une instruction ; et combien d’avis ont conduit à modifier une décision sans qu’aucun blocage ait été nécessaire.

Un mandat se donne, il ne se prend pas

Rien de ce qui précède ne fonctionne sans une condition que l’architecture ne contrôle pas : que la direction veuille savoir. Dans une organisation où la direction générale préfère délibérément l’autonomie des directions à la cohérence de l’ensemble, et l’assume, aucune méthode ne s’y substitue. Il vaut mieux le constater clairement que s’épuiser à le compenser par des comités.

Ce cas est pourtant moins fréquent qu’il n’y paraît. Bien plus souvent, la direction n’a jamais été mise en position de choisir : les conséquences n’étaient écrites nulle part, les décisions se prenaient dans des circuits séparés, et l’architecture demandait du pouvoir au lieu de proposer un mandat. Poser la question clairement — qui décide, qui est consulté, qui répond des conséquences — est déjà un travail d’architecture. C’est probablement le premier.