Webflow
Webflow Client-First : le guide complet pour structurer son projet en 2026
Vous ouvrez un projet Webflow hérité d'un autre développeur. Le panneau de classes ressemble à une armée de noms cryptiques : .div-block-47, .wrapper-2, .text-block-rouge-modif. Naviguer dans ce chantier prend plus de temps que de construire le site de zéro.
Ce problème, quasiment tous les développeurs Webflow l'ont vécu. Et c'est précisément pour y remédier qu'est né Webflow Client-First. Ce système de conventions, créé par l'agence Finsweet, est devenu le standard de l'industrie pour structurer des projets Webflow propres, lisibles et maintenables.
Dans ce guide, vous allez comprendre ce qu'est Client-First, comment fonctionne sa logique de nommage, comment démarrer concrètement, et quelles sont les erreurs à éviter. Que vous soyez seul sur votre projet ou en équipe, ce guide vous donne toutes les clés pour adopter la méthode en 2026.
Qu'est-ce que Client-First ?
Client-First est un système de conventions CSS développé et maintenu par Finsweet, l'une des agences Webflow les plus reconnues au monde. Ce n'est pas un plugin, pas un thème, pas une extension : c'est une méthodologie.
L'idée centrale est simple : donner à chaque classe un nom qui décrit clairement ce qu'elle fait, où elle se trouve, et quel est son rôle dans la structure de la page. Résultat : n'importe quel développeur qui reprend le projet comprend immédiatement ce qu'il a sous les yeux.
Le nom "Client-First" est intentionnel. La méthode est pensée pour que le client, pas seulement l'agence, puisse comprendre et maintenir son site. C'est une vision de long terme, qui tranche avec les projets monolithiques difficiles à transmettre.
Pourquoi adopter Client-First sur vos projets Webflow ?
Il existe plusieurs systèmes de nommage pour Webflow, mais Client-First s'est imposé comme la référence pour une raison principale : la scalabilité. Un projet Client-First reste lisible qu'il soit composé de 5 pages ou de 50.
Voici ce que ça change concrètement pour un projet d'agence ou de freelance :
- La reprise de projet est rapide. Quand un client revient six mois après pour une mise à jour, vous retrouvez vos repères en quelques minutes.
- Le travail en équipe devient possible. Deux développeurs peuvent intervenir sur le même projet sans se marcher dessus.
- Les erreurs de style se réduisent. Quand les classes ont un rôle clairement défini, on évite les effets de bord involontaires.
Pour une PME qui veut autonomie et évolutivité sur son site, choisir un prestataire qui travaille avec Client-First est un vrai gage de qualité. D'ailleurs, si vous comparez les offres d'agences, ce point mérite d'être posé directement.
La structure de base : sections, conteneurs et wrappers
Client-First impose une hiérarchie précise pour chaque bloc de page. Cette hiérarchie se lit de haut en bas, de la même façon sur toutes les pages du site. Voici le schéma de base :
section
└── padding-global
└── container-large (ou medium, small)
└── padding-section-medium
└── [contenu de la section]
Chaque élément a un rôle distinct. La section organise le navigateur dans le Designer. Le padding-global gère les marges latérales. Le container-large définit la largeur maximale du contenu. Et padding-section-medium gère les espacements verticaux.
Cette séparation peut sembler rigide au premier abord. En pratique, elle offre une flexibilité énorme : modifier l'espacement d'une seule section ne casse jamais les autres. Et comme la logique est la même partout, l'inspection d'une page inconnue prend quelques secondes.
Le système de nommage des classes : la logique des préfixes
C'est le coeur de Client-First. Chaque classe suit une convention précise selon son type.
Les classes utilitaires globales, qui s'appliquent partout sur le site, ont un nom sans trait de soulignement. Par exemple : text-size-large, margin-bottom-medium, hide-tablet.
Les classes personnalisées, propres à un composant, utilisent un underscore pour séparer le nom du composant du nom de l'élément. Par exemple : testimonial_wrapper, nav_link, hero_heading.
Cette distinction est essentielle. Elle permet de savoir immédiatement, en lisant un nom de classe, si on touche quelque chose de global (risque d'effet de bord partout sur le site) ou de local (impact limité à un composant).
Un exemple concret : si vous modifiez la classe .text-size-large, vous modifiez tous les textes de grande taille sur le site. Si vous modifiez .hero_heading, vous ne touchez que le titre du bloc hero. Le underscore devient un signal visuel immédiat.
Classes utilitaires vs classes personnalisées : quand utiliser quoi ?
La règle d'or : ne jamais ajouter de style directement aux classes utilitaires globales.
Les classes utilitaires (margin-top-large, flex-center, color-primary) sont définies une seule fois dans le style guide et appliquées en combinaison sur les éléments. On les empile, on ne les modifie pas.
Les classes personnalisées, elles, s'écrivent en composant_element. C'est là que vous ajoutez les styles uniques à chaque section. Par exemple : .cta_button peut avoir une couleur de fond spécifique, une ombre et un border-radius propres à ce bloc.
Cette séparation claire entre le global et le local est ce qui rend Client-First aussi robuste sur le long terme. Elle s'inspire directement des bonnes pratiques du CSS moderne, et notamment des méthodologies BEM (Block, Element, Modifier) que les développeurs front-end connaissent bien.
Comment démarrer avec Client-First
Le point d'entrée officiel est le cloneable Client-First disponible sur Webflow Made in Webflow. Ce template contient le style guide complet : toutes les classes utilitaires pré-définies, la structure de base, les variables de couleurs et de typographie.
Voici la marche à suivre pour un nouveau projet :
- Dupliquer le cloneable dans votre espace Webflow.
- Personnaliser les variables globales (couleurs, polices, espacements) dans le style guide.
- Supprimer les sections de démonstration dont vous n'avez pas besoin.
- Commencer à construire vos sections en appliquant la hiérarchie
section > padding-global > container > padding-section.
Pour un projet existant, la migration est plus complexe. Il n'existe pas de chemin automatique. Le plus pragmatique est d'adopter Client-First progressivement, section par section, à mesure que vous intervenez sur le projet.
La documentation officielle est disponible en français sur finsweet.com/client-first/fr/intro, ce qui lève la barrière de la langue pour les équipes francophones.
Les erreurs classiques à éviter
Même avec la meilleure intention, certains pièges reviennent souvent sur les projets Client-First. Voici les plus fréquents.
Modifier une classe utilitaire globale. C'est l'erreur numéro un. Vous ajoutez un font-weight: bold sur text-size-large pour un élément précis, et voilà tous vos textes de grande taille en gras. Règle absolue : les classes utilitaires sont en lecture seule.
Inventer ses propres conventions. Client-First ne fonctionne que si tout le projet suit les mêmes règles. Dès qu'un développeur crée ses propres préfixes ou ignore le underscore, la lisibilité s'effondre. Documenter les règles au début du projet est indispensable quand on travaille en équipe.
Surcharger la hiérarchie. Il est tentant d'ajouter des wrappers supplémentaires pour gérer des cas particuliers. En général, la structure Client-First standard couvre 95% des situations. Avant d'ajouter une couche, demandez-vous si vous n'êtes pas en train de contourner la méthode plutôt que de l'appliquer.
Ignorer le style guide. Le cloneable n'est pas qu'un point de départ : c'est la référence vivante du projet. Le maintenir à jour, notamment quand on ajoute de nouvelles couleurs ou tailles de texte, est une habitude qui fait gagner beaucoup de temps sur la durée.
Client-First vs autres systèmes de classes Webflow
Client-First n'est pas le seul système de nommage pour Webflow. On peut citer Lumos (par BEM), Flowbase, ou encore des conventions maison développées par certaines agences.
Pourquoi Client-First s'est imposé ? Parce qu'il bénéficie d'une communauté très active, d'une documentation complète (y compris en français), et qu'il est utilisé par des centaines d'agences dans le monde. Reprendre un projet Client-First d'une autre agence est beaucoup plus simple que de décoder un système maison.
Pour un projet Webflow comparé à une solution WordPress, la question de la maintenabilité est centrale. Un site Webflow bien structuré avec Client-First peut être maintenu par n'importe quel développeur Webflow formé, sans dépendance à un prestataire unique. C'est un argument fort en faveur de Webflow face à WordPress sur le long terme.
Conclusion
Webflow Client-First n'est pas une option : c'est devenu le standard de fait pour tout projet Webflow sérieux. Que vous construisiez un site vitrine pour une PME ou une plateforme e-commerce complexe, adopter cette méthode dès le départ vous épargnera des heures de maintenance et de débogage.
Les trois points à retenir : la hiérarchie section-container-wrapper est non négociable, la distinction utilitaire global vs classe personnalisée est la clé du système, et le cloneable officiel Finsweet est votre meilleur point de départ.
Chez Dresscodes, tous nos projets Webflow sont construits avec Client-First. Si vous souhaitez un site structuré, maintenable et évolutif, contactez-nous pour discuter de votre projet.
FAQ
Qu'est-ce que Client-First dans Webflow ?
Client-First est un système de conventions de nommage des classes CSS pour Webflow, créé par Finsweet. Il définit une structure et une nomenclature standard pour rendre les projets Webflow lisibles, maintenables et transmissibles.
Client-First est-il gratuit ?
Oui. La documentation, le cloneable et les ressources Client-First sont entièrement gratuits et accessibles sur finsweet.com/client-first. Finsweet propose aussi des outils payants séparés, mais le système de conventions lui-même ne coûte rien.
Faut-il utiliser Client-First sur tous les projets Webflow ?
Pour tout projet destiné à durer dans le temps ou à être repris par quelqu'un d'autre, oui. Pour un projet personnel jetable ou un prototype rapide, ce n'est pas indispensable. Mais prendre l'habitude de travailler avec Client-First dès le départ est une bonne hygiène de développement.
Comment migrer un projet existant vers Client-First ?
Il n'existe pas de migration automatique. La méthode la plus réaliste est une migration progressive : à chaque intervention sur une section, renommer les classes selon les conventions Client-First et restructurer si nécessaire. Une migration complète d'un gros projet représente un chantier significatif.
Client-First ralentit-il la construction d'un site Webflow ?
Légèrement au départ, le temps de prendre en main les conventions. Mais cet investissement initial est récupéré très rapidement grâce à la vitesse de navigation dans le projet, la réutilisabilité des composants et la réduction des erreurs. Sur un projet de plus de 10 pages, Client-First fait gagner du temps.
