Le schéma directeur a été validé il y a trois ans. La cible était claire : retirer l’ancien système de gestion, constituer un référentiel client unique, mettre en place une couche d’intégration commune, quitter le datacenter historique. Le document a été présenté en comité de direction, salué, puis rangé.

Depuis, chaque année, le comité budgétaire a arbitré une liste de projets. Une obligation réglementaire a été traitée dans l’ancien système, parce que c’était le plus rapide. Une direction commerciale a obtenu un outil qui porte sa propre base clients, parce qu’il répondait à son besoin. De nouveaux produits ont été lancés sur le cœur existant, parce que le remplaçant n’était pas prêt. La couche d’intégration n’a jamais été financée : aucune direction ne la portait. Chacun de ces arbitrages se défendait. Aucun n’a été présenté comme un renoncement à la cible.

Trois ans plus tard, l’ancien système est plus central qu’avant, il existe une base clients de plus, et la cible n’a pas été abandonnée : elle n’a simplement jamais été construite. L’architecture réelle d’une organisation n’est pas celle que décrit son schéma directeur, c’est celle que finance son portefeuille de projets. La cible propose ; le portefeuille dispose. Tant que la cohérence avec la cible n’entre pas dans les critères qui décident du financement, la cible reste une intention.

Pourquoi la cible et le portefeuille divergent

L’écart ne vient presque jamais d’une volonté de contourner l’architecture. Il tient à la façon dont les deux exercices sont menés.

Les projets sont instruits un par un. Une demande de financement se juge sur sa propre valeur : le besoin qu’elle couvre, son coût, son délai, son risque. La question de ce qu’elle fait à l’ensemble du système d’information n’est pas dans la grille. Un projet peut donc être excellent en lui-même et éloigner l’organisation de sa cible, sans que rien dans le dossier ne le signale.

Les deux exercices n’ont pas le même rythme. Le schéma directeur se pense sur plusieurs années ; le budget se vote chaque année, souvent sous contrainte. Le premier est révisé rarement, le second toujours. À force, c’est le second qui fait foi.

Les mouvements structurants n’ont pas de sponsor. Un socle d’intégration, un référentiel partagé, le retrait d’un système : ces chantiers profitent à tout le monde et n’appartiennent à personne. Dans un arbitrage où chaque direction défend ses projets, ils n’ont aucun porteur. Ils sont reportés, non parce qu’on les juge inutiles, mais parce que personne ne les présente.

Le chemin court passe par l’existant. Prolonger un système en place coûte presque toujours moins cher, à court terme, que construire sur son remplaçant. Les obligations réglementaires, qui ne se négocient pas, prennent ce chemin par défaut. Chaque investissement de ce type rend le suivant plus probable, et le retrait plus coûteux — c’est le mécanisme par lequel la dette technique se finance sans être jamais décidée.

Les décisions se prennent ailleurs. Une partie des choix structurants est faite dans des circuits où l’architecture n’est pas présente — l’arbitrage budgétaire, les achats, la direction métier. C’est la situation décrite dans quand le métier décide sans l’architecture : lorsque le projet arrive à la DSI, ce qu’il fait à la cible est déjà fixé.

Lire un portefeuille comme une trajectoire

Un portefeuille de projets est rarement présenté comme une architecture. Il l’est pourtant : chaque projet crée, prolonge, remplace ou retire des systèmes, et touche des capacités métier. Rien n’empêche de le lire ainsi.

L’exercice est simple. On part de la liste des mouvements que la cible annonce — ce qui doit apparaître, ce qui doit disparaître, ce qui doit être consolidé. On prend ensuite la liste des projets financés sur la période, et pour chacun on pose une question : par rapport à ces mouvements, ce projet rapproche-t-il l’organisation de la cible, l’en éloigne-t-il, ou est-il sans effet ?

Les mouvements de la cible confrontés aux projets financés CIBLE ANNONCÉE PROJETS FINANCÉS Retirer l'ancien cœur de gestion Un référentiel client unique Une couche d'intégration commune Un portail client refondu Quitter le datacenter historique aucun projet Mise en conformité dans l'ancien cœur Outil commercial avec sa base clients Refonte du portail client Migration des applications vers le cloud Nouveaux produits sur l'ancien cœur Tableaux de bord de direction hors cible rapproche de la cible éloigne de la cible
Schéma 1 Les mouvements annoncés par la cible, confrontés aux projets financés. Deux mouvements avancent. L'ancien cœur que la cible retire reçoit deux investissements qui le prolongent. Le référentiel client unique n'est touché que par un projet qui crée une base de plus. La couche d'intégration n'a aucun projet. Exemple illustratif : la cible et les projets sont génériques.

La lecture n’a besoin ni d’un outil ni d’un modèle exhaustif. La carte des capacités métier aide à situer les projets et à repérer ceux qui touchent la même capacité sans se connaître. Un inventaire applicatif, même sommaire, suffit à savoir quels systèmes chaque projet prolonge. L’essentiel est de poser la question pour chaque projet, et pas seulement pour ceux que l’architecture a eu l’occasion de revoir.

Le résultat est presque toujours plus instructif que la relecture du schéma directeur. Il montre la trajectoire que l’organisation suit réellement, et la compare à celle qu’elle croit suivre. C’est souvent la première fois que les deux sont posées côte à côte.

Les trois signaux de l’écart

Trois configurations reviennent dans presque tous les portefeuilles confrontés à leur cible.

Des mouvements sans aucun projet. Ce sont presque toujours les mêmes : les socles partagés, les référentiels, les retraits. La cible les annonce depuis plusieurs années, aucun budget ne les porte. Ce signal ne dit pas que la cible est mauvaise ; il dit que la manière dont le portefeuille est constitué ne peut pas les financer, puisqu’il ne finance que ce qu’une direction demande.

Des projets qui investissent dans ce que la cible retire. Chaque investissement se justifie isolément — une obligation, un produit, une interface. Mais chaque cycle budgétaire repousse la date de retrait d’un an ou deux, et le système à retirer devient plus difficile à remplacer à chaque fois. Personne n’a décidé de le garder ; il est simplement prolongé à chaque arbitrage.

La date de retrait d'un système recule à chaque arbitrage budgétaire Année 1Année 2Année 3Année 4Année 5Année 6 retrait prévu au départ Budget année 1 extension réglementaire Budget année 2 nouveaux produits Budget année 3 interface vers un nouvel outil Budget année 4 montée de version de l'éditeur Chaque projet se défend seul ; ensemble, ils repoussent le retrait à chaque cycle. investissement financé retrait prévu date prévue au cycle précédent
Schéma 2 La date de retrait d'un système que la cible prévoit de remplacer. À chaque cycle budgétaire, un investissement raisonnable est financé dans ce système, et le retrait est replanifié plus tard. Aucune décision de le conserver n'a été prise ; le recul résulte de la somme des arbitrages. Exemple illustratif : les années sont relatives.

C’est la configuration la plus coûteuse, parce qu’elle combine les deux mondes : l’organisation finance le remplaçant et continue de financer ce qu’il devait remplacer. La période de coexistence, que la trajectoire avait prévue provisoire, devient permanente.

Des projets qui créent ce que la cible consolide. Une nouvelle base clients dans un outil métier, un nouveau flux point à point alors que la cible prévoit une couche commune, un nouvel hébergement hors de la trajectoire cloud. Ces projets ne s’opposent à rien de façon visible : ils ajoutent simplement un élément à ce que la cible voulait réduire.

Un quatrième constat apparaît parfois, et il mérite autant d’attention : des projets importants qui n’ont aucun lien avec la cible. Ce n’est pas forcément un défaut du portefeuille. C’est parfois le signe que la cible ne couvre pas une priorité réelle de l’organisation.

Faire entrer l’architecture dans l’arbitrage

La réponse habituelle consiste à demander un avis d’architecture sur chaque projet. Elle échoue pour une raison simple : l’avis arrive après la décision de financement, ou il est rendu par une fonction qui n’a pas de voix dans l’arbitrage. Il faut au contraire que l’effet sur la cible soit une information disponible au moment où l’on décide.

Une fiche d’impact courte, jointe à chaque demande de financement. Quelques rubriques suffisent : les capacités métier touchées ; les systèmes que le projet crée, prolonge ou permet de retirer ; son effet sur la cible — la rapproche, sans effet, l’éloigne ; et les coûts futurs qu’il engage, d’exploitation comme de sortie, car le coût total de possession se décide à ce moment. La fiche est remplie par le porteur du projet, avec l’architecture, avant l’arbitrage — pas par l’architecture seule, après.

Un critère dans la grille de priorisation, pas un veto. Un projet qui éloigne de la cible peut être financé : l’urgence réglementaire ou commerciale le justifie parfois. Ce qui change, c’est que l’écart est visible et qu’il a un propriétaire. Le comité décide en connaissance de cause, et la décision est consignée comme un écart, avec une date de réexamen. C’est la logique de la dérogation signée, appliquée au portefeuille.

Un financement explicite pour ce qui n’a pas de sponsor. Les mouvements structurants ne seront jamais portés par une direction. Deux mécanismes existent. Le premier est une enveloppe dédiée aux socles et aux retraits, arbitrée comme telle, avec un responsable désigné. Le second consiste à rattacher le mouvement au projet qui en bénéficie : le financement d’un nouveau système inclut le décommissionnement de celui qu’il remplace, et le projet n’est pas considéré comme terminé tant que l’ancien tourne encore.

Une lecture du portefeuille entier, une fois par cycle. Au-delà des projets pris un par un, l’exercice du schéma 1 se refait à chaque arbitrage annuel, sur l’ensemble du portefeuille. Il prend peu de temps et répond à une question qu’aucun dossier individuel ne pose : si nous finançons cette liste, où en serons-nous dans trois ans ?

Parfois, c’est la cible qui a tort

Confronter le portefeuille à la cible ne revient pas à donner raison à la cible par principe. Si, cycle après cycle, le comité finance des projets qui s’en écartent, deux explications sont possibles : soit les arbitrages manquent d’information sur leur effet, soit la cible ne reflète pas les priorités réelles de l’organisation.

La seconde hypothèse doit être prise au sérieux. Une cible écrite sans tenir compte des capacités de financement, des compétences disponibles ou des contraintes réglementaires ne sera jamais construite, quelle que soit la qualité de la gouvernance. Le portefeuille est alors la meilleure source d’information pour la réviser : il montre ce que l’organisation est prête à payer, et ce qu’elle ne finance jamais.

La révision doit cependant être une décision, pas une dérive. Abandonner un mouvement de la cible, c’est en assumer les conséquences — garder deux bases clients, maintenir l’ancien cœur, renoncer à la couche commune — et le dire. Ce qui est coûteux, ce n’est pas de changer de cible ; c’est d’en garder une sur le papier pendant que le portefeuille en construit une autre.

La cible qui s’exécute

Une architecture cible n’a d’effet que par les projets qu’elle oriente. Tout le reste — les schémas, les principes, les comités — n’agit qu’à travers ce canal. C’est pourquoi la question la plus utile à poser à un schéma directeur n’est pas « est-il juste ? », mais « quels projets a-t-il changés ? ».

L’organisation qui veut que sa cible se réalise n’a pas besoin d’une gouvernance plus lourde. Elle a besoin que la cible soit présente au seul moment où elle peut peser : celui où l’on décide de ce qu’on finance. Le reste du temps, le portefeuille dessine l’architecture à sa place, avec la même assurance et sans jamais le dire.