Le webflow cms provoque souvent un moment de flottement chez ceux qui découvrent la plateforme après avoir manipulé un système ouvert. Il n’y a pas d’extensions à installer, pas de types de contenus à déclarer dans un fichier, pas de base de données à administrer. À la place, un modèle simple en apparence : des collections, des champs, des listes et des pages de gabarit. Cette simplicité est réelle, mais elle a une conséquence directe : les décisions de modélisation prises la première semaine se paient ou se rentabilisent pendant toute la vie du site. Comprendre le fonctionnement et les frontières du système avant de bâtir évite les reconstructions douloureuses.
Ce qu’est vraiment une collection
Une collection définit un type de contenu répétable : article de blog, réalisation, membre d’équipe, offre de service, témoignage, question fréquente. Elle se compose de champs, et chaque entrée de la collection remplit ces champs. Le principe est celui d’un tableau où les colonnes sont les champs et les lignes les entrées, à ceci près que chaque colonne possède un type strict qui conditionne son affichage et son comportement.
Trois objets découlent automatiquement de cette définition. Le premier est la page de gabarit, page unique dont la mise en page sert à afficher n’importe quelle entrée : elle se dessine une fois et se décline en autant de pages publiées qu’il existe d’entrées. Le deuxième est la liste dynamique, composant que l’on pose sur n’importe quelle page pour afficher un sous-ensemble d’entrées. Le troisième est l’interface d’édition, alimentée sans intervention du concepteur.
Cette séparation entre la donnée et sa présentation constitue le vrai apport du système. Modifier la mise en page de deux cents fiches revient à modifier une seule page. Ajouter une entrée revient à remplir un formulaire, sans toucher au design. C’est aussi ce qui rend le modèle inconfortable pour qui pense encore en pages individuelles : on ne dessine plus une page, on dessine un moule.
Modéliser une collection : les décisions qui engagent
Choisir les bons types de champs
Le catalogue de types couvre les besoins courants : texte court, texte enrichi, nombre, date, lien, courriel, téléphone, image unique, galerie d’images, fichier, couleur, commutateur, liste d’options prédéfinies. Chacun se comporte différemment à l’affichage et au filtrage, et le choix initial se change mal une fois les entrées saisies.
Deux erreurs reviennent constamment. La première consiste à tout mettre dans un unique champ de texte enrichi, ce qui produit des fiches impossibles à filtrer, à trier ou à réutiliser ailleurs sur le site. La seconde consiste à saisir en texte libre une information qui devrait être une liste d’options : les variantes d’orthographe et les majuscules erratiques s’accumulent et rendent tout filtrage inopérant. La règle utile tient en une phrase : toute information susceptible de servir à trier, filtrer ou grouper mérite son propre champ typé.
Relier les collections entre elles
Les champs de référence relient une entrée à une autre entrée, d’une collection différente ou de la même. Un article pointe vers sa catégorie et vers son auteur ; une réalisation pointe vers son secteur d’activité et vers les services mobilisés. Une variante permet de relier plusieurs entrées à la fois, par exemple les étiquettes d’un article.
Ces liaisons ouvrent des possibilités structurantes. Une page de gabarit de catégorie peut lister automatiquement tous les articles qui la référencent, ce qui produit des pages de rubrique fournies sans travail supplémentaire. Le maillage interne du site devient cohérent par construction, chaque fiche renvoyant vers ses entités liées. Renoncer aux références et dupliquer l’information dans des champs texte revient à se priver de tout cela, tout en garantissant des incohérences à moyen terme.
Prévoir l’évolution
Un modèle bien conçu anticipe les besoins des dix-huit mois suivants sans les implémenter tous. Concrètement : créer dès le départ les collections annexes qui serviront de référentiel, même avec deux entrées, et prévoir un ou deux champs neutres pour les usages futurs. Ajouter un champ plus tard reste possible et sans danger ; changer le type d’un champ rempli ou scinder une collection en deux relève de l’opération lourde.
Deux conventions font gagner un temps considérable sur la durée. La première consiste à nommer les champs dans une langue unique et selon une règle stable, sans abréviations improvisées : un modèle relu six mois plus tard par une autre personne doit rester compréhensible. La seconde consiste à documenter, dans un simple document partagé, la signification de chaque champ, les valeurs attendues et les contraintes de longueur. Ce guide de saisie vaut mieux que n’importe quelle formation pour maintenir la cohérence quand plusieurs contributeurs alimentent la même collection, et il évite la dérive classique où les titres passent de quarante à cent vingt caractères selon l’humeur du rédacteur, cassant la mise en page des listes.
Afficher le contenu : listes, filtres et gabarits
La liste dynamique se paramètre selon quatre réglages : la collection source, les conditions de filtrage, l’ordre de tri et le nombre d’éléments affichés. Les conditions se combinent, ce qui permet par exemple d’afficher les entrées d’une catégorie donnée, publiées, hors de l’entrée en cours de consultation. Ce dernier réglage sert à construire les blocs de contenus liés en bas de fiche.
La pagination prend le relais quand le nombre d’éléments dépasse la limite d’affichage d’une liste. Elle fonctionne bien, avec une réserve à connaître : le passage d’une page à l’autre modifie l’adresse par un paramètre, ce qui a des conséquences sur l’exploration par les moteurs. Le sujet est traité dans notre guide du référencement sur cette plateforme.
Les listes imbriquées constituent la limite la plus fréquemment rencontrée. Afficher, à l’intérieur d’une liste d’entrées, une seconde liste tirée d’une collection liée fonctionne dans un cas précis, celui des champs de référence, et de manière restreinte quant au nombre d’éléments visibles. Les mises en page qui supposent une imbrication profonde se heurtent rapidement à cette frontière et demandent un contournement, généralement en dupliquant l’information utile dans la collection principale.
Les limites structurelles à connaître
Le système impose des plafonds, définis par le plan souscrit pour l’espace de travail et pour le site. Ils portent sur le nombre de collections, le nombre d’entrées cumulées, le nombre de pages statiques et le volume de trafic. Leurs valeurs évoluent au fil des révisions de l’offre commerciale, ce qui rend inutile de les mémoriser : la vérification se fait sur la grille en vigueur au moment du cadrage, avant tout engagement.
| Contrainte | Nature du blocage | Contournement courant |
|---|---|---|
| Nombre d’entrées par site | plafond lié au plan souscrit | montée de plan ou archivage des anciennes entrées |
| Listes imbriquées | affichage restreint et peu profond | duplication du champ utile dans la collection parente |
| Filtrage par le visiteur | non natif côté serveur | filtrage côté navigateur ou service tiers |
| Recherche interne avancée | fonction de base uniquement | service de recherche externe intégré |
| Champ typé déjà rempli | changement de type impossible | création d’un nouveau champ et migration des valeurs |
| Relations complexes entre collections | modèle volontairement simple | simplification du modèle ou solution externe |
Aucune de ces limites n’est rédhibitoire pour un site vitrine, un blog ou un catalogue de réalisations. Elles deviennent pénalisantes sur des projets qui ressemblent à une application : annuaire avec recherche multicritère, base documentaire de grande taille, espace membre avec contenus personnalisés. Pour ces cas, la comparaison avec un système ouvert prend tout son sens, et notre comparatif des deux approches détaille les arbitrages.
Alimenter le contenu autrement qu’à la main
La saisie manuelle convient tant que le volume reste faible. Au-delà, trois voies existent. L’importation tabulaire permet de créer des entrées en masse, avec une correspondance de colonnes vers les champs de la collection : c’est la méthode retenue lors des reprises de contenu existant. L’interface de programmation de la plateforme autorise la création et la mise à jour d’entrées par un programme externe, ce qui ouvre la synchronisation avec un outil métier. Les plateformes d’automatisation sans code enfin, qui relient des services entre eux, savent créer une entrée à partir d’un formulaire, d’une feuille de calcul ou d’un message.
Ces mécanismes servent aussi dans l’autre sens : notifier une équipe d’une nouvelle publication, alimenter une lettre d’information, tenir à jour un tableau de suivi. Leur mise en place suppose de comprendre finement le modèle de données, compétence que les parcours d’apprentissage abordent inégalement, sujet développé dans notre panorama des formats de formation disponibles.
Pour quels projets ce modèle convient
Le système donne sa pleine mesure sur les sites où le contenu est répétitif, structuré et modérément volumineux : blogs professionnels, portfolios, annuaires de taille raisonnable, catalogues de services, pages de destination déclinées par cible. Il évite la dispersion, produit un maillage cohérent et rend la publication accessible à une personne non technique.
Un signal pratique aide à valider ce choix avant de construire. Prenez les trois pages les plus consultées d’un site comparable et demandez-vous si leur contenu tiendrait dans un tableau de dix colonnes. Si la réponse est oui, le modèle convient et la construction se déroulera sans friction. Si la réponse suppose des tableaux imbriqués, des conditions complexes ou des calculs, le projet relève d’une autre catégorie d’outil. Cette vérification préalable coûte une demi-heure et évite de découvrir le problème à mi-parcours, quand la bascule vers une autre solution implique de tout reprendre.
Le système montre ses limites dès que le besoin glisse vers la manipulation de données : croisements multiples, calculs, recherche fine, personnalisation par utilisateur. Reconnaître ce basculement tôt évite une construction qui fonctionnera mal et coûtera cher à maintenir. Le test le plus simple consiste à décrire en une phrase ce que le visiteur doit pouvoir faire sur le site. Si cette phrase contient les mots « rechercher », « filtrer selon plusieurs critères » ou « accéder à son espace », le modèle atteindra rapidement ses frontières et un examen approfondi s’impose avant de choisir.