Un contexte rapide

Je travaille dans une SSII appelée Capgemini. En bref, c'est une société dans laquelle entre une demande spécifique d'un client, et d'où ressort un logiciel (en théorie) adapté à cette demande. Employant pas mal de personnes (plus de 59 000 employés dans le monde, un peu moins de 19000 personnes en France au 31 décembre 2004 (PDF), il faut savoir que l'employé lambda tel que moi n'est qu'un pion parmi tant d'autres : tant que je coute moins que je ne rapporte, on me garde, sinon tant pis, on ne s'embarrassera pas de sentiments. Mais là n'est pas le propos.

Présentation rapide du cycle de développement logiciel.

Il faut savoir que Capgemini ne fait pas que du développement logiciel, mais a aussi (entre autres) des activités de consulting depuis le rachat de Ernst & Young, ainsi que des activités de service de maintenance (matérielle et logicielle). Mon nom de métier est « Analyste programmeur », et l'activité est de participer au développement logiciel, ainsi qu'à la maintenance logicielle (correctif d'anomalies, et évolution de fonctionnalité). Donc, le cycle de vie d'un logiciel est le suivant :

  1. Contact du client avec la SSII (le contact pouvant venir de n'importe laquelle des deux parties), afin de déterminer le besoin du client.
  2. Une fois le besoin exprimé et défini, la SSII va proposer une solution logicielle et/ou matérielle adaptée à ce besoin.
  3. Partie de ping pong entre le client et la société jusqu'à ce que les deux soient d'accord.
  4. Une fois la solution déterminée, il va y avoir la définition de spécifications fonctionnelles : on va déterminer le fonctionnement général de l'application, d'un point de vue extérieur, bref, de tel écran je passe à celui-là si je fais ça, sur cet écran je dois avoir ceci affiché et l'utilisateur doit pouvoir y faire cela, etc.
  5. Les spécifications fonctionnelles validées par le client, il va falloir faire les spécifications techniques : on va déterminer pour chaque point des spécifications fonctionnelles ce qu'il va falloir programmer, et comment le faire.
  6. Les développeurs vont créer l'application en se basant sur les spécifications techniques.
  7. Pendant ce temps, sont déterminés les tests à effectuer sur l'application afin de la valider autant d'un point de vue fonctionnel que technique.
  8. Une fois l'application créée, il faut lui faire passer les tests déterminés au point précédent, et revenir au point 6 autant de fois que nécessaire.
  9. Une fois l'application validée en interne, elle est livrée au client, qui va lui aussi la valider (et retour au point 6 autant de fois que nécessaire en cas de problème).
  10. Quand l'application est validée par le client, elle passe en phase de production.
  11. Il peut toujours y avoir des anomalies détectées pendant cette phase, ou bien un besoin d'évolution de l'application (modification d'une fonctionnalité existante ou bien ajout d'une nouvelle). A ce moment, le client envoie un rapport d'anomalie ou demande d'évolution à la SSII.
  12. A partir de ce rapport / demande, il va être créé une spécification fonctionnelle et technique (principalement dans le cas d'évolution ou grosse anomalie).
  13. Cette spécification validée en interne puis par le client, elle va être mise en oeuvre.
  14. On repart sur une batterie de tests en interne, puis chez le client, avec autant de retours au point précédent que nécessaire.
  15. Retour au point 10.

Dans toute cette liste, j'interviens (selon les projets) aux points 5, 6, 7, 8, 12, 13 et 14, d'où le nom d'analyste programmeur (j'analyse le besoin, et je le programme).

Les conditions de travail

Selon les projets, les conditions peuvent être très différentes. Mais il se présente en général un des cas suivants, du moins ceux que j'ai déjà expérimentés :

  • Gros projet, avec une grosse équipe. En général, dans ce cas, les rôles de chacun sont bien définis, et il est rare de faire des spécifications, du développement et des tests. On a un rôle assigné (par exemple développement), et on s'y tient pendant toute la durée du projet. C'est en général le genre de projet le plus reposant, dans le sens où l'on a pas à passer d'un rôle à l'autre en permanence, et les tâches étant clairement définies, il y a peu d'initiative personnelle à prendre, le chef de projet se démerde.
  • Gros projet, avec une petite et moyenne équipe. Dans ce cas, tout le monde met la main à la pâte. On peut passer d'un rôle d'analyste sur un point du projet, puis développeur sur une autre partie, au gré de la charge de travail, tout comme s'occuper d'une partie du projet d'un bout (analyse et spécifications) à l'autre (développement et tests). C'est le genre de projet qui peut rapidement devenir fatigant dans le cas où il a une forte charge de travail ou un planning serré, mais à mon avis le plus enrichissant d'un point de vue technique.
  • Petit projet, en phase de création, un seul développeur. Le projet piège : vous êtes le seul développeur, au dessus de vous, il n'y a que le chef de projet. Dans ce cas, c'est à vous de faire les spécifications, le développement, les tests, la documentation, etc. Bref, il faut avoir le cœur bien accroché, tenir le stress et surtout un chef de projet et un interlocuteur chez le client très sympa. J'ai eu de la chance, je suis tombé sur ce genre de projet (pour le CNES) une seule fois, et en face ils étaient compréhensifs, mais plus jamais ça. L'année suivante, j'ai formé et travaillé avec une collègue sur de la maintenance évolutive pour ce projet, et maintenant elle se débrouille toute seule.
  • Petit projet, en phase de maintenance, un seul développeur. La plupart des projets sur lesquels j'ai travaillé et travaille encore. En général, l'activité est en moyenne faible sur un seul de ces projet pris séparément, mais on n' en a jamais qu'un seul sur les mains. De ce fait, il y a toujours quelque chose à faire. D'un point de vue type d'activité, ces projets présentent le même que les précédents, mais sur un rythme beaucoup plus faible et supportable. Le seul problème, c'est qu'en général on est la seule personne de la boîte compétente sur l'application, donc en cas de problème où l'on est bloqué, ce n'est pas génial. De plus, du fait d'avoir plusieurs de ces projets en charge, il faut être capable de passer d'un projet à un autre du jour au lendemain, quitte à mettre en pause ce que l'on était en train de faire, au gré des priorités. Mais bon, le plus gros avantage est que non seulement on se sent indispensable sur ces projets, mais on l'est :)

L'environnement de développement

Celui ci est quasiment aussi varié que les projets. Mais j'ai pu travailler sur quelques grosses tendances :

  • Les applications web en Java/JSP, les 3/4 du temps tournant sur un serveur d'application Sun iPlanet. Ces applications peuvent elles-mêmes utiliser XSLT ou Struts, et sont la plupart du temps interfacées à un SGDB Oracle (même si j'ai vu une fois un PostgrSQL).
  • Les clients lourds en VBA, faits à l'aide d'Access. Ça n'a pas l'air comme ça, mais c'est très fréquent. En général, ils servent plus souvent interfacés à un SGDB externe tels que MS SQLServer ou Oracle qu'avec les fonctionnalités de bases de données internes.
  • Les clients lourds en Visual Basic, en général pour accéder à des bases Oracle.

Le cursus scolaire.

Rien de bien transcendant : un simple baccalauréat scientifique (option SVT), suivi d'un DUT en génie informatique. En revanche, si l'on souhaite dépasser rapidement le simple stade d'analyste programmeur, voire le sauter, il est conseillé de continuer les études au delà.