urbanisation-si.com

Les architectes et urbanistes du S.I. savent qu’il existe différents styles d’architecture possibles pour un S.I. : architecture orientée (micro) services, architecture hexagonale, architecture orientée événement, la conception par domaine, etc. Chacun va avoir son architecture privilégiée, son style architectural.

Il s’agit là des architectures orthodoxes [1], mais tout cela n’est que la partie émergée des architectures existantes en société. Il en existe en fait beaucoup d’autres, jamais identifiées, car jamais nommées, mais pourtant très présentes et très vivaces : les architectures catholiques [2] (je les tiens pour beaucoup plus répandues que les architectures orthodoxes). Je vous propose ici de combler ce manque en en décrivant quelques-unes.

Illustration créée par ChatGPT - DALL-E pour cet article

[1] Orthodoxe : « Qui est conforme à la doctrine officiellement reçue » « Qui s’accorde avec l’opinion couramment admise » (source : Dictionnaire de l’Académie française, 9e édition)
[2] Catholique : « universel » (source : Dictionnaire de l’Académie française, 9e édition)

L’Architecture orientée C.V. (AoCV)

Dans le S.I. où elle est appliquée, cette architecture va faire sourdre de manière isolée des technologies et façons de faire dans la tendance du moment.

Car ce S.I. est vu par ceux qui le font évoluer comme un moyen pour leur permettre d’ajouter des mots-clefs rémunérateurs à leur C.V.

Les composants technologiques à intégrer sont forcément nouveaux dans le S.I., puisqu’ils ont été choisis pour cela : ils sont à la mode, ils sont vendeurs.

On ne s’étonnera pas alors, une fois terminé le projet qui leur a permis de mettre en place ces technologies à la mode, de voir les personnes responsables de ces évolutions partir de leur société (le projet se terminera, car il doit se terminer coûte que coûte, contre toute évidence, non pas seulement à cause du biais d’engagement, mais aussi pour pouvoir « justifier d’une expérience réussie »). En effet, c’était bien là tout l’objectif de ceux qui ont fait les choix d’architecture en question.

Et puis, cela permet de ne pas avoir à assumer ces choix sur le long terme, laissant ainsi aux anciens collègues le soin de gérer une évolution faiblement documentée (pourquoi réaliser une documentation quand on sait dès le début que l’on ne nous la demandera jamais, qu’on ne la lira jamais, et que tout le travail effectué ne l’est que pour soi, et non pour la collectivité ?). Cette évolution est également sans cohérence avec le reste du S.I., donc en rupture avec les habitudes de ceux qui doivent le maintenir en bon état, d’autant qu’elle est facilement branlante, n’étant pas maîtrisée par ceux qui l’ont mise en place.

Ainsi vont fleurir les lacs de données là où une base de données relationnelle aurait suffi, ou encore des conteneurs et orchestrateurs de conteneurs, avec un bus d’événements, là où un développement 3 tiers tristement classique aurait parfaitement convenu, etc.

Le S.I. est (localement) vu comme un bac à sable, dont des enseignements seront tirés… pour le prochain employeur. Cette considération du S.I. comme terrain de jeux est d’ailleurs partagée par un autre style d’architecture assez proche, l’Architecture Orientée Plaisir, qui sera décrite plus après.
Il existe une variante de cette architecture, l’architecture ambitieuse, réalisée à coup de « projets ambitieux ». La montagne accouche alors d’une souris borgne et boiteuse, mais très gourmande.

L’Architecture orientée Histoire (AoH)

Cas symétrique du précédent, ici l’architecture dépend directement du passé de celui qui l'a mise en place. Celui-ci a à cœur de reproduire dans sa nouvelle société ce qu’il a déjà connu dans la précédente (autant que possible) : il ne veut pas de surprise, il sait déjà que cela marche, peut-être même a-t-il été embauché pour cela (et sait-il d’ailleurs faire autre chose ?).

Le contexte a changé, les capacités et les compétences de la D.S.I. présente (et les hommes qui la composent ou interagissent avec eux) ne sont pas les mêmes que celles de la D.S.I. précédente. Tout cela n’importe pas. On croit jouer la sécurité, alors que ce faisant on prend un risque (non identifié, non contrôlé). En fait, on a surtout envie de ne pas réfléchir.

Variante de ce style d’architecture, l’Architecture orientée Grand Éditeur, selon le fameux adage « aucun D.S.I. n’a jamais été viré pour avoir installé de l’IBM / du Microsoft / etc. ».

La société malade du contrôle de gestion

Faisons un petit aparté ici pour noter que ces deux premiers styles d’architecture S.I. ont ceci de commun qu’ils ne sont guidés que par des intérêts personnels, soit pour sortir, soit pour entrer dans une nouvelle société. Ceci étant une conséquence directe de la politique RH généralisée de quasi-non-augmentation de salaire (quant au plan de carrière…). La tension ainsi créée entre l’intérêt général et l’intérêt individuel entraîne logiquement une stratégie de contournement toute trouvée : si ma société ne m’augmente pas, alors je change de société avec une augmentation de salaire à la clef [3].

On ne saurait blâmer cette adaptation, mais il est à déplorer que les conséquences de décisions de contrôleurs de gestion et responsables RH (voire de responsables plus hauts placés) concernant la « masse salariale » et le « centre de coûts » que représente la D.S.I., sous couvert d’optimisations mesurables, entraînent des dégradations invisibles de qualité et de pérennité.

[3] C’est un peu comme si des opérateurs téléphoniques ne proposaient de promotions qu’aux nouveaux clients : forcément, cela pousse à aller voir ailleurs.

L’Architecture orientée Organisation (AoO)

Impossible de ne pas la mentionner, c’est la loi de Conway :

« Les organisations qui définissent des systèmes sont contraintes de les reproduire sous des conceptions qui sont des copies de la structure de communication de leur organisation. » [4]

Je ne m’étendrai pas sur cette loi déjà bien connue, qui a donc tout naturellement sa déclinaison au niveau du système… d’information. On obtient ainsi les fameux « silos » absolument partout dans la société, D.S.I. incluse, chaque directeur souhaitant gérer son budget comme il l’entend (comprendre : sans avoir à en discuter avec un quelconque voisin). D’où la dissémination de développeurs, de chefs de projets, d’acheteurs partout, n’importe où dans l’organisation, pour tendre vers un S.I. composé de plein de sous-S.I., à savoir un mini-S.I. par directeur. Résultat cocasse : dans une société, on pourra ainsi trouver plus de développeurs en dehors de sa D.S.I. qu’à l’intérieur.

Notons l’effet de l’égo qui participe à ce phénomène. Pour un responsable d’équipe, il est valorisant de gérer le plus grand nombre de subordonnés possible, mais également le plus grand budget possible. C’est comme cela que l’on monte dans le classement des « managers ».

Sans méthode ni volonté forte au plus haut niveau, la gestion de la complexité d’un S.I. est réalisée très simplement : il suffit de ne pas se parler. Chaque sous-organisation s’isole dès que possible et autant que possible. Au final, le système est cassé. Il en résulte plusieurs sous-systèmes isolés et, le tout ne pouvant alors être supérieur à leur somme, il n’y a pas de propriété émergente globale (raison d’être de « faire système »).

En particulier, toute organisation à vocation transverse, autrement dit cherchant à mettre du liant avec les autres, doit être, précisément pour cette raison, disqualifiée par toutes les autres par tous les prétextes possibles : trop chère, pas assez compétente, manquant de pragmatisme, pas assez réactive, trop lointaine, etc. Les intérêts étant pour une fois convergents, le consensus se fait pour crier haro sur le baudet.

Effet annexe de cette architecture : c’est le bonheur pour les éditeurs qui peuvent proposer un logiciel plusieurs fois à la même société. Son outil n’a-t-il pas été retenu dans un appel d’offres d’une société ? Il pourra toujours retenter sa chance avec cette même société pour outiller le même périmètre logique à l’occasion d’un autre appel d’offres, mais cette fois-ci passé par une autre partie de son organisation. Son outil a-t-il été retenu dans un appel d’offres ? Il pourra tout aussi bien retenter sa chance dans un autre appel d’offres de la même société, avec la garantie qu’il n’y aura pas de renégociation tarifaire par le client (les clients, de facto) pour bénéficier d’un effet de volume.

Au final, gabegie financière et faiblesse capacitaire.

[4] Melvin Conway, How Do Committees Invent?

L’Architecture orientée Plaisir (AoP)

Les informaticiens sont — assez logiquement — des technophiles. Et nombreux gardent, et c’est heureux, une soif de savoir, un esprit de découverte, qui est forcément nourri par une discipline qui ne cesse d’évoluer à un rythme rapide. Ainsi, certains, qui vont être amenés à pouvoir choisir une technologie, vont succomber à la tentation d’en choisir une, parce qu’elle leur plaît, parce qu’ils ne la connaissent pas (encore), parce qu’elle va leur proposer un défi technologique, parce qu’elle va leur permettre d’explorer de nouvelles façons de faire, d’étancher un temps leur soif de savoir et de savoir-faire. Un expert d’un domaine informatique trouvera toujours une évolution de son champ de connaissance et une évolution des — forcément nombreux — domaines connexes à celui-ci.

Cela peut expliquer pourquoi on pourra observer dans un S.I. un foisonnement de technologies plus ou moins exotiques pour répondre de diverses manières à une même question qui se pose plusieurs fois - et qui, donc, ne devrait plus se poser - (plusieurs technologies de serveurs de bases de données relationnelles, plusieurs mécanismes d’échanges d’un même type de données…).

L’informatique devient alors un jouet (au lieu d’être un outil), une fin en soi (au lieu d’être un moyen), et le S.I. se transforme en un terrain de jeux.

À la décharge de ceux qui mettent en place une telle architecture, il faut dire que nous vivons dans une culture qui prône la nouveauté comme une vertu : le temps n’existe plus, puisque nous sommes dans un perpétuel présent, la dernière nouveauté faisant table rase du passé (c’est tout du moins sa promesse). « Le changement, c’est maintenant », puisque avant et plus tard n’existent pas, le changement les ayant fait disparaître. Le changement fait le présent et nous y enferme ; en fait, ce slogan est en creux une définition : maintenant est le changement. Et l’informatique est un terreau particulièrement fertile pour illustrer, encourager cette idéologie : on ne compte plus les « innovations de rupture », les technologies « disruptives ».

Cependant, si, le nez sur le guidon, seul le présent semble subsister, en prenant du recul, la perception est toute autre. Paradoxalement, c’est en fait dans un S.I. où les changements sont les plus fréquents que l’écoulement du temps est le plus visible. En effet, les technologies s’ajoutant sans complètement se remplacer, on peut voir des strates technologiques se superposer pour raconter, comme des strates géologiques, son histoire.

Rappelons aussi, à toutes fins utiles, qu’une nouveauté a émergé dans un certain contexte d’emploi, et n’est pas forcément bénéfique dans un autre. Et que, outre sa pertinence, on ne sait rien de sa pérennité (notion cardinale pour un architecte). Enfin, ce qui est vieux n’est pas forcément obsolète. Une technologie « ancienne » toujours utilisée a le bon goût d’être éprouvée, et ses capacités comme ses limites sont connues et largement documentées. Son utilisation dans son cadre correspondant sera ennuyeusement sûre et n’apportera aucune gloire, aucun frisson, tout au plus la satisfaction d’avoir simplement servi les utilisateurs du S.I. (mais n’est-ce pas là le suprême sens du service de tout informaticien ?).

Nous n’avons ici passé en revue que quelques-unes des architectures catholiques du S.I. Il nous en reste d’autres à dévoiler, que nous vous proposerons dans une seconde partie. 

"Les erreurs ne se regrettent pas, elles s'assument. 
La peur ne se fuit pas, elle se surmonte. 
L'amour ne se crie pas, il se prouve."
Simone Veil