Produits et projets web

2010 s'en est allé avec une grosse fatigue. Souvenez-vous, nous avons lutté contre les bugs, nous avons rejeté les idées reçues, nous avons rêvé en faisant des plans sur la comète...

Grosse fatigue, disais-je ! Oui, parcequ'entre les fêtes et son traditionnel "Rallye gastrique", il y a le travail. Vous savez les petits travaux ménagers dont vous dites tout au long de l'année : "là j'ai pas le temps, je ferais ça quand ce sera plus calme !".
Tenez par exemple, j'avais laissé un bouton de chemise. Mais figurez vous que j'ai trouvez le moyen de le coudre sur la partie intérieur. Pourquoi vous le partager ? Parceque 2010 était comme celà : pressé par le temps, avec une équipe jeune, nous avons trop souvent cousu le bouton à l'envers !

Mais ce n'est pas tout. En 2010, j'ai changé à minte reprises les lacets de mes mocassins. Tout ça parceque un oeillet est tranchant et sectionne lentement mais irrémédiablement et invariablement le lacet au même endroit ! Il a lâché pour la dernière fois ce 31 décembre. Ah ces petits grains de sable laissés au milieu des algorithmes, que les clients découvrent irrémédiablement et invariablement au même endroit, c'est fini en 2011. Espérons !

Sinon en 2009 et en 2010, il y avait des petites digressions, des petites histoires, des parallèles avec la vie quotidienne, ça il y en aura toujours en 2011.

Voilà les leçons que j'ai retenu de 2010. Voilà donc les résolutions de mon équipe, sinon ça va barder...

Bonne et heureuse année 2011 à tous mes lecteurs !

L'histoire est banal.
Le manager dit à son développeur : "t'as fait ton taf ?".
- ah ben oui cette semaine j'ai tout fini. Pis alors j'ai développé le synchro routeur dans le nouveau framework Ajax. C'est génial s'truc là, on va pouvoir instancier une session oauth même avec Facebook Connect.
- Et t'as corrigé le bug du man (1 man, des men...) ?
- euh le bug de la modération à partir de 23h ? Celui là oui il est bouclé pour de bon. Je me suis couché à minuit pour vérifier. Ça tourne au poil.
- c'est chouette...

Là, la pile de dossier, la fatigue de la semaine, j'ai laisse filer l'argument. Je ne suis pas un manager héroïque. Que je suis faible : méfions nous du développeur qui vous dit réaliser ses tests en vérifiant ... sur le lieu où il a commit son forfait ! A quoi servent les tests unitaires bon sang !

Le weekend arrive et le samedi, coup de fil du client.
- Grrrrrrrrr ! je comprend pas la modération marche plus.
Et flute ! Le samedi et le dimanche c'est modéré en permanence, et là rien. Une bête erreur de condition si "on est samedi ET dimanche" au lieu de "on est samedi OU dimanche".

Une fois de plus mon médecin avait raison "décidément on ne trouve que ce que l'on cherche".

J'ai déjà parlé sur ce blog de Hudson, un serveur d'intégration continu, c'est à dire un logiciel qui permet de jouer des tâches conditionnels et déployer pas à pas les nouveaux développements d'un projets. Pour mémoire, voici les étapes de développement de logiciel :

1. Concevoir l'idée, c'est non seulement avoir une idée mais surtout savoir comment on va la mettre en oeuvre.
2. Planifier ses développements. L'utilisation de méthode Agile inspirée de SCRUM permet d'avoir une démarche itérative priorisant les actions les plus importantes en premier.
3. Développer avec une méthode comme le développement piloté par les tests (TDD : tests driven developpement). Cela permet de s'assurer à tout moment de la non regression d'un développement en jouant des tests unitaires.
4. Jouer les tests quotidiennement pour s'assurer que tout avance pour le mieux

Hudson qui est un logiciel à plugins permet de greffer de nombreux modules d'en faire un tableau de pilotage depuis le developpement jusqu'au déployement voire à l'exploitation de ses produits avec pour obsession le respect qualité.

J'ai découvert par hasard le Hudson de tout les produits de la fondation apache (ant, subversion, spamassassin, solr, ...). Cela donne une excellente idée de l'organisation de cet outil !

Premier postulat :

Un bug c'est comme une faute d'orthographe. Parfois, c'est grave et empêche de fonctionner ou de comprendre, parfois moins grave et purement cosmétique. Quand on se relit on ne voit pas toujours ses fautes ou ses bugs.

Deuxième postulat :

Il y a des applicatifs et développements web qui sont plus complexes que d'autres. La multitude de fonctionnalités fait qu'un produit devient de plus en plus difficilement maîtrisable pour un seul homme. Pouvoir échanger sur les dépendances entre les fonctionnelités permet d'envisager la suites des développements de manière plus sûre.

Conclusion :

Bien souvent certains développements deviennent tellement complexe à force d'ajouter des modules sans architecture logicielle que c'est comme la dictée de Pivot, c'est dure de faire zéro bug !

Après un long bavardage entre collègues, nous sommes tombés d'accord sur la finalité de la description des processus et des procédures. Pour moi qui suis un ultra procédurier, qui aime bien tout fixer et figer, j'avoue que trop de procédure nuit au bon fonctionnement des procéssus. C'est d'ailleurs presque toujours dans des environnements non maitrisés que l'on met en place des procédures. Mais si on ne prends pas le temps de savoir ce que l'on cherche à cadrer à travers ces procédures, on peu se tromper de cible et le remède devient pire que le mal.

J'ai vu une entreprise qui a mis en place des procédures pour cadrer le travail des ouvriers en pensant que le problème venait de l'organisation des tâches alors qu'il s'agissait des outils de travail qui n'étaient pas adaptés !

Donc pour les entreprises qui poussent je précaunise la description des processus pour commencer. Il s'agit de décrire de manière non figée, donc évolutive les us et coutume de l'entreprise. Dans les start-up qui grossissent comme des champignon, prendre le temps d'écrire l'histoire, c'est s'assurer que construire des bases solides. Les employés de seconde, troisième (et plus) génération n'ont pas le même tempérament de créateur d'entreprises et ont besoin d'être rassuré et cadré par rapport au devenir et aux ambitions de l'entreprise encore jeune.

L'autre intérêt d'écrire les processus, c'est l'automatisation des tâches. C'est particulièrement vrai en production ou exploitation informatique. Je me souviens de précédentes expériences où je regardais circonspect un directeur technique vouloir automatiser un procédé sans même le maîtriser manuellement. On ne peut automatiser un procédé que si l'on maîtrise manuellement toutes les étapes.

Une diférence entre l'exploitation d'un site web en B2C par rapport au B2B réside dans le niveau de confiance que le client peut avoir.

Prenons l'exemple de failles de sécurité : c'est un problème grave qu'il faut absolument corriger.

D'une manière générale, faire confiance sur internet est difficile et des sites buggés et peu fiable il en exsite à la pelle. Seulement en b2b l'exploitant prend seul la responsabilité, et le danger est souvent restreint à l'infrastructure et au données éventuellement stockées des utilisateurs. La plupart des services web sont modestes en visiteurs, en revenus, donc en ressource.

Quand on travaille en B2B2C (les services de forum sur les sites web des média tv ou papiers), le client payant un service à l'utilisateur finale, le livrable est un contrat de confiance. Le fournisseur ne peut pas ignorer les vis de fonctionnement, ni les failles de sécurité. S'il s'agit d'un client grand compte il aura d'autant plus de facilité à se retourner qu'il a de moyen de faire pression. Son image est en jeu, il n'aura aucune pitié.

Il y a quelques années, j'avais installé le soft de ma société sur l'infrastructure d'un client. En général, l'hébergement restait dans notre périmètre de sorte que nous maîtrisons mieux certains paramètres. Une nouvelle version logicielle était mise en place car nous avions passé l'applicatif de php4 à php5. Pour limiter les coûts et éviter de déployer le soft et réinstaller les serveurs à quelques mois d'intervalle, nous avons livré la nouvelle version tout juste terminée (fonctionellement oui mais tous les tests de sécurité non). Ils étaient content mais une fois notre job terminé, le client a commandé un audit de sécurité. Toutes les failles de sécutité ont été corrigées en une semaine, mais la négociation commerciale qui s'en ait suivi à été très houleuse (pénalité, ...).

Depuis, quand je suis sur un nouveau projet, je fais des tests, et à tous les coups, je trouve quelques choses. Depuis quelques temps, j'ai élargis les vis de sécurité à tous les vis fonctionnels (bugs critiques) de sorte d'évaluer de manière binaire ce qui marche vraiment sur un service web... Seule 30% des projets informatiques sont des succès (répond au besoin, à été livré à temps en respectant le budget) d'après une étude récente, maintenant, je le comprend.

Pour en conclure avec le Sonnet pour Hélène de Ronsard de ces deux derniers jours: "Vivez, si m’en croyez, n’attendez à demain : Cueillez dès aujourd’hui les roses de la vie."

Vous aurez reconnu l'allusion à la génération Y, qui profite du temps présent avec désinvolture au risque de semer le trouble des managers du temps jadis (sic) ;)

Parmi les choix startégiques à faire, il me semble indispensable de maîtriser son core business. Une fois de plus cela va sembler être des portes ouvertes pour certains, mais dans le milieu des start up, le temps est compté et on commet souvent quelques raccourcis.

C'est tout bête. Emporté par l'euphorie, certains entrepreneurs, et c'est là que l'on reconnais les meilleurs, oublient ou ne savent pas qu'il est impératif de maitriser les techniques qui font l'activité de l'entreprise. Un projet web, un site social networking par exemple, qui externaliserait tous ses développements, sans avoir de compétences en interne pour juger de la qualité du travail s'expose à des difficultés :

• Difficultés pour modifier les développements au quatidien / réactivité
• Soin pour la qualité et la sécurité du site web
• Vision et orientations techniques du projet à long terme
• ...

Cela ne veut pas dire qu'il ne faut pas faire appel à des expertises extérieurs ou externaliser une partie du travail. L'expertise permet justement de monter en compétence sur des techniques qui ne sont pas maitrisés en interne et que l'on a conscience que c'est un point à travailler. Demême, l'externalisation, pour des raisons économiques ou de surcroît d'activité permet d'améliorer la capacité de l'entreprise à répondre aux besoins des clients dans de meilleurs conditions.

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é.