Douze points à vérifier avant qu’un bloc ne parte en production

12 points, un seul incident source par point : cette liste s’est constituée au fil des livraisons, chaque ligne correspondant à un problème déjà rencontré une fois en production, jamais deux depuis qu’il figure ici. Elle ne traite pas du devis initial du projet, mais uniquement de la dernière ligne droite avant mise en production chez un client autonome.

L’ordre suivi ici part du contenu, passe par le comportement technique, et termine par la documentation laissée au client, dans cet ordre précis, parce que c’est l’ordre dans lequel les problèmes se révèlent le plus souvent en usage réel.

Contenu : du vide à l’extrême

1. Le bloc inséré sans aucune modification affiche un état par défaut cohérent, jamais un espace vide inexpliqué.
2. Un champ texte rempli avec un contenu anormalement long ne casse pas la mise en page environnante.
3. Une image au format inattendu, très large ou très étroite, reste correctement cadrée par le bloc.
4. La suppression d’un champ optionnel, une fois le bloc déjà publié, ne produit pas d’erreur de rendu.

Comportement technique et compatibilité

1. Le bloc dupliqué plusieurs fois sur la même page ne partage pas d’état par erreur entre les instances.
2. Le bloc inséré à l’intérieur d’un autre bloc conteneur, comme le bloc Groupe, conserve son comportement attendu.
3. La console du navigateur ne signale aucune erreur JavaScript à l’ouverture de l’éditeur sur une page contenant le bloc.
4. Le rendu front a été vérifié séparément de l’aperçu de l’éditeur, pas seulement supposé identique.

Accessibilité et performance

1. La navigation au clavier permet d’atteindre et d’activer chaque élément interactif du bloc, sans piège de focus.
2. Aucune image du bloc ne se charge sans texte alternatif renseigné ou configurable par l’utilisateur.
3. Le poids des scripts et styles ajoutés par le bloc reste proportionné à ce qu’il affiche réellement, sans dépendance superflue chargée sur chaque page.

Le dernier point, souvent négligé

1. Une documentation courte, écrite pour le client et non pour un développeur, explique ce que chaque réglage du bloc modifie concrètement à l’écran.

Ce douzième point mérite un développement à part, car il conditionne directement le nombre de sollicitations que l’agence recevra dans les semaines suivant la livraison.

Pourquoi la documentation client change tout

Un bloc parfaitement fonctionnel mais dont aucun réglage n’est expliqué au client finit presque toujours par générer des demandes de support évitables : un client qui ne comprend pas à quoi sert un champ le laisse vide, ou pire, tente de contourner le bloc avec une solution improvisée qui casse la mise en page. Une documentation courte, avec une ou deux captures d’écran annotées et un exemple concret de remplissage, réduit ce risque de façon mesurable.

## Bloc « Mise en avant produit »

- Titre : le nom du produit tel qu'il apparaîtra en gros.
- Image : privilégier un format carré, au moins 800x800 pixels.
- Lien « En savoir plus » : laisser vide pour masquer le bouton.

Un principe qui s’est vérifié projet après projet : le temps passé à rédiger cette documentation courte coûte toujours moins cher que le temps passé, plus tard, à répondre à la même question par courriel à plusieurs clients différents.

Comment appliquer cette liste sans en faire une corvée

Sur un projet au calendrier serré, appliquer les douze points en une seule fois avant la livraison finale reste plus efficace que de les vérifier au fil de l’eau pendant le développement, où plusieurs finiraient de toute façon par être recontrôlés après un changement ultérieur du bloc.

• Conserver cette liste dans un outil partagé par l’équipe, pas seulement dans la mémoire d’une seule personne.
• Adapter les points 9 à 11 selon la nature du bloc : un bloc purement statique n’a pas les mêmes enjeux qu’un bloc interactif.
• Faire relire la documentation client par une personne qui n’a pas développé le bloc, pour vérifier sa clarté réelle.

En résumé

Ces douze points ne remplacent pas des tests automatisés plus poussés, mais ils couvrent la plupart des incidents qui surviennent réellement une fois un bloc livré à un client autonome : contenu extrême, comportement combiné à d’autres blocs, accessibilité de base, et documentation adaptée à quelqu’un qui ne lira jamais le code. Appliquée systématiquement avant chaque livraison, cette liste réduit concrètement le nombre de retours après mise en production.