Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

qualité

  • RH : autodidacte vs diplômé

    Dans le monde du web open source, il est assez difficile de recruter. Les profiles d'expérience sont essentiellement des autodidactes. Les jeunes recrues sortant d'écoles d'informatique, quant à elles, possèdent un bagage théorique souvent intéressant qui leur confèrent plus de rigueurs et d'idées.

    Je ne cracherais pas dans la soupe, ma formation d'école d'ingénieur généraliste à dominante mécanique m'a permis de faire du web. Toutes les personnes qui m'ont fait confiance pour me former (stages et embauches) avaient le même profil. Les entreprises françaises ont une forte culture du diplôme et je dois dire que le mien a été souvent un précieux césame. J'ai souvent pu constater que pour un recrutement où l'on cherche un "potentiel", une école d'ingénieur accessible depuis une prépa, ça percute plus vite.

    J'ai pourtant souvent remis en cause ma formation, trop génraliste ! Certes on apprend à apprendre, mais je m'en suis souvent voulu de passer à côté de concepts qui pourtant étaient sous mes yeux. Il n'y a rien de pire que de ne pas imaginer qu'une solution puisse exister car même la curiosité ne sauvera pas. Il s'agissait là, certainement, d'un manque d'expérience. N'avez vous jamais eu un stagiaire à former qui empile 10 fonctions, alors qu'il existe une fonction qui nativement fait la même chose ?

    Finalement de l'autodidacte ou du diplômé, je prend toujours celui qui a la plus forte intuition à penser à l'avance qu'une bonne solution existe. C'est un profile de bon fainéant : refléchir à faire plus simple, plus solide, de meilleur qualité avant de démarer un quelconque développement pour économiser du temps et de l'énergie.

  • Qualité mesurable et qualité perçue

    Il y a quelques temps j'ai été confronté à l'optimisation SEO (Search Engine Optimisation) d'un site. Une société en consulting avait fait une tonne de recommandations très pertinentes du genre "sculpter le linking interne", travailler les balises title, ... Au final, les couches de code se sont accumulés formant un projet web sans contour, ou les erreurs de mises en production se sont accumulés. Quand je suis arrivé, le patron m'a dit fièrement : c'est mathématique, si on projette la courbe d'audience dans 6 mois, on sera à 1M de visiteurs uniques par mois, en faisant quelques optimisations on sera à 1,5 M ce qui voudra dire que la société sera rentable.

    Quand j'ai lu les premières lignes de codes, celui-ci était codé en PHP de "base" sans objets, sans fonction avec beaucoup de requètes sql au milieu du code HTML, aucun log d'erreurs, ma première réaction avant même d'être en poste fût, ce n'est pas possible ce site ne tiendra pas 1 M de VU. J'ai expliqué au patron : "Tu me demandes de faire rouler une 2CV à 200 km/h, combien même on arrive à pousser le moteur, il va y avoir une soudure qui va cèder avant !" ce à quoi je me suis vu répondre : "oui mais j'ai pas les moyens de me payer une Ferrari, alors qu'une 2CV ça me va très bien !". C'était pas gagné.

    1°) La qualité interne

    Je l'ai compris, il y a peu, mais ce que demandait le patron, c'était de "tirer" sur la qualité interne du projet.

    Il a été assez simple de montrer qu'elle était la cause des soucis, mais plus dure de prouver son utilité. C'est paradoxal, n'est-ce pas ?

    En effet, nous avons mis en place des facteurs clef de performance (KPI) en maillant toutes les statistiques sur les points qu'appréciaient les moteurs de recherche. Nous avons utilisé Google Webmaster Tools (GWT) qui est très utile pour faire des relevés quotidiens des pages en 404, duplicate content, suggestion d'améliorations... Ce fut un progrès considérable mais pas une fin en soit. D'une part on c'est aperçu que la croissance précédente était lié à une émoragie qu'il fallu corriger rapidement, d'autre part, à chaque mise en production, on voyait les bugs !

    Au vue des bugs, le patron voulait d'abord que l'on colle un patch et basta. Mais j'ai opté in fino pour une migration progressive des parties du site buggé dans un framework. Cela nous a permis de stabiliser durablement les KPI. Nus avons gagné la confiance du patron par la baisse des retours et bugs. Ceci donna enfin l'impression au patron que la qualité interne était une base fondamentale.

    2°) La qualité perçue

    Il s'est écouler 6 mois et j'ai eu l'ordre de tout migrer dans le framework, la confiance du patron en prime : "C'est vache maigre depuis 6 mois car le site est buggé de partout, je te donne 1 mois pour tout passer dans le framework cela stabilisera toutes les KPI, avec ça si les visiteurs ne reviennent pas faut que l'on fasse autre chose !".

    Nous l'avons fait et pourtant le trafic n'est pas revenu comme escompté, pourquoi ?

    Google via les GWT nous a montré qu'il fallait être attentif à la qualité interne. Notre agence SEO également. Mais ce qu'on oublie trop souvent c'est le service rendu à l'utilisateur. Est ce que la qualité perçue est satisfaisante ? La puissance de Google c'est d'intégrer dans son algorithme cette qualité perçue, mais elle est difficilement mesurable. D'ailleurs, Google utilise des approximations en considérant que le taux de rebond, le temps que reste l'utilisateur, ... est un critère de satisfaction utilisateur. Il a dernièrement mis en place un système de vote sur les résultats.

    Les axes de travail purent être dès lors la qualité perçe.

    Conclusion :

    • La qualité interne est un facteur de non échec du service web proposé.
    • La qualité perçue est le facteur clef du succès du service web proposé.