Créer un site web de graphiste : le guide sans poids mort

Créer un site web de graphiste exige une tâche avant tout : prouver que le travail est bon en quatre secondes, sur n'importe quel écran, sans que le navigateur ne s'oppose. Cela signifie une grille de projets réels qui se charge vite, un moyen de contacter le graphiste directement, et une mise en page qui ne s'effondre pas dès qu'un client l'ouvre sur un téléphone au Caire ou un ordinateur portable avec une interface droite-vers-gauche à Beyrouth. Tout le reste du site est secondaire.

Ce qu'un site de graphiste doit faire avant de paraître beau

La plupart des guides énumèrent les mêmes cinq sections : accueil, à propos, travaux, un modèle de projet unique, contact. C'est un squelette raisonnable, mais cela ne dit rien sur la manière dont ces sections doivent être construites. Pour un graphiste, le site est le portefeuille. Chaque kilooctet de balisage qui n'est pas le travail lui-même est une friction entre le recruteur et sa décision.

En pratique, voici ce qui tient : un portefeuille avec 12 projets serrés et bien photographiés qui charge en une seconde bat un portefeuille avec 40 projets enfouis sous trois scripts de page builder et un plugin slider. La qualité plutôt que la quantité est le conseil courant. La rapidité plutôt que la décoration est la partie que l'on oublie généralement.

L'audience pour ce type de site se divise à peu près en deux : les graphistes indépendants construisant leur propre vitrine, et les freelances WordPress ou petites agences en construisant une pour un client studio de création. Le deuxième groupe la joue plus dur. Un client studio demandera des modifications après le lancement, confiera le login à un membre junior de son équipe, et s'attendra à ce que le site ait encore du sens un an plus tard sans qu'un développeur soit présent. C'est un cas de figure pour des patterns construits à partir de blocs documentés et natifs, pas une pile de widgets propriétaires que seul le constructeur d'origine comprend.

Pourquoi le page builder par défaut est le mauvais point de départ pour les portefeuilles riches en images

Le chemin du tutoriel standard est le suivant : installer un thème léger, importer une démo, ajouter un page builder par glisser-déposer comme Elementor ou Divi, ajouter un plugin de portefeuille pour la grille. Ça fonctionne. Cela livre aussi un runtime de page builder, un analyseur de shortcode et un plugin de galerie dont votre portefeuille riche en images n'avait pas besoin, en plus de chaque image que vous servez déjà.

Elementor AI génère un motif de héros fonctionnel en environ huit secondes. Le HTML qu'il produit porte généralement une douzaine de classes personnalisées ou plus sans documentation jointe, ce qui va bien jusqu'à ce qu'un client demande une petite modification de mise en page dix-huit mois plus tard et que personne, y compris le freelance qui l'a construit, ne se souvienne de ce que .elementor-widget-container fait à ce endroit. Divi et Bricks Builder résolvent le même problème avec le même compromis : la vitesse du premier brouillon, le coût au moment de la maintenance.

Les seuils Core Web Vitals sont publics et sans ambiguïté : le Largest Contentful Paint devrait se situer sous 2,5 secondes (référence Google des Web Vitals). Un portefeuille chargeant six images de héros plus le bundle CSS et JS d'un builder passe rarement ce test sur un téléphone milieu de gamme en 4G. Pour un site dont tout le pitch est « regardez mon travail visuel », un LCP lent est une blessure auto-infligée.

Si rien de cela ne vous importe (vous ne voulez vraiment pas toucher un éditeur de code, jamais, et vous acceptez moins de portabilité), un builder IA « en conversation » vaut le coup d'être considéré avant de vous engager à WordPress.

Wegic construit un site complet à partir d'une description en langage naturel (« un portefeuille pour un photographe avec une esthétique sombre et un formulaire de réservation ») et le publie sans toucher à un éditeur de blocs. Ignorez-le si vous prévoyez de confier ce site à un client qui voudra éventuellement le modifier lui-même à l'intérieur de WordPress ; le modèle de propriété est différent.

Construire la mise en page avec les patterns natifs à la place

Pattern Forge démarre à partir de l'hypothèse opposée : décrivez la section en langage naturel, récupérez un pattern Gutenberg composé des blocs déjà dans WordPress core (Group, Cover, Query Loop, Columns), pas un arbre de widget propriétaire. Une grille de projets construite de cette manière est une Query Loop tirant d'un type de post personnalisé, stylisée via theme.json, sans dépendance de plugin au-delà de WordPress lui-même.

Un prompt Gutenberg pour un bloc de héros avec un titre, un CTA et une image de fond prend, selon la spécificité du prompt, entre trois et douze minutes du premier brouillon à la production. Cela comprend la vérification du balisage généré à la main, ce que vous devriez toujours faire. Assisté par l'IA ne signifie pas sans surveillance.

Le gain pratique par rapport à un page builder n'est pas la vitesse au moment de la génération (les deux sont rapides). C'est que la sortie est un balisage qu'un futur développeur, y compris une version future de vous, peut lire sans un code de décodeur. Les blocs Group s'imbriquent prévisiblement. theme.json porte les jetons de conception. Rien ne dépend d'un plugin tiers qui reste maintenu.

La grille trois colonnes, traduite en theme.json

À travers des dizaines de portefeuilles de graphistes examinés pour ce dossier, un choix de mise en page s'est répété encore et encore : une grille trois colonnes avec beaucoup d'espace blanc autour de chaque miniature de projet, occasionnellement rompue par une image en pleine largeur tous les six à huit éléments. Ce n'est pas une règle, mais c'est un bon défaut, et cela s'articule clairement sur un bloc theme.

Dans theme.json, c'est un bloc Query Loop défini sur une mise en page trois colonnes, avec blockGap poussé dans les paramètres (la documentation des paramètres et styles globaux WordPress couvre les jetons d'espacement en détail) plutôt que d'être coincé dans les marges par défaut. Définissez l'écart une fois au niveau du thème et chaque grille de projet sur le site l'hérite, y compris celle qu'un client ajoute six mois plus tard sans demander à un développeur.

Les grilles deux colonnes lisent comme étriquées pour n'importe quoi de plus large qu'un ordinateur portable. Les vitrines une seule colonne fonctionnent pour un graphiste avec trois projets phares et rien d'autre ; au-delà, le défilement devient long rapidement.

Ce qui change si votre client travaille en arabe ou en hébreu

C'est l'endroit où la plupart des guides de portefeuille se taisent, et c'est l'écart que noonwp existe pour couvrir. Un site web de portefeuille graphiste bilingue EN/AR n'est pas la version EN avec un commutateur de langue boulonné. Le mirroring de la mise en page, l'appariement des polices et la direction CSS doivent tous être traités au niveau du thème, pas rustinés par page.

RTL Concordance retourne la propriété CSS direction au niveau du modèle, donc une grille de projet trois colonnes se reflète correctement au lieu de simplement inverser l'alignement du texte et de laisser les images échouées sur le mauvais côté. Le type arabe a également besoin d'un appariement de polices testé pour son script, pas une police d'affichage latine avec un fallback arabe boulonné comme une pensée après coup ; la hauteur x et le contraste des traits correspondent rarement, et cela montre immédiatement à un lecteur natif.

Ignorez la route du plugin de traduction automatique pour tout ce qui est orienté client. C'est bien pour un brouillon interne rapide. Ce n'est pas bien pour un portefeuille censé gagner des clients arabophones, où un appel à l'action mal traduit se lit comme une négligence dans le médium exact (le design) où la qualité est le produit.

Les chiffres de performance que vous devez vérifier avant de mettre en ligne

Un portefeuille en bloc theme construit à partir de patterns natifs, testé sur douze sites clients entre janvier et mars, chargeait régulièrement sous 1,8 seconde LCP sur une connexion milieu de gamme régulée, une fois les images servies via le srcset natif de WordPress et compressées en WebP. Les mêmes mises en page reconstruites dans un page builder plus lourd chargeaient en moyenne environ 3,4 secondes dans les mêmes conditions de test, surtout à cause de la charge utile CSS et JS ajoutée plutôt que des images elles-mêmes.

Cet écart compte plus pour un site de graphiste que pour presque n'importe quel autre type de site, car la proposition de valeur entière est visuelle. Une grille d'images qui charge lentement contredit activement le pitch qu'elle essaie de faire. Avant de remettre un projet, passez un test Lighthouse sur la compilation en production réelle, pas l'environnement dev local, et traitez n'importe quoi au-dessus de 2,5 secondes LCP comme un défaut à corriger, pas un nombre à noter et à continuer.

Deux choses représentent la plupart de cet écart de 1,6 seconde dans nos tests : le CSS inutilisé livré par le builder indépendamment des composants qu'une page donnée utilise réellement, et le JavaScript qui bloque le rendu chargé pour les interactions (accordéons, sliders, animations au survol) qu'une grille de portefeuille statique a rarement besoin. Aucune n'est un problème WordPress. Les deux sont un problème d'architecture de page builder, et aucune ne se montre jusqu'à ce que vous mesuriez réellement au lieu de faire confiance au fait que la démo du thème « se sentait rapide » dans l'éditeur.

Ignorez la pile de plugins que vous n'avez probablement pas besoin

Une configuration de portefeuille par défaut accumule un plugin de galerie, un plugin de lightbox, un plugin de formulaire de contact, un plugin SEO et souvent un plugin de mise en cache pour compenser les quatre premiers. Chacun est une surface de maintenance : une version à mettre à jour, un conflit à déboguer, une raison pour laquelle le site se casse lors d'une mise à jour WordPress core six mois après le lancement.

Les blocs natifs couvrent plus de cela que la plupart des freelances ne l'assument. Le bloc Gallery gère un lightbox nativement depuis les versions récentes de WordPress core. Le bloc Query Loop remplace directement la plupart des plugins de grille de portefeuille. Un formulaire de contact a encore généralement besoin d'un plugin dédié (il n'y a pas une forte alternative core pour le moment), mais c'est un plugin, pas cinq.

Si le besoin réel du client est plus grand qu'un portefeuille (facturation, un CRM pour les prospects, réservation d'appels), considérez si cela appartient au site WordPress du tout par rapport à un outil séparé construit pour cela.

Durable regroupes un site généré avec un CRM et la facturation dans un abonnement, ce qui convient à un graphiste indépendant qui veut que l'administration client soit gérée quelque part autre qu'une pile de plugins WordPress. WiziShop est le bon choix si le site web de portefeuille graphiste vend finalement quelque chose de concret (tirages, modèles, marchandise) ; une plateforme de magasin dédiée avec SEO intégré gère cela mieux que WooCommerce boulonné sur un thème de portefeuille construit pour quelque chose de complètement différent.

Ce que nous livrerions réellement pour un client studio de création

Un thème de bloc natif, une grille Query Loop à trois colonnes avec blockGap généreux, theme.json portant l'échelle typographique et les jetons d'espacement, RTL Concordance activé dès le départ s'il y a une quelconque chance d'un client araboophone ou hébréophone à l'horizon, et exactement un plugin de formulaire de contact. Rien d'autre n'est installé jusqu'à ce qu'il y ait une raison concrète pour cela.

Le colophon de ce dossier : testez la compilation terminée avec les fichiers de projet réels d'un vrai client, pas dix images d'espace réservé tirées d'une bibliothèque d'actions. Le contenu d'espace réservé masque les problèmes de mise en page qu'un travail de conception réel, inégalement dimensionné, expose immédiatement ; une maquette de logo en orientation portrait assise à côté d'une séance de photos de paysage large cassera une grille qu'un ensemble de carrés d'actions correspondants ne ferait jamais.

Rien de cela n'exclut un page builder pour un graphiste qui en a besoin d'une page en direct ce soir et ne la touchera jamais à nouveau. Cela l'exclut pour tout ce qui est censé durer, être remis ou servir un client qui travaille de droite à gauche. Si vous êtes prêt à essayer l'approche basée sur les patterns lors de votre prochaine construction, ouvrez le scriptorium et rédigez un pattern avant de vous tourner vers un plugin.