Overblog
Editer l'article Suivre ce blog Administration + Créer mon blog
Laurent COCAULT

L'architecte et l'ingénieur

L'architecte et l'ingénieur

Ce midi avait lieu le premier Web Event de la communauté des Software Engineers de Capgemini. A cette occasion, l’un des sujets abordés était celui des similitudes et différences entre les ingénieurs logiciels et les architectes. Ces rôles donnent en effet corps à deux filières dans l’organisation Capgemini et la filière des architectes est souvent perçue comme une filière « naturelle » pour les ingénieurs logiciels ayant acquis une solide expérience du développement et qui souhaitent s’inscrire durablement dans un rôle technique. Pourtant, les deux rôles sont assez différents et considérer uniquement le rôle d’architecte comme un prolongement inévitable de celui d’ingénieur logiciel ressemble à une manifestation du principe de Peter. Ces deux rôles présentent des spécificités et supposent des compétences si différentes qu’on peut l’être un excellent ingénieur logiciel et un médiocre architecte, et inversement.

A l’occasion d’un déjeuner avec un voisin, architecte dans le bâtiment, le week-end dernier, j’ai eu l’occasion de m’interroger à nouveau sur les parallèles que l’on peut tracer entre le monde de la construction et le monde du logiciel. Dans le monde du bâtiment, on retrouve en effet cette distinction entre l’architecte et l’ingénieur. Et je pense que la répartition des responsabilités entre ces rôles nous dit quelque chose de nos rôles d’ingénieur logiciel et d’architecte informatique.

L’architecte est en relation avec l’ensemble des parties prenantes du projet. Dès les phases amont, il intervient auprès du client pour accompagner la capture du besoin et le projeter sur une solution technique. C’est un acteur clé dans l’élaboration de la vision du projet et dans l’esquisse des choix techniques les plus structurants. Par la suite, il est en interface avec les équipes qui réalisent le projet ; garant de la vision initiale, il joue à la fois un rôle pédagogique et assure la cohérence des décisions techniques qui sont prises. Toujours en interface avec le client, les équipes mais également son propre management, il apporte son conseil pour maintenir l’équilibre économique du projet et sa maitrise calendaire. C’est notamment dans ce cadre qu’il porte un regard sur les risques techniques et organisationnels en identifiant les actions de mitigation ou d’évitement qui s’avèrent nécessaires. Cette définition de l’architecte en fait avant tout un rôle de coordination pour lequel la communication est un élément clé. Cette coloration explique que, lors du Web Event Capgemini, la représentante du rôle d’architecte informatique ait insisté sur l’utilisation permanente d’outils de communication tels que Outlook ou Teams. L’utilisation de PowerPoint et d’outils de modélisation s’explique aussi par la nécessité de communiquer de manière efficace au travers de représentations graphiques et de modèles.

Malgré un spectre de connaissances assez étendu, l’architecte ne connaît pas tout sur tout. Il a donc nécessairement besoin d’expertises ponctuelles pour mener ses propres activités, et d’interlocuteurs techniques auxquels déléguer les activités de réalisation qui supposent un savoir-faire spécifique. Dans le cas de la construction, on peut observer cette délégation dès les phases d’étude : qu’il s’agisse de sonder le sol d’un terrain ou d’en cartographier la surface, l’architecte s’appuie sur des ingénieurs qui lui remettent des données permettant d’affiner le projet. Cette délégation est plus importante encore pendant la réalisation, lorsqu’il s’agit de faire ou de vérifier ; dans ce cas, l’architecte intervient en tant qu’autorité, notamment pour valider certains choix ou l’état de certaines réalisations. On retrouve ces délégations dans le monde du logiciel ; qu’il s’agisse de commanditer une preuve de concept, de solliciter l’évaluation d’une technologie, ou par la suite de valider certains aspects de la solution (sécurité, sûreté de fonctionnement, qualité logicielle…), l’architecte délègue à des ingénieurs spécialisés dans le développement logiciel.

L’ingénieur logiciel est ainsi en prise avec la réalité du développement logiciel, avec ses technologies, avec ses outils, avec les méthodologies qui lui sont propres. Il lui manque certainement la vision d’ensemble du projet que l’architecte s’est forgée en interagissant avec les parties prenantes, mais il a une connaissance détaillée plus fine des éléments qui sont réalisés. On perçoit aussi nettement la différence de rôle dans l’outillage utilisé ; comme le mentionnait l’un des intervenant du Web Event, l’outil de prédilection de l’ingénieur logiciel est son environnement de développement intégré (IDE), plus que son logiciel de messagerie ou de réseau social d’entreprise qu’il utilise malgré tout pour se coordonner avec ses pairs, son encadrement et son client. La relation avec le client n’est pas non plus absente du quotidien de l’ingénieur logiciel ; mais la nature des discussions qu’ils tiennent n’est pas la même que celles de l’architecte. Il n’est plus seulement question de définir la structure générale de la réalisation, mais bien d’entrer dans les détails, d’affiner les choix.

Architecte informatique et ingénieur logiciel sont deux métiers passionnants, présentant des caractéristiques communes mais aussi des spécificités qui doivent inviter à questionner nos choix de carrière. Orienter ce choix au seul motif qu’il existerait une évolution naturelle ou qu’un rôle serait plus prestigieux qu’un autre serait une erreur. Un projet, pour réussir, a besoin des compétences de ces deux rôles. Et la seule question qui vaille est celle de la valeur qu’on apporte et du plaisir qu’on retire de l’exercice de notre rôle.

Partager cet article
Repost0
Pour être informé des derniers articles, inscrivez vous :
Commenter cet article