Client-First Webflow : structure, naming et bonnes pratiques
Client-First est une méthodologie de développement créée par Finsweet pour organiser les projets Webflow de façon claire, cohérente et maintenable. Son objectif n’est pas seulement de donner de “bons noms” aux classes CSS : la méthode définit une logique de structure, de classes, d’espacement, de typographie et de gestion globale du projet afin qu’un site puisse évoluer sans devenir difficile à reprendre.
J’utilise Client-First sur mes projets Webflow parce que cette logique répond à un problème très concret : un site ne doit pas être compréhensible uniquement par la personne qui l’a construit. Il doit rester lisible pour un autre développeur, pour une équipe interne et, lorsque c’est pertinent, pour le client lui-même.
Dans ce guide, je reviens sur la structure Client-First, sa convention de nommage, les unités REM, les variables, la maintenance et la certification officielle, avec un regard pratique de développeur Webflow.
Qu’est-ce que Client-First dans Webflow ?
Client-First est un système d’organisation pensé spécifiquement pour Webflow. Finsweet le présente autour de plusieurs objectifs : standardiser une structure de base entre les pages, définir une stratégie de classes, accélérer le travail dans le Designer, rendre les projets évolutifs et permettre à plusieurs personnes de comprendre la construction du site.
La nuance est importante : Client-First n’est pas un framework CSS traditionnel ni une bibliothèque de composants prête à l’emploi. C’est surtout une convention et une méthode de travail pour construire plus proprement dans Webflow.
Concrètement, deux développeurs utilisant Client-First doivent pouvoir ouvrir le même projet et comprendre rapidement la logique générale, même s’ils n’ont pas travaillé ensemble auparavant.
La structure de base Client-First
L’un des points les plus utiles de la méthode est sa core structure. Au lieu d’inventer une architecture différente pour chaque page, on part d’un ensemble de couches récurrentes.
- page-wrapper englobe la page ;
- main-wrapper contient le contenu principal ;
- section_[identifiant] identifie une section spécifique ;
- padding-global gère les marges horizontales globales ;
- container-[taille] contrôle la largeur maximale du contenu ;
- padding-section-[taille] gère l’espacement vertical des sections.
Cette logique est simple, mais elle change beaucoup la maintenance d’un projet. Si toutes les pages partagent les mêmes principes de conteneur, de padding et de structure, une évolution globale demande beaucoup moins de corrections ponctuelles.
Elle rend aussi le Navigator du Designer plus lisible. On distingue rapidement la section, le conteneur et le composant sur lequel on travaille, au lieu d’accumuler des Div Block sans logique identifiable.
Comment construire un site Webflow avec Client-First
Dans un projet réel, je n’applique pas Client-First comme une checklist isolée. Je l’utilise comme fil conducteur du développement.
- Définir les styles globaux : couleurs, typographies, tailles de texte, conteneurs et échelle d’espacement.
- Installer la structure de base : page-wrapper, main-wrapper, padding-global, containers et paddings de section.
- Créer les composants avec des classes personnalisées : navbar, hero, cartes, formulaires, sliders ou sections spécifiques.
- Réserver les utility classes aux usages réellement globaux afin d’éviter de mélanger logique de composant et logique utilitaire.
- Structurer le CMS en gardant la même lisibilité entre le Designer et les contenus dynamiques.
- Tester le responsive et l’accessibilité avant de valider les composants comme réutilisables.
- Préparer le handoff avec une structure suffisamment claire pour qu’un autre développeur puisse reprendre le projet.
Cette méthode permet de conserver une continuité entre design, développement et maintenance. Le gain de temps ne vient pas d’un raccourci magique, mais du fait que les décisions structurelles sont prises une fois et réutilisées de manière cohérente.
Comment fonctionne le naming Client-First ?
Le naming est probablement l’aspect le plus connu de Client-First. La documentation distingue principalement les classes personnalisées, utilisées pour un composant, une section ou un élément spécifique, et les classes utilitaires, utilisées pour des comportements réutilisables.
Une classe personnalisée peut par exemple suivre une logique comme pricing-card_title ou navbar_menu. L’underscore permet de montrer la relation entre le composant et son élément. Une utility class sera plutôt descriptive d’une propriété ou d’un usage global, comme text-color-primary ou une classe d’espacement.
Le principe derrière ces noms est plus important que la syntaxe elle-même : une personne doit pouvoir comprendre le rôle d’une classe sans avoir besoin de retrouver son contexte visuel. Finsweet recommande donc des noms descriptifs, sans abréviations inutiles ni raccourcis difficiles à interpréter.
Cette lisibilité est particulièrement utile lorsqu’un site change de prestataire ou lorsque plusieurs développeurs interviennent successivement sur le même projet.
Folders, composants et organisation des classes
Client-First a également évolué avec les Folders. L’idée est de regrouper visuellement les classes liées à un même composant ou à une même logique, ce qui devient très utile sur les projets importants.
Sur un petit site, quelques composants clairement nommés peuvent suffire. Sur un site avec beaucoup de templates CMS, de landing pages ou de modules réutilisables, l’organisation en dossiers permet de conserver une structure lisible sans transformer le panneau Styles en liste interminable.
Dans ma pratique, je garde cependant une règle simple : l’organisation doit aider le projet, pas devenir une fin en soi. Ajouter des couches de nomenclature inutiles sur un site très simple peut ralentir le travail au lieu de l’améliorer.
Pourquoi Client-First utilise les REM
Client-First recommande largement l’utilisation des unités REM. Un REM est relatif à la taille de police racine du document. Avec la valeur de navigateur standard, 1rem correspond généralement à 16px.
L’intérêt n’est pas seulement mathématique. Les unités relatives respectent mieux les préférences de taille de texte du navigateur et facilitent une approche plus cohérente des dimensions et espacements. Elles sont donc particulièrement intéressantes pour l’accessibilité et pour la gestion d’un système de design.
Je préfère aussi cette logique parce qu’elle évite une multitude de valeurs isolées. Une échelle d’espacement cohérente rend les décisions de design plus prévisibles et les ajustements responsive plus simples à maintenir.
Variables Webflow et Client-First
Les variables ont ajouté une couche supplémentaire à l’organisation des projets Webflow. La documentation actuelle de Client-First recommande notamment les variables de couleur pour centraliser les valeurs utilisées dans le projet.
Le bénéfice est évident : si une couleur de marque change, on modifie la variable plutôt que des dizaines de styles indépendants. Cela renforce à la fois la cohérence et la maintenabilité.
Finsweet reste cependant prudent sur les variables de taille : sa documentation indique ne pas les intégrer actuellement à sa méthode recommandée tant que la gestion des variables ne permet pas de les adapter par breakpoint comme souhaité. C’est un bon exemple d’un principe que j’apprécie dans Client-First : la méthode évolue avec Webflow plutôt que de figer des règles pour toujours.
Client-First améliore-t-il vraiment la maintenance ?
C’est pour moi l’un de ses avantages les plus concrets. Une structure cohérente réduit le temps nécessaire pour retrouver un style, comprendre une section ou modifier un composant plusieurs mois après la mise en ligne.
Elle facilite aussi la reprise par un autre développeur. Un projet organisé selon une convention documentée est beaucoup moins dépendant de son créateur qu’un site construit avec des classes comme div-block-42, new-class-3 ou une accumulation de combo classes difficiles à décoder.
C’est particulièrement important sur les sites qui continuent d’évoluer après leur lancement. Dans mes prestations de maintenance Webflow, une base structurée permet d’ajouter des pages, faire évoluer des composants ou corriger un problème avec beaucoup moins de risque de casser des styles ailleurs.
Client-First rend-il un site plus accessible ?
Client-First ne rend pas automatiquement un site accessible. Une bonne nomenclature ne remplace ni une structure HTML sémantique, ni une navigation clavier correcte, ni des contrastes suffisants, ni des textes alternatifs pertinents.
En revanche, certaines décisions de la méthode vont dans la bonne direction : utilisation des REM, structure cohérente, attention portée au HTML sémantique et documentation dédiée à l’accessibilité. Une base organisée facilite également les audits et les corrections, car les composants et styles sont plus faciles à identifier.
Il faut donc voir Client-First comme un socle qui peut favoriser de bonnes pratiques, pas comme une garantie de conformité.
Qu’est-ce que la certification Client-First ?
Finsweet propose aujourd’hui une certification Client-First officielle. Le parcours comprend un examen théorique et une revue de projets, avec différents niveaux de certificat et une possibilité d’apparaître dans leur annuaire d’experts après validation.
Cette certification peut être intéressante pour un développeur qui veut faire vérifier sa maîtrise de la méthode par son créateur. Elle n’est cependant pas nécessaire pour utiliser Client-First correctement, et un badge ne remplace évidemment pas l’analyse de vrais projets, de leur structure et de leur qualité de développement.
Je préfère donc considérer la certification comme un signal supplémentaire, pas comme le seul critère pour choisir un développeur Webflow.
Client-First est-il adapté à tous les projets Webflow ?
Je l’utilise comme base sur la majorité de mes projets, mais cela ne signifie pas qu’il faille appliquer chaque règle mécaniquement.
Sur un site éditorial ou corporate avec plusieurs pages, des composants réutilisables et un CMS, la valeur est évidente : structure partagée, classes prévisibles, maintenance plus simple et handoff plus propre. Sur une landing page très courte ou un prototype temporaire, certaines couches peuvent être simplifiées.
Le bon réflexe n’est donc pas de “faire du Client-First” pour cocher une case. Il faut utiliser les principes qui rendent réellement le projet plus lisible et plus évolutif.
Pourquoi je l’utilise dans mes projets Webflow
Ce que je recherche dans une méthode de développement n’est pas seulement la vitesse pendant la construction. Je veux qu’un projet reste propre six mois ou deux ans plus tard, lorsqu’il faut ajouter une page, intégrer un nouveau développeur ou faire évoluer le design.
Client-First me donne une base commune pour atteindre cet objectif. J’y ajoute ensuite les conventions propres au projet, les composants nécessaires, le CMS et le niveau de documentation adapté au client.
Dans un développement Webflow sur mesure, cette organisation est invisible pour l’utilisateur final, mais elle fait une vraie différence sur la qualité technique, la maintenance et la capacité du site à évoluer.
Vous cherchez un développeur Webflow pour construire ou reprendre un projet Client-First ? Parlons de votre site.
FAQ
Qu’est-ce que Client-First dans Webflow ?
Client-First est une méthodologie de développement créée par Finsweet pour organiser les projets Webflow. Elle définit une structure de base commune, une stratégie de classes, des conventions de nommage, des principes d’espacement, de typographie et d’utilisation des unités REM. Son objectif est de rendre un projet plus lisible, évolutif et facile à reprendre par un autre développeur ou une équipe interne.
Quelle est la structure de base Client-First ?
La core structure Client-First repose notamment sur page-wrapper, main-wrapper, section_[identifiant], padding-global, container-[taille] et padding-section-[taille]. Ces couches donnent à toutes les pages une organisation prévisible et permettent de gérer plus facilement les largeurs de contenu, les marges globales et les espacements verticaux à l’échelle du site.
Comment fonctionne le naming Client-First ?
Client-First distingue principalement les classes personnalisées, liées à un composant ou à un élément spécifique, et les classes utilitaires, conçues pour des usages globaux et réutilisables. Les noms doivent rester descriptifs et compréhensibles sans contexte. L’objectif est qu’un développeur ou une autre personne puisse identifier rapidement le rôle d’une classe sans devoir inspecter tout le projet.
Existe-t-il une certification Client-First officielle ?
Oui. Finsweet propose une certification Client-First officielle comprenant un examen théorique et une revue de projets. Les candidats validés peuvent obtenir des certificats et être référencés dans l’annuaire Client-First Experts. Cette certification est un signal de maîtrise supplémentaire, mais elle n’est pas obligatoire pour utiliser correctement Client-First.
Client-First est-il adapté à tous les projets Webflow ?
Client-First fonctionne particulièrement bien sur les sites qui doivent rester maintenables et évoluer dans le temps : sites corporate, éditoriaux, projets CMS ou plateformes composées de nombreux modules. Sur une landing page très simple ou un prototype temporaire, certaines couches peuvent être allégées. L’essentiel est d’appliquer les principes qui améliorent réellement la lisibilité et la maintenance du projet.
