J’ai rencontré trop souvent des situations où mes interlocuteurs prenaient leurs goûts personnels pour de grandes vérités technologiques. Cela m’aurait systématiquement amusé, si je n’avais pas vu trop de mauvais choix résulter de ce genre de comportement.

On a tous entendu ce genre de réflexions :

• « PHP c’est juste bon pour faire des pages perso », venant d’un ingénieur JEE.
• « Perl, c’est pour prototyper un logiciel avant de le coder pour de vrai », entendu chez un codeur C/Unix.
• « DotNet, c’est une copie de Java, c’est forcément moins bien », d’un autre ingénieur JEE.
• « MySQL ce n’est pas une base de données sérieuse », assuré par un DBA Oracle.
• « Bah, pourquoi vous utilisez Linux ? », par un candidat à un stage habitué à Windows.
• « Ubuntu, c’est nul, je préfère Debian », par un autre candidat.
• « Avec la base de données et le serveur Web sur des machines différentes, on ralentit le site », par un développeur expérimenté.

On peut apporter des réponses intelligentes à toutes ces remarques :

• Si Yahoo, Facebook et Wikipedia sont codés en PHP, c’est parce que ce sont des sites perso, hein ?
• Pour la plupart des développements, le Perl est plus rapide à développer, avec des performances plus qu’acceptables.
• Les développeurs qui prennent le temps de mettre le nez dans DotNet semblent dire que c’est une très bonne plate-forme.
• Wikipedia utilise plusieurs bases MySQL, qui fonctionnent conjointement de manière très performante.
• La vraie question est plutôt « Pourquoi utiliser Windows ? ».
• Avec de l’Ubuntu Serveur sur les serveurs, et de l’Ubuntu Desktop sur les postes de développement, on s’assure d’avoir une plate-forme unifiée.
• Vous imaginez que Google tourne sur une seule machine ?

Faire un choix structurant

Nous avons tous des préférences. Je me sens bien sous Linux, à coder en C et en PHP. C’est ce qui correspond à mes goûts et mes choix. Je peux l’expliquer de manière factuelle, mais il y a aussi des raisons inexplicables.

Dans le cadre de l’entreprise, on ne peut pas laisser ses goûts personnels prendre le dessus et faire les choix techniques structurels. Il faut prendre les meilleures décisions possible, et réaliser des choix technologiques en fonction de critères sérieux :

1. Choisissez des technologies stables, éprouvées et pérennes. Non, vous n’allez pas faire tourner vos serveurs sous BeOS.
2. Choisissez des solutions qui offrent une réponse globale à votre problématique. On ne fait pas de sites Web en C++ ; il est devenu raisonnable d’en faire en Ruby depuis l’arrivée de RubyOnRails.
3. Choisissez des technos qui s’adaptent à votre organisation, et non l’inverse. Mettre en place une plate-forme JEE est plus lourd que du LAMP, même si cela peut comporter d’autres avantages ; mais si vous avez une petite start-up, ce n’est pas un bon choix.
4. Choisissez des technologies que vous connaissez, que vous maîtrisez, et que vous appréciez. Travailler à longueur de semaine dans un environnement dans lequel on se sent bien est le meilleur moyen de faire progresser l’équipe technique.

Ce dernier point reste très important. Du développeur au directeur technique, il est difficile de se sentir motivé et de motiver ses collaborateurs quand on travaille sur une plate-forme à laquelle on ne « croit » pas. Sans parler du fait qu’il faut avoir une certaine maîtrise de l’environnement que l’on met en place, à la fois pour faire les choses correctement, mais aussi pour participer à la formation de l’équipe technique. Mais cela ne doit pas faire porter des œillères pour autant.

Évidemment, il ne faut pas jouer les masochistes en cherchant à mettre en place une plate-forme qu’on ne connait pas à tout prix. Par contre, il faut savoir faire le bon choix pour l’entreprise, entre une techno qu’on connait et qui serait parfaite, et une autre techno qu’on adore et qui convient moins bien.

S’adapter aux choix existants

A priori, quand on rejoint une entreprise ou une équipe, c’est en toute connaissance de cause. Il serait un peu étrange de choisir pertinemment d’aller travailler sur une plate-forme qui ne permet pas de valoriser notre expérience à son maximum.

Mais vous savez ce qu’on dit : en informatique, les choses évoluent vite. Les technologies et langages de programmation que vous utilisez aujourd’hui ne sont pas ceux que vous voudrez utiliser dans 15 ans.
Pourtant, je ne suis pas complètement d’accord avec cette approche ; si vous vous spécialisez dans le développement embarqué, il y a de fortes chances que vous utilisiez le C et l’assembleur pendant longtemps ; si vous faisiez du Web il y a 10 ans, vous avez pu suivre les évolutions technologiques (qui n’ont finalement pas été aussi drastiques qu’on veut nous le faire croire) ; le développement en Visual Basic n’a pas eu besoin de remise en cause profonde ces 12 dernières années.

Il n’empêche, au fil des années vous allez développer des expertises qui vont dépasser le simple cadre de l’environnement de développement d’applications. Chez certaines personnes, cela concernera la gestion de projet. Chez d’autres, ce sera le suivi de procédures (équipe de test ou support). Cela peut aussi concerner des connaissances sur tout ce qui concerne un business particulier.

J’ai vécu cette situation lorsque, après avoir travaillé 4 ans dans la téléphonie mobile en environnement Linux/Apache/MySQL/Perl, j’ai été embauché comme chez de projet senior, toujours dans la téléphonie mobile, mais sur une plate-forme JEE/JBoss/Oracle. J’ai été recruté sur des connaissances techniques qui ont permis de lancer rapidement des projets, que j’ai pu mener car je savais où les conduire. Ces mêmes projets auraient été plus délicats à gérer pour un expert JEE qui n’aurait pas eu d’expérience en téléphonie.

Dans tous les cas, il faut s’intéresser à l’environnement technique dans lequel on évolue. J’ai vu de trop nombreux ingénieurs brillants mettre leur carrière sur une voie de garage, parce qu’ils voulaient à tout prix s’en tenir à « leurs » technos, et ne cherchaient pas à développer une expertise sur celles employées au sein de leur entreprise.
Je ne le répèterai jamais assez : nous ne sommes pas des mercenaires. Il n’est pas possible de travailler efficacement, ni d’être heureux au travail, si on n’adhère pas totalement aux choix de l’entreprise. On peut proposer des solutions alternatives, quand elles peuvent s’appliquer. Mais on ne peut pas réussir à s’en sortir en « faisant le minimum ».