urbanisation-si.com

Voici la seconde partie de notre exploration des architectures catholiques du S.I. (commencée ici "Les architectures catholiques du S.I. (1/2)"), étant entendu que celle-ci ne se prétend en aucune manière exhaustive.

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

L’Architecture orientée Bidouille (AoB)

Cette architecture très populaire est guidée par la recherche systématique d’une solution à court terme facile à trouver, facile à réaliser, et peu coûteuse, le sacro-saint « quick win ». Bref, l’idéal quand on n’a pas affaire à un système (d’information), et quand le périmètre du sujet traité a une durée de vie courte… ce qui n’est quasiment jamais le cas. Ce style d’architecture du S.I. aboutit ainsi à mettre de la bidouille sur de la bidouille sur de la bidouille (vous me rajouterez un peu de bidouille pour corriger les effets d’une bidouille précédente…), jusqu’à ce que, étonnamment, le coût de l’ensemble devienne insupportable, sa qualité devienne déplorable et son évolutivité quasi nulle.

Cette architecture a quelques caractéristiques qui méritent que l’on s’y attarde. Premièrement, elle n’est quasiment pas documentée. Normal, puisque sa logique est systématiquement court-termiste alors que la documentation, par essence, s’effectue dans une démarche d’héritage, de transmission, donc de moyen / long terme — paradoxe savoureux, cette logique court-termiste peut courir pendant des années ; c’est même pour cela qu’elle est douloureuse.

Deuxièmement, elle se construit par des bonds réalisés par un individu. En effet, comme chaque évolution est petite, elle n’est réalisée que par une seule personne, celle qui la plupart du temps l’aura d’ailleurs préalablement proposée (« Je peux le faire » annonce ainsi fièrement celui qui pourra ensuite se targuer d’être celui qui aura « solutionné le problème » si efficacement, faisant ainsi le bonheur du chef de projet ou du responsable hiérarchique qui aura ainsi « tenu le budget »). Ce phénomène renforce d’ailleurs l’absence de documentation (« la documentation est dans le code », en fait dans sa tête), car celui qui réalise devient également celui qui maintient. Et ce dernier va se faire un plaisir, au gré des évolutions demandées, de faire grossir son paquet de bidouilles (d’autres termes moins fleuris, mais tout aussi pertinents, pourraient venir à l’esprit du lecteur espiègle, mais je lui en laisserais l’entière responsabilité).

Précisons bien que cela ne signifie pas qu’un seul individu est à l’origine de toute la bidouille présente dans le S.I. On peut parfaitement y trouver plusieurs paquets de bidouilles, chacun ayant son propre auteur. Et pour boire le calice jusqu’à la lie, un paquet de bidouilles peut parfaitement traiter de sujets qui n’ont rien à voir entre eux. Simplement, comme ils ont été traités par une même personne qui ne veut pas s’embêter à faire un autre paquet (dans tous les cas, c’est son « quick win »), ils se retrouvent intriqués, interdépendants.

Il y a alors une seconde phase dans cette architecture : la vitrification. Le temporaire s’éternise. Car, certes, le coût de l’ensemble devient exorbitant, mais le coût du remplacement l’est également (avec en plus un certain degré d’incertitude). Un consensus s’établit alors pour décider que, même s’il fallait le remplacer, il est urgent d’attendre, d’autant que l’on souhaite réaliser des dépenses d’investissement sur un autre sujet un peu plus glamour (la même décision, basée sur le même constat et la même envie, sera donc prise l’année suivante, et la boucle est bouclée). Il est à noter que, bizarrement, personne ne songe à demander au créateur et mainteneur du tas de bidouilles de mettre à profit l’année perdue pour le documenter et ainsi faciliter son remplacement.

Eh oui, l’existant coûte, mais il s’agit là d’un « coût de fonctionnement », donc peu sexy, qui n’intéresse personne ou presque, tant qu’il reste en dessous d’un certain seuil de douleur.
Le « build » (et son coût) est surveillé, l’affectation de son budget pour l’année à suivre peut faire l’objet d’innombrables réunions pendant des mois, mais le « run », lui, est subit. Voici une illustration de plus que la psychologie a un impact fondamental sur l’architecture d’un Système d’Information.

Il est valorisant de construire, mais pas de maintenir, ni encore moins de détruire. Nos écoles d’ingénieurs forment des bâtisseurs, pas des nettoyeurs. Qui a déjà été félicité pour avoir nettoyer les écuries d’Augias : décommissionner n logiciels inutiles, redondants, voire dangereux, ou pour avoir supprimer des flux illogiques [5] et optimiser des communications en point-à-point ? Alors qu’ajouter (ou remplacer) un logiciel entraîne facilement une bonne publicité interne.

Autre biais psychologique, un tas de bidouilles étant l’émanation d’une seule personne, il devient son bébé. Elle l’aura créé, elle l’aura fait grandir, elle est la seule à vraiment le connaître (il assoit sa légitimité), et il peut même devenir pour cette raison son activité principale. À partir de là, on comprend bien qu’elle aura donc du mal à accepter d’en faire la critique et à le voir disparaître. Autrement dit, encore une fois, cette architecture crée une tension entre l’intérêt général et des intérêts individuels.

[5] Pour le coup, j’ai quand même eu cette chance une fois dans ma carrière.

L’Architecture par Népotisme (ApN)

Les liens interpersonnels qui se créent dans une société en débordent : les personnes qui changent d’organisation ou qui passent d’une société à une autre conservent des liens avec de précédents collègues (d’autant que les autres sociétés vers lesquelles aller assez facilement participent logiquement d’un même écosystème ; elles sont soit clientes, soit fournisseuses, soit concurrentes, de la première : on a donc une certaine probabilité de retrouver d’anciens collègues quand on en quitte une), les anciens élèves d’une même école nourrissent leur réseau, les liens familiaux s’en mêlent, des couples se créent, ou encore d’aucuns utilisent leur proximité avec certains collègues pour créer leur société avec la certitude que celle-ci aura comme premier (seul ?) client celle qu’ils viennent précisément de quitter.

On comprend mieux ainsi pourquoi toute analyse architecturale tentant, par exemple, de démontrer l’absurdité de payer un fournisseur proposant une technologie de chaînes de blocs à localisation centralisée et contribution unique sera peine perdue si son dirigeant possède des liens très étroits avec les « bonnes » personnes de la société cliente, et l’auteur de cette analyse sera logiquement gentiment prié de la mettre sous le boisseau.

Ce style d’architecture possède des variantes : l’Architecture sur Canapé
et l’Architecture par Corruption.

L’Architecture orientée Éditeur / Intégrateur (AoE)

Architecture que l’on pourrait également appeler l’Architecture par Délégation. Pour intégrer un nouveau logiciel dans un S.I., son éditeur va naturellement être sollicité (soit directement soit indirectement, via un intégrateur). Et celui-ci a naturellement envie que cette intégration soit la plus rapide possible pour que la vente lui soit la plus rentable possible. Il peut donc vouloir limiter ses risques en poussant une architecture qu’il connaît, des moyens de communication qu’il maîtrise, indépendamment du style d’architecture existant ou souhaité de son client ni de son besoin.

Si les critères d’intégration n’ont pas été pris en compte en amont, si l’équipe interne n’est pas suffisamment ferme, suffisamment volontaire et informée, ou tout simplement si une architecture S.I. n’a pas été conçue, alors chaque éditeur, selon son historique, son niveau de maturité sur telle ou telle technologie ou encore sa stratégie, va orienter localement le S.I. dans une certaine direction. Ici une communication par API REST, là par échanges de fichiers. Ici l’utilisation d’un logiciel médiateur, là une communication point-à-point, là encore l’installation d’un orchestrateur de l’éditeur, et là enfin une transmission de données par courrier électronique (les variantes sont quasi infinies).

Quand on ne sait pas où l’on veut aller, d’autres prendront la barre.

Ce type d’architecture est apparemment très bénéfique à chaque projet, car ainsi certains risques ont été maîtrisés et la probabilité de finir dans le temps et dans le budget imparti est augmentée. Voilà deux critères mesurables, et donc des indicateurs systématiquement suivis par la chefferie de projet. Mais voilà, un projet n’est pas isolé — c’est même le principe de travailler dans et pour un système, donc une optimisation locale peut très bien aboutir à une dégradation globale.

En plus de l’éditeur ou intégrateur, l’une des sources de ce style d’architecture est à trouver dans l’organisation : ceux qui participent à la phase de changement sont rarement ceux qui participent à celle du maintien en condition opérationnelle, autrement dit ceux qui « optimisent » durant un temps fini ne sont pas ceux qui vont en subir les conséquences sur le temps long de l’utilisation (pour ceux qui décident de le — laisser se — mettre en place, ce style d’architecture est bénéfique sur le court terme et indolore sur le long terme ; pour ceux qui en héritent, en revanche…).

Si les caractéristiques précédemment décrites de ce style d’architecture de S.I. le font ressembler à un paquet de confettis, il peut aussi évoluer selon une même logique sur un large périmètre lorsqu’un unique éditeur participe à tout un sous-ensemble du S.I. (c’est typiquement le cas pour les GAFAM [6] qui proposent des outils intégrés pour stocker, diffuser, traiter et représenter des données). Dans ce cas, il pourra orienter l’architecture d’une partie significative — si elle n'est pas structurante — du S.I. de ses clients simplement en changeant sa politique de licences. Ici, la perte de souveraineté de la société sur son S.I. est à peu près totale, car ce dernier appartient, de facto, à un éditeur : d’une part, il a connaissance de tout le savoir de la société (il stocke ses fichiers, données structurées et courriers électroniques) et, d’autre part, il peut piloter son patrimoine logiciel et ses choix technologiques.

Deux facteurs contribuent à ne pas sortir de cette dépendance : tout d’abord une question d’égo, car en changer reviendrait à reconnaître qu’une décision stratégique, prise à très haut niveau et impliquant des sommes colossales, a été mauvaise, et ensuite, car le coût de la prise d’indépendance est considéré comme bien supérieur au coût du maintien de l’inféodation (d’année en année, le coût de la D.S.I. doit augmenter, et/ou la part prise par l’éditeur sur le budget de la D.S.I. doit grossir ; la vache à lait n’a d’autre choix que de se laisser traire — jusqu’à ce qu’une certaine limite soit franchie, et alors des décideurs soient changés).

Tant qu’il n’y a pas de changement de décideur, il n’y a pas de changement de décision.

[6] Mais ils sont loin d’être les seuls ; citons simplement SAP.

L’influence de la SMARTabilité sur le S.I.

Coût, Délai, Qualité, Pérennité : sur ces quatre caractéristiques, 2 sont mesurables, 2 autres ne le sont pas. 2 sont faciles à définir, 2 autres sont ambiguës. 2 sont sensibles uniquement à court terme (sauf cas extrêmes), 2 sont sensibles à moyen / long terme : lesquelles seront suivies par des KPI, d'après vous ? Pour un tableau de bord, ce qui ne se mesure pas n’existe pas ; ça vous énerve ?

Deuxième aparté, qui prolonge d’ailleurs celui de la première partie, sur la non-prise en compte de la qualité et la pérennité dans la construction d’un S.I. En effet, n’étant pas mesurables, ces caractéristiques ne sont par conséquent jamais dans les objectifs « SMART » de l’Entretien Individuel de Performance (E.I.P.) annuel d’un quelconque salarié. Typiquement, les chefs de projets s’y intéresseront diversement, selon les appétences des uns et des autres, alors que les coûts et les délais des projets seront observés par tous (et pourront même permettre de comparer les chefs de projets entre eux).

Par ailleurs, comment espérer avoir des actions collectives cohérentes quand les objectifs à atteindre ne sont tous qu’individuels ? Quelle société rend public (en interne) l’ensemble des objectifs individuels qu’elle donne ? Quelle société s’assure de la cohérence de ces objectifs, s’assure qu’ils n’entrent pas en conflit les uns les autres (et l’assure à ses membres) ? Quelle société, enfin, a mis en place des Entretiens Collectifs de Performance ?

L’Architecture Syncrétique (AS)

Finissons en apothéose, car tous ces styles d’architectures ne sont pas mutuellement exclusifs ! Il est donc parfaitement possible de voir une combinatoire de tous les styles d’architectures précédemment décrits dans un seul et même S.I.

Conclusion

Dans un S.I., il y a des décisions prises, parfois bien obscures pour un architecte S.I. se voulant orthodoxe. Et ce bref panorama de styles d’architecture rencontrés dans les sociétés devrait rendre modeste tout architecte du S.I. attitré. D’une part, il importe avant toute chose de voir la poutre qui est dans son œil, car sous couvert de promouvoir une architecture orthodoxe, il met probablement lui-même en place, sans s’en rendre compte, une architecture catholique. D’autre part, il n’a pas la main — et il ne l’aura jamais — sur les facteurs structurants d’un système d’information : politique RH, contrôle de gestion, structure organisationnelle, choix de nouveaux salariés, biais psychologiques, principes culturels ; tout cela est décidé ou existe sans lui.

Et, vis-à-vis de ces enjeux, pourtant incontournables comme nous l’avons vu, pour qui souhaite maîtriser la complexité d’un S.I., aucune méthode, aucun cadre d’urbanisation du S.I., ne lui sera d’aucune utilité, d’aucun secours, car aucun ne les traite de front (et à plus forte raison, aucun logiciel ni aucun langage de modélisation). En outre, appartenant le plus souvent à une organisation transverse dédiée, il n’a par conséquent à sa disposition ni carotte ni bâton vis-à-vis des directeurs, chefs de projets, développeurs, intégrateurs, etc., qui font du S.I. ce qu’il est. Tout est-il pourtant perdu pour l’esthète ? Non, mais c’est un autre sujet.

Chers confrères architectes ou urbanistes du S.I., si ce que je vous ai proposé vous parle, je vous invite maintenant à amender, enrichir ou illustrer (par de croustillantes anecdotes) les architectures présentées ici en commentaire.

"La beauté, c'est l'harmonie du hasard et du bien.
Sachons faire confiance à la jeunesse pour conserver à la vie sa valeur suprême."
Simone Veil