Parlons recettes, voulez-vous ? Recette informatique !

Le métier de chef de projet comporte un aspect souvent négligé mais pourtant vital : la recette. Que l’on soit in-house avec des comptes à rendre à sa hiérarchie, ou prestataire qui souhaite voir son projet validé par le client, cette étape doit être au cœur du projet dès sa conception.

Avant d’entrer dans les détails technique, je pense qu’il est nécessaire d’expliquer ce qu’est une recette parce que nous verrons qu’il n’y a pas une, mais des recettes. Ensuite je vous propose d’aborder la théorie de la recette fonctionnelle. Enfin je vous proposerai une méthode « spécial débutant » pour faire la recette d’un site internet quand rien n’est formalisé à ce sujet, et nous discuterons des limites de cette méthode.

Pour illustrer cet article nous allons prendre le cas de la mise en place d’un site internet fonctionnant sous WordPress avec le développement d’un plugin de collecte d’emails et d’envoi de newsletter sur mesure. Rassurez-vous nous n’aborderons aucun aspect technique, le projet sera simplement en toile de fond, un liant entre les exemples.

checklist

Les recettes d’un projet informatique

Commençons donc par expliquer ce qu’est la recette d’un projet informatique. Il s’agit d’un test ou d’une série de tests, destinés à valider le fonctionnement d’un site internet ou d’un logiciel et sa conformité par rapport au cahier des charges. Dans cette définition il y a 3 éléments à retenir :

  • une série de tests : chaque étape du projet, chaque fonctionnalité doit être testée et validée ;
  • le fonctionnement du produit : il ne s’agit pas d’afficher une page à l’écran mais de s’assurer que tout ce qu’il y a derrière est opérationnel. Pour notre plugin de newsletter nous allons par exemple vérifier que les adresses collectées sont bien stockées quelque part (fonctionnalité 1), que l’interface d’affichage des adresses collectées affiche bien la totalité des emails (fonctionnalité 2) … ;
  • la conformité par rapport au cahier des charges : le client n’est pas forcément intéressé par le fait que les adresses collectées soient stockées dans un varchar(255), ce qu’il sait c’est que dans le cahier des charges il est écrit que les adresses sont collectées et qu’il y a accès pour envoyer ses mailings. Vous saisissez cette subtile nuance entre le développeur et l’utilisateur ?

Vous comprenez maintenant pourquoi il n’y a pas une, mais plusieurs recettes réalisées avant et après la livraison.

Côté MOE : la recette interne, ou recette usine

A ce stade nous allons vérifier en interne le fonctionnement du produit à l’aide de 3 types de test :

  • tests unitaires : chaque fonctionnalité va être testée séparément,
  • tests d’intégration : toutes les fonctionnalités regroupées dans notre plugin doivent fonctionner ensemble
  • tests de validation : avant de demander au client si le plugin correspond au cahier des charges, on s’en assure dans notre coin à l’aide de 3 types de tests de validation :
    • la validation fonctionnelle : est-ce que le produit est tel que décrit dans le cahier des charges ?
    • les tests de performance : s’il faut 1 minute pour afficher une liste de 500 adresses, le client ne sera certainement pas satisfait. On peut faire ces tests au jugé ou bien en utilisant des outils de mesure précis (la mention «62 requêtes effectuées en 0.21 secondes» affichée en bas de page sur certains sites…)
    • les tests de robustesse : que se passe-t-il si on injecte 1000 adresses ? 10000 adresses ? Si 15 personnes se connectent en même temps ? Si 150 personnes se connectent en même temps ? En répondant à ces questions je viens de tester la capacité à gérer augmentation du volume de données et un pic de charge.

Le client n’est pas concerné par ces tests : si vous faites bâtir votre maison vous demandez à avoir un interrupteur à côté de la porte qui allume une lumière au plafond, vous ne voulez pas savoir comment ça a été construit ni testé.
En théorie ces 3 types de tests internes sont bien dissociés. Si vous travaillez sur un grand projet avec une grande équipe vous avez peut-être une cellule dédiée à chaque étape. Si vous travaillez dans une équipe plus modeste mais qui applique des méthodes Agile vous avez peut-être un chef de projet qui gère l’intégration et la validation pendant que chaque développeur fait ses propres tests unitaires, c’est typiquement une configuration rencontrée avec avec la méthode Scrum. Si vous êtes seul sur le projet vous ferez certainement les 3 types de test plus ou moins en même temps, selon l’avancée du développement.

Dans tous les cas, vous devez faire une recette interne complète avant chaque livraison ! Introduire un bug arrive à tout le monde, expliquer à quelqu’un qu’on a perdu 1/2 journée à cause d’un bug est acceptable (même si cela aurait dû être mieux planifié) et passera certainement mieux aux yeux d’un client que la livraison d’un site buggé.

usine

Côté MOA : la recette utilisateur

Ca y est, vous avez livré le site. Vous pensiez avoir fini ? Et bien non !

Passons maintenant à la recette utilisateur, que l’on rencontre parfois sous le terme «vérification d’aptitude au bon fonctionnement» (VABF). Cette recette, ces recettes encore une fois, vont être faites soit par le client, soit par le chef de projet MOA sous son contrôle.

Pourquoi le chef de projet ferait des tests pour le client ? Parce que la recette utilisateur comprend une recette technique qui ressemble pour beaucoup aux tests de validation de la recette usine. Il s’agit de tester le site (ou logiciel) dans son environnement de production : performance, robustesse, sauvegarde… Dans le cas de notre projet WordPress, certains modules ont peut-être besoin d’une configuration spécifique sur le serveur, le module de sauvegarde nécessite peut-être un nouveau paramétrage… Le client pourra dire « oui je vois que cela fonctionne » mais il ne pourra peut-être pas déclencher les tests lui-même.

Par contre, la recette fonctionnelle sera généralement faite par le client : il va valider point par point que ce qui lui est livré correspond à ce qu’il a commandé en s’appuyant à son tour sur le cahier des charges.

reunion

C’est pas fini : la recette définitive

Le site fonctionne peut-être le jour de la livraison mais il peut arriver que cela cesse au bout de quelques jours, par exemple parce que la base de données est pleine. Il est donc nécessaire de passer par une phase dite de vérification du service régulier qui est une période à l’issue de laquelle le projet est considéré comme définitivement validé. Cette période peut être fixée par contrat pour une durée variable de quelques jours à plus d’une année selon l’importance du projet. Comment valider le service régulier d’un site web ? En général on utilise son taux de disponibilité, par exemple pour confirmer que le site fonctionne bien on attend 99% de taux de disponibilité, ce qui représente un peu plus de 7 heures d’indisponibilité sur 30 jours.

Pour compléter ce sujet, je vous invite à lire cette page qui se concentre sur l’aspect juridique de la procédure de recette.

 

La recette fonctionnelle – cas théorique

Si l’utilisateur final doit être capable de valider une par une chaque fonctionnalité du site web c’est, comme je l’ai dis en introduction, parce que cette recette a été pensée dès la rédaction du cahier des charges. En paralèlle à la rédaction de ce dernier, nous allons créer un cahier de recette qui contiendra la liste des fonctionnalités à tester, avec pour chacune la description du ou des test et le résultat attendu. Pour des projets de taille modeste à moyenne, il arrive que le cahier de tests apparaisse dans le cahier des charges, il se limite alors souvent à la description des tests manuels, les tests automatisés étant réservés à l’usage interne.

Petite parenthèse :

Notez que j’utilise des termes comme «souvent », «parfois », «généraleme »nt» à l’envi. En effet, le formalisme n’est pas imposé et chaque société a sa propre façon de rédiger ses documents, son degré de précision en fonction du projet (on ne va peut-être pas passer par une phase de spécifications techniques si on met en place un site statique de 5 pages sans même un formulaire de contact)… La seule chose importante est que les informations soient là et que la documentation soit utile.

A chaque fonctionnalité prévue correspond un test ou une batterie de tests, par exemple  :

  • Inscription à la newsletter  – 1
    • Fonctionnalité  : Affichage d’un message de confirmation
    • Test  : le message s’affiche-t-il  ?
    • Type de test  : manuel
  • Inscription à la newsletter – 2
    • Fonctionnalité  : stockage de l’adresse en base de données
    • Test  : Rechercher l’adresse saisie en base de données
    • Type de test  : automatisé. Utilisation d’un script qui envoie de 10 requêtes http POST simulant le formulaire et une requête sql pour vérifier l’enregistrement des adresses
  • Inscription à la newsletter – 3
    • Fonctionnalité : affichage des informations dans le backoffice
    • Test : les adresses saisies apparaissent-elles ?
    • Type de test : manuel

Cet exemple est intéressant parce qu’on voit à la fois des tests humains et un test automatisé, qui pourra donc être mis en place de façon systématique pendant tout le cycle de développement. Si nous nous interessons aux deux tests manuels, on s’aperçoit que décrire la fonctionnalité revient à décrire le test, le travail ici est juste de formaliser les futurs tests et de déterminer ce qui peut être automatisé et de quelle façon ça peut l’être.

Pour faire la recette fonctionnelle, le client n’aura plus qu’à effectuer les tests décrits et à valider leur réussite.

Vous rendez-vous compte qu’il ma fallu environ 40 lignes à expliquer comment anticiper la phase de recette et qu’il suffit d’une phrase pour expliquer comment réaliser la recette ? Si oui, vous avez compris que le travail ne se fait pas après, mais avant le développement.

cycle de recette d'un projet web

Voici comment la recette évolue en parallèle du projet

Avant de passer à la suite, revenons un instant sur le test automatisé. A-t-on perdu du temps ? Si tout est développé comme il faut dans un monde idéal, sans aucun doute. Mais dans le monde réel, celui où les test échouent de temps en temps, je suis sûr que non. Nous allons perdre 15 minutes à écrire le script d’automatisation, nous allons même nous payer le luxe d’ajouter une ligne dans le script pour nettoyer la base de données après avoir fait le test si le test n’échoue pas (c’est important). Si nous effectuons ce test une fois à la main, cela prendra 5 minutes, la version automatisée nous en aura fait perdre 10, si nous le faisons 4 fois nous aurons gagné 5 minutes grâce au script et si le test est lancé avant chaque commit d’un projet qui implique plusieurs branches (notre plugin de newsletter pourrait avoir une équipe qui s’occupe du frontend et une qui s’occupe du backoffice) pendant plusieurs semaines nous aurons gagné des heures entières et nous aurons surtout l’assurance qu’aucun bug n’a été introduit pendant le cycle de développement. Autre avantage non négligeable : personne n’aura à s’occuper de cette tâche ingrate et répétitive.

temps-projet

La recette fonctionnelle – cas pratique

Il existe un univers entre la théorie ou les bonnes pratiques mises en place dans les grands groupes et les agences les plus sérieuses et la réalité des PME qui sont sans cesse en train de repousser les limites pour trouver du temps et/ou du budget. Ainsi le cahier des charges n’existe bien souvent pas ou se résume à sa plus simple expression (ne me dites pas que vous n’avez jamais croisé un projet dont l’avant vente se résume à une réunion, un débrief d’une page et un wireframe de la page d’accueil, on verra le thème plus tard…) et quand il s’agit de faire la recette c’est tout de suite plus compliqué ! Est ce qu’on parle des graphismes ? Doit-on traiter de la même façon un lien qui ne marche pas et une phrase manquante ?

Réalisation du document de recette fonctionnelle

Je vous propose une méthode pour faire le tour d’un site et construire à la fois une recette détaillée et une todo list priorisée qui permettra de faire remonter les anomalies et de suivre leur correction. Pour aujourd’hui nous n’utiliserons pas de logiciel de suivi des anomalies mais un simple tableur, un logiciel de dessin et un peu de méthode.

Le principe est simple : nous allons nous placer sur la page d’accueil du site et en faire une capture d’écran que nous allons annoter à chaque fois que nous trouvons une erreur. Il suffit d’utiliser votre logiciel de dessin préféré pour entourer l’anomalie et la numéroter.

Pour expliquer à quoi correspondent ces erreurs nous allons créer un tableau qui comportera les colonnes suivantes :

  • Page : utilisez au choix le nom de la page ou son url, ce qui compte c’est de s’y retrouver
  • Section ou fonctionnalité : parce qu’une page peut être très riche, il peut être nécessaire de préciser (par exemple, bloc d’inscrption newsletter)
  • Description de l’anomalie : elle doit être assez claire pour que n’importe quel lecteur puisse comprendre (préférez «le message de confirmation n’apparaît pas» à «problème js confirmation»)
  • Nom du fichier de capture d’écran : cela nous évitera d’avoir à chercher partout
  • Numéro de l’annotation sur la capture d’écran : enlève toute ambiguïté
  • Le niveau de criticité de l’anomalie : cette anomalie est-elle importante ou pas vraiment ? On y revient dans une seconde.

Votre tableau de recette est désormais prêt à être rempli. Commencez par la page d’accueil comme nous venons de le voir et suivez une à une toutes les pages de votre site.

Mais avant cela, parlons du niveau de criticité comme promis. On a tous à l’esprit une échelle de valeur qui va de « tant pis » à «  là ça va pas être possible » mais il faut bien trouver une échelle un peu plus formelle que ça pour communiquer avec d’autres intervenants. Je vous propose d’utiliser une méthode assez répandue pour classer les anomalies par niveau d’importance.

priorités MoSCoW

La méthode MoSCoW

Si vous n’avez jamais entendu parler de cette méthode vous vous demandez certainement pourquoi j’ai écrit MoSCoW de cette façon et pas tout en minuscules ou majuscules. C’est simplement parce qu’il s’agit de l’acronyme de Must – Should – Could – Won’t (MSCW) auquel on a rajouté des «o» juste pour faire joli (vous avez essayé de prononcer MSCW ?).

Alors, must, should, could, won’t. De quoi s’agit-il ?

Nous avons là 4 niveaux de priorités :

  • Must – il est impératif de traiter cette anomalie. Dans cette catégorie se trouvent tous les bugs (liens morts, images qui ne s’affichent pas, emails qui ne s’envoient pas…) et les non respects flagrants de la charte graphique (logo erroné, les CTA ne sont pas de la bonne couleur…)
  • Should – cette anomalie devrait être traitée. Ici je place toutes les anomalies graphiques génantes pour garantir une expérience utilisateur optimale : mauvais calibrage des textes, un bouton qui dénote de la charte graphique (c’est le cas de figure typique quand on utilise un thème prêt à l’emploi, il y a toujours un bouton qui n’a pas été traduit ou un lien quelque part qui ne ressemble pas aux autres). Si quelque chose ne fonctionne pas, il s’agit d’un must. Si ça fonctionne mais que ça n’est pas joli, il s’agit d’un should
  • Could – s’il reste du temps et du budget on peut traiter cette anomalie. Tout fonctionne mais on s’est rendu compte que ça serait plus joli avec les boutons en bleu, le carousel de la page d’accueil n’affiche pas de jauge pour indiquer le temps restant avant le défilement… En fait il ne s’agit pas d’anomalies selon le cahier des charges, il s’agit plus de petits bonus pour améliorer le confort de l’utilisateur. En général les tâches «could» ne sont pas chronophages.
  • Won’t – cette anomalie ne sera pas traitée. D’ailleurs ça n’est pas une anomalie : vous aviez demandé un grand bandeau sur votre page d’accueil, pas un slider dont on peut administrer les calques et les effets de transition comme une présentation Powerpoint ! Nous aurons droit ici aux souhaits d’améliorations non prévues par le cahier des charges et qui nécessitent de renégocier le budget initial.

Ca peut sembler un peu tiré par les cheveux de raisonner de cette façon, d’autant que la méthode MoSCoW est à l’origine prévue pour spécifier les besoins que pour faire de la recette fonctionnelle, mais je trouve que cela fonctionne plutôt bien.

Pour résumer, si une fonctionnalité manque ou ne fonctionne pas, c’est du Must. Si ça fonctionne mais que ça ne rend pas comme prévu, c’est du Should. Si ça fonctionne comme prévu mais que, à la réflexion, ça pourrait être mieux, c’est du Could. Si on veut ajouter une fonctionnalité ou révolutionner la charte graphique, c’est Won’t.

Une dernière chose : puisque nous travaillons sur un tableur et que nous allons bientôt trier nos lignes, pensez à préfixer les libellés de vos priorités : 1-Must, 2-Should, 3-Would, 4-Won’t.

Organiser le projet à partir de la recette fonctionnelle

Nous sommes toujours dans l’optique de la recette dite «à l’arrache» alors optimisons nos efforts au maximum et utilisons notre document de recette pour organiser le travail de correction à venir. Nous allons simplement ajouter 4 colonnes :

  • Status : cette colonne va indiquer si l’anomalie est «à corriger», «corrigée», «en cours»…
  • Acteur : nous allons assigner chaque ligne à la personne qui va la traiter
  • Date de mise à jour
  • Commentaire

Pour savoir qui doit faire quoi c’est simple il suffit de trier le tableau par priorité descendante et de le filtrer par acteur et par status. Bien entendu il faut un suivi sérieux du document et des priorités.

Les limites de cette méthode

Cette méthode fonctionne mais elle montre quand même ses limites.

Tout d’abord, vous imaginez peut-être déjà la difficulté de définir le niveau de criticité d’une anomalie : le client trouvera tout vital, le développeur trouvera tout normal et au milieu le chef de projet deviendra chèvre. Le talent de ce dernier se mesurera alors à tenir le budget tout en ayant un client satisfait d’en avoir eu pour son argent plutôt qu’un client qui a eu ce qu’il a payé.

Ensuite, en l’absence de pistes à explorer, cette recette doit être exhaustive et manuelle ce qui est extrèmement coûteux en temps. Oui vous avez bien lu un humain va devoir tester une par une toutes les pages, un par un tous les liens ! Il est donc nécessaire dès que le site dépasse les 10 pages de définir un protocole de tests automatisés pour gagner du temps : on peut utiliser un outil pour tester les liens des pages et/ou les chemins d’accès aux images, on peut créer des macros sur le navigateur pour simuler des remplissages de formulaires… Le travail de réflexion que nous avions mené avant le développement dans le chapitre théorique se retrouve à nouveau sur le tapis maintenant.

Je ne le répéterai jamais assez mais un bon cahier des charges est à la base de tout projet, et même un mauvais cahier des charges est mieux que rien.

Enfin, j’imagine qu’une partie d’entre vous a bondi de sa chaise en voyant que la partie « gestion de projet » suivant la recette était gérée par 4 colonnes dans notre tableur. Oui, nous sommes très loin des outils de suivi de bugs, de leur puissance et de leur souplesse. Rassurez-vous je prépare un article sur l’excellent Mantis pour les semaines à venir, nous aurons l’occasion d’en reparler. Vous aurez certainement noté qu’avec mon tableau on ne peut absolument pas gérer les diverses mises à jour sur une anomalie donnée. Imaginons pour notre projet que l’anomalie soit « rien ne se produit quand essaie de s’inscrire à la newsletter ». Nous aurons une seule ligne dans notre tableau, elle sera bien entendu en priorité « Must », et aura pour status « à faire ». Le développeur va commencer par tester le formulaire en lui même, ses javascripts… Le status de la ligne passe à « en cours », la date de mise à jour change. Le développeur pense avoir trouvé, le formulaire réagit, tout semble bon, la ligne passe à « résolu », la date de mise à jour est actualisées. On se rend compte que le front-office réagit bien mais que les adresses ne sont pas inscrites dans la base de données. Est-ce que l’on retourne au status « à faire » ou est-ce que l’on inscrit une nouvelle ligne ? Est-ce qu’il n’aurait pas mieux fallu scinder le bug dès le début ? La seule façon de gérer tout cela est l’utilisation intensive du champ « commentaires », ce qui est finalement loin d’être pratique.

question

Comment conclure maintenant alors que je viens de passer 10 minutes à vous présenter une méthode pour expliquer qu’elle n’est pas terrible ? Si vous pensez cela, vous m’avez mal compris ! J’ai utilisé cette méthode pendant des années et je l’utilise encore pour des petits projets. Croyez-vous que j’utilise un bug tracker pour ce blog ? Croyez vous que je n’ai pas de suivi des anomalies ? Donc je confirme, mon fichier Excel peut servir selon vos besoins. Mais il peut surtout servir de base, de tremplin pour professionnaliser vos pratiques, pour vous aider à acquérir un formalisme.

Si vous n’avez jamais fait une recette fonctionnelle, si vous n’avez pas de planning de développement, alors il est urgent de vous y mettre. Si vous pratiquez la recette « à l’arrache », alors il est urgent de vous professionnaliser parce qu’en lisant ces lignes vous aurez compris que l’alpha et l’oméga du projet informatique finalement c’est le cahier des charges et que le temps que vous aurez gagné en ne le rédigeant pas sera perdu par la suite.

Encore une fois, votre expérience est précieuse alors n’hésitez pas à nous parler de vos propres pratiques en commentaires : expliquez nous quelle importance a la recette dans vos projets, dites-nous si vous êtes en agence, in-house, en freelance, quelle est la taille de votre équipe… et n’hésitez pas à partager vos propres méthodes de recette, parce que j’en ai présenté une, mais que les vôtres sont probablement très différentes !

7 réponses

  1. Octobre Blanc dit :

    Bonjour.
    Tout d’abord bravo pour cette explication très complète.
    Je suis dans une petite agence web : 5 personnes. La recette se limite à un tour du site avec le client et on travaille souvent sans cahier des charges.

  2. Renaud M.G. dit :

    Merci Octobre Blanc pour ton retour d’expérience, quel type de clients avez-vous ? des PME ? des artisans ?

  3. […] Parlons recettes, voulez-vous ? Recette informatique ! Le métier de chef de projet comporte un aspect souvent négligé mais pourtant vital : la recette. […]

  4. C’est parfois difficile d’intégrer un recettage sur des petits sites au budget réduit, car cela demande pas mal de temps au final.

  5. Renaud M.G. dit :

    @Aurélien, oui ça demande du temps mais si le site est petit, pas tant que ça… à moins de trouver un tas de problème (auquel cas la recette sera justifiée) on peut parcourir sérieusement un site de 20 pages en 1H, ça dépend aussi s’il y a un livrable pour cette recette et son niveau de détail.

  6. bob dit :

    Excellent – j’avais du mal à trouver un article concret sur les recettes, et le tiens est ce qu’il me faut.

    N’hésite pas à mettre à disposition les templates/exemples des livrables si possible : cahier de recette, xls des anomalies – l’idéal serait l’ensemble des templates du cycle en V

  7. Renaud M.G. dit :

    @bob, merci pour ta suggestion. C’est vrai que ça pourrait faire l’objet d’un ou 2 nouveaux articles

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *