Savez-vous pourquoi j'aime l'informatique ? Ou plutot devrais-je je voudrais aimer l'informatique. Parce que c'est un domaine d'innovation, qui mérite d'être sans entraves. L'informatique, c'est proposer une alternative au papier crayon et à l'huile de coude. C'est simplifier la vie des gens. Des utilisateurs. Des travailleurs.
Alors, quand une avancée est possible, on se doit de l'adopter, quand elle apporte un plus. Parce qu'elle entraine le contentement de l'utilisateur. Mais voilà, de toutes mes expériences passées et présente, je n'ai pas encore trouvé l'accomplissement. Ce qui fait croire à l'informaticien qu'il accomplit un travail utile.

Qu'est-ce que l'accomplissement dans le travail ?

C'est un concept très subjectif, assez personnel, qui fait qu'une personne sait qu'elle est à sa place, et qu'elle s'y plait. Dans mon cas, cela revient à aimer ce que je fais, savoir que je suis utile à une cause quelconque (économique, écologique, ou autre). Il faut pour cela que je puisse constater ce à quoi j'ai contribué. Par exemple, si je fais un site Internet, il me faut voir le produit final. Pouvoir me dire : je suis fier de ça. J'y ai contribué. Ce site, c'est un peu de moi.
Je crois que c'est ça. Il faut pouvoir etre fier de son travail. Cette fierté peut etre purement égoiste, mais l'approbation de l'utilisateur peut y contribuer fortement.

  • J'ai travaillé dans une petite SSLL. C'est une société de service en informatique orientée logiciels libres. L'expérience que j'ai pu en tirer, c'est que la gestion d'un projet est primordiale pour obtenir un bon résultat. C'est d'ailleurs ce qui faisait que la quasi totalité des projets réalisés n'étaient jamais bons. Ou plutôt qu'ils ne permettaient pas d'en etre fier.
  • J'ai travaillé pour une première entreprise, où j'ai appris que le développement le plus efficace est souvent celui qui avance. Celui qui, contre vents et marées, arrive à progresser. Innover pour progresser. Malheureusement, j'y ai appris une triste réalité également : l'innovation est un levier économique qu'on a tendance à utiliser à tort : en baissant l'innovation et la R&D, on croit diminuer les charges et les dépenses, alors que déjà à court terme, le résultat s'avérait catastrophique : sans innovations, l'entreprise passe de leader à fabricant de solutions "sans fonctionnalités, mais cheap". J'ai eu la chance d'avoir pu y travailler à ma guise, et je crois pouvoir etre fier de mon résultat. Malgré tout, la volonté anti-innovation a pris le dessus.
  • Dans l'entreprise où je suis actuellement, je crois pouvoir dire que j'atteins le summun de l'emploi sans intéret. Je suis chargé de l'industrialisation d'un produit (sous licence d'une grosse entreprise francaise).

Prenons donc point par point ce qui pourrait etre le fer de lance de l'informaticien (industrialisateur ou développeur) :

L'application sur laquelle il travaille doit fonctionner.

C'est la base. Si elle ne fonctionne pas, l'utilisateur ne sera pas content, et comment être fier d'un résultat médiocre ? Ici, l'application est une application tiers, ce qui veut dire que je n'en maitrise pas du tout le fonctionnement. Je ne suis là que pour tenter de la garder dans les rails. Autrement dit, je dois palier les déficiences d'un autre. Il est très difficile de maintenir une application dont les erreurs peuvent arriver aléatoirement, pour des raisons aussi diverses que variées (panne réseau, base indisponible, bug applicatif...). Un exemple concret : que penser d'un démon (sensé tourner en tache de fond donc), qu'il faut régulièrement relancer. Pire : il est techniquement impossible de prévoir l'impact d'un arrêt brutal.

Il doit voir le travail fini (récompense subjective du travail accompli)

L'application doit produire une richesse. Cette richesse est en soi une récompense toute personnelle pour l'informaticien, qui peut estimer alors qu'il a bien accompli sa tache. Ici, j'industrialise une application X. Je ne sais absolument pas à quoi sert X, ce que ça fait, qui l'utilise, et pourquoi. X doit tourner, point. A quoi ressemble X ? Aucune idée. Je travaille également sur une application Y. Qui crée des images. Je ne peux pas les voir, les importer, les exporter. Je ne constate pas le travail accompli grace à moi (entre autres bien sur). Comment être fier de son travail si l'on est incapable de savoir à quoi il a servi ?

L'informatique ici est considérée comme un travail de l'ombre.

Il doit etre dynamique, changeant, et utile.

Dès lors qu'on trouve son emploi inutile à la cause, alors on perd tout intérêt à accomplir sa tache. A quoi sert mon poste ? Sur le diagramme des personnes impliquées sur le projet, je suis sensé être le point central, par qui toutes les informations passent. C'est un schéma malheureusement faux sur bien des points.
L'organisation globale des processus a été mal pensée et entraine des emplois inutiles. Là où une tache x pourrait être automatisée, on va employer une personne qui n'aura meme pas le temps de l'automatiser (si encore il en avait le droit), mais qui devra l'accomplir. On y bride l'innovation par la saturation des emplois du temps et des taches inutiles et/ou mal pensées. La moitié des personnes impliquées sur le projet ne devraient pas etre à leur poste mais travailler à l'amélioration du projet, au lieu de travailler à son maintien !

En partant du travail, l'informaticien doit tous les soirs pouvoir se dire qu'il a avancé.

C'est très bête et primaire à dire. Passer 3 jours à ne rien faire d'autre que programmer (sur un temps qui est en dehors des temps alloués aux projets, puisque, réduction des couts oblige, il faut estimer un projet à son temps réel divisé par 3) des opérations à faire le week-end qui suit ne motive pas : le temps passé sur place aurait pu remplacer le temps qui sera à passer le week-end.

L'organisation ne doit pas empecher le déroulement des opérations.

Comme dit sur le point sur mon premier travail, sans organisation, point de salut. Ici, tout est minuté (on compte les journées par dixièmes de journée, et on minute notre emploi du temps, meme si de toute façon on excède le temps imparti). Ce qui n'est pas nécessairement un mal, mais qui donne à penser que les choses avancent "parce que" le temps est minuté. Ce qui est faux en général.
Ensuite, tout est documenté, ce qui est formidable. Tout ? Non, une poignée d'irreductibles reste toujours sans documentation. Le plus curieux : ça ne dérange personne. De toute façon, ce qui est normalisé et documenté est fait pour etre outre-passé. Une modification est souvent faite *avant* sa demande. Cette meme demande, qui la rendra officielle et permettra à 2 personnes de travailler sur la demande alors que la modification a déjà été mise et est déjà utilisée massivement, plus la personne qui a modifié, qui va devoir faire la demande, et préparer les fichiers qui remplaceront la modification par... elle-meme. On nage en plein délire.
L'organisation ici entraine la désorganisation, ou l'exces d'organisation.

Le nerf de l'informatique devrait etre le mouvement pour le perfectionnement, l'innovation, et l'amélioration des conditions de vie et de travail.

Est-ce qu'on peut etre fier d'un travail pour lequel on passe plus de temps à lutter contre la passivité, sans succès ?