La recette d’un site avant la mise en prod : l’étape à ne pas négliger

Vous venez de ter­mi­ner le déve­lop­pe­ment d’un site (ou une refonte com­plète), et l’en­vie de bas­cu­ler immé­dia­te­ment en pro­duc­tion est grande. Tout le monde a hâte de pas­ser à autre chose. Mais avez-vous vrai­ment véri­fié que tout fonc­tionne, du pre­mier clic jus­qu’au dernier ?

C’est exac­te­ment à ça que sert la recette d’un site. Une étape par­fois per­çue comme une for­ma­li­té un peu fas­ti­dieuse, alors qu’elle est en réa­li­té la der­nière ligne de défense avant que vos uti­li­sa­teurs et uti­li­sa­trices ne découvrent les bugs à votre place !

Qu’est-ce que la recette d’un site ?

La recette, c’est la phase de véri­fi­ca­tion qui inter­vient juste avant la mise en prod. Concrè­te­ment, il s’a­git de tes­ter de manière métho­dique chaque fonc­tion­na­li­té du site, sur un envi­ron­ne­ment de pré­pro­duc­tion (sou­vent appe­lé envi­ron­ne­ment de sta­ging ou de recette), pour s’as­su­rer que tout cor­res­pond à ce qui était pré­vu au départ.

On parle par­fois de recette fonc­tion­nelle, quand il s’a­git de véri­fier que les fonc­tion­na­li­tés marchent comme atten­du, et de recette tech­nique, quand on s’in­té­resse plu­tôt à la per­for­mance, la sécu­ri­té ou la com­pa­ti­bi­li­té. Dans les faits, les deux se mélangent sou­vent dans un même cahier de recette.

L’i­dée n’est pas de refaire un audit com­plet du site à chaque vir­gule près. C’est plu­tôt de dérou­ler une liste de véri­fi­ca­tions pré­cises, éta­blies en amont, pour cou­vrir l’en­semble des cas d’u­sage importants.

D’ailleurs, ce nom sur­prend sou­vent les per­sonnes qui découvrent le voca­bu­laire du déve­lop­pe­ment web. Il vient en réa­li­té du monde du bâti­ment, où l’on parle de « recette des tra­vaux » : l’ar­chi­tecte et le client passent le chan­tier au peigne fin avant d’ac­cep­ter que les tra­vaux sont ter­mi­nés et conformes à la com­mande. Le déve­lop­pe­ment web a sim­ple­ment repris ce terme et cette logique : on véri­fie, point par point, que ce qui a été livré cor­res­pond à ce qui avait été deman­dé, avant de l’ac­cep­ter officiellement.

Cette étape est indispensable. Pourquoi ?

On pour­rait se dire qu’un site tes­té au fur et à mesure du déve­lop­pe­ment n’a pas besoin d’une véri­fi­ca­tion sup­plé­men­taire à la fin. Pour­tant les rai­sons de ne pas sau­ter cette étape sont nombreuses.

D’a­bord, un déve­lop­peur ou une déve­lop­peuse teste rare­ment son propre tra­vail avec un œil neuf. On connaît le par­cours qu’on a codé, on clique ins­tinc­ti­ve­ment au bon endroit, on évite sans le vou­loir les cas limites. On a le nez dans le gui­don. Alors qu’un regard exté­rieur (celui d’une per­sonne qui n’a pas les mains dans le code) repère des pro­blèmes qu’on ne voit plus.

Enfin, et c’est peut-être le plus impor­tant, un bug décou­vert en pro­duc­tion coûte plus cher qu’un bug décou­vert en recette. Il peut abî­mer la confiance de la clien­tèle, faire perdre des ventes, ou pire, expo­ser des infor­ma­tions qui n’au­raient jamais dû être visibles. 

Qui participe à la recette ?

La recette n’est pas réser­vée à l’é­quipe tech­nique. C’est même tout l’in­verse : plus les pro­fils qui testent sont variés, plus les chances de détec­ter des pro­blèmes augmentent.

Voi­ci l’é­quipe qui peut recet­ter le site :

- L’é­quipe de déve­lop­pe­ment (ou le ou la free­lance), qui véri­fie que le code fonc­tionne comme pré­vu techniquement.

- Le ou la cliente ou com­man­di­taire, qui connaît le métier et sait repé­rer si le conte­nu ou le par­cours ne cor­res­pond pas à ses besoins.

- Une per­sonne exté­rieure au pro­jet, idéa­le­ment peu fami­lière du site, pour simu­ler le regard d’un un visi­teur lambda.

- Si le pro­jet le per­met, ce serait l’i­déal, on peut faire appel à un panel d’u­ti­li­sa­teurs et uti­li­sa­trices réels, pour un test gran­deur nature.

Il m’est arri­vé que des bugs soient remon­tés non pas par l’é­quipe tech­nique, mais par une per­sonne du ser­vice com­mer­cial qui tes­tait le site avec un usage tota­le­ment dif­fé­rent du nôtre. C’est ça, la richesse d’une recette bien menée : elle croise les points de vue.

Que vérifie-t-on concrètement ?

Voi­ci les grandes familles de tests à réaliser :

• Le fonc­tion­nel : chaque for­mu­laire envoie-t-il bien les don­nées au bon endroit ? Les bou­tons font-ils ce qu’ils sont cen­sés faire ? Le tun­nel d’a­chat va-t-il jus­qu’au bout sans accroc ?
• Le conte­nu : les textes sont-ils à jour, sans faute, sans « pla­ce­hol­der » oublié du type « lorem ipsum » ? Les images s’af­fichent-elles cor­rec­te­ment, avec leur texte alternatif ?
• La com­pa­ti­bi­li­té : le site s’af­fiche-t-il cor­rec­te­ment sur les prin­ci­paux navi­ga­teurs, sur mobile, sur tablette ? Le res­pon­sive tient-il la route sur toutes les tailles d’écran ?
• Les liens : y a‑t-il des liens cassés ?
• La per­for­mance : les pages se chargent-elles dans des délais raisonnables ? 
• Le réfé­ren­ce­ment : les balises titres et méta des­crip­tions sont-elles bien ren­sei­gnées ? Il fau­dra aus­si vér­fier dès la mise en ligne que l’in­dexa­tion du site par les moteurs de recherche n’est pas bloquée ?
• La sécu­ri­té : le cer­ti­fi­cat SSL est-il actif, les for­mu­laires sont-ils pro­té­gés contre les sou­mis­sions auto­ma­ti­sées, les accès admi­nis­tra­teur sont-ils bien restreints ?
• La confor­mi­té : la ban­nière de cookies fonc­tionne-t-elle, les men­tions légales et la poli­tique de confi­den­tia­li­té sont-elles pré­sentes et à jour ?
• Les emails auto­ma­tiques : la confir­ma­tion de com­mande, la réini­tia­li­sa­tion de mot de passe arrivent-elles bien ?
• Les sites e‑commerce : tes­ter le tun­nel de vente d’un site e‑commerce.

Cette liste n’est pas figée. Chaque site a ses spé­ci­fi­ci­tés, et c’est jus­te­ment l’ob­jet du cahier de recette : l’a­dap­ter au pro­jet, plu­tôt que de cocher des cases géné­riques sans réfléchir.

Comment organiser une recette efficace

Pour que cette étape soit vrai­ment utile, quelques bonnes pra­tiques aident à ne pas se disperser.

D’a­bord, tra­vailler sur un envi­ron­ne­ment de pré­pro­duc­tion, une copie du site final mais sépa­rée de la ver­sion publique. On peut tes­ter en toute tran­quilli­té, sans risque pour le site en ligne.

Ensuite, for­ma­li­ser les véri­fi­ca­tions dans un cahier de recette (un simple tableau suf­fit) qui : 

• liste les tests à effectuer, 
• leur sta­tut (vali­dé, en attente, bloquant) 
• per­sonne en charge. 

Cela évite les oublis et per­met de suivre l’a­van­ce­ment d’un coup d’œil.

Fixer un seuil de tolé­rance. Tous les bugs ne se valent pas : un bou­ton mal ali­gné n’a pas le même impact qu’un tun­nel de paie­ment qui ne fonc­tionne pas. Il faut Prio­ri­ser ce qui doit abso­lu­ment être cor­ri­gé avant la mise en ligne, et ce qui peut attendre une pro­chaine itération.

Enfin, il faut pré­voir du temps pour les cor­rec­tions. En effet, caler la recette la veille de la mise en prod, sans marge pour cor­ri­ger ce qui sera trou­vé n’est pas la meilleure idée. Une bonne recette a besoin de temps pour être sui­vie de vraies cor­rec­tions, puis d’une seconde véri­fi­ca­tion si nécessaire.

Cette étape protège tout le monde

La recette n’est pas là pour ralen­tir un pro­jet ou poin­ter du doigt le tra­vail de quel­qu’un. C’est une étape col­lec­tive, qui pro­tège à la fois l’é­quipe tech­nique, le com­man­di­taire et, au final, les uti­li­sa­teurs et uti­li­sa­trices du site.

Un site qui a été cor­rec­te­ment recet­té ins­pire confiance dès les pre­mières minutes de mise en ligne. C’est un peu comme une répé­ti­tion géné­rale avant un spec­tacle : on pré­fère tou­jours décou­vrir les impré­vus avant que le public ne soit là.

Cré­dit image à la Une : John