Ergonomie, Rails et Architecture de l'information web (2.0)

On lit souvent un peu tout et surtout n’importe quoi à propos à propos des entretiens d’embauche dans les NTIC, et le sujet des tests techniques n’est évidemment pas en restes. Entre les adeptes du test pratique comme seul déterminant possible de la valeur d’un candidat et les zélotes du QCM de 200 questions à réaliser en trente minutes, difficile de faire son choix. Toutes proportions raisonnables gardées, l’un et l’autre ont pourtant leurs avantages. Le test pratique vous permet de voir en peu de temps comment travaille votre candidat. Cependant, 3 requêtes dans une base de données ne garantissent pas la qualité du travail sur le long terme, ni les capacités de reprise d’une application complexe, ancienne, et développée par plusieurs personnes. Le QCM vous assure que votre développeur a un profil purement technique et qu’il a bien appris par coeur fr.php.net. Mais un développeur n’est pas (seulement) un pisseur de code, et rien ne vous garantit qu’il sera capable de réfléchir le jour où il sera confronté à un problème vraiment sérieux. Sans compter qu’on ne peut pas demander la même chose à quelqu’un qui sort de l’école et à un senior avec 10 ans d’expérience.

Ces derniers temps, j’ai pas mal réfléchi à ce que pourrait être le questionnaire technique “idéal”. Complément du test technique, il “idéal” pourra être donné aussi bien au junior qu’au senior, et me renseigner à la fois sur sa maîtrise du langage et sur ses capacités à réfléchir. Le candidat ne devra pas passer plus d’une demi-heure dessus, et il devra comporter une dizaine de questions très ouvertes afin de s’adapter à tous les niveaux. Un exemple de ce qu’on pourra y trouver serait comment vous connectez-vous à une base de données MySQL ? Cette question a ceci d’intéressant qu’elle appelle aussi bien la réponse mysqlpconnect() / mysqlselect_db() que des considérations sur les librairies d’abstraction de base de données.

Dans tous les cas, une fois posé le principe, le plus difficile est de trouver les questions poser.

Je ne dirais pas que KDE est bon à jeter, mais dans le doute, ils ont même prévu un Konqui recyclable

L’insertion d’un élément au sein d’une entreprise dès les études – et notamment à l’occasion des divers stages qui jalonnent son parcours est un investissement des plus avisés. La future recrue est intégrée au groupe existant et formée aux méthodes de l’entreprise avant sa véritable arrivée dans la vie active. Cela permet non seulement de se rendre compte rapidement du véritable potentiel du candidat, mais aussi de créer une “période d’essai à rallonge” quand un ou trois mois peuvent ne pas suffire à évaluer quelqu’un, particulièrement sur des projets à long termes.

Durant l’année passée, j’ai eu l’occasion de côtoyer ou de gérer des stagiaires à bac +2, bac +3 et bac +5, tous se dirigeant vers un bac +5, et de dégager une tendance intéressante : la motivation à apprendre du stagiaire est inversement proportionnelle à son avancée dans son parcours estudiantin. En grossissant un peu peu le trait, ce que j’ai pu voir donne globalement :

• À bac +2, ils sont motivés, peuvent passer 3 jours à résoudre un problème complexe, ont une énorme soif d’apprendre, de se former et de se remettre en question.
• À bac +3, après un premier stage, ils ont tendance à croire qu’ils connaissent tout de la vie en entreprise, et sont moins à l’écoute. Je les ai sentis globalement moins en attente que ceux de la génération précédente.
• À bac +5, ils abattent du boulot, un peu plus que la moyenne dans l’espoir d’être embauchés rapidement, mais ils ne cherchent plus ni à apprendre, ni à se remettre en question, ni à progresser. Ils attendent un “vrai salaire”.

Se remettre en question quotidiennement, aussi bien sur le plan technologique que méthodologique est fondamental si on veut pouvoir avancer au delà de ce qu’on a appris à l’école, et qui est le plus souvent décorrélé d’un projet en grandeur réelle, et c’est dommage que ce réflexe se perdre à mesure que les années d’étude passent. Je crois de plus en plus en l’accompagnement des futurs collaborateurs d’une entreprise tôt dans le cycle d’études, charge à l’entreprise de proposer des conditions suffisamment attrayantes au stagiaire afin de le garder sur le long terme. Cela nécessiterait probablement de revoir un peu la fiscalité des entreprises de notre beau pays afin de permettre de payer un stagiaire plus de 320 euros par mois sans se prendre tout un tas de charges sur le coin de la figure, par exemple en augmentant le plafond en fonction du nombre d’années d’études, tout en mettant en place des contrôles plus poussés afin d’éviter les abus.

En tout cas, si vous avez déjà encadré des stagiaires à ces trois niveaux d’études, ça m’intéresserait de connaître votre ressenti sur leur ratio soif d’apprendre / années d’études.

Vendredi dernier, je devais conseiller au pied levé un ancien camarade d’école, deux promotions en dessous de moi, confronté à un dilemme cornélien quant à son avenir professionnel : à salaire, clients et avantages égaux, valait-il mieux qu’il fasse son stage de fin d’études dans une petite ou une grosse SSII ? Souvent considérées – pas toujours à tort – comme les négriers du XXIème siècle, les Sociétés de Services en Ingénierie Informatique représentent aussi un formidable tremplin pour les jeunes diplômés, à condition de ne pas craindre les heures supplémentaires. Grands comptes, projets d’envergure, missions de longue durée permettent de se constituer très rapidement un CV alléchant, propre à vous faire rejoindre quelques années plus tard la DSI d’un de vos anciens clients, ou à vous constituer le réseau professionnel dont vous aurez besoin le jour où vous voudrez voler de vos propres ailes. Le tout est de bien commencer, et de savoir quand s’arrêter.

Pourquoi rejoindre une grosse ?

L’époque où le seul moyen pour une petite société d’intégrer de gros comptes était de sous-traiter ses ressources à un partenaire plus gros est heureusement révolu. Aujourd’hui, les plus petits peuvent coopérer avec les plus grands. Avec seulement deux ans et demi d’existence, Actualys en est une preuve parmi d’autres. Cependant, sur les projets vraiment majeurs – plusieurs dizaines de personnes, planification sur plusieurs années – les postes à responsabilité seront systématiquement tenus par la société qui dirige le projet, bien qu’il soit possible de tirer son épingle du jeu aux moments critiques. Tout est une question de compétences et de vivacité d’esprit, mais ne comptez pas en tirer une quelconque gloire en dehors de votre équipe.

Les très grosses SSII ont généralement un système d’avancement établi, tous les deux ou trois ans, au rythme des inévitables et redoutés entretiens annuels. Le plan de carrière est tout tracé : technique les premières années, puis fonctionnel ou management après, jusqu’en haut de l’échelle pour les meilleurs. C’est un des points souvent appréciés de ces sociétés : la visibilité sur l’avenir et sur les possibilités d’évolution.

J’en profite pour introduire une digression dans mon propos.

Je souris toujours quand je reçois des CV de futurs diplômés à la recherche d’un stage de fin d’études en tant que chefs de projets. Mon livre de chevet du moment dit avec raison qu’on ne peut être un bon supérieur si on n’est pas d’abord un bon inférieur, et que pour bien commander, il faut d’abord apprendre à bien obéir. On ne peut pas concevoir un projet en grandeur réelle sans en avoir réalisé un, tout comme une ceinture noire en UML et MS Porject ne permettent pas à elles seules de résoudre des situations de crise. Et puis, code is fun tant qu’on choisit bien son langage. Bannissez PHP et Java de votre existence, ça ira mieux.

Fin de mon aparté.

Autre avantage des grosses SSII pour ceux que ce genre de détails intéresse : le comité d’entreprise. Pour certains, il s’agit d’un point non négligeable au moment de choisir une entreprise, et vous avez peu de chances d’en trouver un dans les petites structures. Un comité d’entreprise, cela signifie généralement les places de cinéma moins chères, et les chèques vacances à la fin de l’année.

Et une petite ?

Comité d’entreprise, carrière planifiée au millimètre, plus de chance d’avoir des responsabilités sur les projets vraiment majeurs, dès lors, pourquoi choisir une petite SSII ? Ces dernières ne semblent pas vraiment avantagées, et pourtant, je leur ai toujours donné ma préférence, pour 3 raisons précises.

Il est plus simple de se faire remarquer dans une petite société

Performant, mais en bas de l’échelle, vous avez beaucoup plus de chances de vous faire remarquer par vos employeurs au sein d’une petite société qu’au sein d’une grande, dans laquelle le cloisonnement hiérarchique ne permettra pas forcément à vos exploits de se répandre. Inversement, vous avez plus de chances de voir vos conneries rester au niveau de votre commercial traitant dans une grosse société.

Les responsabilités arrivent plus rapidement

Que vous soyez sur un projet en régie ou au forfait, chez le client ou à domicile, vos supérieurs vous confieront plus facilement des responsabilités s’ils vous côtoient au quotidien, et s’assurent par là même de vos compétences, et peuvent s’affranchir de l’inertie hiérarchique propre à certains grands cabinets. J’ajouterais que le côté relation humaine est beaucoup plus présente, encore plus quand votre entreprise travaille aussi au forfait.

Les perspectives d’évolution sont généralement plus variées

Bien que ce ne soit pas toujours le cas, particulièrement dans les entreprises pratiquant la monoculture technologique, une petite structure offre souvent une plus grande diversité de missions et de postes pour un profil donné. Les raisons en sont simples :

• Le nombre de ressources est moins important.
• La taille humaine de la structure permet de mieux connaître ses collaborateurs.

Le jour où vous postulerez, tâcher donc de cerner les pôles technologiques de votre futur employeur, afin de savoir à quoi vous pourrez être amené à toucher. Renseignez-vous ensuite sur les possibilités de formations en interne afin de faire, à terme, ce qui vous plaît dans un environnement qui vous plaît.

C’est pas la taille qui compte…

Une fois de plus, rappelez-vous que ce n’est pas la taille de la société qui compte, mais la manière dont vous envisagez votre carrière en son sein. Une fois que vous savez ce que vous voulez, renseignez-vous soigneusement sur les conditions de travail réelles, et pas sur ce que vous font miroiter des commerciaux ou des recruteurs le plus souvent payés à la commission, et donc prêts à tout pour vous faire signer un contrat.

Enfin, dernière recommandation, ne faites pas (toujours) confiance aux camarades de promotion qui vous promettent monts et merveilles : il y a de grandes chances pour qu’ils soient grassement récompensés le jour où ils vous feront rentrer dans leur société. Selon les cas, la cooptation peut rapporter plus de 1000 euros par personne embauchée, ce n’est pas rien. D’ailleurs, ça me fait penser qu’Actualys embauche toujours des développeurs web PHP, Java et Ruby on Rails. N’hésitez pas à postuler en disant que vous venez de ma part : de toute manière, je ne gagnerai pas un centime dessus.

Dans le cadre de son développement, Actualys, agence spécialisée dans l’accompagnement des grands comptes dans leurs projets web recrute un développeur PHP expérimenté pour une mission longue durée dans la banque et la finance.

Expert en PHP, vous maîtrisez parfaitement l’environnement LAMP, la programmation orientée objet et les outils de gestion de sources (CVS). Imaginatif et ouvert d’esprit, vous utilisez quotidiennement les méthodes agiles, et plus particulièrement l’eXtrême Programming. Vous serez amené à rejoindre une équipe dynamique au sein d’un grand groupe bancaire pour une mission longue durée autour des problématiques liées aux OPCVM.

Si vous justifiez de 3 ans d’expérience réussie dans les technologies citées et êtes disponible immédiatement, envoyez votre CV à candidat[at]actualys[dot]com.

• Post : CDi / Freelance.
• Disponibilité : immédiate
• Environnement technique : LAMP / Sybase

Actualys, agence web spécialisée dans l’accompagnement de projets grands comptes (banques, opérateurs téléphoniques, industries…) recherche un directeur artistique pour renforcer son équipe sur son site de Neuilly sur Seine.

Doué d’un grand sens artistique, vous serez chargé de concevoir maquette, design et charte graphique des sites, applications et opérations lancés par Actualys pour ses clients.

Indépendant et curieux, vous aimez travailler sur des projets variés allant du site commercial décalé à l’application métier client léger.

Communiquant, vous serez le premier interlocuteur du client pour toute la partie visuelle de son projet, mais aussi de l’équipe de graphistes qui accompagnera votre travail.

Habitué au média web et à ses problématiques spécifiques, de bonnes notions en ergonomie des IHM et en utilisabilité sont un plus appréciable.

Si vous justifiez d’une expérience significative dans le design ou la direction artistique sur le web, envoyez votre CV à rh[at]actualys[dot]com.

Rémunération selon profil, comme on dit dans les SSII.

Les offres d’emploi dans les technologies de l’information constituent généralement une bonne approche de l’état du marché. Sortis du langage très formel généralement utilisé dans la description des postes, l’utilisation de certains mots clés donnent des indications intéressantes sur les tendances en cours, aussi bien en matière de technologies que de projets.

Malheureusement, cela permet aussi de se rendre compte que de nombreux commerciaux jouent encore sur les mots clés du moment sans pour autant avoir la moindre idée de ce dont ils parlent, comme me le prouve cette annonce reçue ce matin :

La société souhaite réorganiser le site [insérer ici un site quelconque] et le doter de nouvelles fonctionnalités, en y intégrant des applications faisant appel aux nouvelles technologies de l’Internet, notamment celles en relation avec le Web 2.0.

Difficile de ne pas sourire quand je lis la liste des compétences requises :

• Fortes compétences en deéveloppement d’application Web interactives utilisant la programmation en langage objet et les technos AJAX
• PHP / MySQL, JavaScript, XHTML et CSS, DOM, XMLHttpRequest

Et je ne peux réprimer de tiquer en voyant la dernière ligne de l’offre :

En complément, les connaissances dans les domaines suivants seraient un plus :

• architecture client/server J2EE

J2EE… sooooo web 1.0.

Combien de fois ai-je vu des étudiants en stage de fin de cursus me déclarer “je veux être chef” avant même d’obtenir leur diplôme ? Et chef de quoi, d’abord ? Chef de projets, avant même sa première confrontation à un vrai projet dans le monde réel – comprendre celui de l’entreprise. Permettez moi de sourire : lors de mon passage à EDF, j’ai vu des centraliens pisser du Java sans rechigner 10 heures par jour, avant de pouvoir enfin obtenir le statut tant convoité.

On tient pourtant là un des (nombreux) paradoxes de bien des informaticiens :

Jeunes développeurs, ils craignent de le rester toute leur vie et n’ont rien de plus pressé que de quitter ce statut pour rejoindre le coté obscur de la force, peuplé de tableaux Excel, de présentations Powerpoint et de plateaux repas froids apportés par un traiteur en plein milieu d’une réunion marathon.

Chefs de projets, leur première inquiétude est de perdre pied sur le plan technique, et de ne plus pouvoir suivre ce que réalisent les développeurs placés sous leur responsabilité, voire d’effectuer des choix cohérents : CGI en C ou framework en PHP5 ? J2EE ou Ruby on Rails ?

On ne peut donner tort aux premiers : dans le monde impitoyable des sociétés de services, un développeur trop expérimenté coûte bien plus cher que ce que le marché accepte de le payer, ou alors c’est qu’il il fait du COBOL et maintient des applications plus vieilles que moi.

On peut donner pareillement raison aux seconds sur lesquels plane l’ombre de ces chefs de projets ou DSI de 55 ans, confortablement installés dans leur fauteuil en attendant la retraite, incapables de prendre une décision sensée puisqu’aux antipodes de la réalité, mais refusant de se remettre en question au nom du sacro saint principe de Dilbert qu’on ne doit pas nommer mais qu’on ne se gène pas pour appliquer au jour le jour. Ceux qui pensent que j’exagère manquent probablement encore d’expérience dans les méandres des grands groupes de notre beau pays.

Aux premiers, j’aurais envie de dire “patience” : vous apprenez la gestion de projets à l’école, et c’est très bien, mais avant de réclamer des responsabilités, souvenez-vous de ces deux proverbes :

La pratique n’est rien d’autre que la mise en application de la théorie… du moins en théorie.

et :

C’est au pied du mur qu’on voit le mieux le mur.

Quand aux seconds, je ne saurais leur conseiller meilleure alternative aux coûteuses formations dispensées par des instituts renommés que l’investissement au titre de vos loisirs dans un projet open source. Pas forcément à grosse dose, chacun selon ses possibilités mais vous n’en tirerez que des bénéfices :

• La dynamique de groupe de tels projets vous encouragera à participer.
• C’est une très bonne carte de visite pour le jour où un client fera une recherche sur votre nom sur Google.
• Le monde de l’open source est généralement très au fait des derniers changements technologiques auxquels vous risquez un jour d’être confronté.
• Vous nouez de nombreux contacts à l’international

En un mot : vous continuez à apprendre tout en vous amusant et vous rendant utile.

Ce billet fait suite à un certain nombre d’expériences malheureuses et conversations survenues ces deux dernières années, dont les plus récentes entre autres avec Mathieu Pillard. Rendons à César ce qui est à César, je râle suffisamment quand on ne me le fait pas.

Je ne sais pas si vous avez remarqué la quantité de gens qui se présentent à des entretiens d’embauche – ou que des sociétés de service peu scrupuleuses vous présentent comme les plus fines gâchettes de la profession – sans avoir jamais développé une ligne du langage dont ils se prétendent pourtant spécialistes. Je me souviens un jour avoir entendu un commercial tentant de vendre un stagiaire technicien réseau au CV maquillé comme une voiture volée en tant que développeur PHP expérimenté. Il clamait à qui voulait bien l’entendre : “Il a déjà fait un site perso en HTML, le PHP c’est facile, n’importe quel imbécile peut en faire, il y a suffisamment de documentation et d’exemples sur Internet, il fera l’affaire”. Deux semaines plus tard, le garçon se faisait dégager de la mission avec pertes et fracas.

C’est sans doutes à cause de ce genre d’anecdote que je crois fermement qu’un simple entretien technique ne suffit pas à déterminer le niveau réel d’un développeur. Un test pratique représente la solution à la fois la plus efficace et la plus intéressante, pour peu, évidemment, qu’il soit mené intelligemment.

Il y a deux ans, j’avais assisté à la mise en place d’une batterie de tests techniques à destination des postulants avec la philosophie de laquelle j’avais du mal à m’accorder.

Dans un premier temps, le candidat devait, en deux heures de temps, développer une petite application simple en PHP, comme un carnet d’adresses, une interface de vente de voitures, ou un annuaire simple. Il s’agissait avant tout de tester ses capacités de “machine à pisser du code”, plus que son degré de réflexion et d’abstraction. Curieusement, sur parfois une trentaine de candidats présentés par des sociétés de service, seuls deux ou trois pouvaient prétendre à passer la seconde partie du test. Seconde partie qui consistait en l’intégration d’un nouveau module dans une application effroyablement compliquée, bourrée de bugs aléatoires, codée avec les pieds par un unijambiste parkinsonien, et reposant sur un moteur de template interne non documenté. Pendant ce temps, certains membres de l’équipe passaient derrière le courageux postulant, regardaient son travail et émettaient des réflexions pas toujours très agréables à son propos. Après ma sortie, je me suis sincèrement demandé s’ils cherchaient un développeur ou un mélange entre Mac Gyver et un bonze tibétain pour les capacités de concentration en milieu particulièrement hostile.

Je trouvais cette manière de faire critiquable sur deux points :

Le premier projet était un exercice d’école basique, sans aucun lien ni dans l’esprit ni dans le domaine fonctionnel avec ce que le postulant aurait à développer par la suite. Malgré le peu de réussite, j’aurais aujourd’hui tendance à dire qu’il était trop facile, et ne correspondait pas aux contraintes techniques de la mission (php objet, javascript omniprésent, ajax partout pour des contraintes de bande passante). Le second projet était particulièrement difficile, trop même, et l’application à reprendre très loin de la moyenne des projets développés au sein de cette équipe. D’autant que l’utilisation du template maison nécessitait quelques jours de formation et d’adaptation en internet.

En un mot, le test visait à recruter des techniciens purs, capables de pondre, de lire et de reprendre du code très rapidement, mais sans aucune méthode ni réflexion, même si les développeurs rapides savent aussi souvent réfléchir à leur code. Cela va bien pour des applications simples, jetables, mais en aucun cas pour des projets complexes et destinés à évoluer dans le temps.

Plus le temps passe, et plus j’envisage le test d’embauche pour les développeurs comme un mélange intelligent de plusieurs éléments avec des coefficients différents :

• Une partie purement technique, afin d’évaluer la connaissance du langage, sur 10 points. Le candidat doit développer quelque chose de simple, mais avec des contraintes particulières, notamment en termes de sécurité, de rapidité ou d’utilisabilité, toutes ces contraintes étant clairement exprimées dans l’énoncé de l’exercice.
• Une partie méthodologie et compréhension sur 20 points. Celle-ci se traduit par une revue de code. Le code est revu avec le candidat qui explique sa démarche, et justifie ses choix.
• Une partie “freestyle”, sur 5 points, qui récompense les candidats ayant dépassé les consignes de base afin d’offrir une application plus sexy, plus agréable à utiliser, ou fonctionnellement plus riche.

L’idée derrière cela est de laisser leur chance à des éléments parfois moins bons techniquement, mais intelligents, capables de réfléchir et d’évoluer avec une bonne tournure d’esprit, pour de les mélanger à des équipes plus expérimentés et leur permettre de parfaire leur technique. Parce qu’une équipe projet n’est pas seulement un investissement pour l’immédiat.

En voilà une annonce qu’elle me fait plaisir.

Actualys, société spécialisée dans l’accompagnement global des grands comptes dans leurs projets web recherche actuellement un développeur spécialisé dans le framework Ruby on Rails (le même que celui qui fait tourner ce blog) pour une mission de longue durée chez un de ses clients.

Si vous justifiez d’au moins une première expérience significative dans le développement en Ruby on Rails et d’une bonne connaissance de ce merveilleux framework, merci d’envoyer votre CV à candidat[at]actualys[dot]com.

Actualys, jeune société parisienne spécialisée dans l’accompagnement des grands comptes dans toutes les phases de leurs projets web (nous ne sommes pas une SSII au sens général du terme) recherche un chef de projets web junior ayant de bonnes connaissances techniques, principalement en PHP, SQL, XHTML et CSS. Ruby, Ruby on Rails, Python et Java / J2EE seraient un plus.