[Théma] Et si l’on parlait architecture !


Zahnräder 2

Que ce soit pour un architecte classique, d’intérieur ou informatique, la démarche intellectuelle est, à quelques variantes près, la même… son objectif principal reste celui de concevoir une architecture qui garantisse la cohérence entre tous les éléments qui la composent afin de répondre au mieux à l’ensemble des exigences et contraintes de son environnement.

Pour mieux comprendre tous les enjeux d’une architecture dite « réussie », servons nous de l’analogie de l’architecte classique.

Il n’est pas rare de voir de magnifiques bâtiments très design sortir de terre.
Ceux ci font bien souvent le prestige et la renommée de l’architecte ou de son cabinet.
Mais, même si l’aspect extérieur d’un bâtiment peut paraître réussi au premier abord, cela reste du domaine du subjectif car très interdépendant de la mode du moment, du style utilisé, de la sensibilité de chacun, des sommes investies,… et il ne faudrait pas confondre esthétisme et qualité.
Ainsi, les passants qui le regardent depuis la rue n’ont par définition pas accès à l’intérieur, ni aux plans du bâtiment et donc ne peuvent y porter qu’un jugement incomplet, voire erroné. Tandis que ses occupants pourront le juger selon des critères plus concrets et objectifs. Enfin, l’architecte ne serait pas grand-chose sans lesmaîtres d’œuvre et les ouvriers qui ont réalisé les prouesses techniques nécessaires pour ériger l’édifice.

« Seul le temps reste le véritable juge de paix »

C’est pourquoi, ce qui permet de caractériser la réussite finale d’un projet doit être avant tout du domaine du pragmatisme, à savoir sa fonctionnalité, son ergonomie, sa modularité, son intelligence d’agencement, sa sécurité, son coût global, son délai de livraison, sa capacité de maintenance et d’entretien,…
En réalité, on s’aperçoit que seul le temps reste le véritable juge de paix dans cette affaire car c’est uniquement après une période plus ou moins longue, après réception du bâtiment, que l’on pourra juger concrètement de la justesse des décisions prises et que l’on verra apparaître (ou pas) les défauts de conception ou de fabrication, ainsi que les vices cachés.
C’est pour cela que parfois l’on constate qu’un splendide projet sur le papier devient invivable ou inhabitable une fois réalisé. J’appelle cela le syndrome du « papier glacé » car dans ce cas précis seul compte la photo que l’on pourra faire pour apparaître en couverture du prochain mensuel de déco à la mode… et ceci au détriment d’autres aspects moins glamour mais beaucoup plus fonctionnels et pérennes.

« Leurs concepteurs ne se sont jamais imaginer y vivre »

Combien de constructions ont ainsi été des échecs retentissants car leurs concepteurs ne se sont jamais imaginer y vivre un seul instant dedans et ont simplement tenté d’assouvir des fantasmes personnels ou parce qu’ils ont cherché à reproduire ce qu’un confrère (ou concurrent) avait déjà fait ailleurs, en faisant abstraction complète du contexte et de l’environnement proche dans lequel ce fameux projet a vu le jour.

L’architecture informatique doit être considérée de la même façon car ceux qui y « vivent » sont avant tout ceux qui l’administreront (à savoir le Service IT), avant même de penser aux investisseurs et à ceux qui l’utiliseront depuis l’extérieur (les utilisateurs finaux). Je sais, cela peut paraître excessif et provocateur de dire cela car, bien entendu, une infrastructure doit en priorité fournir aux utilisateurs finaux le service attendu (en général ce sont quand même eux qui payent la note). Mais penser uniquement de cette façon, c’est comme si vous faisiez pousser de la vigne hors-sol, en imaginant que pour faire un bon vin il suffirait de lumière et d’engrais, et que tous les éléments fournis par le terroir seraient inutiles ou insignifiants.

« Il est très important qu’un architecte informatique comprenne les enjeux et les contraintes de la Production »

Ce faisant, concevoir une infrastructure c’est aussi savoir être ouvert d’esprit et prendre toute la mesure des capacités techniques, humaines, procédurales et managériales d’une entreprise. Par exemple, la simple copie ou transposition d’une architecture réussie, dans un service IT mature, peut s’avérer ingérable, voire désastreuse dans un service IT immature, en sous effectif, incompétent, mal géré, en restriction budgétaire ou soumis à des tensions internes.

C’est pourquoi il est très important qu’un architecte informatique comprenne les enjeux et les contraintes de la Production (idéalement il faudrait que ce soit un ancien de la Prod) et prenne le temps d’écouter et de comprendre ces personnes car en réalité elles devront adhérer à la vision qu’il tentera de leur « imposer ». Quoiqu’il en soit, il devra toujours intégrer le degré de maturité de son SI car au final ce seront ceux qui la composent qui feront que cette architecture connaîtra un franc succès. Sinon, celle-ci sera vouée à vivre des échecs fréquents et permanents (downtime, outage, maintenances) et devra tôt ou tard être repensée, voire cassée partiellement ou entièrement (engendrant d’immenses surcoûts). Au final, ce seront les utilisateurs finaux qui seront les grands perdants : ils auront payé, parfois très cher, pour un service médiocre, voire inexistant.

« L’architecte n’a donc pas seulement un rôle purement technique »

Ainsi, l’architecte devra donc, en plus des aspects techniques de conception, prendre en compte les chantiers nécessaires de formation, de rédaction de documents d’exploitation, de profils clés manquants et/ou à recruter, des supports à souscrire auprès de prestataires ou de fournisseurs, des fréquences et des modalités des tests de PRA (Plan de Reprise d’Activité), du degré de collaboration et de cohésion nécessaire entre les services Etudes/Prod/Dev,… et tout ceci en ayant du respect pour le travail que fournit l’ensemble de ces personnes (sans les mépriser, ni les humilier car vous n’aurez pas les moyens de renouveler tout un service, soyez en sûr !).

N’oublions jamais que tout comme dans la sécurité, on ne jugera une infrastructure qu’en fonction de son maillon le plus faible. Cela implique d’avoir une réflexion précise, sans préjugés ni tabous sur chacun des éléments qui composent l’architecture afin de s’assurer de leur meilleure imbrication dans la vision globale que l’architecte souhaite mettre en œuvre.

Comme vous pouvez le constater, l’architecte n’a donc pas seulement un rôle purement technique, il doit aussi et surtout assurer l’équilibre indispensable et subtile de la pertinence de ses choix techniques en fonction des contraintes métiers, budgétaires, environnementales et de maturité de son service IT. C’est uniquement à ces conditions qu’il pourra répondre au mieux aux exigences métiers et ainsi donner entière satisfaction aux utilisateurs finaux.

Tagué:,

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :