Café Arona : une vitrine Shopify familiale

Une famille de Sherbrooke m’a confié le site de Café Arona, une entreprise qui souhaite faire découvrir le café camerounais au Québec. L’histoire, les personnes et l’identité visuelle étaient déjà là. Le mandat : leur donner une place claire sur le Web et une structure de contenu que l’équipe pourra gérer.

Le site présente l’histoire de l’entreprise, ses valeurs, son équipe et les articles fournis par le client. Son thème comprend aussi les composants de catalogue : collections, fiches de produits, sélection d’options, recherche et panier. Les textes et les images s’inscrivent dans des sections prévues pour être modifiables depuis Shopify.

Mon travail porte sur la migration du site Webflow existant vers Shopify, l’organisation des contenus et le développement du thème. Au stade actuel, Café Arona est une vitrine d’information en développement, sans ouverture des ventes ni remise au client sur Shopify. Voici ce qui est construit, comment les différentes parties fonctionnent et les principes qui encadrent leur gestion.

Donner une place aux personnes derrière le café#

Pour comprendre Café Arona, il faut rencontrer l’équipe et voir ce qu’elle souhaite transmettre entre le Cameroun et le Québec. Les pages sur l’histoire, les valeurs et les membres de l’équipe occupent donc une place importante dans le site.

J’ai organisé ces contenus dans des formats qui ont chacun leur rôle. Une page raconte l’origine du projet. Une autre présente ses valeurs. La page d’équipe réunit une photo de groupe, des portraits et des textes de présentation. Le blogue offre un espace pour les articles fournis par le client, en complément des pages plus permanentes.

Une personne peut ainsi comprendre qui porte l’entreprise avant de s’intéresser aux produits. Elle peut lire un article ou trouver comment joindre l’équipe. Ce parcours a une utilité propre : la vitrine présente une entreprise et son univers, même avant l’ouverture des ventes.

Une identité existante, des contenus modifiables#

Les couleurs, les photographies et la typographie existantes servent de point de départ. La migration consiste à faire vivre cette identité dans un thème Shopify, avec des pages que le client pourra mettre à jour depuis son administration.

La distinction entre présentation et gestion guide le travail. Un titre doit avoir sa place dans la mise en page et un endroit compréhensible où le modifier. Une photo doit bien se cadrer sur un petit écran et pouvoir être remplacée sans reconstruire la page. Une fiche doit présenter les renseignements du café et les lire dans des champs qui pourront être tenus à jour.

Shopify réunit ces besoins de contenu avec les fonctions qui serviront à la future boutique. Le thème comprend déjà des collections, des fiches, une recherche et un panier. Leur existence décrit le travail construit; elle ne signifie pas que le catalogue définitif est chargé ou que les ventes sont ouvertes.

Les sections dépliables qui suivent permettent de choisir son niveau de détail. Chacune explique une partie du site : son rôle, son fonctionnement et les points à contrôler lorsqu’on la modifie.

Ce qui est en place et la suite prévue#

Café Arona dispose d’une vitrine de développement, de pages de présentation et d’un thème qui relie contenus modifiables, fiches, variantes et structure bilingue. Les choix techniques servent des tâches concrètes : savoir où changer une information, comment elle se répercute et ce qu’il faut vérifier après une modification.

La prochaine étape prévoit l’intégration du catalogue définitif, la validation des parcours destinés à la vente et la remise au client avec sa documentation et sa formation. Ces ajouts s’appuieront sur la structure déjà construite.

Le site repose sur un thème Liquid de Shopify, à partir de la base Skeleton. Liquid assemble les contenus gérés par Shopify avec les éléments du thème. Le navigateur reçoit ensuite une page HTML, sa présentation CSS et les comportements JavaScript nécessaires. Cette organisation convient au besoin du projet : une vitrine dont la gestion et le futur catalogue se trouvent dans la même administration.

Le thème comporte plusieurs niveaux. Une enveloppe commune place l’en-tête, le contenu principal et le pied de page. Les modèles JSON indiquent quelles sections composent une famille de pages. Les sections portent les éléments visibles, comme le bandeau d’accueil ou la présentation de l’équipe. Des petits composants réutilisés prennent en charge des détails communs, par exemple un bouton ou un prix.

Chaque niveau a une responsabilité. Changer le style d’un bouton partagé peut modifier plusieurs pages. Changer le texte d’un bouton dans une section vise le contenu de cette section. Confondre les deux conduirait soit à multiplier les exceptions dans le code, soit à demander du développement pour une simple correction de texte.

Ce que l’éditeur rend modifiable#

Les sections déclarent leurs réglages : textes, images, liens et options prévues par le thème. L’exemple suivant est une illustration minimale écrite pour cet article, distincte du code du projet. Il représente un titre et une destination que l’on souhaite rendre modifiables :

{
  "name": "Introduction",
  "settings": [
    { "type": "text", "id": "intro_title", "label": "Titre" },
    { "type": "url", "id": "intro_destination", "label": "Lien" }
  ]
}

Dans cet exemple, intro_title et intro_destination sont des identifiants stables. Le client travaille avec les libellés visibles dans l’éditeur. Il peut modifier le contenu sans avoir à retrouver une ligne de HTML.

Le cadre visuel demeure défini par le thème. Ajouter une nouvelle interaction ou une nouvelle famille de pages demande encore du développement. L’autonomie visée concerne des tâches reconnaissables : corriger une phrase, remplacer une image, mettre à jour une présentation ou changer la destination d’un lien.

Le cas d’un modèle partagé#

Si deux pages utilisent le même modèle, modifier la composition de ce modèle peut toucher les deux. Avant une modification, il faut donc distinguer le contenu propre à la page de la structure commune. La documentation de remise devra indiquer cette portée.

Une courte carte d’édition suffit souvent à rendre cette distinction concrète : les biographies dans la section d’équipe, les articles dans le blogue, les renseignements sur un café dans le catalogue et les champs personnalisés. Le bon endroit dépend du type d’information, pas seulement de l’endroit où elle apparaît à l’écran.

Un catalogue ne se résume pas à une série de cartes avec un nom et un prix. Il faut définir ce que représente chaque objet. Un produit rassemble une présentation commune. Une variante désigne une combinaison précise d’options que l’on pourra sélectionner. Une collection regroupe des produits pour la navigation. Un champ personnalisé décrit une caractéristique supplémentaire.

Dans Café Arona, la structure de collections prévoit le café vert, le café torréfié et la marchandise. Cette organisation donne une place aux catégories du projet; elle ne constitue pas une annonce de produits tous disponibles. Le contenu final et son état de publication doivent suivre les décisions confirmées du client.

Description, option ou donnée de stock?#

L’origine d’un café et ses notes de dégustation décrivent le produit. Un format ou une préparation peut distinguer une variante. La quantité disponible correspond à des unités précises. Si ces informations sont mélangées dans un seul paragraphe, la page peut sembler complète alors que les données nécessaires à la gestion ne le sont pas.

Le thème possède une fiche qui affiche des champs personnalisés, avec un traitement différent pour les valeurs simples et les listes. Les notes de dégustation peuvent ainsi être présentées comme plusieurs éléments. Voici une illustration Liquid indépendante du code du projet :

{% for tasting_note in coffee_notes %}
  <span>{{ tasting_note | escape }}</span>
{% endfor %}

coffee_notes représente ici une liste, et tasting_note une note à la fois. Le filtre escape fait afficher chaque valeur comme du texte plutôt que comme du balisage HTML. L’exemple montre comment une même présentation peut recevoir des renseignements différents. Il ne détermine pas les arômes du café : les valeurs doivent venir des produits confirmés et des textes approuvés.

Tous les champs ne sont pas destinés au public. Les renseignements affichables doivent être distingués des notes de travail internes. La reprise du catalogue doit donc inclure une vérification de ce qui ressort réellement dans la fiche, et pas seulement du formulaire qui sert à saisir les données.

Un exemple de combinaisons#

Prenons un exemple fictif, sans rapport avec les formats définitifs de Café Arona : deux formats, A et B, et deux préparations, en grains ou moulue. Cela donne 2 × 2 = 4 combinaisons possibles. Si seulement trois ont été approuvées, la quatrième ne doit pas apparaître comme une variante simplement épuisée. Elle n’est pas encore une offre confirmée.

Cette différence compte aussi pour les photos et les prix. Chaque sélection doit conserver le bon identifiant de variante, afficher le renseignement qui lui correspond et ne pas reprendre silencieusement celui d’une autre option. La quantité du panier concerne la variante choisie, pas le nom général du café.

Cette structure sépare les composants déjà construits des données qu’ils affichent. Un catalogue confirmé peut y être ajouté sans recréer la présentation de chaque fiche. Le cadre d’édition reste commun, tandis que les valeurs et les variantes appartiennent à chaque produit.

Une collection vide n’est pas une recherche sans résultat#

Une collection organise l’accès aux produits. Son modèle affiche une grille, les contrôles de filtrage et une pagination lorsque nécessaire. Il prévoit aussi deux situations qui se ressemblent visuellement, mais qui demandent des explications différentes : aucun produit dans la collection, ou aucun résultat pour les filtres choisis.

Dans le premier cas, le visiteur a besoin de savoir ce que contient cette rubrique et où poursuivre sa visite. Dans le second, il doit pouvoir comprendre que sa sélection limite les résultats et la modifier. Afficher le même message dans les deux cas laisserait croire qu’un filtre a fait disparaître le catalogue, ou qu’une rubrique vide peut être réparée en changeant des options.

Cette séparation se retrouve dans le thème sous forme de messages d’état partagés. Le cadre visuel reste commun, tandis que le titre, l’explication et l’action correspondent à la situation. C’est un exemple de réutilisation utile : le composant assure la présentation; les données de la collection déterminent le sens du message.

La revue d’une collection doit donc inclure son état normal, sa pagination et ses états sans contenu. Elle doit également vérifier les liens vers les fiches. Le visiteur suit un parcours entre plusieurs vues du même catalogue; la cohérence ne se limite pas à une carte de produit isolée.

Un produit visible n’est pas nécessairement achetable. Une fiche peut servir à présenter une offre à venir. Une variante peut exister sans être disponible. Une quantité peut être insuffisante pour la demande. Ces situations doivent produire des messages et des actions différents.

Le thème prépare un premier état côté Shopify lorsque la page est générée. Ensuite, le JavaScript du navigateur réagit au choix des options : il cherche la variante correspondante et met à jour les renseignements visibles. Le point important est la cohérence entre ces deux moments. Une règle appliquée au chargement doit continuer à s’appliquer après un changement de sélection.

Rendre la règle explicite#

Pour expliquer cette distinction, voici un modèle illustratif écrit pour l’article. Il représente une règle à vérifier avant l’ouverture des ventes; ce n’est pas le code déployé du projet :

function purchaseState({ salesEnabled, productApproved, variant }) {
  if (!salesEnabled || !productApproved) return "information";
  if (!variant) return "unavailable";
  return variant.available ? "available" : "sold_out";
}

Le modèle examine d’abord si les ventes et le produit sont autorisés, puis si la variante existe, et enfin si elle est disponible. Les identifiants sont fictifs. L’intérêt est l’ordre du raisonnement : un stock disponible ne doit pas annuler une décision de présenter le produit à titre informatif.

Quatre situations donnent des attentes différentes :

• Ventes non ouvertes : la page peut informer, sans proposer l’achat.
• Produit confirmé, combinaison inexistante : expliquer que cette sélection n’est pas proposée.
• Variante existante mais indisponible : annoncer son indisponibilité, sans la confondre avec une erreur du site.
• Variante disponible dans un parcours de vente autorisé : permettre de poursuivre, sous réserve de la validation finale du panier.

Pour vérifier ce comportement, les mêmes règles doivent être examinées à l’affichage initial, au changement d’option et au moment de la demande d’ajout. La présence d’un bouton désactivé sur une capture ne suffit pas à démontrer tout ce parcours. Le scénario intéressant est celui où la sélection change : le message, la variante et l’action autorisée doivent rester cohérents.

La demande et sa réponse#

Le navigateur envoie une demande d’ajout au panier, puis reçoit une réponse de Shopify. Tant que cette réponse n’est pas revenue, l’interface doit distinguer une demande en cours d’un ajout confirmé. Un échec de quantité et un problème de réseau ne demandent pas la même explication.

Il faut aussi distinguer l’ajout lui-même de la mise à jour de l’affichage du panier. Si l’ajout réussit mais que le compteur ne se rafraîchit pas, relancer automatiquement la commande pourrait ajouter le produit deux fois. Le retour visuel doit donc suivre ce que le système a effectivement confirmé.

Ces détails donnent un sens pratique à la validation : essayer un changement de variante, une combinaison absente, une quantité refusée et une réponse lente. Ils ne se vérifient pas en regardant seulement la page dans son état normal.

La disponibilité affichée sur une page correspond aussi à un moment. Pendant que la personne choisit ses options, l’état du stock peut changer. La vérification côté navigateur aide à guider la sélection, mais une demande refusée par le service doit rester un refus, même si le bouton était actif juste avant. Le message doit permettre de reprendre le parcours sans présenter l’ancien affichage comme une confirmation de commande.

Le thème peut afficher un prix, une disponibilité et plusieurs options. Pour que ces éléments aient un sens, les données doivent décrire la même variante et le même état du produit. La question dépasse donc l’apparence de la fiche : que compte-t-on, qui confirme l’information et quelle donnée sert à l’affichage?

Un nombre d’unités physiques, un nombre d’unités réservées et une disponibilité ne sont pas interchangeables. Une description et une photo approuvées ne remplacent pas un comptage. Inversement, une quantité disponible ne confirme ni le texte commercial ni les conditions de livraison.

La fiche de réception du catalogue#

Le modèle de réception du catalogue prévoit une ligne par variante destinée à la vente. Cette ligne doit relier son nom, ses options, son format, son prix approuvé, son image, sa quantité et son état. Elle doit également permettre de savoir qui a validé ces renseignements. Les exemples présentés ici ne reprennent aucune donnée d’exploitation du client.

Une donnée absente reste à confirmer. La remplacer par une valeur plausible ferait perdre la distinction entre une maquette et une offre réelle. Cette règle s’applique aussi aux traductions et aux descriptions de goût.

Un calcul fictif pour comprendre le contrôle#

Imaginons, uniquement pour illustrer la méthode, 40 unités finies comptées physiquement, dont 6 réservées et 2 non commercialisables. Si ces catégories sont distinctes et que les 40 unités les incluent, le nombre restant serait 40 − 6 − 2 = 32. Ce calcul ne décrit aucun stock de Café Arona.

L’intérêt de l’exemple est de préciser les définitions. Si un système donne déjà la quantité disponible après réservation, retirer encore les six unités produirait une erreur. Avant de rapprocher un tableau et Shopify, il faut vérifier ce que chaque colonne compte, à quelle variante elle correspond et à quel moment le relevé a été fait.

Intégrer en étapes contrôlées#

Le catalogue pourra être intégré d’abord sur un petit ensemble représentatif : une fiche avec ses options, ses champs, ses images et ses traductions. La prévisualisation permettra de vérifier ce que produit réellement cette structure. Une fois ce modèle de saisie confirmé, les autres fiches pourront suivre le même cadre.

Cette méthode porte sur la qualité des données reçues. L’architecture de présentation est déjà construite; la vérification suit les relations entre produits, collections, variantes et quantités. Elle permet de contrôler le résultat d’une saisie sans confondre son apparence avec sa validité.

Le français est la langue principale du projet. Le thème comprend aussi les fichiers de langue et le mécanisme de changement de langue pour l’anglais. Cette base prépare le bilinguisme, mais plusieurs familles de contenu doivent rester cohérentes.

Les textes d’interface sont les libellés de navigation, les boutons et les messages de résultat ou d’erreur. Les contenus éditoriaux sont les présentations, les biographies et les articles. Les renseignements produits comprennent les descriptions, les noms d’options et les valeurs des champs personnalisés. Une correction dans une famille ne met pas automatiquement les autres à jour.

Le sélecteur du thème s’appuie sur le formulaire de localisation de Shopify. Son rôle est de demander un changement parmi les langues disponibles. Les adresses de pages et les actions du site doivent ensuite continuer dans le bon contexte de langue. Un bouton traduit qui ramène vers le mauvais parcours laisserait le travail incomplet.

Un changement de contenu comme point de départ#

Si le client modifie une description française, la vérification anglaise doit porter sur la même information, pas uniquement sur la fluidité de la phrase. Une note de dégustation retirée, un format changé ou une condition de disponibilité révisée doit avoir un équivalent exact.

Il faut aussi distinguer le libellé d’un champ de sa valeur. Traduire « origine » ne traduit pas nécessairement le contenu qui suit. Le thème lit des données que Shopify peut localiser; l’édition doit donc vérifier à la fois le nom présenté au lecteur et la donnée affichée.

Vérifier un parcours complet#

La revue prévue suit une page dans les deux langues, puis ses liens, ses messages et ses états moins courants. Elle inclut les contenus longs qui changent le cadrage, ainsi que les erreurs qui ne sont pas visibles au premier chargement.

Cette approche permet de définir une livraison bilingue par des contenus et des parcours vérifiés. L’existence de fichiers anglais dans le dépôt ne suffit pas à déclarer toutes les mises à jour du client traduites. La gestion bilingue relie ainsi le contenu modifié, sa traduction et le parcours où il apparaît.

L’identité de Café Arona utilise des contrastes de couleurs, une typographie marquée, des photographies et un bandeau vidéo. La tâche consiste à conserver cette présence tout en laissant de la place au contenu et aux interactions.

Une page d’équipe illustre bien ce travail. La photo de groupe situe les personnes ensemble. Les portraits permettent de choisir une présentation individuelle. À petite largeur, la composition doit rester lisible sans demander au visiteur de parcourir une grille conçue seulement pour un grand écran.

Le thème possède un comportement partagé pour les interfaces à onglets de l’équipe et des valeurs. Il relie l’élément sélectionné au panneau de contenu correspondant et gère des commandes de clavier. La réutilisation porte ici sur un comportement commun; les deux sections conservent leur contenu et leur présentation.

Le focus fait partie du parcours#

Voir un portrait sélectionné et savoir où se trouve le clavier sont deux informations différentes. Les flèches, le début et la fin de liste, ainsi que la visibilité du panneau doivent former un ensemble cohérent. Les tests de logique du projet couvrent notamment les déplacements d’index et l’interprétation des touches. Ils ne remplacent pas l’utilisation réelle de la page au clavier.

La même distinction vaut pour un message d’erreur : il doit apparaître au bon endroit et être perceptible par une personne qui ne suit pas uniquement les changements visuels. Le thème prévoit des zones d’annonce, mais leur présence doit être vérifiée avec le comportement complet.

Images, vidéo et poids de la page#

Les images principales et les petites vignettes n’ont pas le même rôle. Le thème demande des tailles adaptées et réserve certaines dimensions à l’affichage. La vidéo du bandeau possède une image d’attente; le comportement tient aussi compte d’une préférence de réduction des mouvements. Ces mécanismes font partie du code construit, sans démontrer à eux seuls une performance mesurée.

Une photo nette sur un grand écran peut être trop lourde pour l’usage prévu. Un recadrage réussi sur bureau peut couper un visage sur mobile. La vérification doit regarder le contenu réellement visible, les dimensions téléchargées et le comportement du navigateur.

Les deux vues de l’accueil retenues pour cette présentation proviennent du navigateur sur la vitrine de développement. La vue mobile représente une largeur de navigateur, pas un essai sur un téléphone physique. Elles documentent l’interface à ce stade. Elles ne constituent pas une validation de tous les écrans ou de toutes les pages.

Pour que le client puisse entretenir le site, il doit savoir quel changement il fait et ce qu’il faut regarder ensuite. Remplacer une photo, modifier une structure partagée et ajouter une variante n’ont pas la même portée.

La procédure de reprise proposée commence par nommer le contenu visé, la personne qui l’approuve et le résultat attendu. Pour un changement de mise en page, une copie du thème permet de préparer une prévisualisation avant publication. Pour un produit ou un article, il faut aussi gérer le contenu lui-même : une copie du thème ne duplique pas automatiquement toutes les données de la boutique.

Exemple : remplacer une photo d’équipe#

Le travail ne s’arrête pas à choisir le fichier. Il faut confirmer la bonne image, son droit d’utilisation, son texte alternatif et le cadrage du sujet. Ensuite, on prévisualise la page complète : photo de groupe, portraits, textes voisins et disposition étroite. Si la légende change, sa version anglaise entre dans la même revue.

Ce parcours fait apparaître la valeur de champs bien définis. La personne qui édite doit pouvoir modifier le bon contenu sans toucher au comportement des onglets. La personne qui développe intervient si le besoin change la structure ou l’interaction.

Exemple : préparer une fiche de produit#

Une fiche représentative permet de parcourir le cycle : données confirmées, saisie, affichage des champs, sélection d’options, langue et état de disponibilité. Une option absente doit donner le résultat prévu. Une image manquante ne doit pas passer inaperçue sous prétexte que le reste de la page fonctionne.

Les tests automatisés du projet portent notamment sur certaines fonctions du panier et de la navigation par onglets. Ils aident à vérifier des règles précises, comme le traitement d’un index ou d’une erreur. Ils ne prouvent pas que les photos, les données, les traductions et tous les parcours sont corrects ensemble.

Un retour arrière qui correspond au changement#

Pour une modification de thème, conserver la version précédente fournit un point de retour. Pour une erreur de description ou de stock, revenir à l’ancien thème ne rétablit pas automatiquement la donnée. La procédure doit donc conserver ce qui a réellement été modifié.

La remise devra inclure un exercice de ce type, avec le client : effectuer un changement simple, le prévisualiser, le faire vérifier et retrouver la marche à suivre si le résultat n’est pas celui attendu. L’exercice permet de vérifier une capacité de gestion concrète, au-delà de la présence d’un bouton d’édition.

Le résultat attendu de la remise est un site que le client peut gérer dans le cadre prévu. Les accès seuls ne suffisent pas. Il faut aussi des contenus confirmés, une carte des responsabilités et des gestes de maintenance compréhensibles.

Le client doit garder la décision sur ses produits, ses prix, ses quantités et ses textes. Une personne peut s’occuper des mises à jour courantes, et une autre les approuver. Les changements de code, les nouveaux comportements et les interventions sur la structure demandent une responsabilité technique distincte. Une entente de soutien doit préciser le périmètre des interventions et la responsabilité de chacun.

Propriété et continuité#

L’inventaire de remise doit couvrir la boutique, le domaine, les accès nécessaires, les contenus, les médias, les traductions, les applications et la documentation. Il faut savoir qui possède les comptes, qui peut récupérer un accès et qui approuve une modification importante. Aucun identifiant ou détail privé n’a besoin d’être montré dans une étude de cas pour expliquer cette exigence.

La procédure Shopify dépend du type exact de boutique et de sa situation au moment de la remise. Le nom d’un environnement de développement ne suffit pas à déterminer ce qui peut être transféré. Cette vérification appartient à la préparation du transfert ou, si nécessaire, d’une migration autorisée. Le contrôle porte sur la propriété réelle et les droits des comptes, pas sur leur nom.

Une maintenance proportionnée#

L’entretien courant pourra regrouper les contenus devenus inexacts, les images à remplacer, les liens à vérifier et les traductions à reprendre. Une revue technique sera nécessaire après des changements qui touchent le thème ou les applications. La fréquence doit correspondre à l’activité réelle et à l’entente de soutien.

Pour chaque intervention, une trace courte est utile : ce qui a changé, pourquoi, qui l’a approuvé et ce qui a été vérifié. Cette trace aide une autre personne à reprendre le site et évite que la connaissance reste seulement dans la mémoire du développeur.