Ce qu’on aime en informatique, c’est la simplification. Tout projet nécessite la présence de deux entités : la maîtrise d’oeuvre (MOE) et la maîtrise d’ouvrage (MOA), aidée éventuellement par une assistance MOA (MOA). Si on se place côté MOE, pour un projet informatique, il faut au moins 3 rôles : l’analyste, le concepteur et le développeur. Cela sonne comme un western des années 70.
L’analyste. Son rôle est d’affiner le besoin exprimé par la MOA. Il va donc discuter avec la MOA pour expliciter l’attente des utilisateurs dans un langage compréhensible par le client final et son collègue le concepteur. Il connaît aussi les limites et les possibilités des technologies employées par ses collègues et orientera le client pour un produit final plus efficace. L’analyste est un informaticien qui ne code pas.
Le concepteur. Son rôle est de définir et de mettre en place l’architecture sur laquelle tournera l’application finale. Il peut aussi aider l’analyste lors de la présentation à l’utilisateur de la solution. Son rôle est celui d’un architecte logiciel. Si son collègue produit les spécifications fonctionnelles d’une application, lui produit les spécifications techniques.
Le développeur. Il attend les études de ces deux collègues et crée réellement l’application. Dans un cycle de projet en ‘V’, il est en bas du ‘V’. Il ne décide ni de ce que fait réellement l’application (c’est le rôle de l’analyste), ni de comment est construite l’application (c’est le rôle du concepteur). Il aligne le code comme d’autres alignent les briques. Cette description est caricaturale mais c’est souvent la vision de ses responsables.
Un informaticien sur un petit projet peut donc se retrouver à jouer ces trois rôles. En principe, les petits projets sont donnés aux débutants. En sortie d’école, ils ne sont pas encore formatés ni spécialisés dans un domaine ou dans une technologie. Cela leur permet de connaître leurs préférences dans le domaine informatique.
Et surtout, les petits projets sont souvent les projets que les autres ne veulent pas. Je mets le terme petit en italique parce que bien souvent ce sont des projets que les informaticiens expérimentés préfèrent mettre de côté. Ce sont des projets sans enjeux réels pour l’entreprise, ou répétitifs et ennuyeux.
Parfois, ce trio ressemble à celui du western spaghetti ‘le bon, la brute et le truand’. Le gentil analyste aide le client à définir l’application de ses rêves. Le concepteur terre à terre défini ce qui peut être fait et comment. Et ce ne sera pas autrement. Le développeur essaiera tant bien que mal de réaliser dans les délais impartis (et réduits) avec des choix technologiques parfois inadaptés. Il bidouillera les programmes pour faire croire au client que tout fonctionne.
Il y a tant à dire sur les bidouilles. Les conséquences sont souvent à l’origine des bugs. La plus classique est de ne pas coder le mécanisme attendu et de renvoyer simplement le résultat. “Je mets un TODO et je le ferai plus tard !” se dit le développeur. Le problème est que plus tard, l’application est partie chez le client, sans la correction. Et c’est trop tard pour corriger.
Pour ces trois activités, il existe de nombreuses méthodes. L’analyste, suivant son client, utilisera des méthodes différentes pour concevoir le projet. Les plus anciens préfère la méthode Merise. D’autres utilisent le formalisme UML. En pratique, l’analyste manipule beaucoup les schémas et le texte brut. Visio, Word, Excel et Powerpoint sont des outils maîtrisés.
Le concepteur lui se base sur ces expériences précédentes. Si au début, il est parti sur des produits Microsoft, il ne proposera que des solutions Microsoft pour permettre le fonctionnement de l’application. Des technologies, cela ne s’arrête pas à Microsoft. Oracle, SAP, OpenText, … La foire aux technologies est encore plus grande lorsqu’on se tourne dans le monde libre. Le concepteur reste fidèle à ses premiers amours.
Le développeur est choisi suivant l’architecture proposée par le concepteur. Les développeurs qui travaillent sur des technologies généralistes trouvent facilement du travail. Ceux qui sont spécialisés sur des technologies devenues rares (Cobol, Assembleur, …) gagnent très bien leurs vies mais doivent se déplacer plus souvent.
Comme pour les médecins, il existe des informaticiens spécialistes et généralistes. Bien qu’ayant fait les mêmes études, certains n’ouvriront jamais un programme. Et comme dans le sketch des inconnus, il y a les bons informaticiens et les mauvais informaticiens. Vous êtes prévenus.