Ce module est conçu pour permettre à chaque intervenant de travailler avec le bon niveau d’autonomie dans Wix Studio, sans dégrader l’architecture des sites, le responsive, les collections CMS ou le code Velo.

Les trois niveaux d’intervention

Règle de décision

• Si la modification change seulement une donnée visible : généralement N1.
• Si elle change la manière dont le site est construit ou se comporte : N2.
• Si elle peut casser une connexion, du code, une collection, une permission ou la publication : N3.

Objectif d’autonomie

Le but n’est pas que chacun touche à tout. Le but est que chaque intervenant sache exactement ce qu’il peut faire seul, ce qu’il doit contrôler et quand il doit escalader une décision.

1. Identifier le site, la page et le breakpoint avant de commencer.
2. Ne jamais aligner des éléments avec des espaces, des retours ligne ou des marges improvisées.
3. Utiliser containers, grids et stacks pour conserver un layout responsive.
4. Ne jamais supprimer un élément juste parce qu’il semble inutile : vérifier les calques, connexions CMS et code.
5. Ne jamais renommer l’ID d’un élément lié à Velo.
6. Ne jamais renommer ou supprimer un champ CMS sans validation.
7. Préserver les relations de référence et multi-référence entre collections.
8. Tester les modifications sur desktop, tablette et mobile.
9. Utiliser Preview avant toute publication.
10. Tester tous les liens, boutons, formulaires et pages dynamiques concernés.
11. Publier uniquement après validation lorsqu’une modification est structurelle ou sensible.
12. Après publication, contrôler immédiatement le site en production.

Les zones essentielles

• Panneau gauche : pages, calques, ajout d’éléments, CMS, médias et outils de développement.
• Canvas central : représentation visuelle de la page au breakpoint choisi.
• Inspecteur : dimensions, position, comportement responsive, design et interactions de l’élément sélectionné.
• Barre supérieure : breakpoint, taille d’édition, Preview, sauvegarde / état du site et publication.

Avant de cliquer

Toujours regarder le fil de hiérarchie ou le panneau Calques avant de déplacer un élément. Deux éléments visuellement proches peuvent appartenir à des parents différents et donc réagir différemment sur mobile.

La logique

Une page propre est une hiérarchie. La page contient des sections ; les sections contiennent des outils de layout ; ces outils contiennent les éléments. Plus cette structure est logique, plus le responsive est fiable.

À privilégier

• Sections pour séparer les grands blocs de contenu.
• Containers pour regrouper une carte ou un module cohérent.
• Stacks pour conserver un espacement régulier entre éléments.
• CSS Grid lorsque plusieurs colonnes ou zones doivent rester structurées.

À éviter

• Positionner dix éléments indépendants à la main.
• Créer des containers vides uniquement pour faire de l’espace.
• Dupliquer une section entière pour desktop puis une autre pour mobile.
• Utiliser des marges extrêmes pour “forcer” un placement.

Procédure standard

1. Ouvrir le panneau Calques et identifier le parent de l’élément.
2. Vérifier si l’élément appartient à une stack, une grid ou un container.
3. Noter le breakpoint actif.
4. Faire la modification la plus locale possible.
5. Vérifier que la modification n’a pas changé la hiérarchie.
6. Passer sur tablette puis mobile.
7. Utiliser Preview et faire défiler toute la section.
8. Si une structure parent a été modifiée, classer l’intervention en N2.

Position et taille

Préférer des comportements responsive et des contraintes cohérentes plutôt qu’une position absolue rigide. Les mesures fixes ne sont pas mauvaises en soi, mais elles doivent être utilisées avec une logique claire : largeur maximale, min/max, docking et comportement de redimensionnement.

Espacements

Wix Studio utilise par défaut trois breakpoints : desktop à partir de 1001 px, tablette de 751 à 1000 px et mobile de 320 à 750 px. Il est possible d’en ajouter, jusqu’à six au total par page ou section globale, mais cela doit rester exceptionnel.

La règle de cascade

• Le design créé sur desktop se propage vers les breakpoints plus petits.
• Un override créé sur tablette se propage vers mobile, mais ne remonte pas vers desktop.
• Un override mobile reste local au mobile.

Ce qui est global

Le remplacement d’une image, la modification d’un lien, la suppression d’un élément ou un changement structurel de parent ne sont pas de simples overrides visuels : ils affectent les autres breakpoints.

Ordre de travail

1. Commencer sur le breakpoint desktop principal.
2. Réduire progressivement la largeur du canvas et observer les ruptures.
3. Passer sur tablette et corriger uniquement ce qui nécessite un override.
4. Passer sur mobile : empilement, textes, boutons, images et zones tactiles.
5. Vérifier les largeurs intermédiaires, pas seulement la largeur d’édition par défaut.
6. Lancer Preview et tester comme un visiteur réel.

Contrôles indispensables

Le texte doit rester un composant de design, pas un bloc posé par défaut. Sur les projets Squared, la hiérarchie visuelle doit être nette : titre, sous-titre, body, label et microcopy.

Règles internes

• Conserver la police et les styles globaux définis pour le site. Sur l’écosystème Squared, Space Grotesk est la référence principale lorsqu’elle est configurée dans le projet.
• Éviter les tailles arbitraires : réutiliser les styles et échelles existants.
• Ne pas mettre un paragraphe en gras pour simuler un titre.
• Ne pas utiliser des retours ligne pour contrôler la largeur d’un titre si un réglage de largeur suffit.
• Préserver une longueur de ligne confortable sur desktop et mobile.

Contenu

Lors d’une correction éditoriale, relire le texte dans son contexte. Une phrase plus longue peut casser une carte, une navigation ou une hauteur cohérente. Toute modification de contenu doit donc être suivie d’un contrôle visuel.

Le CMS est la base de contenu du site. Une collection stocke les données ; un dataset connecte ces données à une page ; les éléments affichent ou écrivent les champs connectés.

Vocabulaire

Ce qui relève d’une intervention autonome

• Modifier la valeur d’un champ existant en respectant son format.
• Ajouter un item lorsque le modèle de données est clair et déjà utilisé.
• Remplacer une image ou compléter un alt text.
• Renseigner une référence existante vers le bon item.

Ce qui exige une validation

• Ajouter un nouveau champ à une collection structurante.
• Changer le type d’un champ.
• Modifier les permissions d’une collection.
• Changer des valeurs utilisées comme statut, filtre ou clé logique.

Ce qui est réservé

• Renommer/supprimer un field key ou une collection.
• Modifier des références ou multi-références sans connaître les pages concernées.
• Supprimer massivement des items.
• Modifier des champs utilisés par Velo ou des automatisations.

Procédure opérateur

1. Ouvrir le CMS et identifier la collection exacte.
2. Regarder un item existant correctement rempli avant de créer le nouveau.
3. Remplir tous les champs utiles en respectant le format des données existantes.
4. Vérifier les références et multi-références.
5. Contrôler le slug ou l’URL si la collection alimente une page dynamique.
6. Ajouter le média optimisé et son texte alternatif lorsque le champ le permet.
7. Respecter les champs de statut / visibilité s’ils existent.
8. Ouvrir la page qui consomme la collection et prévisualiser le résultat.
9. Contrôler desktop, tablette et mobile.
10. Ne publier qu’après validation si l’item touche une zone stratégique du site.

Exemples typiques

Cette méthode s’applique notamment aux collections de services, projets, actualités, produits ou contenus éditoriaux lorsqu’elles existent dans le projet concerné.

Un dataset fait le lien entre la collection et les éléments d’une page. Il peut gérer le mode de lecture/écriture, les filtres, les tris, le nombre d’items et le contexte d’une page dynamique.

Pourquoi c’est sensible

• Changer la collection d’un dataset peut remplacer toutes les données affichées.
• Modifier un filtre peut masquer une partie du contenu sans erreur visible.
• Changer un tri peut altérer l’ordre éditorial du site.
• Modifier le mode d’un dataset peut avoir un impact sur les formulaires ou entrées utilisateur.

Diagnostic simple

1. Sélectionner l’élément qui affiche un contenu CMS.
2. Vérifier sa connexion de données.
3. Identifier le dataset et le champ connecté.
4. Si le mauvais contenu apparaît, ne pas reconnecter au hasard : remonter l’information avec page + élément + résultat attendu.

Les pages dynamiques permettent de construire un seul template qui affiche différents items d’une collection. Une page “Service” peut ainsi servir à tous les services sans créer une page manuelle pour chacun.

Deux grands usages

• Page liste : affiche plusieurs items, souvent dans un repeater ou une galerie.
• Page item : affiche le détail d’un seul item selon son URL dynamique.

Points de contrôle

• Le bon champ est connecté au bon élément.
• Les liens des cartes pointent vers la bonne page dynamique.
• Le slug est propre, stable et lisible.
• Le SEO dynamique exploite les bons champs.
• Un item incomplet ne crée pas de bloc vide ou de layout cassé.

Avant import

• Utiliser un fichier propre, correctement cadré et suffisamment défini.
• Éviter les fichiers inutilement lourds et les exports multiples non utilisés.
• Nommer le fichier de manière lisible quand c’est possible.

Dans Wix

• Respecter le ratio prévu par le composant.
• Choisir le bon comportement de recadrage : fit, crop ou fill selon le contexte.
• Vérifier le focal point sur mobile.
• Ajouter un texte alternatif descriptif lorsque l’image porte une information utile.

À ne pas faire

• Étirer une image pour remplir une carte.
• Importer une capture d’écran comme remplacement d’un vrai visuel.
• Changer une image globale en pensant ne modifier qu’un breakpoint.

Liens

Chaque bouton doit avoir une destination explicite : page, ancre, URL externe, email, téléphone, téléchargement ou action. Ne jamais laisser un bouton actif sans destination en production.

Interactions

• Vérifier les états normal, hover et focus lorsque le composant les utilise.
• Ne pas multiplier les animations simplement pour “faire vivant”.
• Respecter les durées et mouvements déjà utilisés sur le site.
• Contrôler que l’animation n’empêche pas le clic ou ne décale pas le layout.

Formulaires

• Tester chaque champ obligatoire.
• Vérifier le message de succès / erreur.
• Tester la destination des données ou notifications.
• Ne jamais modifier permissions, automatisations ou connexions métiers sans validation.

Le SEO d’une page ne doit pas être modifié comme du simple texte décoratif. Une URL, un title ou une meta description peut avoir un impact sur l’indexation et les résultats de recherche.

À contrôler

Pour les pages statiques, Wix peut créer une redirection 301 automatique lorsqu’un slug est modifié. Cela ne justifie pas de modifier les URLs sans raison : les liens, campagnes et usages externes doivent malgré tout être contrôlés.

Accessibilité

• Conserver un contraste suffisant entre texte et fond.
• Ne pas transmettre une information uniquement par la couleur.
• Utiliser une hiérarchie de titres logique.
• Renseigner les textes alternatifs pertinents.
• Garder des zones cliquables utilisables sur mobile.
• Éviter les textes trop petits ou les animations qui rendent la lecture difficile.

Performance

• Ne pas conserver des sections dupliquées uniquement pour gérer des breakpoints.
• Supprimer les containers inutiles uniquement après vérification de leurs dépendances.
• Éviter d’empiler des animations lourdes sans valeur fonctionnelle.
• Optimiser les médias avant d’en ajouter de nouveaux.

Velo ajoute de la logique JavaScript aux sites Wix. Un élément visuel peut donc être utilisé par du code même si rien ne l’indique à première vue.

Risques principaux

• Renommer l’ID d’un élément peut casser une référence $w(...) dans le code.
• Supprimer un élément peut provoquer une erreur ou supprimer une fonctionnalité.
• Renommer un champ CMS peut casser une requête, un filtre ou une écriture de données.
• Modifier un fichier de code peut affecter plusieurs pages ou fonctionnalités.

Règle d’intervention

Lecture autorisée pour comprendre. Modification réservée à une intervention validée. Si une erreur semble venir du code, noter le scénario exact, la page, l’action effectuée, l’heure et le message affiché dans la console.

Wix Studio distingue notamment les membres d’un workspace et les collaborateurs externes. Les accès peuvent être limités par rôle, par site ou par responsabilités. Le principe Squared est le moindre privilège : chacun accède uniquement à ce dont il a besoin.

Bonnes pratiques

• Ne jamais utiliser le compte d’une autre personne.
• Ne pas modifier son propre rôle ou les permissions d’autrui sans instruction.
• Utiliser les commentaires de l’éditeur lorsque cela clarifie une modification à valider.
• Quand plusieurs personnes travaillent simultanément dans Studio Editor, communiquer sur les zones modifiées pour éviter les conflits de décision.

À savoir

Wix Studio permet l’édition collaborative en temps réel ; les changements se synchronisent entre les personnes présentes dans le Studio Editor. La coordination reste nécessaire, surtout pour les sections globales, le CMS et le code.

Phase 1 — cadrer

• Quel site ? Quelle page ? Quelle collection ? Quel résultat attendu ?
• N1, N2 ou N3 ?

Phase 2 — modifier

• Faire la modification la plus locale possible.
• Éviter les changements opportunistes non demandés pendant l’intervention.

Phase 3 — vérifier

• Responsive, contenu, liens, CMS, interactions et console si nécessaire.

Phase 4 — valider

• N1 : autonomie après contrôle.
• N2 : validation du responsable de projet avant publication.
• N3 : intervention d’un responsable habilité ou instruction explicite.

Phase 5 — publier et contrôler

• Après publication, ouvrir la version live et refaire le parcours concerné.

Checklist avant Publish

• La modification demandée est complète.
• Aucun élément voisin n’a été déplacé involontairement.
• Desktop, tablette et mobile ont été vérifiés.
• Les liens et CTA fonctionnent.
• Les items CMS concernés affichent les bonnes données.
• Les formulaires concernés ont été testés.
• Aucune erreur visible dans le parcours testé.
• La validation requise N2/N3 a été obtenue.

Après Publish

Ouvrir le site public dans une nouvelle session et tester à nouveau le parcours. Vérifier notamment le cache visuel, les pages dynamiques et les liens externes.

Wix conserve un historique des versions enregistrées ou publiées. Il permet de voir quand une modification a été réalisée, par qui, et de restaurer une version antérieure lorsque cela est nécessaire.

Quand l’utiliser

• Une modification majeure a cassé plusieurs pages.
• Un élément ou une section importante a été supprimé.
• Une publication a introduit un défaut difficile à isoler.

Avant de restaurer

1. Identifier précisément la dernière version saine.
2. Noter les modifications valides réalisées depuis cette version.
3. Prévenir le responsable du projet : une restauration peut écraser des changements plus récents.
4. Restaurer seulement après décision claire, puis recontrôler le site.

Rapport d’incident minimal

• Site + page + breakpoint.
• Action réalisée juste avant le problème.
• Résultat obtenu et résultat attendu.
• Capture si utile.
• Message d’erreur exact s’il existe.

Fonctionnalités vérifiées pour cette édition le 18 septembre 2026. L’interface Wix Studio peut évoluer ; en cas de différence entre le guide et l’éditeur, utiliser la documentation officielle et préserver les règles internes Squared.

Studio Editor — Managing Breakpoints

Studio Editor — Designing Across Breakpoints

Studio Editor — Building a Responsive Site

Wix Studio — Using the CMS

Wix Studio — Managing Your Team

Studio Editor — Collaborating on a Site

Viewing and Managing Your Site History

Studio Editor — Adding and Managing Pages / SEO Basics

Studio Editor — Troubleshooting Responsiveness Issues

Portée du document

Ce guide couvre l’exploitation quotidienne de Wix Studio dans le contexte Squared Group. Il ne remplace pas une spécification technique détaillée d’un site, d’un CMS ou d’un module Velo particulier.