Omnifood

Une page d'abonnement alimentaire à monter sous WordPress avec le constructeur visuel Divi : un hero en deux colonnes, trois étapes alternées, deux fiches repas, quatre témoignages doublés d'une galerie, deux formules tarifaires et un formulaire d'inscription - neuf blocs en tout. C'est mon premier projet sous WordPress, et le seul dont la formation ait distribué ensuite une correction en HTML et CSS - c'est ce qui le rend intéressant : et la comparer à ce que je venais d'assembler à la souris m'a appris davantage que l'exercice lui-même.

Ouvrir la correction HTML/CSS

Le site qu'ouvre ce bouton n'est pas de moi : c'est la correction en HTML et CSS distribuée par ma formation, reproduite ici parce que cette étude de cas la commente. Ma production sur ce projet est le site WordPress décrit ci-dessous.

Rôle: Montage du site sous WordPress avec le constructeur Divi
Livrable: 1 site WordPress, thème Divi et thème enfant, 9 blocs, 1 formulaire
Outils: WordPress, Divi, Contact Form 7, Local by Flywheel
Contexte: Projet de formation - Objectif 3W, août 2026

Huit des douze photographies de plats utilisées dans la galerie du site Omnifood, disposées en planche de quatre par deux.

Le brief

Une maquette et un fichier de contenu me sont fournis : un service d'abonnement à des repas livrés, une page unique, neuf blocs. Le contenu arrive séparément, section par section, avec les chiffres, les témoignages et les deux grilles tarifaires déjà rédigés. Rien n'est à inventer, tout est à restituer.

La consigne portait sur WordPress et le constructeur Divi : monter la page en assemblant des modules dans l'interface, sans écrire de CSS. C'est ainsi que je l'ai livrée, et c'est la version qui m'a appris le métier de l'outil - les colonnes, les sections, les réglages hérités, le thème enfant pour ce que l'interface ne permet pas.

C'est le plus gros des quatre exercices d'intégration par le nombre de blocs - le site Univers des Massages, monté un mois plus tard, est le seul du portfolio à le dépasser. La difficulté n'est pas dans une technique isolée : elle est dans le fait de tenir neuf blocs cohérents entre eux quand chaque réglage se fait dans un panneau différent, et qu'aucun fichier ne permet de les relire tous d'un coup.

La question que je me suis posée : jusqu'où un constructeur visuel tient-il la cohérence à ma place, et à partir de quand est-ce à moi de la tenir ?

La correction, et ce que j'y ai lu

Une fois l'exercice rendu, la formation distribue une correction : la même page, écrite en HTML et CSS, sans WordPress ni constructeur. Ce code n'est pas le mien, et c'est pourtant lui que le bouton en haut de page ouvre. Je préfère l'écrire noir sur blanc plutôt que de laisser l'ambiguïté faire son travail.

Je l'ai gardé dans ce portfolio pour une raison précise. Lire une correction est un exercice à part entière, et c'était le seul moyen de mesurer l'écart entre ce que je venais d'assembler à la souris et ce que la même page coûte au clavier. Les relevés qui suivent sont les miens ; les décisions qu'ils décrivent sont celles de la correction.

Le contraste entre les deux est brutal, et c'est ce qui le rend instructif.

Mon montage, sous Divi: WordPress 7.1, thème Divi 5.11.1 d'Elegant Themes, un thème enfant pour les surcharges, Contact Form 7 pour le formulaire. 301 fichiers de médias, 22 Mo. Demande un serveur PHP, une base de données, et des mises à jour à suivre indéfiniment.
La correction, en HTML et CSS: 541 lignes de HTML, 771 de CSS en 2 fichiers, une seule dépendance externe. Aucun langage serveur, aucune base : le dossier se dépose tel quel sur n'importe quel hébergement, et ne demande plus rien ensuite.

Ce que je ne dis pas

Que Divi soit le mauvais outil. Il ne l'est pas : il répond à une autre question. Sur un site qu'un client doit pouvoir modifier seul - changer un tarif, publier un article, remplacer une photo un dimanche soir - un constructeur visuel est la bonne réponse, et du HTML écrit à la main serait une faute professionnelle : il faudrait me rappeler à chaque virgule.

Ce que cette comparaison m'a appris, c'est à poser la question dans ce sens-là. Qui va modifier cette page après moi ? Si c'est le client, un constructeur. Si c'est personne, ou moi seul, du code. Les deux réponses sont justes, et ce n'est pas la même page qui les appelle.

Sur trois des autres projets de ce portfolio - Japan., Shop et Symbolicons - la réponse était « moi seul », et le code est de ma main. Ici elle était « le client » : c'est pour ça que j'ai monté ce site sous Divi, et pour ça que le code consultable est celui d'un autre. Sur Univers des Massages, un mois plus tard, la réponse était la même, et c'est là que j'ai vraiment mesuré ce que l'outil demande sur un site complet.

Cible et contexte d'usage

La page s'adresse à quelqu'un qui n'a pas le temps de cuisiner et qui doit être convaincu d'ouvrir un abonnement. C'est l'inverse exact de Japan., où l'on vient regarder : ici, on vient décider. Toute la page est construite pour amener à un seul geste, l'inscription en bas.

Cette lecture se vérifie dans la structure fournie. L'appel à l'action est répété trois fois - dans la navigation, dans le hero, et en bas dans le formulaire. Entre les deux, tout est de la preuve : le nombre de repas livrés, cinq logos de presse, quatre témoignages, une galerie de douze photos, deux grilles de prix affichées sans détour.

La conséquence pour l'intégration est directe. Sur une page de consultation, on soigne le poids des images ; sur une page de conversion, on soigne le chemin vers le formulaire - sa lisibilité, son accessibilité au clavier, et le fait qu'il reste atteignable en petit écran sans traverser toute la page.

Je n'ai mené ni entretiens ni tests sur ce projet : la maquette et le contenu étaient le point de départ imposé. Ce que je décris ici est une lecture argumentée de l'intention, pas une recherche utilisateur.

Lecture de la maquette

Avant de poser le premier module, j'ai relevé ce que la maquette fixe et ce qu'elle laisse ouvert. Sur un projet à neuf blocs, ce relevé décide de tout : c'est lui qui dit ce qui peut devenir un gabarit réutilisé et ce qui devra être réglé bloc par bloc.

Ce que la maquette fixe

Une seule famille typographique, Rubik, en quatre graisses. Une grotesque géométrique à contreformes ouvertes, qui tient les très grands titres du hero sans se refermer.
Un orange unique pour toutes les actions, posé sur un crème très clair qui revient dans une section sur deux. C'est ce crème, et non le blanc, qui donne son unité à la page : il apparaît onze fois dans le CSS.
Un rythme d'alternance : les trois étapes se lisent texte à gauche puis capture à droite, puis l'inverse, puis à nouveau. La maquette impose l'alternance, pas la façon de l'obtenir.
Des sections de largeurs différentes. La galerie de témoignages déborde en pleine largeur pendant que le reste de la page reste dans un conteneur de 120 rem.

Ce qu'elle ne dit pas

Rien sur le comportement en petit écran. Divi applique ses propres paliers sans qu'on les choisisse ; la correction, elle, n'en retient qu'un seul. Deux réponses opposées au même silence de la maquette, et aucune des deux n'est bonne.
Rien sur les états de focus. Aucun contour de sélection au clavier n'est dessiné, ni sur les boutons, ni sur les champs du formulaire.
Rien sur les contrastes. La maquette donne des couleurs, pas des ratios. Ni mon montage ni la correction ne les ont vérifiés à l'époque ; je les ai mesurés depuis, et les écarts sont au bilan.

Structure et découpage

La page se découpe en neuf blocs autonomes : un header, sept section, un footer. Chaque section porte son identifiant d'ancre, ce qui fait fonctionner la navigation sans script, par simple lien interne. Sous Divi, ce découpage correspond aux sections de l'éditeur ; dans la correction, ce sont les balises elles-mêmes.

Le choix structurant de la correction est ailleurs. Plutôt qu'une règle de mise en page par section, elle sort trois classes réutilisables dans un fichier general.css chargé avant le reste : .container pour la largeur maximale, .grid pour les gouttières, .grid-cols-2, -3 et -4 pour le nombre de colonnes. Neuf blocs se composent avec ces trois classes.

Le second fichier, style.css, ne contient alors que ce qui est propre à chaque section. Deux fichiers pour 771 lignes, contre quatre pour les 451 lignes de Japan. : la répartition suit ici la nature du code - générique d'un côté, spécifique de l'autre - et non l'ordre de chargement. C'est le point que j'ai retenu pour mes propres projets, celui-ci compris.

Schéma du découpage de la page Omnifood en neuf blocs, avec pour chacun le nom de la balise HTML et la technique de mise en page retenue. — Le découpage relevé dans la correction. Sept blocs sur neuf sont des grilles, ce qui est l'inverse de Japan. où Grid ne servait que deux fois. La raison tient à la maquette : presque chaque section y est un tableau à colonnes, et le nombre de colonnes est la seule chose qui change de l'une à l'autre. C'est exactement le cas où une couche d'utilitaires se justifie.

Direction artistique

La direction est celle de la maquette, et elle est la même dans les deux versions. Les valeurs ci-dessous sont relevées dans le CSS de la correction, où elles sont écrites en clair ; sous Divi, les mêmes couleurs vivent dans les réglages du thème. Les cinq qui suivent structurent la page ; les quatorze autres ne servent qu'aux étiquettes de régime et aux notes de score.

Palette

Orange

#E67E22

Boutons et pictogrammes
Ambre

#CF711F

Sur-titres et états de survol
Crème

#FDF2E9

Fond d'une section sur deux
Brun sombre

#45260A

Bouton d'envoi du formulaire
Graphite

#333333

Tous les titres

Typographie

Titres: Rubik 700, de 3 rem pour les titres de niveau 3 à 5,2 rem pour le titre de page. L'interlignage est resserré à 1,05 sur le hero : à cette taille, l'interlignage par défaut ouvrirait des blancs plus larges que les mots.
Texte courant: Rubik 400 et 500, corps de 1,8 rem. Une seule famille sur toute la page, quatre graisses, chargée depuis Google Fonts avec display=swap.

Iconographie

Trente et un pictogrammes, dont seize fois la même coche dans les listes de régimes et de formules. Ils viennent d'ionicons, chargé depuis un CDN tiers - c'est la seule dépendance JavaScript du projet, et la seule de tous ceux présentés ici. Chaque pictogramme est systématiquement accompagné de son libellé écrit : aucun ne porte l'information seul.

Le résultat

Les captures ci-dessous sont celles de la correction, puisque c'est la version consultable depuis cette page. Mon montage Divi suit la même maquette : ce sont les mêmes écrans, obtenus autrement.

Section « How it works » : trois étapes numérotées, chacune sur deux colonnes, avec le texte et la capture d'application qui échangent de côté d'une étape à l'autre. — Les trois étapes. L'alternance ne demande aucune grille supplémentaire : les six blocs se suivent dans le même flux à deux colonnes, et une seule classe `.order` renvoie l'image devant le texte sur l'étape du milieu. Le HTML garde donc l'ordre de lecture logique, quel que soit l'ordre visuel.

Section tarifaire : deux formules côte à côte, celle de droite mise en avant par un fond crème et une étiquette d'angle, suivies de quatre avantages en ligne. — Les deux formules et les quatre avantages. La formule recommandée n'est pas signalée par la seule couleur : elle porte une étiquette écrite, posée en diagonale dans l'angle. La mention des taxes et de la résiliation est placée sous les deux cartes, pas dans l'une d'elles.

Le site en largeur mobile, côte à côte : à gauche le menu fermé et son icône à trois points, à droite le menu ouvert avec ses cinq entrées. — Les deux états du menu en petit écran. Il s'ouvre sans JavaScript, par le même mécanisme que sur Japan. et Symbolicons : une case à cocher masquée, un libellé qui sert de bouton. L'icône à trois points pivote d'un quart de tour pour signaler l'état ouvert - une rotation, et non un changement de dessin.

Quatre décisions relevées dans la correction

Ces quatre décisions ne sont pas les miennes : ce sont celles de la correction. Je les expose parce que les relire m'a appris à quoi ressemble une décision technique argumentée, et parce que savoir lire le code d'un autre fait partie du métier autant que savoir en écrire.

Une couche d'utilitaires plutôt qu'une règle par section

Trois classes - .container, .grid, .grid-cols-N - couvrent la mise en page de neuf blocs. Sur une page dont presque tous les blocs sont des tableaux à colonnes, écrire neuf grilles séparées aurait produit neuf fois les mêmes déclarations de gouttières. La contrepartie est réelle : la structure se lit alors dans le HTML, et changer une grille demande d'ouvrir le HTML plutôt que le CSS. C'est exactement le compromis que fait Divi, à ceci près qu'il le fait dans une interface au lieu d'un attribut class.

L'alternance obtenue par `order`, pas par le HTML

Les trois étapes alternent texte et image. Inverser l'ordre des balises dans le HTML de l'étape du milieu aurait donné le même aspect, mais un lecteur d'écran aurait annoncé l'image avant le titre qu'elle illustre. Une seule règle order: -1 déplace le bloc à l'écran en laissant l'ordre du document intact. C'est la décision que j'ai trouvée la plus instructive : sous Divi, inverser deux colonnes se fait par glisser-déposer, et rien ne signale qu'on vient de changer l'ordre de lecture.

Le fond du formulaire décrit, pas décoratif

La photo qui occupe la moitié droite du formulaire est posée en image de fond CSS, ce qui la rend invisible aux technologies d'assistance. Le conteneur porte donc role="img" et un aria-label qui la décrit. Sans ces deux attributs, la moitié de ce bloc n'existerait pas pour un lecteur d'écran.

Un pas de base à 10 pixels

La règle html { font-size: 62.5% } ramène 1 rem à 10 pixels. Toutes les valeurs du CSS se lisent alors directement : 1.8rem se comprend comme 18 pixels sans calcul. Les tailles restent exprimées en rem, donc elles suivent toujours le réglage de taille de police du navigateur - c'est un confort d'écriture, pas un retour aux pixels fixes.

Bilan

Ce que j'ai appris

Monter un site au constructeur visuel est un métier à part : sections, lignes, colonnes, réglages qui se transmettent d'un niveau à l'autre, thème enfant pour ce que l'interface ne permet pas. Divi ne dispense pas de comprendre la mise en page, il déplace l'endroit où on la décrit.
Relire la correction après coup m'a montré ce que l'interface m'avait caché : l'ordre de lecture réel, les contrastes, les états de focus. Un constructeur produit un résultat correct sans jamais poser ces questions, et c'est exactement là qu'il faut se les poser soi-même.
Séparer l'ordre du document de l'ordre à l'écran est une décision d'accessibilité, pas une astuce de mise en page - et une image de fond CSS sort du document, invisible aux lecteurs d'écran. Deux points que je n'aurais pas vus sans relire du code.
Avoir la même page sous deux formes - la mienne au constructeur, la correction au clavier - vaut mieux que l'une des deux seule. C'est la comparaison qui enseigne, pas l'exercice.
Le choix d'un outil ne se juge pas sur sa qualité mais sur la question « qui modifiera cette page après moi ? ». C'est la seule chose que je regarde maintenant avant de trancher.

Axes d'amélioration

Le contraste du bouton principal est insuffisant : du blanc sur l'orange #E67E22 donne 2,85:1, là où le niveau AA en demande 4,5. C'est le défaut le plus grave de la page, et il touche l'élément le plus important. Il se corrige en assombrissant l'orange ou en passant le libellé en brun sombre.
Les sur-titres en ambre #CF711F sont à 3,48:1 sur blanc. À leur taille - 1,6 rem, du texte courant - le seuil applicable est bien 4,5 et non 3.
Le CSS contient deux fois outline: none, sur les champs du formulaire et sur son bouton, sans indicateur de remplacement. La sélection au clavier devient invisible sur les quatre commandes du seul formulaire de la page.
Un seul point de rupture, écrit en max-width: 640px. Entre 641 et 1200 pixels - toute la tablette - la page reste en mise en page de bureau et déborde. Aujourd'hui je l'écrirais en min-width en partant du mobile, comme sur ce portfolio.
Les dix-neuf couleurs sont écrites en dur, sans une seule variable CSS. C'est l'inverse de ce que j'avais fait sur Japan., et je considère aujourd'hui que c'est une régression.
L'image du hero pèse 2,9 Mo à elle seule, en PNG là où un JPEG suffirait. Le dossier d'images du projet fait 4,5 Mo au total.

Si je reprenais ce projet en conception

Deux choses m'ont gêné en intégrant. La première : la page annonce partout que le premier repas est offert, mais le formulaire d'inscription demande trois informations avant de laisser voir quoi que ce soit. Sur une page dont c'est l'unique objectif, l'adresse e-mail seule suffirait à ouvrir le parcours.

La seconde : les deux formules tarifaires sont affichées côte à côte sans que rien ne dise laquelle correspond à quel usage. Les quatre avantages placés juste en dessous s'appliquent aux deux indistinctement. Je rapprocherais les deux blocs pour que le tableau des avantages devienne un vrai comparatif, colonne par colonne.