Usages

Développeur ? Architecte ? Expert ? Consultant ?

Publié le : Auteur: vhanniet Laisser un commentaire
usages

Une question récurrente dans notre métier du service en informatique : qu’est-ce qui différencie un développeur d’un architecte d’un expert d’un consultant ? En fait c’est assez simple et compliqué à la fois…

Pour l’aspect simple de choses, il suffit de considérer qu’il s’agit là de rôles, assez précis, à jouer au sein du processus de développement de SI :

Rôle « développeur » : celui qui développe les programmes.

Concrètement le développeur produit des programmes sources qui une fois compilés, débuggés, intégrés, packagés, déployés sont utilisés par l’utilisateur final. Dans une définition large, ce rôle est en charge de l’écriture du code source, des tests unitaires, de la correction des anomalies provenant du code source et des fichiers de paramètres associés dans toute phase du cycle de vie logiciel, de l’intégration ou assemblage de composants unitaires, des tests d’intégrations, de la finalisation du logiciel pour qu’il puisse être déployé sur les machines cibles. En bref, le (rôle) développeur est celui sans qui tout projet logiciel ne produirait rien de concret pour les utilisateurs !

Rôle « architecte » : celui qui conçoit la solution.

Concrètement l’architecte, à la différence du développeur, ne produit pas de programmes. Dans une définition large, l’architecte « informatique » conçoit une solution ou une famille de solutions qui fournit la réponse « produit logiciel » à un besoin exprimé. Cette solution, ou famille de solutions, met en oeuvre une organisation de la réponse au besoin en fonctions (ou services) et en données, des choix de structure et technologies logicielles, des choix de structure et moyens matériels. L’architecte intervient lors de la conception générale, en support aux développeurs, en optimisation, en amélioration continue tout au long de la vie de la solution.

Rôle « expert » : celui qui maîtrise complètement un sujet.

Concrètement on peut être expert en n’importe quoi : il suffit de connaître parfaitement n’importe quoi ;D. En informatique on rencontre généralement des experts en technologie, des experts métier, des experts en infrastructure. Tout intervenant d’un projet informatique, quel que soit son rôle, peut connaître un sujet sur lequel il est expert. Il sera dans ce cas fait appel à lui en cas de problème complexe sur ce sujet afin qu’il fournisse des réponses concrètes et éprouvées aux questions en suspend.
Il y a plusieurs difficultés avec l’expertise :

  • Il faut savoir où elle commence et où elle se termine. Il est facile de reconnaître un expert sur un sujet pointu, sur un périmètre restreint. Plus le sujet est général plus la notion d’expertise est floue, voire inappropriée. Par exemple, dans un contexte Java, on imagine bien un expert Websphere mais plus difficilement un expert « serveurs d’applications ». On comprend qu’un expert Java connaît parfaitement la syntaxe du langage Java, mais connaît-il toutes les API de toutes les versions de JEE ?
  • L’expertise n’est généralement requise qu’à certains moments dans un projet informatique et donc un expert (rôle) ne sera généralement pas employé à temps plein à ce titre sur un projet. Un expert (personne) sera donc amené à proposer son expertise sur plusieurs projets en parallèle ou bien a jouer d’autres rôles entre temps.
  • On peut être théoriquement expert… Dans un métier informatique ! Par exemple, un expert en architecture maîtrise parfaitement le processus d’élaboration d’une architecture et le rôle d’un architecte. Ça ne veut pas dire pour autant qu’il maîtrise une seule architecture de bout en bout ! On atteint là les limites de l’expertise et ce rôle « meta-expertise » se nomme généralement « consultant ».

Rôle « consultant » : celui qui…

Dans la vie courante dans le milieu informatique le terme consultant est employé « à toutes les sauces » et désigne indifféremment : un prestataire de services, un prestataire de services confirmé, un prestataire de service avec une formation supérieure, un prestataire de service qui fait tout sauf du développement, un conseiller (ie qui conseille le client), un prestataire de service côté MOA…
Concrètement, consultant en tant que rôle doit être pris au sens de conseiller : celui qui aide à réfléchir avant de prendre des décisions.
Dans ce sens de conseiller, une des principales caractéristiques du consultant est qu’il doit bénéficier d’une expérience et connaissance suffisante pour avoir le recul nécessaire sur le problème posé afin de le traiter avec objectivité et de pouvoir challenger les solutions qu’il propose avec l’état de l’art.
Les solutions qu’il propose ? Pas exactement en fait. Le consultant n’est pas forcément là pour proposer des solutions. Dans beaucoup de situations, ce qu’on attend d’un consultant n’est pas une solution qu’il invente mais un challenge des solutions déjà envisagées par le client ou bien encore une aide à l’arbitrage pour aboutir à un compromis accepté par tous.
De ce point de vue, il est possible de combiner les rôles :

  • Ex: architecte et consultant s’il s’agit de définir une méthodologie d’architecture, ou d’aider à mettre au point un plan d’urbanisme fonctionnel cible
  • Ex: expert et consultant s’il s’agit de choisir un serveur d’application, ou de finaliser le MCD de la base client
  • Par contre « développeur et consultant » est plus rare

On aura aussi compris qu’une autre caractéristique principale d’un consultant est son aptitude à communiquer, à l’oral comme à l’écrit.

Une remarque amusante pour terminer :

Les définitions données ci-dessus fonctionnent aussi en remplaçant « informatique » par tout autre domaine de « construction » et « développeur » par le terme propre au domaine pour le rôle en contact avec les éléments de construction terminaux. Par exemple : « bâtiment » et « maçon », « cuisine » et « commis »…

Et au fait, l’aspect compliqué ?

Ces définitions paraissent logiques et fondées, mais elles ne sont pas forcément partagées par tout le monde. Parce derrière ces rôles se cachent aussi des titres, des fonctions, des plans de carrière, des grilles de référencement, des discours de différenciation commerciale etc. Il faut donc faire attention aux mots qu’on emploie en fonction des circonstances. Mais sur le fond… ;D

Si vous n’êtes pas d’accord avec le contenu de ce billet n’hésitez pas à réagir dans les commentaires !

 
Image empruntée sur http://www.trilliantinc.com/news-events/press-room/press-kit