Une maquette générée avec l’IA peut être convaincante à l’écran et difficile à maintenir une fois publiée. Les titres sont parfois inscrits dans le HTML, les boutons pointent vers des ancres temporaires et les sections ne correspondent pas aux contenus du backend.
Avec Phoenix, le travail consiste à transformer cette proposition visuelle en un ensemble de blocs administrables.
Faire l’inventaire de la maquette
Parcourez la page et nommez ses sections : introduction, présentation, bénéfices, étapes, questions et appel à l’action. Repérez les éléments répétés et les interactions réellement utiles.
Notez également les dépendances : polices, bibliothèques, icônes, images distantes et scripts. Une maquette peut charger plusieurs outils pour un effet que quelques lignes de CSS suffiraient à réaliser.
Conservez une capture comme référence, puis travaillez sur une copie. Le code généré doit pouvoir être comparé à son état initial pendant l’intégration.
Associer les sections aux blocs existants
Un hero de présentation peut alimenter hero.twig. Une série de bénéfices peut correspondre à features. Les questions fréquentes suivent faq et l’action finale utilise cta.
Maquette : titre + introduction + deux boutons → hero
Maquette : méthode et image → about
Maquette : trois cartes de bénéfices → features
Maquette : questions et réponses → faq
Maquette : invitation finale → cta
Vérifiez le schéma de champs avant de confirmer cette association. Si une section ne rentre pas correctement dans un contrat existant, demandez si elle représente un vrai besoin nouveau ou seulement une variation visuelle.
Une page de présentation ne justifie pas automatiquement un grand modèle PHP unique. Le guide de composition aide à conserver les blocs réutilisables.
Remplacer les valeurs fixes par leurs sources
Pour chaque titre et paragraphe, choisissez le champ qui l’alimente. Pour le logo, les coordonnées et les boutons globaux, utilisez les réglages Phoenix. Raccordez la navigation aux menus WordPress.
Les destinations doivent correspondre à de vraies pages ou à des URL externes validées. Supprimez les href="#" utilisés uniquement pour la démonstration lorsque l’action n’est pas encore disponible.
Les cartes et FAQ doivent accepter une liste éditable. Une boucle Twig explicite est préférable à trois copies de contenu qui ne peuvent évoluer qu’avec un développeur.
Isoler le style sans tout casser
Déplacez le CSS et le JavaScript utiles dans assets/, puis déclarez-les dans styles.json. Donnez aux classes un préfixe propre au design.
Évitez de conserver deux systèmes de grille ou deux bibliothèques de composants pour une seule page. Si le projet utilise déjà Bootstrap, décidez ce qui appartient à ce socle et ce qui relève du CSS personnalisé.
Testez les sections séparément avant de réunir toute la page. Une animation peut masquer un contenu absent pendant la revue ; vérifiez aussi le rendu sans mouvement et sans JavaScript lorsque la fonction ne l’exige pas.
Remplacer les données de démonstration
Une maquette peut inclure de faux avis, des logos de clients ou des compteurs sans source. Remplacez-les par des informations validées ou retirez-les.
Vérifiez les licences et les droits d’utilisation des visuels. Les images doivent être disponibles dans le projet, avec un texte alternatif approprié lorsqu’elles transmettent une information.
Le résultat doit raconter la vraie proposition de Phoenix : des composants réutilisables, un design isolé et une gestion des contenus à éprouver concrètement.
Réussir le test de modification
Ouvrez WordPress et changez un titre, une image, une carte et le bouton principal. La page doit conserver son apparence sans vous obliger à retoucher les fichiers.
Demandez ensuite à une autre personne d’effectuer ces changements. Les hésitations qu’elle rencontre indiquent les points de passation à améliorer.
La transformation est terminée lorsque vous avez conservé les qualités de la maquette et rendu ses contenus réellement administrables.
