J'ai été invité par Le Train de 13h37 à m'exprimer sur un sujet qui a été recalé de peu à Sud Web et Paris Web. Le thème en est l'importance d'un service de bug dans un projet web conséquent. C'est un sujet qui me tient à cœur car il représente en lui-même un fondamental de la qualité web.
C'est aujourd'hui qu'est publié « Concevoir un service de rapport de bug », et je remercie énormément Corinne Schillinger et Loïc Mathaud de leur patience et leurs conseils avisés pour en faire un article qualitatif.

Néanmoins, il me fut difficile de tout mettre dans un article. J'avais matière à remplir plusieurs papiers, entre anecdotes et éléments trop en dehors du sujet. Je profite donc de mon blog personnel pour compléter ce que j'ai écrit dans Le Train de 13h37

La terrifiante vérité sur les bugs

Nombre de gens sont intimement persuadés que les développeurs font exprès de faire des bugs. Et en plus, ils y croient dur comme faire fer.

Le premier bug report dans un log d'ordinateur, avec un papillon de nuit en pièce-jointe.

Le terme de bug pour une incohérence de fonctionnement est plus vieux que l'histoire de l'informatique. À en croire le Musée National de l'Histoire Américaine, Thomas Edison utilisait ce terme pour parler de ses soucis sur son réseau de distribution électrique. Grace Hooper, dont Google a souhaité un joyeux anniversaire hier, serait la reportrice du premier bug insectoïde dans le journal à lampes d'un super ordinateur papier. oups : inversion

Mais il est impossible de faire croire aux profanes que nous ne le faisons pas exprès : Parce qu'à leurs yeux, nous sommes capables de faire n'importe quoi avec les ordinateurs, même les trucs les plus magiques comme on en voit que dans les films.

Pourquoi cette passion

Quand j'ai commencé en tant que développeur web indépendant, je connaissais quelques services de rapports de bugs : Celui de Mozilla; bien sûr, celui de Gnome, de KDE, et de bien d'autres outils. Mais je croyais que ce genre de service était trop gros, trop présomptueux pour moi.

Et puis, alors que je travaillais sur des projets de plus en plus importants, je me rendais compte que j'avais du mal à trier les erreurs par priorités. Tout arrivait dans ma boîte e-mail : demandes de devis, spams, refus de devis, contrats, propositions de veuves nigérianes, CR, plans et bien évidemment signalement de bugs.

Or il n'y avait aucune hiérarchie ou information utilisable dans ces e-mails. Lesquels me parlaient de bugs ? Où avaient-ils lieu ? Quelle est l'intention ? Quelle criticité ? Des fois, je retrouvais dans le même e-mail jusqu'à 20 points abordés. Le vrac total.

J'ai donc commencé à concevoir dans mon service une fonctionnalité de rapport de bug. Avec des questions simples, un système qui récupère les informations susceptibles de m'être utile (heure, navigateur, login, URL, derniers formulaires remplis, feedbacks…), et des alertes d'avancement par e-mail. Je pense qu'au bout de 3 mois de pédagogie, certains clients en étaient contents car ils s'en servaient préférentiellement plutôt que m'envoyer un e-mail ou m'appeler sur mon portable.

Là, j'ai entrevu la puissance du bug tracker.

Ce qu'on ne dit pas sur un bug tracker

On sous-estime la puissance d'un bug tracker : c'est bien plus qu'un outil de signalement et suivi de résolutions de bugs.

Bien des entreprises refusent d'entendre parler de ce genre d'outils, même en interne. La notion d'imperfection est taboue, la possibilité qu'errare humanum est n'est même pas rationnellement envisageable, donc perseverare diabolicum. Il faut donc souvent travailler au corps et au core du projet pour arriver à instaurer ce qui semble, pour nous qui concevons, le principe même de base de la qualité d'un produit.

Tenez, par exemple, quand Mozilla est devenu un projet open-source, l'une des premières idées fut d'instaurer un service de rapport de bug. C'est le fameux Bugzilla, qui est un devenu projet indépendant et utilisé par de nombreuses entreprises en interne. Quand, suite au lancement de Firefox et au grignotage de part de marché, Microsoft relance le développement d'une nouvelle version de leur navigateur web, Internet Explorer 7, l'équipe de conception IETeam a immédiatement pris note de l'importance de collecter les retours utilisateurs : ils permettaient d'établir très vite les manques les plus gênants pour les utilisateurs et les concepteurs de sites. Bref, de classer par priorité.
Évidemment qu'ils étaient fiers de leur service de bug report. Sauf que les gens du marketing ont hurlé la première fois qu'ils l'ont vu, et ont exigé que la copie de Bugzilla par la IETeam soit renommée feedback IE. I.E. avec des messages beaucoup plus positifs. L'intention n'était pas mauvaise en soit, mais cette incompréhension en interne aurait désespéré l'équipe IETeam.

Cet espace de discussion

Point extrêmement important : une base de bugs est une importante mine d'informations sur les regrets, ces portions de code qui ont été abandonnées, ces fonctionnalités qui ont été supprimées, ou même des idées qui ont été très vite écartées.
Car un service de rapport de bug doit aussi pouvoir servir comme boîte à idées, ouverte à des suggestions, à des propositions d'améliorations, à collecter des information manquantes dans une documentation. Un service de bug est intimement lié à un produit, à partir du moment où ce produit atteint la taille critique lui permettant d'être utilisable. Et de là, certains bugs alimenteront votre base de tests fonctionnels (TDD, BDD,…).

En fait, une collection de rapports de bugs, c'est un peu comme les messages de commits de CVS/SVN/Git, les carnet de produit d'un projet Scrum, la todo-list crayonnée aux toilettes ou les commentaires de votre code source : ce sont des éléments insoupçonnés qui indiquent la vie d'un projet, un ensemble de tests fonctionnels à décrire etc... D'importantes métadonnées de votre code.

Il faut toujours y motiver les décision, y collectionner les liens d'informations.
Comme un service de bug est accessible par bien plus de personnes que le code source d'un produit — et quand je dis accessible, je sous-entend bien plus lisible que le code source ou les messages de commit — il se trouve de fait comme un espace de discussion, une base d'information collaborative privilégié.

Cela veut dire que l'information ne doit pas aller en sens unique « Je me plains des bugs », mais permet de remonter aussi les incohérences de cahiers des charges, de cinématiques, de charte graphique, d'UX, etc… Il n'y a pas de raisons que les commerciaux croient qu'ils ne font jamais d'erreurs, ou que les graphistes qui travaillent exclusivement sur Photoshop aient la science infuse.

Ça marche pas n'est pas un rapport de bug

On ne fait jamais l'économie d'expliquer : les commentaires one-liner (phrase d'une ligne, totalement sibylline et en générale sujette à interprétations contradictoires) n'incitent pas à remplir proprement des bugreports.

Les premiers jours seront longs. Le plus difficile sera d'expliquer à vos utilisateurs que non, ce n'est pas parce que le téléphone est à côté de vous qu'il permet une correction plus rapide. Que multiplier les coups de fils ne vous rend pas forcément plus disponible et disposé à corriger plus vite. Que non, vous n'êtes pas un putching-ball de leurs frustrations. Et que prendre le temps de répondre aux questions et de décrire un problème, c'est autant de temps de gagné pour eux-même.

Oui, cela peut sembler évident pour nous, mais pour bien des clients, la démarche est totalement contradictoire.

Pièces jointes

Comme le disait Napoléon « une capture d'écran vaut mieux que mille messages par MSN ». Comme il avait raison, le bougre.

Le problème, ce sont les clients qui croient plus parlant les captures d'écrans collés dans des powerpoint.
C'est inutilisable, mais il aiment les powerpoints. Ils aiment tellement qu'ils s'échangent les blagues mails collectées dans La Dépêche, les photos de femmes nues, collés dans des documents powerpoint comme on faisait des albums Panini dans le temps. Et finalement, ils vous envoient aussi des powerpoint pour vous dérider.
À tel point que vous n'ouvrez jamais les documents powerpoint...

J'avais tenté le pari de me passer de captures d'écrans, afin d'avoir du texte. Parce que le texte, c'est plus facile à chercher par une requête texte qu'un powerpoint farci de captures.

Mais des fois, on a besoin d'une capture écran. Doit-on héberger des images, au risque du flood ? S'en passer, c'est obliger à être descriptif. Très utile si le design concerné change lourdement par la suite alors qu'on parle d'une cinématique, d'une action ou d'une fonction.

Question de priorités

Dans mon projet Dagence, moi et Xylpho avions établi différents niveaux de priorités, et que nos clients qui les remontent puissent eux-même les classer. Nous avions 4 groupes principaux :

  • Triviaux (principalement les demandes d'améliorations)
    • Suggestions
    • Améliorations
    • Extensions
  • Non négligeables (ne remettant pas en cause la production)
    • Problèmes esthétiques
    • Problèmes fonctionnels
  • Importants (causant des soucis en production)
    • Gènes ergonomiques
    • Gènes fonctionnelles
  • Urgents (rendant le service inutilisable)
    • Problèmes critiques

Tout bug classé dans le dernier groupe entraînait immédiatement l'arrêt de toute tâche en cours pour le résoudre au plus vite.
Évidemment, certain-e-s excité-e-s abusaient un peu du mode critique. À tel point que nous avions envisagé que pour tout bug reporté en critique, le formulaire demande confirmation par un captcha afin de juger de l'urgence de la chose par la motivation. Comme ceci :

captcha impossible à ré-écrire

Nous ne l'avions pas fait car nous même nous n'aurions pas eu la patience de le décoder en rédigeant un bug critique. Et puis surtout, c'est une méthode dark pattern qui fut poussée à l'extrême par 1&1.

Donc nous avons opté pour une éducation de nos clients pour qu'ils ne mettent pas tout en Critique, on arrête tout tant que c'est pas résolu : une facturation au ticket incident.

Et plutôt que payer, les clients problématiques ont commencé à tout mettre en Urgent. Alors il a fallut leur expliquer le sens de l'urgence, et l'importance qu'une fonctionnalité qu'ils n'ont pas voulu payer dans le devis ne coûtera pas moins cher s'il est lourdement redemandé comme condition de livraison du service.

Phare de west-end

Un bug tracker, c'est un moyen efficace pour instaurer dans une entreprise les premiers pas d'une gestion de projet cohérente : priorités, assignations, temps de résolution. Et cela supprime bien des “raisons” de réunions.

Quand on est indépendant, un bug tracker est aussi un baromètre : il se montre un excellent indicateur quand le projet part à la dérive, parce qu'il commence à être encombré de demandes de fonctionnalités refusées dans le premier devis, quand le client n'arrête pas de remonter le même bug qui correspond à la demande validée à la commande ou quand un prestataire tiers n'arrive plus à suivre.

Un service de bug est excessivement utile. Quant à savoir s'il vaut mieux le concevoir ou utiliser un service cloud, je vous laisse juger par vous-même dans mon article publié aujourd'hui sur Le train de 13h37.

Bien plus qu'une fonction support, l'exercice en est passionnant

À lire ailleurs :