--- title: "Refonte Fernando Kylas : étude d'une phase de conception" description: "Étude historique de la version trois de mon site : relier compétences, choix de services et demande réfléchie, sans revendiquer de résultats mesurés." url: https://fkweb.dev/fr/articles/refonte-site-fernando-kylas/ lang: fr alternates: en: https://fkweb.dev/en/insights/fernando-kylas-website-rebuild/ fr: https://fkweb.dev/fr/articles/refonte-site-fernando-kylas/ nl: https://fkweb.dev/nl/inzichten/fernando-kylas-website-herbouw/ de: https://fkweb.dev/de/wissen/fernando-kylas-website-neuaufbau/ x-default: https://fkweb.dev/en/insights/fernando-kylas-website-rebuild/ --- 1. [Accueil](https://fkweb.dev/fr/) 2. [Articles](https://fkweb.dev/fr/articles/) 3. Un site enrichi par ajouts, repensé autour d'une décision # Un site enrichi par ajouts, repensé autour d'une décision Étude historique de la version trois de mon site : relier compétences, choix de services et demande réfléchie, sans revendiquer de résultats mesurés. Par [Fernando Kylas](https://fkweb.dev/fr/a-propos/)14 octobre 20269 min de lecture Mon site était arrivé à un point familier : il présentait de nombreuses compétences, mais leurs relations demandaient clarification. Design web, WordPress, SEO, hébergement, maintenance, performance et audits avaient leur place. Les présenter comme un ensemble de services disponibles laissait au visiteur la responsabilité de comprendre comment ils s’articulaient. La refonte a commencé par une autre question : que devait comprendre une personne avant de choisir un service ? La réponse a guidé le projet. J’aide les organisations à identifier le bon problème et choisir une réponse proportionnée. Le site devait rendre ce jugement visible, pas seulement montrer des capacités techniques. Cette étude examine la phase de planification et de prototypage de la version trois, documentée en 2026. Elle explique les raisons de cette phase, pas le plan actuel du site en ligne ni un lancement achevé. Des plans ultérieurs peuvent différer. Les bénéfices visés ne sont pas des gains mesurés de trafic, vitesse ou demandes. ## Quand les compétences organisaient le site La présentation antérieure introduisait design, SEO et hébergement avec des routes pour abonnements, maintenance, hébergement géré, conception, référencement et audits. Chaque élément correspondait à un travail possible. La difficulté était leur relation avec la pratique de conseil plus large que je souhaitais expliquer. Un visiteur pouvait reconnaître un service sans savoir s’il constituait le bon début. Une faible visibilité pouvait conduire directement au SEO alors que proposition ou structure de contenus demandaient d’abord attention. Une demande de refonte pouvait justifier un diagnostic avant remplacement. Le problème dépassait donc un menu chargé. La structure décrivait la disponibilité plus clairement que le raisonnement nécessaire au choix. Ajouter une explication ou une fonction pouvait augmenter l’information sans retirer cette responsabilité au visiteur. Le projet devait examiner la décision demandée, pas seulement réorganiser des intitulés. ## Donner une hiérarchie au jugement Le document d’expérience de conseil archivé définit une direction : présenter une activité de conseil en impact numérique, soutenue par les compétences de réalisation. Lorsque le problème est incertain, le diagnostic précède la planification ; lorsque le besoin est compris, la réalisation intervient. Le suivi protège ensuite le système. Cette séquence donnait un test pratique à la refonte. Le site pouvait-il aider une personne à reconnaître sa situation et comprendre une prochaine étape appropriée ? La réponse devait apparaître dans architecture et textes. Le visiteur ne devait pas tout déduire du seul titre de consultant, sans explication de ce qu’il change dans la relation. Les compétences techniques restaient importantes : WordPress, UX, SEO, performance et entretien appartenaient toujours au travail. Le changement concernait leur organisation et leur explication. Elles devaient soutenir un choix plutôt que rivaliser pour une attention égale. Cette distinction permettait de conserver l’expertise sans lui demander d’organiser toute l’expérience. ## Organiser autour de besoins reconnaissables Le registre du projet documente une décision d’août 2026 : organiser cette phase autour de trois gammes, sites WordPress, SEO et visibilité, et audits de sites. Elles fournissaient des entrées compréhensibles pour des situations différentes, tout en laissant les travaux sous-jacents liés lorsque cela était pertinent. La gamme WordPress accueillait création, refonte importante, migration, remise en état ou commerce électronique. La visibilité concernait découverte et difficultés techniques ou de performance liées. Les audits offraient un départ aux organisations voyant des symptômes mais ayant besoin de preuves avant de décider des corrections. La structure expliquait une orientation, pas encore un périmètre contractuel. Ces gammes ne supposaient pas que chaque problème appartient à une seule discipline. Elles devaient aider à commencer la conversation. La définition détaillée demandait encore du jugement. Le site pouvait guider sans prétendre que quelques clics remplaçaient la compréhension de l’organisation, de ses contraintes et de ce qu’elle cherchait réellement à améliorer. ## Donner un argument à la page d’accueil L’accueil prévu pour cette phase allait du point de départ à la reconnaissance du problème, aux gammes, au déroulement, aux standards, aux preuves et à ma présentation. Articles et invitation finale complétaient la séquence. La page obtenait un rôle narratif au-delà de l’exposition des travaux disponibles. L’ordre importait. Avant de faire choisir, il fallait expliquer la nature de l’aide. Avant de demander confiance, il fallait montrer standards et preuves. Ces questions recevaient une place plutôt que transformer les sections en décoration interchangeable. Chaque partie devait préparer suffisamment la compréhension de la suivante, sans exiger une lecture rigide de tout le site. Cela limitait aussi les ajouts. Une section proposée devait contribuer à la compréhension à cet endroit. Si elle répétait ou introduisait une priorité concurrente, sa place demandait justification. Une page pouvait être substantielle sans devenir un stockage de tout ce que l’activité souhaitait dire. ## Relier compétences et résultats attendus La gamme WordPress associait stratégie, UX, design, réalisation, fondations SEO, performance, formation et transmission dans un projet de site. Le visiteur n’avait pas à assembler lui-même les disciplines pour comprendre une réalisation réfléchie. L’organisation rendait leur relation plus lisible sans promettre un résultat chiffré automatique. La gamme visibilité permettait interventions ciblées et situations nécessitant plusieurs systèmes de découverte. Standards, limites, preuves et aide au choix faisaient partie du contenu prévu. Cette structure laissait expliquer valeur et frontières. Elle évitait de présenter toute demande comme une raison de commander systématiquement l’ensemble des travaux possibles. La frontière de l’audit était essentielle : il devait être utile seul et ne pas engager à la réalisation. Cela préservait le diagnostic. La recommandation devait tenir par ses preuves plutôt que dépendre de la vente du projet suivant. Le lecteur pouvait comprendre l’intérêt d’une investigation sans accepter par avance une refonte ou une autre mission. ## Préparer une demande réfléchie Le parcours de prototype documenté utilisait quatre étapes : explorer, choisir, compléter la configuration, puis relire et demander. Il présentait problème, périmètre, preuves et investissement indicatif, puis les routes selon la situation et les besoins complémentaires. La demande arrivait ensuite pour examen personnel, avec davantage de contexte sur l’intention du visiteur. Cette frontière commerciale était délibérée. Le parcours prévu n’était ni paiement ni devis engageant. Il aidait à exprimer une demande informée tout en conservant une conversation sur adéquation et périmètre. L’interface devait rendre cette différence claire au lieu de laisser sa présentation suggérer une transaction déjà conclue. La page de démarrage prévoyait résumé, questions de projet, orientation et explication de la suite. Le résultat souhaité était une meilleure conversation initiale. Son obtention devait être évaluée à l’usage, pas déduite de la présence d’un formulaire. Un processus bien expliqué reste une hypothèse à vérifier auprès des personnes qui l’utilisent. ## Donner une raison au travail complémentaire L’architecture enregistrée traitait les options complémentaires comme soutien d’une route, pas comme quatrième gamme égale. Entretien WordPress, analytique, suivi des conversions, revue des textes, architecture de contenus, stratégie et intégrations avaient une pertinence dépendant du projet et de ses fondations. Leur disponibilité ne suffisait pas à justifier leur sélection. Les règles indiquaient également aucune présélection des options payantes. Certaines demandaient audit, fondation vérifiée ou qualification technique. Ces détails comptaient : un parcours guidé peut sinon augmenter les coûts sans expliquer les besoins. La personne devait voir la raison d’une recommandation et pouvoir distinguer obligation réelle et possibilité facultative. Le principe était de fermer une lacune définie. Si l’entretien protège le projet, expliquer le lien. Si une intégration exige investigation, le préciser. Le soutien devait renforcer le résultat par une raison intelligible et un périmètre relu, pas par une inclusion supposée. La conversation gardait ainsi un rôle réel dans le choix final. ## Distinguer projets et articles La rubrique de réalisations proposée organisait projets choisis et résultats. Le modèle d’étude comprenait situation, diagnostic, décisions, travail, résultat et démonstration. Il permettait d’expliquer le raisonnement derrière un projet au lieu de compter uniquement sur des captures terminées. La preuve devait rester liée au travail particulier décrit. Les articles avaient une autre fonction : rendre une réflexion utile disponible avant une relation client. Contexte, réponse, conseils, étapes pratiques et lectures liées soutenaient un contenu permettant de progresser indépendamment. La valeur n’était pas seulement d’attirer une visite mais d’aider le lecteur à mieux comprendre une décision. Garder ces rôles distincts renforçait la cohérence. Une étude documente un projet ; un article explore un principe, comme les décisions derrière les problèmes de site. Ensemble, ils montrent manière de penser et application, sans transformer un principe général en résultat client non documenté. ## Tester la direction avant de figer la réalisation Le registre local documente un travail d’abord en HTML avant WordPress : planification des contenus et du SEO, prototypes, revue navigateur et système de design. Cette séquence permettait d’évaluer l’expérience avant de l’attacher entièrement à l’environnement éditorial final. Les documents montrent aussi le besoin de préserver intention narrative et composants approuvés. De petits changements répétés peuvent affaiblir la cohérence malgré une direction initiale solide. Un brief clair ne garantit pas automatiquement le résultat fini. Il faut pouvoir expliquer pourquoi une modification convient et ce qu’elle risque d’altérer ailleurs. Le processus rendait donc les décisions traçables. But de page, réflexion attendue du visiteur et prochaine action devaient survivre à la réalisation et aux revues. La leçon dépasse un outil : préserver le raisonnement qui rend la conception appropriée. Sinon, des améliorations locales peuvent finir par produire une expérience globale moins compréhensible. ## Garder un lancement proportionné Pour cette phase, le principe utile était un noyau cohérent plutôt qu’une bibliothèque complète mais mince. Les idées ultérieures devaient être séparées du positionnement, des contenus, du contact et des fondations nécessaires. Le plan de site ne devait pas devenir une obligation de tout publier immédiatement, indépendamment de la substance disponible. Une page mérite lancement lorsqu’elle a un rôle clair et assez de contenu pour le remplir. Sa présence dans un plan ne suffit pas. Pour un consultant, une page faible peut obscurcir le niveau du travail davantage qu’un sujet délibérément différé. La décision de garder une destination pour plus tard peut donc être une forme de rigueur. La même retenue concernait les fonctions. Le parcours de conseil documenté excluait le paiement des missions par checkout. La demande reposait sur évaluation et discussion. Préserver cette frontière évitait une complexité opérationnelle sans lien avec la relation souhaitée. La fonction devait soutenir l’engagement réel, pas reproduire un modèle transactionnel familier. ## Distinguer changement documenté et preuve attendue Le changement était architectural : cette phase reliait les compétences par trois gammes, une demande guidée et des rôles distincts pour preuve et pédagogie. La question organisatrice était devenue ce que le visiteur devait comprendre et décider. Cela décrit une direction de projet, pas une mesure de son efficacité. Choix mieux orientés, meilleur contexte et lien plus clair avec le conseil étaient des objectifs. Il fallait les tester par compréhension, qualité des demandes, parcours et retours une fois utilisés. Le récit ne leur attribue pas de résultat acquis. La distinction protège la valeur du cas en maintenant la portée exacte de ce qu’il démontre. Performance et entretien demandent leurs propres preuves. Un plan plus calme ne démontre ni téléchargement réduit ni interaction plus rapide. Mon article sur [les sites plus légers](https://fkweb.dev/fr/articles/site-plus-leger/) explique pourquoi résultats techniques et opérationnels doivent être évalués séparément de la direction stratégique. Les deux dimensions comptent sans être interchangeables. ## Organiser la décision avant les pages Le changement utile consistait à décider ce que le site devait aider à faire. Gammes, séquence, soutien et contact recevaient alors un objectif commun. Cela ne supprimait pas les détails du design, mais leur donnait une base. La cohérence venait de cette relation plutôt que d’une simple ressemblance entre les pages. Si votre site a grandi par ajouts, examinez le choix qu’il demande. Le visiteur dispose-t-il des informations nécessaires et d’un point de départ approprié ? La réponse peut montrer un changement plus important qu’une fonction ou un rafraîchissement visuel. Ce cas montre aussi pourquoi dater et délimiter un récit de refonte. Une décision utile ne reste pas forcément l’architecture finale. Préservez sa raison, jugez les évolutions selon le besoin réel et mesurez l’expérience séparément. C’est plus instructif que présenter un plan de site comme une réponse permanente. ## Services liés - [Création de site internet](https://fkweb.dev/fr/services/creation-site-internet/) - [Développement web](https://fkweb.dev/fr/services/developpement-web/) [Tous les articles](https://fkweb.dev/fr/articles/) Prochaine étape ## Un projet en tête ? Parlons-en. Dites-moi ce qui existe aujourd'hui et ce qui doit changer. Je réponds sous 2 jours ouvrés, en anglais ou en français. [Démarrer un projet](https://fkweb.dev/fr/contact/)Ou écrivez-moi directement [thatsme@fernandokylas.com](mailto:thatsme@fernandokylas.com)