Cookies

J’utilise Google Analytics pour savoir quelles pages vous sont utiles. Aucun cookie publicitaire. Vous pouvez changer d’avis à tout moment. Lire la page Confidentialité

Aller au contenu

Pour les agences et les graphistes

Maquette Figma vers WordPress : ce que l’intégrateur doit recevoir

Audit avant-vente offert Le site de votre prospect

Sur une intégration, le délai se joue rarement au moment du code. Il se joue à la réception du fichier. Un brief complet part en production le jour même. Un brief incomplet déclenche une liste de questions, une attente de réponse, une reprise à froid, et un chantier de trois jours s’étale sur deux semaines sans que personne n’ait travaillé davantage.

Voici ce qu’un intégrateur attend d’une maquette Figma, dans l’ordre où il s’en sert, les états que les maquettes oublient presque toujours, le piège des polices, et une checklist à copier dans votre modèle de brief. C’est ce que je demande aux agences pour l’intégration de maquettes WordPress.

Le fichier Figma lui-même

Un lien de partage avec l’accès aux propriétés, plutôt qu’une série de captures d’écran. L’intégrateur doit relever les valeurs exactes : couleurs, tailles, interlignes, marges, arrondis, ombres. Une capture oblige à mesurer à l’œil, et c’est là que naissent les écarts de deux pixels qu’on se renvoie ensuite pendant une semaine.

Dans le fichier, trois choses font la différence :

  • Des frames nommées. Accueil, Services, Article, Contact, plutôt que « Desktop copie 3 finale v2 ». Le nom de la frame devient le nom du gabarit, et un fichier bien nommé se lit sans réunion de cadrage.
  • Une page « à jour » identifiée. La plupart des fichiers contiennent des versions abandonnées et des variantes non retenues. Dites lesquelles font foi, sinon l’intégrateur risque de reprendre une piste écartée trois semaines plus tôt.
  • Des styles déclarés. Couleurs et typographies posées en styles Figma, plutôt qu’appliquées à la main. Un gris est alors le même gris partout, et ces styles deviennent directement les variables du thème.

Les sept états qu’on oublie toujours

Une maquette montre le site quand tout va bien. Le code doit gérer le reste, et le reste n’est presque jamais dessiné.

État Pourquoi il compte
Survol liens, boutons, cartes : le visiteur doit voir ce qui se clique
Focus clavier une obligation d’accessibilité, visible au clavier
Champ en erreur le message et sa place, sous le champ concerné
Confirmation d’envoi ce que voit le visiteur après avoir écrit
Liste vide aucun résultat, panier vide, catégorie sans article
Texte qui déborde un titre sur trois lignes, un nom de produit à rallonge
Menu mobile ouvert avec ses sous-niveaux

Ces sept états ne demandent pas sept écrans de plus : une frame qui les regroupe suffit. Sans eux, l’intégrateur décide à votre place, et ses choix n’apparaissent qu’à la recette.

Le responsive, dit plutôt que supposé

Deux maquettes, ordinateur et mobile, laissent une zone entière sans instruction : tout ce qui se passe entre les deux. Précisez à quelle largeur la grille change, ce que devient la navigation, et comment se réorganisent les blocs qui ne peuvent pas rester côte à côte. Une maquette tablette n’est pas toujours nécessaire : une phrase comme « à partir de 900 px, les trois colonnes passent sur deux » supprime un aller-retour.

Précisez aussi les images : format attendu, cadrage, et ce qui se passe quand le client en dépose une au mauvais format. C’est la question qui revient le plus souvent après la mise en ligne.

Le piège des polices

Une police utilisée dans une maquette n’est pas forcément utilisable sur un site : sa licence web est souvent distincte de la licence de bureau. Envoyez le nom exact de la police, sa licence web, les graisses réellement utilisées et les fichiers si vous les avez. Si la licence n’est pas réglée, dites-le : il existe presque toujours une police libre très proche.

Un fichier Figma bien rangé fait gagner plus de temps à une intégration que n’importe quel outil.

Les contraintes techniques, en cinq réponses courtes

  • Sur quoi intégrer. Thème dédié, éditeur de blocs de WordPress, ou le constructeur de pages imposé par l’agence. Le choix change la façon de découper.
  • Ce que le client modifiera seul. Un bloc éditable coûte plus cher qu’un bloc figé. Dire lesquels le sont évite de tout rendre modifiable, ce qui finit toujours par casser la mise en page.
  • L’hébergement, et s’il existe déjà.
  • L’existant à reprendre : adresses à conserver, contenus à migrer, redirections.
  • Les services connectés : outil d’emailing, réservation, paiement, statistiques.

Ce qu’il ne sert à rien d’envoyer

Les exports de code générés automatiquement depuis Figma : ils produisent un code inutilisable dans WordPress, et l’intégrateur repart du fichier. Les captures d’écran si le lien Figma est déjà fourni, et les couleurs recopiées à la main dans un document : deux sources finissent toujours par diverger, et le fichier doit rester la seule référence.

Le brief qui arrive en plusieurs fois

C’est le cas le plus courant en agence, et il ne pose aucun problème s’il est annoncé. Les maquettes sont prêtes, les contenus arriveront la semaine suivante, le client n’a pas encore choisi son hébergeur. Le chantier se lance quand même : les gabarits s’intègrent avec les contenus disponibles, et les manques sont listés dans le devis avec leur effet sur la date.

Le vrai coût vient d’un brief incomplet présenté comme complet. La production démarre, bute sur un manque, s’arrête, et redémarrer un chantier refroidi prend plus de temps que de l’avoir attendu. Dites simplement ce qui manque et quand ça arrivera.

Envoyer un brief