Un principe d'architecture que personne ne peut enfreindre ne sert à rien : écrire des principes qui arbitrent

La liste a été présentée au comité il y a deux ans. Une dizaine de principes, chacun formulé en une phrase : la donnée est un actif de l’entreprise, réutiliser avant d’acheter et acheter avant de construire, la sécurité est l’affaire de tous, le système d’information doit être agile et évolutif, l’utilisateur est au centre. Elle a été approuvée sans débat, publiée sur l’intranet, reprise en annexe de chaque dossier d’architecture.

Aujourd’hui, un choix difficile se présente. Une direction veut souscrire à un service en ligne qui porte sa propre base clients ; la DSI préférerait étendre l’outil existant. Chacun des deux camps cite un principe de la liste, et les deux citations sont exactes. Le premier invoque « acheter avant de construire », le second « la donnée est un actif ». Le comité tranche finalement sur le calendrier et le budget, comme il l’aurait fait sans liste.

Personne n’a violé les principes. C’est justement le problème. Un principe que personne ne peut enfreindre ne décide rien, parce qu’il n’exclut rien. Les listes de principes ne s’usent pas faute d’être appliquées : elles naissent inutiles, parce qu’elles sont écrites pour être approuvées plutôt que pour arbitrer. Un principe utile est une décision prise à l’avance pour une catégorie de cas. Comme toute décision, il doit coûter quelque chose à quelqu’un.

Pourquoi les listes finissent en décoration

Les causes sont connues, et elles tiennent à la manière dont les listes sont produites plus qu’à la bonne volonté de ceux qui les rédigent.

Le critère de validation est le consensus. Une liste de principes est généralement soumise à un comité où siègent des directions aux intérêts divergents. Chaque formulation qui gêne l’une d’elles est adoucie jusqu’à ce que personne ne s’y oppose. Le texte qui en sort est celui que tout le monde peut signer — et donc celui qui n’engage personne.

Les principes sont écrits dans l’abstrait. Ils sont rédigés en séance de travail, loin de toute décision réelle, sans qu’on se demande à quel dossier récent ils auraient changé quelque chose. Un principe qui n’a jamais été confronté à un cas n’a aucune raison d’en trancher un.

Rien ne dit lequel l’emporte. Une liste de dix principes sans règle de préséance permet de justifier presque n’importe quelle décision, puisqu’il suffit de choisir celui qui convient. La liste devient un répertoire d’arguments, mobilisé après la décision pour la légitimer, pas avant pour l’orienter.

Rien ne dit ce que le principe coûte. « Privilégier les solutions du marché » paraît raisonnable tant qu’on ne précise pas la contrepartie : que l’organisation adaptera ses processus au progiciel, et qu’une partie des demandes métier sera refusée pour cette raison. Sans cette précision, le principe est approuvé par ceux-là mêmes qui s’y opposeront au premier cas concret.

Le test de la négation

Un critère simple permet de trier une liste existante en quelques minutes. Un principe n’apporte d’information que si son contraire est une position qu’une organisation raisonnable pourrait tenir.

« La donnée est un actif de l’entreprise » ne passe pas le test : personne ne défend que la donnée n’a pas de valeur. La phrase n’est pas fausse, elle est vide — elle décrit une conviction partagée, pas un choix. Il en va de même pour « la sécurité est l’affaire de tous », « le SI doit être agile » ou « l’utilisateur est au centre ». Leur contraire est absurde ; leur affirmation n’exclut donc aucune option.

« Chaque donnée de référence est écrite par un seul système ; les autres la lisent » passe le test. Son contraire — chaque application tient sa propre copie des clients ou des produits, et on rapproche les versions ensuite — n’est pas absurde. C’est la situation de nombreuses organisations, et elle se défend : elle laisse chaque domaine avancer à son rythme, au prix d’une réconciliation permanente. Choisir l’un plutôt que l’autre est une vraie décision. Le principe la prend une fois pour toutes, au lieu de la laisser se reprendre, dossier par dossier, au gré des projets.

Le test ne condamne pas les convictions. « La donnée est un actif » peut figurer en préambule d’un document de stratégie. Mais une conviction n’est pas un principe d’architecture tant qu’elle n’a pas été traduite en choix. La traduction consiste presque toujours à se demander : si nous le pensons vraiment, qu’allons-nous nous interdire ? Pour la donnée, la réponse peut être un propriétaire désigné par référentiel, un seul système autorisé à écrire, l’interdiction de créer une copie maîtresse dans un outil métier. C’est cette réponse qui mérite d’être écrite.

Ce qu’un principe doit contenir pour arbitrer

Le format le plus répandu, popularisé par TOGAF, prévoit déjà l’essentiel : un nom, un énoncé, une justification, des implications. Le problème n’est pas le format ; c’est que les deux dernières rubriques sont souvent remplies par des généralités. Un principe qui arbitre les prend au sérieux, et y ajoute deux précisions.

Un énoncé qui exclut quelque chose. Le test de la négation s’applique ici : on doit pouvoir nommer au moins une option raisonnable que l’énoncé écarte.

Une justification propre à l’organisation. Pas une vérité générale sur l’informatique, mais la raison pour laquelle cette organisation fait ce choix maintenant : une réglementation, une dépendance subie par le passé, une capacité jugée stratégique, une compétence qui manque. La justification a une fonction précise : elle dit dans quelles conditions le principe cessera d’être valable. Un principe justifié par une contrainte réglementaire devient discutable le jour où cette contrainte change ; sans justification écrite, personne ne pense à le réexaminer.

Des implications assumées. C’est la rubrique décisive. Elle énonce ce que l’organisation s’engage à faire, et surtout ce qu’elle accepte de perdre : les demandes qui seront refusées, les coûts qui seront supportés, les directions qui devront changer leurs pratiques. Une implication qui ne coûte rien à personne n’en est pas une.

Un périmètre. Presque aucun principe ne vaut partout. « Le marché avant le spécifique » se défend pour les capacités de support, beaucoup moins pour celles qui différencient l’organisation — c’est tout l’objet de l’arbitrage entre standard et spécifique. Écrire où le principe ne s’applique pas le rend plus crédible là où il s’applique.

Une procédure d’écart. Qui peut décider de s’en écarter, sur quelle base, et comment l’écart est consigné. Un principe sans procédure d’écart est contourné en silence ; un principe avec une procédure d’écart produit une trace, et cette trace dit quelque chose du principe lui-même. C’est la même logique que la dérogation signée : on ne retire à personne le droit de passer outre, on demande que ce choix ait un propriétaire.

Appliqué au principe sur les données de référence, l’exercice donne un texte court mais lisible par un comité. L’énoncé : chaque donnée de référence — client, produit, tiers, organisation — est créée et modifiée dans un seul système ; les autres la consultent ou en reçoivent une copie en lecture seule. La justification : les rapprochements entre systèmes mobilisent aujourd’hui des équipes et produisent des chiffres divergents dans les tableaux de bord de direction. Les implications : tout nouvel outil qui porte une notion de client devra s’alimenter depuis le référentiel, ce qui peut exclure certaines solutions ou imposer un développement d’interface ; les directions qui saisissent aujourd’hui des clients dans leurs propres outils devront passer par le référentiel. Le périmètre : les données de référence partagées, pas les données propres à un seul processus. L’écart : décidé par le propriétaire de la donnée concernée, consigné avec une date de réexamen.

Rédigé ainsi, le principe ne fait pas l’unanimité. Une direction au moins y verra une contrainte. C’est le signe qu’il est utile, et c’est le moment de le discuter — une fois, au moment de l’écrire, plutôt qu’à chaque projet.

Les principes se contredisent, et c’est normal

Les décisions difficiles ne se situent presque jamais dans le périmètre d’un seul principe. Elles naissent précisément là où deux principes légitimes indiquent des directions opposées.

Préférer les services managés d’un fournisseur de cloud réduit la charge d’exploitation ; préserver la réversibilité invite à éviter les services propres à un seul fournisseur. Privilégier le progiciel accélère la mise en œuvre ; garder la maîtrise des capacités qui différencient l’organisation pousse au développement. Mutualiser les plateformes réduit les coûts ; cloisonner les systèmes limite la propagation d’un incident. Aucun de ces principes n’est faux. Mais une liste qui les contient tous sans rien dire de leurs conflits laisse chaque camp choisir son principe, et ramène l’arbitrage au rapport de force.

Il n’est ni possible ni souhaitable de supprimer ces tensions : elles reflètent des objectifs réels de l’organisation. Il est en revanche possible de les écrire. Deux formes sont courantes.

Un ordre de préséance explicite. Lorsque deux principes s’opposent, l’un l’emporte par défaut, et l’autre ne peut prévaloir que par une dérogation motivée. Par exemple : la réversibilité prime sur la réduction de la charge d’exploitation, sauf pour les services dont la sortie a été estimée et jugée acceptable.

Une préséance conditionnelle. L’ordre dépend de la nature de ce qui est décidé. La carte des capacités métier est ici l’outil le plus naturel : pour une capacité de support, le marché l’emporte sur la maîtrise ; pour une capacité différenciante, l’inverse. La règle se lit alors capacité par capacité, et non plus principe contre principe.

Dans les deux cas, écrire la règle de préséance oblige à un débat que la liste initiale avait soigneusement évité. C’est inconfortable. C’est aussi la seule manière d’obtenir des principes qui servent le jour où ils sont réellement sollicités.

Éprouver une liste sur les décisions déjà prises

La meilleure manière d’évaluer une liste de principes n’est pas de la relire, mais de la confronter à des décisions réelles. L’exercice est simple, et il ne demande aucun outil particulier.

On retient une poignée de décisions structurantes prises au cours des dernières années — un choix de progiciel, un hébergement, une refonte, un recours à un service cloud. Si l’organisation tient un registre des décisions d’architecture, il fournit la matière ; sinon, les comités de direction et les dossiers de projet suffisent. Pour chaque décision et chaque principe, on pose une seule question : ce principe aurait-il orienté la décision, a-t-il été écarté, ou était-il muet ?

Trois constats sortent presque toujours de cet exercice.

Des principes muets partout. Ils n’ont orienté aucune décision, parce qu’aucune décision ne pouvait aller contre eux. Ce sont ceux qui échouent au test de la négation. Il faut les réécrire en choix, ou les retirer de la liste et les assumer comme des convictions.

Des principes écartés sans trace. La décision est allée à l’encontre du principe, et personne ne l’a consigné. Deux lectures sont possibles, et il faut choisir : soit le principe était juste et la gouvernance n’a pas fonctionné, soit la décision était juste et c’est le principe qu’il faut revoir. Dans les deux cas, l’absence de trace est le vrai défaut.

Des principes qui se contredisent sur un même cas. C’est le signal qu’une règle de préséance manque. Le cas réel fournit d’ailleurs le meilleur point de départ pour l’écrire : il est plus facile de s’accorder sur ce qui aurait dû l’emporter dans une décision concrète que sur une hiérarchie abstraite.

L’exercice a un mérite supplémentaire : il déplace la discussion. On ne débat plus de la formulation d’un principe en général, mais de ce qu’il aurait changé à une décision que chacun connaît.

Peu, courts, et réexaminés

Quelques règles de tenue découlent de ce qui précède.

Peu de principes. Un principe n’agit que s’il est présent à l’esprit de ceux qui décident au moment où ils décident. Au-delà de ce qu’un comité peut garder en tête sans relire le document, la liste cesse d’être un outil de décision et redevient un référentiel qu’on consulte après coup. Mieux vaut quelques principes qui tranchent que beaucoup qui rassurent.

Des principes cités. Chaque décision consignée devrait indiquer les principes qu’elle applique et ceux dont elle s’écarte. Au bout d’un an, un principe qui n’a jamais été cité est un candidat au retrait ; un principe qui fait l’objet d’écarts répétés est un candidat à la réécriture. Le registre des décisions devient ainsi l’instrument de révision de la liste.

Des principes réexaminés quand leur justification change. Pas seulement à date fixe, mais chaque fois que la raison écrite du principe évolue : une réglementation révisée, un fournisseur remplacé, une capacité qui cesse d’être stratégique. C’est l’intérêt d’une justification propre à l’organisation : elle porte en elle sa propre condition d’expiration.

Un principe est une décision prise à l’avance

La valeur d’un principe tient à une idée simple : il épargne à l’organisation de refaire le même arbitrage à chaque projet. Il concentre le débat en un seul moment — celui de sa rédaction — au lieu de le disperser dans des dizaines de comités, où il se rejoue chaque fois sous la pression d’un calendrier et d’un budget.

Cette économie a un prix, et il est impossible de l’éviter. Une décision prise à l’avance qui n’écarte rien n’a rien décidé ; une décision qui écarte quelque chose déçoit quelqu’un. Écrire des principes qui arbitrent, c’est accepter que ce désaccord ait lieu au moment de la rédaction, entre les personnes qui ont le mandat de le trancher, plutôt que plus tard, cas par cas, entre celles qui n’ont que la liste pour argumenter. Une liste qui a été approuvée sans débat n’a probablement encore rien tranché.