Réutiliser une base technique ne signifie pas donner la même apparence à tous les clients. Pour une agence, Phoenix peut servir de socle commun tandis que chaque projet conserve son dossier de design, ses contenus et ses décisions visuelles.
La valeur de cette approche dépend de conventions partagées et de contrôles reproductibles, pas seulement d’une collection de fichiers.
Définir ce qui est commun
Commencez par les besoins récurrents : introduction, présentation, cartes, FAQ, navigation et appels à l’action. Vérifiez les contrats des composants et les fonctions déjà disponibles.
Le socle partagé peut comprendre les conventions de champs, les règles de lien, les traitements de formulaire et les pratiques de sécurité. Le dossier du design porte l’identité du projet et ses variantes de présentation.
Évitez de copier dans chaque design une version légèrement différente du même traitement métier. Une correction doit pouvoir être portée à son bon niveau, avec une version et une recette identifiables.
Garder une identité propre à chaque projet
Le choix des couleurs, de la typographie, des rythmes et des visuels appartient au contexte du client. Une grille de cartes commune peut produire des expériences différentes lorsque ces décisions sont cohérentes.
Ne créez pas une variante pour chaque différence mineure. Documentez plutôt les quelques options visuelles qui correspondent à de vrais usages : média à gauche ou à droite, présentation dense ou aérée, section avec ou sans image.
L’organisation du design permet de localiser ces décisions sans modifier le cœur pour chaque client.
Rendre le brief exploitable par l’équipe
Pour chaque page, indiquez son public, son action principale, ses contenus et sa source de données. Cette fiche réduit les interprétations entre la rédaction, le design et le développement.
Ajoutez les contraintes qui changent l’implémentation : multilingue, paiement, documents privés, rôles d’édition ou intégration métier. Un simple bouton peut cacher un parcours qui doit être cadré avant le devis et la réalisation.
Le brief Phoenix sert de base à cette discussion. L’IA peut aider à repérer les zones floues, mais les faits et les engagements restent validés par l’équipe.
Organiser les revues de code et de contenu
Une revue doit pouvoir associer le changement à un comportement observable. Demandez : quel fichier a changé, quelle donnée l’alimente, quels états ont été essayés et qui peut ensuite le modifier ?
Les points récurrents méritent une liste courte :
- Champs et fonctions existants utilisés avant d’en créer d’autres.
- Liens et valeurs échappés dans leur contexte.
- Contenus absents et textes longs pris en charge.
- Menus et coordonnées administrables.
- Rendu mobile, clavier et formulaires essayés.
- Assets déclarés et dépendances identifiées.
Ces contrôles doivent rester proportionnés au changement. Une retouche de couleur ne demande pas la même recette qu’un nouveau parcours de paiement.
Livrer avec un test d’autonomie
Confiez au client ou à un collègue trois modifications prévues dans le périmètre : remplacer une photo, ajouter une question et modifier un bouton. Observez les points où il cherche une instruction.
La documentation doit nommer les écrans et les champs réels. Une capture accompagnée d’une phrase précise peut être plus utile qu’un long manuel générique.
Conservez les accès administratifs, les responsabilités de sauvegarde et la procédure de retour arrière dans une documentation interne appropriée. Ils n’appartiennent pas à un ZIP public d’exemples.
Faire évoluer le socle à partir des projets
Après la livraison, notez ce qui a été répété, ce qui a surpris l’éditeur et ce qui a demandé une correction. Une amélioration du socle devrait répondre à plusieurs besoins observés, sans imposer une règle arbitraire à tous les designs.
Le test du relais complète cette méthode. L’objectif est de réutiliser des fondations utiles tout en gardant des sites compréhensibles et adaptés à leurs utilisateurs.
