Chargement… Loading…
Retour aux réalisations
Réalisations
Refonte d'un site corporate avec Next.js
Refonte complète du site vitrine d'une entreprise de commerce international, du builder Odoo vers une application Next.js moderne.
EntrepriseNext.jsReactGSAPTypeScriptTailwind CSS
Preuves visuelles
Captures et démonstrations issues des projets réels.
Hero vidéo et positionnement
Premier écran du site corporate, conçu autour d'un fond vidéo, d'un message clair et de CTA orientés distribution/création produit.
Mise en avant des marques partenaires
Section interactive avec logos de marques distribuées et animation GSAP draggable.
Preuves de distribution retail
Section de réassurance orientée partenaires retail et crédibilité commerciale.
Rendu local du hero
Capture générée depuis le site corporate monté en local pour vérifier le rendu réel.
Audit Lighthouse du site
Score mesuré lors de l'audit : 99 performance, 100 accessibilité, 96 bonnes pratiques.
01
Présentation
Un site vitrine destiné aux clients professionnels.
Le site corporate de 1UP Distribution a pour rôle de présenter l'entreprise, son activité et sa capacité à accompagner des partenaires commerciaux. Un site corporate n'est pas une boutique en ligne : il expose le positionnement, les services, les marques et les éléments de confiance qui permettent de comprendre l'organisation. Le public principal est constitué de clients professionnels, c'est-à-dire d'entreprises susceptibles de travailler avec 1UP plutôt que de consommateurs achetant directement un produit. Le site doit également contribuer à attirer de nouveaux partenaires en leur donnant une vision claire et crédible de l'entreprise.
Un ancien site construit avec le builder d'Odoo 16.
La version précédente avait été réalisée avec le constructeur de sites intégré à Odoo. Un website builder est un outil visuel permettant d'assembler des pages à partir de blocs sans développer toute l'interface dans le code. Cette solution facilite la création rapide d'un site lié à l'écosystème Odoo, mais elle ne répondait plus au niveau de liberté recherché pour cette refonte. Le projet avait besoin d'un contrôle plus fin sur la structure des pages, les animations, l'affichage sur les différents écrans et l'évolution future du code.
Une image visuelle devenue vieillissante.
Le premier écart concernait le design. L'apparence générale ne correspondait plus au niveau d'image que l'entreprise souhaitait présenter à des interlocuteurs professionnels. Le problème n'était pas uniquement esthétique : la qualité perçue d'un site influence la confiance accordée aux informations qu'il présente. Une interface datée pouvait laisser penser que l'entreprise, ses services ou sa manière de communiquer n'avaient pas évolué. La refonte devait donc produire une présentation plus actuelle sans transformer le site en démonstration graphique déconnectée de l'activité réelle.
Un message qui ne décrivait plus correctement l'entreprise.
Le contenu de l'ancien site ne reflétait plus fidèlement la réalité de 1UP Distribution. L'entreprise et son positionnement avaient évolué, tandis que les textes et la hiérarchie des informations étaient restés attachés à une représentation antérieure. Un visiteur professionnel pouvait donc comprendre imparfaitement l'activité ou ne pas identifier les raisons de prendre contact. La refonte devait aligner le message, les visuels et les preuves présentées avec ce que l'entreprise est aujourd'hui.
Un affichage mobile insuffisant.
L'ancien site s'affichait mal sur les téléphones. Le responsive design désigne la capacité d'une interface à adapter sa mise en page, ses textes, ses images et ses zones interactives à la largeur de l'écran. Il ne suffit pas de réduire une page conçue pour un ordinateur : les blocs doivent se réorganiser, les boutons rester utilisables et les contenus importants conserver une hiérarchie lisible. Ce défaut pouvait dégrader l'expérience d'un prospect consultant le site depuis un appareil mobile et affaiblir la première impression donnée par l'entreprise.
Une visibilité insuffisante dans les moteurs de recherche.
Lorsqu'une personne recherchait le nom de l'entreprise, le site apparaissait après d'autres organisations portant un nom similaire. Le référencement naturel, ou SEO, regroupe les pratiques qui aident les moteurs de recherche à comprendre une page et à la proposer pour les requêtes pertinentes. Le constat initial portait donc sur une difficulté très concrète : l'identité numérique de 1UP Distribution n'était pas assez visible ni assez différenciée. La refonte devait fournir une base plus claire pour présenter le bon contenu, structurer les pages et renforcer progressivement cette présence.
Une administration devenue trop contrainte.
Faire évoluer l'ancien site avec le builder Odoo était jugé difficile et peu adapté aux ambitions du projet. Les limites ne concernaient pas seulement la modification d'un texte : chaque évolution visuelle ou comportement spécifique devait rester dans le cadre prévu par l'outil. Ce fonctionnement réduisait la liberté de conception et rendait plus coûteuse la création d'une expérience réellement sur mesure. La décision de changer de socle technique répondait donc à un besoin de maîtrise à long terme autant qu'à une volonté de modernisation immédiate.
Une initiative portée avec le directeur général.
Le projet a été lancé conjointement avec le directeur général. J'ai personnellement porté l'idée de la refonte, car je considérais que l'ancien site ne représentait plus correctement l'entreprise et qu'il devenait dommageable de le conserver en l'état. Cette démarche montre une posture proactive : la demande n'est pas arrivée sous la forme d'un cahier des charges technique déjà défini. J'ai identifié le problème, défendu l'intérêt du changement puis pris en charge sa traduction en projet réalisable avec la direction.
Next.js comme nouveau socle technique.
J'ai retenu Next.js, un framework fondé sur React pour construire des applications web. Un framework fournit une architecture, des conventions et des outils communs afin de ne pas reconstruire les fondations à chaque page. Par rapport au builder précédent, cette solution offre une liberté complète sur les composants, la navigation, les animations, le responsive design et les optimisations. Le choix ne consistait donc pas seulement à employer une technologie plus récente : il permettait de maîtriser précisément le code et d'adapter le site aux besoins graphiques et marketing plutôt qu'aux limites d'un éditeur visuel.
Un lancement bilingue plutôt que treize langues.
Une première hypothèse envisageait un nombre beaucoup plus important de langues, mais le périmètre a été réduit pour la première livraison. Le site sortira d'abord en français et en anglais. Une locale désigne la combinaison de langue et de conventions utilisée pour afficher un contenu adapté à un public. Le bilinguisme permet déjà de présenter l'entreprise à une audience plus large tout en limitant le volume de textes à produire, relire et maintenir avant la mise en ligne. D'autres langues pourront être envisagées plus tard si leur valeur commerciale justifie cet effort.
Une première version concentrée sur l'essentiel.
Les deux pages indispensables identifiées au démarrage sont la page d'accueil et la page de contact. La page d'accueil doit expliquer rapidement qui est l'entreprise, ce qu'elle fait et pourquoi un professionnel pourrait travailler avec elle. La page de contact doit transformer cet intérêt en prise de relation. Ce périmètre évite de retarder la première livraison en multipliant les pages secondaires avant d'avoir validé le message principal et le parcours conduisant un visiteur vers l'entreprise.
Une conception graphique produite par les spécialistes de l'entreprise.
Les maquettes et la direction visuelle ont été préparées par les graphistes et designers internes. Mon rôle n'était donc pas de m'attribuer leur travail, mais de transformer leurs propositions en une interface web fidèle, responsive et performante. Cette distinction est importante : un visuel statique décrit une intention, tandis que l'intégration doit déterminer comment les composants réagissent aux différentes tailles d'écran, comment les animations s'enchaînent et comment l'ensemble reste accessible et maintenable.
Des contenus répartis entre marketing et direction.
L'équipe marketing était responsable de la production des textes. Le directeur de cette équipe ainsi que le directeur général validaient le contenu et l'image générale renvoyée par le site. Ce partage des rôles garantit que la communication correspond à la stratégie de l'entreprise et que les affirmations présentées peuvent être assumées. De mon côté, je devais signaler les contraintes du support web, proposer une organisation lisible et coordonner l'intégration des contenus dans les composants prévus.
Une utilisation des marques soumise à leur accord.
Le site présente des marques avec lesquelles l'entreprise travaille. Leur logo, leurs produits ou leurs visuels ne peuvent pas être considérés comme de simples ressources décoratives librement utilisables. Leur apparition doit être couverte par l'accord des marques concernées et respecter l'image qu'elles autorisent. Cette contrainte implique de coordonner les contenus disponibles, de vérifier ce qui peut être publié et de ne pas concevoir une section impossible à alimenter légalement ou commercialement.
Une séparation volontaire avec l'ERP.
Le site corporate n'affiche pas de catalogue destiné à la vente et n'a donc pas besoin de lire les produits, les stocks ou les commandes d'Odoo. Il est conçu comme une application indépendante de l'ERP, ce qui réduit les dépendances techniques et évite de connecter deux systèmes sans bénéfice métier. Une intégration reste envisagée pour la réception des demandes du formulaire de contact. Dans ce cas précis, la connexion aurait un objectif identifiable : transmettre automatiquement une prise de contact vers l'outil utilisé par l'entreprise pour la traiter.
Un rôle de responsable technique et de coordinateur.
J'assure seul la responsabilité du développement, mais le projet reste collectif. En tant que responsable technique, je choisis l'architecture, transforme les maquettes en composants, veille aux performances et organise la réalisation. En tant que coordinateur, je fais circuler les besoins entre les graphistes, le marketing, le directeur marketing et le directeur général, puis je signale les décisions ou contenus nécessaires pour avancer. Cette position relie la vision de l'entreprise, la conception graphique et la construction concrète du site.
02
Objectifs, contexte et enjeux
Moderniser en priorité l'image de l'entreprise.
La refonte poursuit plusieurs objectifs, mais la modernisation constitue la priorité. Le site doit donner une image cohérente avec l'entreprise actuelle dès le premier contact numérique. Cette modernisation ne se limite pas à remplacer des couleurs ou des polices : elle concerne la hiérarchie de l'information, le rythme des pages, la qualité de l'intégration et la manière dont les activités sont expliquées. Le référencement, l'attraction de partenaires et la génération de contacts restent importants, mais ils reposent d'abord sur une présentation crédible et contemporaine.
Faire comprendre le double métier dès le premier écran.
Dans les premières secondes, un visiteur doit comprendre le rôle de 1UP Distribution et la nature de son activité. L'entreprise intervient dans la distribution, c'est-à-dire la mise à disposition de produits auprès de réseaux professionnels, mais aussi dans la création de produits liés à la pop culture, aux objets de collection et aux accessoires de jeux vidéo. Un collectible est un produit conçu pour être collectionné, par exemple autour d'une licence ou d'un univers culturel. Le message d'accueil doit rendre ce positionnement immédiatement lisible sans exiger que le visiteur parcoure plusieurs pages.
Transformer la visite en prise de contact.
L'action principale recherchée est le contact avec l'entreprise. Les contenus, les preuves de partenariat et la présentation des activités doivent conduire le visiteur vers ce point de conversion. Une conversion désigne l'action utile accomplie après une visite, ici l'envoi d'une demande professionnelle. Le site n'a donc pas pour objectif de retenir artificiellement l'utilisateur avec des animations : il doit répondre à ses premières questions, instaurer suffisamment de confiance puis lui indiquer clairement comment entrer en relation avec l'équipe.
Attirer des interlocuteurs B2B pertinents.
Les nouveaux contacts recherchés appartiennent au marché B2B, ou Business to Business, dans lequel une entreprise vend ou collabore avec d'autres entreprises. Il peut notamment s'agir de distributeurs et de retailers. Un distributeur organise la mise à disposition de produits dans un réseau commercial ; un retailer, ou détaillant, les commercialise auprès du client final dans des magasins physiques ou en ligne. Le site doit employer un vocabulaire, des exemples et un niveau de preuve adaptés à ces professionnels plutôt qu'à un consommateur individuel.
Évaluer la qualité des contacts plutôt que leur seul nombre.
La pertinence de la nouvelle image pourra être observée à travers le profil des entreprises qui prennent contact. Si les demandes proviennent d'organisations comparables aux clients et partenaires que 1UP accompagne déjà, le site aura mieux transmis son positionnement. Cet indicateur reste qualitatif au lancement : il ne fixe pas encore un volume cible de formulaires. Il permet néanmoins de distinguer une hausse de trafic peu utile d'une visibilité qui attire réellement le public professionnel recherché.
Préserver le design sans dégrader l'expérience mobile.
L'objectif responsive consiste à conserver autant que possible les intentions des maquettes sur ordinateur, tablette et téléphone. Certains éléments peuvent toutefois devoir changer de taille, de disposition ou de comportement pour rester lisibles et faciles à utiliser. L'expérience utilisateur, ou UX, prime lorsqu'un choix graphique gêne la compréhension, ralentit une interaction ou occupe trop d'espace sur un petit écran. Le résultat attendu n'est donc ni une copie réduite de la version ordinateur ni une version mobile appauvrie, mais une adaptation qui maintient l'identité visuelle sans créer de friction.
Faire ressortir 1UP Distribution sur la recherche de sa propre marque.
Le principal objectif de référencement est que le site apparaisse avant les entreprises portant un nom similaire lorsqu'un utilisateur recherche précisément « 1UP Distribution ». Cette requête correspond à une intention de navigation : la personne connaît déjà le nom et cherche la bonne organisation. Le site doit aider les moteurs de recherche à l'identifier grâce à un contenu explicite, des titres cohérents, des métadonnées adaptées et une structure technique accessible. L'amélioration dépendra ensuite du temps d'indexation et de la concurrence ; elle ne peut pas être garantie uniquement par le déploiement.
Conserver un niveau élevé de performance.
Un audit Lighthouse réalisé pendant le développement a produit des scores de 99 sur 100 en performance, 100 en accessibilité et 96 en bonnes pratiques. Lighthouse est un outil d'audit automatisé qui analyse une page selon plusieurs critères techniques. Ces résultats constituent une référence à maintenir au moment de la mise en ligne, plutôt qu'une preuve définitive obtenue sur la future production. Ils devront être contrôlés de nouveau avec le domaine, l'hébergement, les ressources et les contenus définitifs, car ces éléments peuvent modifier les performances observées.
Ne publier que des informations commerciales validées.
Les statistiques qui figuraient dans certaines maquettes étaient du texte factice destiné à tester la composition visuelle. Elles ne doivent pas être utilisées comme preuves dans le portfolio ni publiées sur le site tant qu'elles ne sont pas vérifiées. Un dummy text est un contenu provisoire qui occupe l'espace d'un futur texte pendant la conception. L'objectif est donc de séparer clairement les données réelles des éléments de démonstration et de faire valider chaque affirmation commerciale par le marketing et la direction avant la mise en ligne.
Structurer la page d'accueil autour de trois contenus essentiels.
Pour être considérée comme complète, la page d'accueil doit présenter l'entreprise, ses partenaires et ses activités. La présentation répond à la question « qui sommes-nous ? » ; les activités expliquent la distribution et la création de produits ; les partenaires apportent des éléments de confiance concrets, sous réserve de leur autorisation. Ces trois ensembles doivent former un récit cohérent conduisant vers le contact, plutôt qu'une juxtaposition de sections indépendantes.
Construire un formulaire de contact suffisamment précis.
Le formulaire doit recueillir l'objet de la demande, un message libre, l'adresse électronique, le nom et le prénom. Le numéro de téléphone reste facultatif afin de laisser au visiteur le choix du canal de réponse. Chaque champ doit servir au traitement de la demande sans imposer inutilement une information personnelle. L'objectif fonctionnel est de fournir à l'équipe assez de contexte pour comprendre qui contacte l'entreprise et pourquoi, tout en gardant le parcours court.
Déterminer le circuit de réception avant la mise en ligne.
La personne ou l'équipe qui recevra les demandes n'est pas encore définitivement choisie. Ce point fait partie des décisions restant à prendre avant la première livraison. Le formulaire ne sera réellement opérationnel que si chaque message arrive dans une boîte ou un outil surveillé, avec une responsabilité claire pour le lire et y répondre. L'éventuelle transmission vers Odoo pourra être évaluée à partir de ce circuit, mais elle ne doit pas retarder le formulaire si un envoi plus simple répond d'abord au besoin.
Préparer une première mise en production pendant l'été 2026.
La période visée pour le lancement est l'été 2026. Cette échéance donne un cadre au projet sans imposer de multiplier les fonctionnalités avant la sortie. Le périmètre bilingue, la priorité donnée à l'accueil et au contact ainsi que la validation progressive des textes permettent de concentrer l'effort sur une première version réellement présentable. Les contenus ou pages non indispensables peuvent être ajoutés après cette mise en ligne plutôt que de bloquer l'ensemble.
Obtenir une validation éditoriale et visuelle explicite.
Pour le directeur général et le directeur marketing, le site pourra être validé lorsque les textes définitifs auront été approuvés et que le design aura été intégré d'une manière qui correspond à l'image recherchée. Cette validation réunit deux dimensions différentes : l'exactitude du message et la fidélité de sa réalisation visuelle. Un site techniquement rapide mais porteur d'un texte non validé ne serait pas prêt ; de même, une maquette approuvée mais mal adaptée au navigateur ou au mobile ne satisferait pas le besoin.
Réunir modernité, visibilité et efficacité commerciale.
L'objectif global est de construire une présence numérique moderne qui explique correctement le métier, fonctionne sur tous les écrans, améliore progressivement la visibilité de la marque et facilite les prises de contact B2B. Aucun de ces résultats ne doit être obtenu au détriment des autres. Une animation qui dégrade l'UX, un texte optimisé pour les moteurs mais peu naturel pour les visiteurs ou un formulaire sans responsable de traitement iraient à l'encontre du projet. La réussite repose donc sur l'équilibre entre image, technique et usage commercial.
03
Risques et mesures de maîtrise
Un design encore incomplet comme risque principal.
Le premier risque pour la sortie prévue pendant l'été 2026 est que la conception graphique ne soit pas entièrement achevée. Tant que certaines maquettes, variantes responsive ou décisions visuelles restent ouvertes, je ne peux pas finaliser l'intégration correspondante. Développer trop tôt une section encore instable ferait perdre du temps si sa structure change ensuite ; attendre toutes les décisions peut au contraire retarder l'ensemble. La maîtrise de ce risque passe par la priorisation des écrans indispensables à la V1 et par une validation progressive des blocs déjà suffisamment définis.
La validation éditoriale comme goulot d'étranglement.
Les textes et leur approbation par le marketing et la direction constituent le principal bottleneck du projet. Un bottleneck, ou goulot d'étranglement, est l'étape dont la capacité ou la vitesse limite l'avancement de tout le reste. Une page peut être techniquement prête tout en restant impossible à publier si son message n'est pas validé. Ce risque impose de rendre visibles les contenus manquants, de soumettre les textes suffisamment tôt et de distinguer ce qui bloque réellement la mise en ligne de ce qui pourra être amélioré après la première version.
Des visuels de marque dépendants d'une autorisation.
Une marque peut refuser que son logo, ses produits ou ses visuels apparaissent sur le site. Dans ce cas, l'entreprise ne les publiera pas et utilisera d'autres partenaires disposant d'une autorisation. Le risque n'est donc pas de bloquer tout le projet, mais de devoir adapter une section ou sa composition lorsque le contenu prévu devient indisponible. Les maquettes doivent rester suffisamment flexibles pour remplacer un élément sans reconstruire le composant complet, et la validation des droits doit intervenir avant la publication définitive des ressources.
La publication accidentelle d'un contenu factice.
Les maquettes peuvent contenir des chiffres, noms ou textes provisoires destinés à tester la mise en page. S'ils sont confondus avec des informations réelles, le site pourrait publier une affirmation fausse et porter atteinte à la crédibilité de l'entreprise. Pour limiter ce risque, chaque contenu est contrôlé une seconde fois avec l'équipe responsable de la validation des textes. Les valeurs provisoires doivent également être identifiables pendant le développement afin que la revue ne repose pas uniquement sur la mémoire des participants.
Un périmètre V1 protégé de l'ajout continu de fonctionnalités.
L'augmentation incontrôlée du périmètre, parfois appelée scope creep, peut retarder une livraison en ajoutant de nouvelles exigences pendant sa réalisation. Ce risque est limité par une décision claire : les fonctions supplémentaires feront l'objet d'une V2 distincte. La première version reste concentrée sur l'accueil, le contact, le bilinguisme et les contenus nécessaires à la validation. Cette séparation permet d'enregistrer les bonnes idées sans les laisser remettre en cause la date de sortie de la version initiale.
Une adaptation mobile complexe pour les éléments graphiques riches.
Les animations, le motion design et les grands éléments placés en arrière-plan sont les contenus les plus difficiles à transposer sur un petit écran. Le motion design utilise le mouvement pour donner du rythme ou expliquer une transition visuelle. Une composition efficace sur ordinateur peut masquer un texte, occuper trop d'espace ou perdre son sens lorsqu'elle est réduite. La réponse consiste à adapter la taille, la position ou le comportement de ces éléments et, lorsque nécessaire, à en simplifier certains pour protéger la lisibilité et l'interaction.
Des performances dépendantes de la quantité d'animations.
Le hero vidéo, les carrousels et les animations GSAP ne sont pas considérés comme un problème tant que leur nombre et leur coût restent maîtrisés. Le risque apparaît lorsque trop d'effets s'exécutent simultanément, chargent des ressources volumineuses ou sollicitent continuellement le navigateur. Une page peut obtenir un bon score avec un contenu provisoire puis ralentir lorsque les médias définitifs sont ajoutés. Les effets doivent donc rester au service du message, les ressources être optimisées et les mesures Lighthouse répétées avec la version réellement destinée à la mise en ligne.
Une prise en charge des animations réduites encore hétérogène.
Le dépôt contient déjà une première prise en charge de la préférence système prefers-reduced-motion : certains composants Motion désactivent leurs effets, certaines vidéos utilisent une image fixe de remplacement et un test Playwright vérifie ce comportement sur une partie des pages corporate. Cette couverture n'est toutefois pas encore uniforme pour toutes les animations historiques, notamment celles pilotées directement par GSAP, les transitions et le défilement Lenis. La V2 devra harmoniser ces mécanismes et prévoir un comportement plus léger pour les appareils peu puissants ou les connexions lentes. Dans l'intervalle, aucune information essentielle ne doit dépendre uniquement d'un mouvement.
Des risques d'accessibilité liés aux animations et aux contrastes.
Le design final peut produire un contraste insuffisant entre un texte et son arrière-plan, en particulier lorsqu'un texte se superpose à une vidéo ou à un grand visuel. Les animations peuvent également distraire, rendre la lecture difficile ou modifier trop rapidement une interface. Les scores automatisés constituent un premier contrôle, mais ils ne remplacent pas une vérification visuelle des contrastes, de la lisibilité et du parcours au clavier. Toute décision graphique finale devra être confrontée à ces usages avant validation.
Une migration susceptible d'affecter le référencement.
Le remplacement de l'ancien site peut faire perdre une partie de la visibilité déjà acquise si des pages disparaissent, si leurs adresses changent sans redirection ou si les moteurs rencontrent temporairement une version non indexable. Une redirection permanente indique aux visiteurs et aux moteurs qu'une ancienne URL a été déplacée vers une nouvelle. Avant la bascule, il faudra donc inventorier les URL utiles, conserver celles qui peuvent l'être, rediriger celles qui changent, publier un sitemap cohérent et vérifier que les règles temporaires de blocage utilisées pendant le développement ne restent pas actives.
Une cohérence bilingue dépendante du marketing.
L'équipe marketing produit et valide les versions française et anglaise. Le risque n'est pas seulement une faute de traduction : deux langues peuvent finir par présenter des offres, des chiffres ou des appels à l'action différents lorsque l'une est modifiée sans l'autre. Les contenus doivent donc être suivis comme deux versions du même message et validés ensemble avant chaque publication importante. Une clé de traduction manquante ou un texte resté en français dans la page anglaise doit également être détecté pendant les tests.
Plusieurs risques concentrés dans le formulaire de contact.
Le formulaire peut recevoir du spam, perdre un message lors d'une erreur, envoyer la demande vers une mauvaise adresse, exposer des données personnelles ou dépendre d'un service d'envoi momentanément indisponible. Ces risques couvrent à la fois la sécurité, la confidentialité et la continuité du parcours commercial. La mise en œuvre devra donc contrôler les données reçues, limiter les soumissions automatisées, transmettre les messages par un canal protégé, afficher un résultat compréhensible à l'utilisateur et journaliser suffisamment les erreurs pour qu'une demande non remise puisse être diagnostiquée sans exposer son contenu inutilement.
Un destinataire encore inconnu, mais pas un blocage actuel.
La destination finale des formulaires n'est pas encore connue, car cette décision doit être prise avec les responsables concernés. Ce manque d'information ne ralentit pas actuellement le développement de l'interface et de la validation des champs. Il deviendra néanmoins un critère obligatoire avant la mise en production : une adresse, une boîte partagée ou un outil devra être choisi, testé et associé à une personne responsable du traitement. Le sujet est donc une décision en attente plutôt qu'un risque majeur du projet.
Un retour possible vers l'ancien site en cas d'échec de la bascule.
Si le nouveau site rencontre un problème important au moment de sa mise en ligne, l'ancien site peut rester disponible ou être rétabli. Ce rollback, ou retour arrière, limite le temps pendant lequel l'entreprise risquerait de ne plus disposer d'aucune présence fonctionnelle. Cette possibilité doit être préparée en conservant l'ancienne version et les paramètres nécessaires à son exploitation jusqu'à ce que le nouveau site soit validé dans ses conditions réelles. Elle ne dispense pas de tester la nouvelle version, mais elle réduit l'impact d'un défaut critique découvert trop tard.
Une dépendance future envers un seul responsable technique.
Je suis actuellement le seul développeur du projet. Cette organisation accélère certaines décisions, mais elle crée un risque si aucun autre développeur n'est disponible pour reprendre la maintenance. Une évolution, un incident ou une mise à jour de dépendance pourrait alors attendre mon intervention. La réduction de ce risque passe par un code structuré, un historique de version clair, une documentation de l'installation et du déploiement ainsi que des choix suffisamment standards pour permettre une reprise sans devoir comprendre chaque décision uniquement par échange oral.
Une future connexion à Odoo à traiter comme un périmètre sensible.
La transmission des formulaires vers Odoo créerait une dépendance supplémentaire entre le site public et l'ERP interne. Elle devrait vérifier l'identité du service appelant, limiter les droits accordés, valider toutes les données reçues et gérer l'indisponibilité temporaire d'Odoo sans perdre silencieusement une demande. Cette intégration n'est pas nécessaire à la première version et devra être réalisée avec soin dans un périmètre séparé. Son bénéfice devra justifier l'exposition et la complexité ajoutées par rapport à un simple envoi vers une boîte surveillée.
04
Les étapes — ce que j'ai fait
Auditer l'existant avant de choisir la solution.
La première étape a été l'audit de l'ancien site. J'ai examiné son design, la manière dont il présentait l'entreprise, son comportement sur mobile, sa visibilité dans les moteurs de recherche et les limites rencontrées lors de ses évolutions avec le builder Odoo. Un audit consiste à observer l'état réel d'un système selon plusieurs critères afin de distinguer les symptômes des causes. Cette analyse m'a permis de justifier une refonte complète plutôt qu'une simple retouche graphique et de relier chaque choix technique à un problème identifié.
Formaliser le besoin dans un cahier des charges.
Les conclusions de l'audit ont été transformées en cahier des charges. Ce document sert de référence commune entre la direction, le marketing, les graphistes et le développement. Il décrit le résultat attendu, les fonctions à prévoir et les contraintes à respecter sans imposer nécessairement chaque détail d'implémentation. Cette étape évite que le projet repose uniquement sur des échanges oraux et permet de comparer les propositions de design ou les décisions techniques avec le besoin de départ.
Recevoir et analyser les maquettes Figma.
Les graphistes transmettaient les maquettes dans Figma, un outil collaboratif de conception d'interfaces. Les versions ordinateur, tablette et mobile étaient déjà représentées, ce qui donnait une intention claire pour les principaux formats. Mon travail consistait ensuite à analyser les espacements, les typographies, les couleurs, les composants répétés et les comportements implicites entre deux tailles d'écran. Une maquette ne décrit pas chaque largeur possible ni tous les états interactifs ; l'intégration devait donc prolonger les décisions des designers sans déformer leur intention.
Transformer trois maquettes en responsive continu.
Les variantes Figma servaient de points de référence, mais le site devait fonctionner sur toutes les dimensions intermédiaires. J'ai utilisé les classes responsive de Tailwind CSS pour faire évoluer les grilles, les marges, les tailles de texte et l'ordre des éléments selon les breakpoints. Un breakpoint est une largeur à partir de laquelle la mise en page adopte une nouvelle organisation. Je vérifiais également l'absence de débordement horizontal et créais des alternatives, comme le passage d'une frise complexe à des cartes empilées sur les écrans plus étroits.
Initialiser la stack à partir de la documentation.
Le projet a été démarré avec Next.js 16 et React 19 en suivant la documentation des outils retenus. J'ai utilisé l'App Router de Next.js, qui organise les pages et les layouts à partir de l'arborescence du dossier app. TypeScript apporte le typage du code, Tailwind CSS fournit les règles de mise en forme, et les bibliothèques spécialisées sont ajoutées uniquement pour un besoin identifié. La documentation m'a servi à comprendre les conventions officielles avant d'assembler la stack, plutôt que de reproduire une configuration sans en connaître les implications.
Construire un système de composants réutilisables.
Le code est séparé entre primitives d'interface, éléments de mise en page, sections de la page d'accueil, formulaires, composants corporate et providers globaux. Les primitives comprennent par exemple Button, Container, FadeIn, AnimatedText et les surfaces lumineuses GlowSurface. Les couleurs de marque, les couleurs sémantiques et les dimensions communes sont centralisées dans les variables CSS du design system. Cette organisation évite de redéfinir un bouton ou un conteneur dans chaque page et garantit que les améliorations d'accessibilité ou de style peuvent être appliquées à plusieurs usages depuis un même composant.
Séparer composants serveur et composants interactifs.
Les pages et les éléments qui ne nécessitent pas d'interaction restent des Server Components, c'est-à-dire des composants rendus côté serveur sans envoyer inutilement toute leur logique au navigateur. Les composants qui utilisent une animation, un formulaire ou un état local sont déclarés comme Client Components. Cette frontière est visible dans le dépôt : les pages récupèrent les contenus et métadonnées sur le serveur, tandis que Hero, BrandCarousel, FadeIn ou ContactForm prennent en charge les interactions côté client. Cette séparation réduit le JavaScript envoyé lorsqu'une interactivité n'est pas nécessaire.
Répartir les animations entre GSAP, Motion et Lenis.
GSAP est utilisé pour les séquences complexes, les révélations liées au défilement avec ScrollTrigger et les carrousels de logos manipulables avec Draggable. Le hero anime successivement le titre, le sous-titre et les appels à l'action ; certaines sections déclenchent leur apparition lorsqu'elles entrent dans la zone visible. Motion est utilisé pour des animations plus locales, comme les transitions de page et l'apparition de composants. Lenis pilote un défilement plus fluide. Cette répartition évite de demander à une seule bibliothèque de résoudre tous les besoins et permet de conserver des composants animés ciblés plutôt qu'une animation globale difficile à maîtriser.
Créer des interactions sans bloquer le contenu.
Les carrousels de marques et de retailers utilisent le plugin Draggable de GSAP. L'utilisateur peut déplacer un logo ; sa vitesse est calculée au relâchement, puis le logo poursuit brièvement son mouvement avant de revenir à sa position. Les révélations GSAP utilisent un scope limité au composant et les éléments restent visibles lorsque la préférence de réduction des mouvements est active. Les composants corporate plus récents utilisent aussi useReducedMotion pour supprimer des mouvements non essentiels. L'objectif est de produire une sensation de richesse visuelle sans rendre l'information dépendante de l'animation.
Intégrer les vidéos et images selon leur usage.
Le hero utilise une vidéo HTML en arrière-plan, muette, lancée automatiquement, répétée en boucle et compatible avec la lecture intégrée sur mobile. Un calque sombre améliore la lisibilité du texte et une piste de sous-titres est déclarée. Pour les images et logos, le projet utilise le composant Image de Next.js avec des dimensions ou des indications sizes adaptées aux différents écrans. Les visuels locaux sont notamment convertis en WebP. Les images provenant de Sanity sont générées avec une largeur cible et un format automatique. Certains composants vidéo plus récents chargent seulement les métadonnées et remplacent la vidéo par son poster lorsque l'utilisateur demande moins de mouvements.
Mettre en place une internationalisation centralisée.
Les routes utilisent un segment dynamique de langue et next-intl charge le fichier de messages correspondant. Les liens internes passent par une navigation consciente de la locale, le document HTML reçoit les attributs de langue et de direction, et les textes d'interface sont regroupés dans des fichiers JSON. Le code avait initialement été préparé pour treize locales. La décision produit est maintenant de limiter la V1 au français et à l'anglais ; la configuration de routage, les alternates, le sitemap et les données structurées devront être alignés sur ce nouveau périmètre avant la mise en ligne.
Organiser les contenus entre fichiers de traduction et Sanity.
Les textes stables de l'interface et de la page d'accueil sont actuellement lus avec next-intl depuis les fichiers de messages. Le projet intègre aussi Sanity, un CMS ou système de gestion de contenu, pour les articles, les carrières et des pages corporate plus éditoriales. Des schémas définissent les pages, sections, marques, FAQ, paramètres et métadonnées SEO ; les requêtes publiques excluent les contenus marqués comme placeholders. Les pages peuvent utiliser un texte de traduction comme solution de repli lorsqu'aucun contenu Sanity publié n'est disponible. Cette architecture doit permettre au marketing de faire évoluer les contenus structurés sans modifier directement le code.
Construire une base SEO technique.
Les pages définissent leurs titres, descriptions, URL canoniques et variantes linguistiques. Le site génère un sitemap, un fichier robots.txt et des données JSON-LD décrivant l'organisation, le site, les fils d'Ariane, les pages, les articles, les offres d'emploi ou les FAQ selon le contexte. JSON-LD est un format de données structurées qui aide les moteurs à comprendre la nature du contenu sans modifier sa présentation visuelle. La migration finale devra encore réduire ces informations au français et à l'anglais, vérifier les URL de l'ancien site et ajouter les redirections nécessaires.
Développer une première chaîne de contact fonctionnelle.
Le formulaire possède déjà une interface, des états d'envoi, de succès et d'erreur, ainsi qu'une case de consentement renvoyant vers la politique de confidentialité. Il transmet les données à une route API Next.js, qui vérifie les champs obligatoires et l'adresse électronique, neutralise les retours à la ligne dans l'objet puis envoie un courriel avec Resend et un modèle React Email. Le routage distingue actuellement le développement des demandes de production. Cette première version doit encore être alignée sur le besoin final : séparer nom et prénom, ajouter le téléphone optionnel, choisir définitivement les destinataires et compléter la protection contre les soumissions indésirables.
Tester les composants, l'API et les parcours réels.
Vitest et React Testing Library couvrent des composants et des fonctions isolées, tandis que Playwright exécute des scénarios de navigateur. La configuration Playwright prévoit Chromium, Firefox et WebKit ainsi que des profils Pixel 7, iPhone 13 et iPad. Les scénarios existants vérifient notamment l'accueil, la navigation, le formulaire, l'absence de débordement horizontal, le chargement des images, les données structurées et certains comportements de réduction des mouvements. Cette combinaison permet de détecter aussi bien une erreur de logique qu'une rupture visible uniquement dans un navigateur ou une largeur particulière.
Mesurer Lighthouse après chaque étape importante.
Je relance Lighthouse après les grandes étapes du projet et surtout après les modifications front-end. Cette fréquence permet d'identifier plus facilement la régression qui a fait baisser un score : ajout d'une image trop lourde, JavaScript supplémentaire, contraste dégradé ou élément mal structuré. L'audit n'est pas réservé à la fin, lorsqu'il serait plus difficile d'isoler l'origine du problème. Les scores actuels servent de référence, puis un nouvel audit devra être réalisé avec les contenus définitifs et les conditions réelles d'hébergement.
Préparer le déploiement sur Vercel sans enfermer le projet.
L'hébergement prévu est Vercel, une plateforme adaptée au déploiement des applications Next.js. Le dépôt indique qu'une mise à jour de la branche principale déclenche la production, ce qui transforme l'historique Git en source du déploiement. L'entreprise envisage toutefois de déplacer éventuellement le site vers l'un de ses serveurs dédiés. Le code et les variables d'environnement doivent donc rester documentés afin qu'un changement d'hébergeur ne demande pas de reconstruire l'application ni de perdre les services externes comme Sanity ou Resend.
Poursuivre par prototypes en attendant les contenus définitifs.
Le projet est actuellement dans une phase où j'attends les textes de l'équipe marketing tout en testant plusieurs prototypes de design front-end. Ce travail parallèle permet d'avancer sur les composants, les comportements responsive et les pistes visuelles sans présenter les textes provisoires comme validés. Avant la mise en production, il restera à sélectionner et terminer le design, intégrer les contenus approuvés, réduire le périmètre linguistique à deux langues, finaliser le formulaire, effectuer les validations marketing et direction puis rejouer les tests et audits sur la version candidate.
05
Les acteurs — les interactions
Une équipe resserrée aux responsabilités complémentaires.
Le projet réunit deux graphistes, le directeur de l'équipe marketing, le directeur général et moi-même en tant que responsable technique. Les graphistes conçoivent l'univers visuel et préparent les ressources nécessaires à l'intégration, l'équipe marketing porte le message de l'entreprise, la direction fixe le cap et je transforme ces choix en un site utilisable, performant et maintenable. Cette organisation distingue la responsabilité créative, la responsabilité éditoriale, la décision stratégique et la réalisation technique, tout en obligeant chaque acteur à confronter son travail aux contraintes des autres.
Deux graphistes chargés de préparer les ressources visuelles.
Les deux graphistes produisent les maquettes et les assets destinés à mon intégration. Un asset est une ressource visuelle prête à être utilisée dans le site, par exemple un logo, une image, une vidéo, une texture, une icône ou une composition graphique. Leur travail ne consiste donc pas seulement à proposer une intention générale : ils doivent aussi me transmettre des éléments exploitables dans les formats, dimensions et niveaux de qualité adaptés au Web. Je reste responsable de leur comportement réel dans la page, notamment selon la taille de l'écran, le temps de chargement et les possibilités d'interaction.
Le lead graphiste comme interlocuteur visuel principal.
Mon point de contact principal pour les maquettes est le lead graphiste, c'est-à-dire la personne qui coordonne la direction graphique et maintient la cohérence entre les différentes propositions visuelles. Je peux ainsi centraliser les questions portant sur les espacements, les proportions, les animations envisagées ou la priorité entre plusieurs éléments. Ce rôle évite que deux retours graphiques contradictoires soient appliqués directement dans le code sans décision commune.
Des itérations facilitées par la proximité de l'équipe.
Nous travaillons dans le même bureau. Plutôt que d'attendre une réunion formelle pour chaque détail, nous pouvons nous montrer régulièrement les avancées et itérer immédiatement. Une itération est un cycle court durant lequel une proposition est présentée, discutée, modifiée puis de nouveau vérifiée. Le graphiste peut constater le comportement concret de sa maquette dans un navigateur, tandis que je peux expliquer directement pourquoi un effet fonctionne différemment sur mobile ou pourquoi un élément trop lourd pénalise le chargement. Cette proximité réduit le délai entre l'identification d'un problème et sa correction.
Une responsabilité technique assumée de bout en bout.
Je suis seul responsable du développement et je prends les décisions concernant l'architecture, les composants, les bibliothèques, l'affichage responsive, les tests, le référencement technique et le déploiement. Je valide moi-même les adaptations nécessaires lorsque la maquette ne décrit pas précisément un écran ou un comportement. Cette autonomie ne signifie pas que je modifie librement l'intention graphique : elle signifie que je choisis le moyen technique le plus adapté pour la respecter sur les différents appareils sans dégrader l'expérience utilisateur.
Le directeur marketing comme référent éditorial.
Le directeur de l'équipe marketing est mon interlocuteur principal pour les textes et leur cohérence avec le positionnement de l'entreprise. Les contenus à produire, corriger ou valider sont suivis dans Jira. Jira est un outil de gestion de projet dans lequel chaque élément de travail peut être décrit dans un ticket, attribué, priorisé puis déplacé selon son état d'avancement. Cette formalisation est importante, car le code peut être prêt alors que le site ne peut pas être publié si un titre, une description d'activité ou un message commercial reste provisoire.
Une décision partagée lorsque le design rencontre une contrainte technique.
Lorsqu'une intention visuelle soulève un problème de performance, d'accessibilité ou de faisabilité, je recherche d'abord un accord avec le directeur marketing. J'expose l'effet attendu, la contrainte observée et les solutions possibles afin que la décision ne soit ni uniquement esthétique ni uniquement technique. Si nous ne parvenons pas à un compromis, le directeur général arbitre. Ce circuit permet de préserver l'image recherchée tout en rendant visibles les conséquences concrètes d'un choix sur l'utilisateur et sur le fonctionnement du site.
Les animations comme sujet concret de compromis.
Les animations rendent le site plus vivant et participent à son identité, mais leurs bibliothèques et leurs médias consomment des ressources : elles peuvent augmenter le JavaScript téléchargé, solliciter davantage le processeur graphique ou ralentir l'affichage sur un appareil moins puissant. Mon rôle consiste à trouver un juste milieu entre richesse visuelle et performance. Cela peut signifier limiter une animation aux éléments réellement importants, employer une transformation moins coûteuse, différer son chargement ou la simplifier sur mobile et pour les personnes demandant moins de mouvement. Je présente ces arbitrages aux responsables de l'image afin que l'allègement ne soit pas perçu comme une perte inexpliquée du design.
Une autonomie spécifique sur le responsive.
Les choix d'adaptation aux différentes tailles d'écran relèvent de ma responsabilité technique. Le responsive design consiste à faire évoluer la mise en page selon l'espace disponible afin de conserver un contenu lisible et des interactions utilisables sur ordinateur, tablette et téléphone. Lorsque la transposition exacte d'une composition desktop provoquerait un débordement, un texte illisible ou une navigation difficile, je peux réorganiser les blocs, réduire certains effets ou modifier leur ordre. Je contrôle ensuite que cette adaptation reste fidèle à la hiérarchie visuelle définie avec les graphistes.
L'équipe marketing responsable des droits liés aux marques.
Le site doit présenter des marques partenaires, mais leur présence publique ne dépend pas seulement de la possibilité technique d'afficher leur logo. L'équipe marketing vérifie et obtient les autorisations nécessaires pour employer les noms, logos et visuels concernés. De mon côté, je n'intègre dans la version publiable que les ressources dont l'utilisation a été confirmée. Si une autorisation manque, la marque est retirée ou remplacée plutôt que présentée comme un partenaire sans validation.
Le directeur général comme responsable du cap et de la validation.
Le directeur général intervient sur l'orientation du projet, sa priorisation et sa validation. Il confirme que le site sert bien la stratégie de l'entreprise, décide de l'importance du travail par rapport aux autres projets et tranche lorsqu'une décision dépasse le périmètre technique ou marketing. Il donne également l'autorisation finale de mise en production. Le passage en ligne n'est donc pas déclenché par la seule fin du développement : il correspond à une décision de l'entreprise engageant publiquement son image.
La maîtrise de l'infrastructure et du déploiement.
Je gère le nom de domaine, sa configuration DNS, Vercel et plus largement les décisions techniques liées à l'hébergement. Le DNS, ou système de noms de domaine, associe l'adresse lisible du site au service qui doit répondre aux visiteurs. Vercel construit et héberge actuellement l'application à partir du dépôt de code. Cette responsabilité me permet de relier la mise en production à une version précise et testée, tout en préparant la possibilité d'un futur hébergement sur un serveur dédié de l'entreprise.
Une chaîne de contact partagée entre technique et métier.
Je construis le formulaire, sa validation, l'envoi technique et les états affichés à l'utilisateur. En revanche, l'équipe marketing ou le directeur général doit déterminer les personnes qui recevront effectivement les demandes, car ce choix dépend de l'organisation commerciale et non du code. Cette séparation évite que je déduise seul le circuit de traitement d'un prospect. Une fois les destinataires décidés, je peux configurer l'acheminement, vérifier la réception et documenter la manière de modifier ce routage.
Des prototypes présentés lorsqu'ils permettent une décision réelle.
Je montre une nouvelle proposition aux acteurs du projet dès qu'elle est suffisamment crédible pour qu'ils puissent se projeter dans le résultat. Un prototype crédible ne doit pas nécessairement être terminé, mais il doit représenter correctement la structure, l'intention visuelle et les principales interactions. Le retour porte alors sur une expérience concrète plutôt que sur une explication abstraite. Après validation, les décisions et le travail restant sont suivis dans les tickets afin d'éviter de perdre les ajustements formulés oralement.
Une validation proportionnée à la portée de chaque décision.
Je décide de manière autonome pour les sujets strictement techniques, par exemple la structure d'un composant, l'organisation du code ou le traitement d'un comportement responsive. Dès qu'un choix modifie l'image, le discours ou la perception publique de l'entreprise, je le fais valider. Cette limite me laisse la liberté nécessaire pour développer efficacement tout en évitant qu'une préférence technique personnelle devienne, sans discussion, une décision de communication pour l'entreprise.
Une répartition prévue pour l'après-lancement.
Après la mise en ligne, l'équipe marketing mettra à jour les contenus éditoriaux au moyen de Sanity, le système de gestion de contenu du site, tandis que je resterai responsable de la maintenance du code. Cette séparation permet au marketing de publier ou corriger un contenu structuré sans modifier l'application. Je continuerai à prendre en charge les évolutions techniques, les incidents, les dépendances et les déploiements. Le directeur général conserve la décision finale de lancement, puis les rôles établis pendant le projet deviennent le mode de fonctionnement du site dans la durée.
06
Les résultats
Un projet arrivé à environ 50 % de son développement.
Le site n'est pas encore en production et ses résultats doivent donc être présentés sans les confondre avec des effets commerciaux déjà mesurés. À ce stade, j'estime que la moitié du travail nécessaire à la première version est accomplie. Cette estimation tient compte des fondations techniques déjà construites, mais aussi du design restant à finaliser, des textes marketing à intégrer, de la réduction du périmètre linguistique au français et à l'anglais, de la finalisation du formulaire et des validations précédant le lancement. Le premier résultat est ainsi un socle fonctionnel vérifiable, et non un produit que je présenterais prématurément comme terminé.
Une page d'accueil et une page de contact déjà présentables.
La page d'accueil et la page de contact sont les deux parcours les plus aboutis. La première pose le positionnement de l'entreprise, introduit ses activités et met en scène ses partenaires au moyen d'une identité visuelle plus actuelle. La seconde fournit déjà un parcours permettant à un visiteur de saisir une demande et de recevoir une confirmation de son traitement par l'interface. Ces pages sont suffisamment avancées pour servir de prototypes crédibles lors des échanges internes, même si leur contenu et certains choix graphiques doivent encore recevoir une validation définitive.
L'application concrète du design system de l'entreprise.
La direction visuelle retenue repose sur le design system de l'entreprise. Un design system est un ensemble cohérent de règles et de composants qui organise notamment les couleurs, les typographies, les espacements, les formes et les comportements interactifs d'une interface. Son application donne au site une continuité visuelle et évite que chaque page soit conçue comme un objet indépendant. Le résultat n'est donc pas seulement une nouvelle apparence : le code commence à matérialiser une identité réutilisable dans les boutons, les conteneurs, les titres, les surfaces et les animations.
Des prototypes améliorés par les retours graphiques.
Les présentations intermédiaires ont donné lieu à plusieurs modifications du design global. Ces retours ne constituent pas un échec du prototype : ils montrent qu'il remplit sa fonction en rendant les choix suffisamment concrets pour être discutés. Chaque version permet aux graphistes et aux responsables de l'image d'évaluer la composition, le rythme, la hiérarchie du contenu et la cohérence avec la marque. Le résultat de cette boucle est une direction progressivement mieux alignée avec l'entreprise qu'une interface développée puis soumise uniquement à une validation finale.
Des audits Lighthouse réalisés dans plusieurs conditions.
Les audits ont été exécutés en simulation mobile et ordinateur, à la fois sur l'environnement local de développement et sur la préproduction. La préproduction est une version déployée du site réservée aux vérifications avant sa publication officielle. Lighthouse est un outil d'audit automatisé de Google qui examine notamment la performance, l'accessibilité et certaines bonnes pratiques techniques. Au cours de ces mesures, le site a atteint jusqu'à 99 sur 100 en performance, 100 sur 100 en accessibilité et 96 sur 100 en bonnes pratiques. Ces scores démontrent la qualité du socle actuel, mais ils devront être recalculés avec le design, les médias, les textes et l'hébergement définitifs : un résultat obtenu à mi-projet n'est pas une garantie immuable pour la version publiée.
Une compatibilité vérifiée au-delà d'un seul navigateur.
J'ai testé les parcours sur les navigateurs les plus utilisés ainsi que sur téléphone. Cette vérification croisée est importante, car deux navigateurs peuvent interpréter différemment une règle de style, une vidéo, une animation ou le comportement d'un formulaire. Les tests mobiles permettent également d'observer le site dans les contraintes réelles d'un écran tactile et d'un espace réduit, plutôt que de se limiter à diminuer la largeur d'une fenêtre sur ordinateur. Aucun test ne permet d'affirmer qu'un site fonctionnera sur tous les appareils existants, mais cette couverture réduit le risque de publier une expérience valable uniquement dans mon environnement de développement.
La résolution du défaut mobile le plus visible de l'ancien site.
Les prototypes actuels corrigent le mauvais affichage mobile qui faisait partie des limites principales du site précédent. Les contenus se réorganisent selon la largeur disponible, les textes restent lisibles et les interactions essentielles ne dépendent plus d'une mise en page pensée uniquement pour l'ordinateur. Ce résultat est directement observable lors de la navigation et ne repose pas sur une promesse future. Il devra néanmoins être contrôlé une dernière fois après l'intégration de tous les contenus, car un titre plus long, une nouvelle image ou un bloc éditorial supplémentaire peut encore créer une régression responsive.
Un ensemble de composants réutilisables déjà opérationnel.
Les composants partagés constituent l'un des principaux résultats techniques. Un composant réunit la structure, le style et éventuellement le comportement d'un élément d'interface afin qu'il puisse être réemployé de manière cohérente. Les boutons, conteneurs, effets d'apparition, textes animés et surfaces visuelles ne sont donc pas recréés séparément pour chaque page. Cette organisation accélère la suite du développement et réduit le risque de variations involontaires. Une correction apportée à un composant commun peut bénéficier à toutes les pages qui l'utilisent.
Un responsive et des tests intégrés au développement.
L'adaptation aux écrans et la vérification du comportement ne sont pas reportées à la fin du projet. Le responsive est pris en compte dans les composants, tandis que les tests automatisés contrôlent déjà plusieurs éléments de logique, d'interface, d'API et de navigation. Les scénarios exécutés dans de vrais moteurs de navigateur complètent les tests plus isolés en vérifiant ce que voit et fait réellement un visiteur. Cette combinaison ne remplace pas l'observation humaine, notamment pour juger la qualité visuelle, mais elle rend les régressions plus faciles à repérer lorsque le code évolue.
Une première chaîne de contact fonctionnelle.
Le formulaire dispose déjà de ses principaux états d'interface, vérifie les informations indispensables et peut transmettre une demande par courriel au moyen de l'API développée pour le site. Une API, ou interface de programmation, est ici le point d'entrée serveur qui reçoit les données du formulaire, les contrôle puis appelle le service chargé de l'envoi. Ce résultat valide la faisabilité technique du parcours. Il ne signifie pas encore que le traitement organisationnel est terminé : les champs définitifs, les protections antispam et les destinataires de production doivent encore être confirmés par l'équipe marketing ou la direction.
Une gestion éditoriale préparée, mais pas encore remise au marketing.
L'architecture Sanity et les modèles de contenu existent dans le projet, mais l'équipe marketing ne les utilise pas encore de manière autonome puisque le site n'est pas en production. Je distingue donc la disponibilité technique de l'outil de son adoption réelle. La prochaine étape sera de finaliser les contenus, de vérifier les droits d'accès et d'accompagner l'équipe dans la publication. Le résultat attendu est qu'elle puisse ensuite faire évoluer les textes, articles et offres sans dépendre de moi pour chaque modification, tandis que je conserve la responsabilité du code et de la structure technique.
Des fondations de référencement plus complètes.
Le nouveau site prépare des métadonnées, des adresses canoniques, un sitemap, des données structurées et des pages plus rapides et mieux adaptées au mobile. Les métadonnées donnent notamment aux moteurs de recherche un titre et une description ; le sitemap leur fournit une liste organisée des pages ; les données structurées décrivent explicitement certains contenus comme l'entreprise, un article ou une offre d'emploi. Ces mécanismes ne garantissent pas une première position dans les résultats de recherche, car le classement dépend de nombreux facteurs externes. Ils donnent cependant aux moteurs des informations plus fiables que l'ancien site et réduisent les handicaps techniques qui limitaient sa visibilité.
Une image plus professionnelle comme bénéfice principal attendu.
Le résultat stratégique visé est une meilleure crédibilité auprès des clients professionnels, distributeurs, retailers et partenaires potentiels. Le terme retailer désigne une entreprise qui vend les produits au client final, en magasin ou en ligne. Le site doit permettre à ces interlocuteurs de comprendre plus rapidement qui est l'entreprise, ce qu'elle distribue ou crée et comment la contacter. À mi-parcours, le design system, la nouvelle page d'accueil et la qualité responsive rendent déjà cette évolution perceptible en interne. Son effet commercial réel ne pourra toutefois être confirmé qu'après la mise en ligne.
De nouveaux usages prévus pour les candidatures et le contenu.
Le futur site ne doit pas seulement présenter l'entreprise. Il doit aussi permettre de gérer les candidatures et de montrer l'activité au moyen d'un blog. Le blog donnera à l'équipe un espace pour publier des actualités ou expliquer ses projets, tandis que la partie carrière structurera la consultation des offres et la réception des candidatures. Ces usages sont inclus dans l'architecture éditoriale, mais je les présente comme un périmètre à achever plutôt que comme un résultat déjà adopté par les utilisateurs. Leur valeur apparaîtra lorsque les équipes publieront réellement du contenu et traiteront des candidatures par ce canal.
Des indicateurs définis avant le lancement.
Après la publication, deux familles de mesures permettront d'évaluer le résultat : le nombre de consultations et les conversions réalisées au moyen du formulaire. Une consultation indique qu'une page a été affichée ; une conversion correspond ici à l'action attendue d'un visiteur, par exemple l'envoi d'une demande de contact. Le simple volume de visites ne suffira donc pas à juger la réussite. Il faudra observer si les visiteurs atteignent les pages importantes et si une part pertinente d'entre eux prend effectivement contact, tout en respectant le consentement nécessaire à la mesure d'audience.
Un apprentissage du design au service d'une identité qui n'est pas la mienne.
Ce projet m'a appris à appliquer un design en fonction de l'image que l'entreprise veut transmettre, plutôt qu'à construire uniquement l'interface qui correspondrait à mes préférences. C'est aussi la première fois que je développe une interface dont je n'ai pas moi-même produit le design. J'ai dû comprendre l'intention des graphistes, préserver ses éléments importants, signaler les contraintes puis proposer une traduction technique fidèle. Cette expérience renforce ma capacité à collaborer avec des métiers créatifs et à distinguer goût personnel, besoin utilisateur et objectif de communication.
La démonstration d'une responsabilité technique de bout en bout.
J'ai pris en charge tout le périmètre technique : choix et mise en place de l'architecture, intégration du design, développement des composants, responsive, animation, internationalisation, gestion éditoriale, référencement, formulaire, tests, audit et préparation du déploiement. Ce résultat démontre ma capacité à relier des sujets qui sont souvent traités séparément et à rendre leurs compromis compréhensibles aux décideurs. Les captures d'écran, rapports Lighthouse, extraits de composants et tests pourront servir de preuves dans le portfolio. Les maquettes de conception ne seront pas publiées, ce qui respecte la limite d'autorisation tout en laissant des éléments vérifiables issus de mon propre travail.
07
Les lendemains du projet
Choisir une direction graphique avant de poursuivre l'intégration.
Le prochain jalon consiste à sélectionner l'un des prototypes suffisamment aboutis pour devenir la base de la première version. Ce choix doit stabiliser la composition, les éléments visuels majeurs et le niveau d'animation attendu. Je pourrai alors arrêter de maintenir plusieurs hypothèses de design en parallèle et concentrer le développement sur une direction commune. Les ajustements resteront possibles, mais ils ne devront plus remettre en question l'architecture complète des pages principales.
Intégrer ensuite les textes validés.
L'ordre de travail immédiat est volontairement simple : le design d'abord, puis les textes. Le contenu définitif dépend actuellement du directeur de l'équipe marketing, qui constitue la principale dépendance externe à mon travail technique. Une fois les versions française et anglaise reçues, je devrai les intégrer sans altérer leur sens, vérifier leur longueur dans les composants et contrôler qu'aucun texte provisoire ne reste visible. Cette étape permettra aussi de détecter les écarts entre la place prévue dans la maquette et le volume réel du message.
Recueillir les retours de chaque équipe sur une version cohérente.
Après l'intégration du design et des textes, les différentes équipes pourront examiner une préproduction suffisamment proche du résultat final. Leur revue ne portera plus sur un prototype isolé, mais sur les parcours réels, le contenu approuvé et le comportement responsive. Les graphistes vérifieront la fidélité visuelle, le marketing la justesse du discours, tandis que les autres équipes pourront signaler une présentation inexacte de leur activité. Les retours seront centralisés dans Jira afin d'être qualifiés, priorisés et suivis jusqu'à leur résolution.
Viser une mise en ligne avant la Gamescom 2026.
L'objectif est de publier le site courant août 2026, avant la Gamescom. La Gamescom est un salon international consacré au jeu vidéo et aux activités qui l'entourent ; elle représente une échéance pertinente pour une entreprise active dans la distribution et la création de produits liés à la pop culture et aux accessoires de jeu vidéo. Cette date fournit une limite concrète au projet. Elle justifie de concentrer la première version sur les pages essentielles plutôt que de retarder toute la communication pour des fonctions secondaires.
Définir une V1 prête lorsque les pages principales sont terminées.
La première version pourra être considérée comme prête lorsque les pages principales seront finalisées, relues, testées et validées par les responsables concernés. L'objectif n'est pas d'intégrer immédiatement toutes les idées recensées pendant le projet. Une fonction qui n'est pas indispensable à la présentation de l'entreprise ou à la prise de contact peut rejoindre une V2. Cette règle protège la date d'août et donne un critère de sortie compréhensible : terminer un périmètre utile et cohérent plutôt que poursuivre une exhaustivité sans fin.
Organiser une recette impliquant les acteurs du projet.
Avant la publication, les graphistes, l'équipe marketing et la direction participeront à une recette finale. La recette est une phase de vérification durant laquelle les personnes responsables confirment qu'un produit correspond au besoin et peut être accepté. Elle portera sur le rendu visuel, les textes, les liens, le formulaire, les langues, les principaux appareils et l'image générale renvoyée par le site. Une validation explicite permettra de distinguer les défauts bloquant la sortie des améliorations qui peuvent être planifiées après le lancement.
Valider une version candidate en préproduction.
Le déploiement ne partira pas directement d'une version seulement testée sur mon ordinateur. Une version candidate sera d'abord publiée en préproduction afin que les acteurs puissent la parcourir dans des conditions proches du site public. Une version candidate est une révision considérée comme potentiellement publiable si les derniers contrôles ne révèlent aucun problème bloquant. Elle figera le code et les contenus soumis à la recette, ce qui évitera qu'une modification non vérifiée soit ajoutée entre l'accord de la direction et la mise en ligne.
Déployer au moyen du pipeline CI/CD jusqu'à Vercel.
Une fois la version candidate validée, le pipeline d'intégration et de déploiement continus prendra en charge les vérifications et la publication. Un pipeline CI/CD est une suite automatisée d'étapes déclenchées à partir du dépôt de code : installation du projet, contrôles, construction de l'application puis déploiement de la version autorisée. Vercel hébergera la première mise en production. Ce flux réduit les manipulations manuelles et relie le site publié à une révision identifiable, ce qui facilite le diagnostic ou le retour à une version antérieure en cas de problème.
Contrôler l'absence de défaut bloquant après la bascule.
Dans les premières heures, je parcourrai les pages essentielles afin de vérifier qu'aucun bug visible ou erreur d'exécution ne bloque la navigation. Je contrôlerai notamment les liens, le responsive, les langues, les médias et le formulaire. L'objectif ne sera pas de conclure qu'aucune anomalie mineure n'existe, mais de confirmer que le site public fournit les parcours validés en préproduction et qu'aucune différence liée au domaine ou à l'environnement de production ne les a interrompus.
Vérifier l'état des services connectés.
Une page peut s'afficher correctement alors qu'un service externe nécessaire est indisponible. Je vérifierai donc que Sanity répond, que les contenus publiés sont récupérés et que le service d'envoi transmet correctement les courriels du formulaire. Un service « UP » est un service accessible et capable de remplir la fonction attendue ; à l'inverse, un état « DOWN » signifie qu'il ne répond plus ou échoue. Ces contrôles permettront de détecter un site visuellement disponible mais partiellement inutilisable.
Traiter les anomalies dans Jira après le lancement.
Les problèmes observés par les équipes après la mise en ligne seront enregistrés sous forme de tickets Jira. Chaque ticket devra décrire le comportement rencontré, le résultat attendu, le contexte et, lorsque cela est possible, les étapes permettant de reproduire le défaut. Les incidents qui empêchent un contact, rendent une page principale inaccessible ou publient une information incorrecte seront prioritaires. Les ajustements purement esthétiques ou les nouvelles idées pourront être regroupés dans le périmètre d'une version ultérieure.
Former le marketing à Sanity avant la production.
L'équipe marketing devra être accompagnée avant la mise en ligne afin de pouvoir utiliser Sanity sans dépendre de moi pour chaque publication. La formation portera sur la création et la modification d'un contenu, les champs obligatoires, les versions linguistiques, les médias et le passage d'un brouillon à un contenu publié. Je conserverai la maintenance de la structure et du code, tandis que le marketing deviendra responsable de la vie éditoriale. Ce transfert doit être vérifié par un exercice réel avant que l'outil ne soit nécessaire en production.
Faire du premier contenu éditorial un choix marketing.
Le sujet du premier article n'est pas encore arrêté. La Gamescom constitue une possibilité cohérente avec la période de lancement et l'activité de l'entreprise, mais elle ne doit pas être présentée comme une décision prise tant que le marketing ne l'a pas validée. Le choix devra tenir compte de l'information réellement disponible, de l'intérêt pour les partenaires professionnels et de la capacité de l'équipe à publier un contenu suffisamment travaillé. Cette première publication servira aussi à éprouver le processus éditorial complet dans Sanity.
Décider séparément du lancement de la gestion des candidatures.
La présence de la fonctionnalité de candidature dans la V1 n'est pas encore certaine. Elle pourra être incluse si le parcours, le traitement des données et la responsabilité de réception sont prêts sans menacer l'échéance principale. Dans le cas contraire, elle rejoindra la V2. Cette décision évite d'afficher un formulaire de recrutement qui ne serait pas correctement suivi ou qui collecterait des informations personnelles sans processus défini.
Constituer une V2 à partir des besoins déjà identifiés.
Les fonctions qui ne conditionnent pas le lancement seront traitées dans une deuxième version. Le périmètre potentiel comprend la gestion des candidatures si elle est reportée, une connexion du formulaire avec Odoo lorsqu'elle apporte un bénéfice démontré, ainsi qu'une amélioration plus uniforme de la réduction des animations. Les animations, le motion design et les grands éléments de fond pourront également être enrichis ou ajustés après observation de la V1, sans sacrifier les performances ni l'accessibilité. Cette V2 sera priorisée à partir des retours réels plutôt que par l'ajout automatique de toutes les idées disponibles.
Étendre les langues uniquement lorsqu'un besoin le justifie.
La première version restera limitée au français et à l'anglais. D'autres langues pourront être ajoutées si l'entreprise en formule la demande et dispose des textes ainsi que des personnes capables de les maintenir. L'architecture est déjà conçue pour l'internationalisation, mais la possibilité technique ne suffit pas à justifier une langue supplémentaire. Une traduction qui n'est jamais mise à jour finirait par présenter un message différent ou obsolète et diminuerait la qualité globale du site.
Conserver Vercel tant que son rapport coût-service reste acceptable.
Vercel est le choix prévu pour la première mise en ligne en raison de son intégration naturelle avec Next.js et le pipeline de déploiement. Un transfert vers un serveur dédié de l'entreprise serait envisagé si la tarification devenait disproportionnée par rapport au trafic ou aux fonctions réellement utilisées. Une migration d'hébergement ne devra pas être décidée sur le seul prix affiché : il faudra aussi comparer le temps d'administration, les sauvegardes, la sécurité, la surveillance et la facilité de déploiement que l'entreprise devrait alors prendre en charge elle-même.
Maintenir le site par des contrôles réguliers.
Après le lancement, je resterai responsable des mises à jour de dépendances, des correctifs de sécurité, de l'exécution des tests et du suivi des performances. Une dépendance est une bibliothèque externe utilisée par l'application ; sa mise à jour peut corriger un défaut, mais aussi introduire une incompatibilité, d'où la nécessité de rejouer les tests avant chaque livraison. Comme le site devrait évoluer moins fréquemment qu'une application métier, je prévois un audit Lighthouse hebdomadaire, complété par un contrôle après chaque modification significative du frontend.
Surveiller le référencement lors du remplacement de l'ancien site.
Des outils de suivi SEO permettront d'observer l'indexation des nouvelles pages, les erreurs d'exploration, les positions sur les recherches importantes et l'évolution des visites provenant des moteurs. Le suivi devra porter en priorité sur les semaines entourant la bascule, période pendant laquelle une mauvaise redirection ou une page bloquée peut provoquer une baisse. L'objectif ne sera pas de réagir à chaque variation quotidienne, mais d'identifier une tendance durable ou un défaut technique nécessitant une correction.
Faire vivre le site grâce au blog.
À moyen terme, le blog doit empêcher le site de redevenir une vitrine figée. Des publications régulières pourront présenter les activités, les événements, les projets ou les actualités pertinentes pour les partenaires. Chaque contenu donnera une nouvelle raison de consulter le site et pourra indirectement renforcer le référencement en enrichissant les sujets associés à la marque. Cet effet ne sera ni immédiat ni automatique : il dépendra de la qualité des articles, de leur régularité et de leur intérêt réel pour les lecteurs visés.
Réutiliser l'architecture pour la branche EPI.
Les composants, le design system, l'internationalisation, Sanity, les formulaires, les tests et le pipeline de déploiement pourront servir de base à d'autres présences Web de l'entreprise. Une application envisagée concerne notamment la partie EPI, c'est-à-dire les équipements de protection individuelle destinés à protéger une personne contre un risque professionnel. La réutilisation ne consistera pas à dupliquer le site sans réflexion, mais à conserver les fondations génériques et à adapter le contenu, l'identité et les parcours à cette activité. Le projet corporate produit ainsi un socle potentiellement utile au-delà de sa première mise en ligne.
08
Mon regard critique
Une difficulté principalement organisationnelle.
La principale limite rencontrée n'est pas venue du code, mais de la lenteur des échanges avec les équipes. La refonte du site restait un projet secondaire par rapport à leurs activités quotidiennes ; les validations, les contenus et les retours ne pouvaient donc pas toujours être traités immédiatement. Cette situation m'a appris qu'un projet peut être techniquement en avance tout en progressant lentement à cause de dépendances humaines légitimes. Mon erreur a été de ne pas intégrer assez tôt cette disponibilité réduite dans l'organisation et le calendrier.
Une base de design qui aurait mérité davantage de temps au départ.
Avec du recul, le design est la partie que j'aurais pu cadrer plus tôt et plus profondément. J'ai consacré du temps à préparer des fonctionnalités alors que la direction visuelle, qui conditionne toute l'intégration, n'était pas encore suffisamment stabilisée. Cela n'a pas rendu le travail inutile, mais a réparti mon attention sur des sujets moins prioritaires. Pour un site corporate dont la fonction principale est de transmettre une image, la base graphique n'est pas une finition : elle fait partie du cœur du produit.
Treize langues comme préparation, pas comme erreur structurante.
Je ne considère pas que la préparation initiale de treize langues ait été une mauvaise décision technique. Elle a permis de vérifier que le routage, les messages et les métadonnées pouvaient être internationalisés sans reconstruire l'application. En revanche, maintenir réellement treize contenus aurait dépassé le besoin de la première version. La réduction au français et à l'anglais montre la différence entre concevoir une architecture extensible et remplir immédiatement tout le périmètre qu'elle autorise. La première démarche reste utile ; la seconde aurait dispersé l'effort.
Des prototypes multiples nécessaires pour ouvrir les options.
La réalisation de plusieurs propositions a consommé du temps, mais elle était nécessaire tant que la direction graphique n'était pas arrêtée. Un prototype ne servait pas seulement à produire une page : il permettait de comparer des rythmes, des compositions et des niveaux d'animation suffisamment concrets pour susciter une décision. Le risque aurait été de transformer cette exploration en recherche sans limite. Pour rester utile, chaque proposition devait répondre à une question précise et rapprocher l'équipe d'un choix plutôt que simplement ajouter une nouvelle variante.
Un développement parallèle au design qui reste justifié.
Je ne pense pas qu'il aurait fallu attendre la finalisation complète de toutes les maquettes avant de commencer. Une partie du travail était indépendante de la direction graphique finale : initialisation du projet, architecture, internationalisation, accès aux contenus, tests, formulaire et composants génériques. Développer en parallèle a permis de rester en avance sur le planning. La leçon n'est donc pas d'attendre davantage, mais de mieux distinguer les fondations stables des éléments visuels susceptibles d'être réécrits.
Trois bibliothèques d'animation dont les rôles restent justifiés.
L'utilisation de GSAP, Motion et Lenis ajoute des dépendances et impose de comprendre plusieurs modèles d'animation, mais je considère toujours ce choix pertinent. GSAP prend en charge les séquences avancées et les interactions liées au défilement, Motion les transitions locales de composants et Lenis le défilement fluide. La condition est de conserver cette séparation claire et de ne pas utiliser plusieurs bibliothèques pour résoudre le même effet sans raison. Leur présence doit continuer à être évaluée selon la valeur visuelle apportée, le poids envoyé au navigateur et la facilité de maintenance.
Sanity utile à terme, mais non indispensable pour commencer.
La première version aurait pu être réalisée sans système de gestion de contenu, en conservant temporairement les textes dans le code. Sanity représente donc un investissement anticipé plutôt qu'une obligation technique immédiate. Son intérêt apparaîtra lorsque le marketing publiera régulièrement des articles, modifiera les pages ou gérera les offres sans intervention d'un développeur. Si cette autonomie éditoriale reste peu utilisée, la complexité de configuration et de maintenance devra être réévaluée. Un outil n'est justifié dans la durée que par l'usage qu'il permet réellement.
Une couverture de test large, mais jamais absolue.
Tous les parcours et comportements identifiés dans le périmètre actuel font l'objet de vérifications manuelles ou automatisées. Je ne considère donc pas qu'une zone connue ait été volontairement laissée sans test. Cette couverture ne permet toutefois pas d'affirmer que toutes les combinaisons possibles ont été reproduites. Le contenu définitif, un appareil inhabituel, une extension de navigateur, un service externe momentanément indisponible ou un usage non anticipé peuvent encore révéler un défaut. Les tests réduisent le risque ; ils ne remplacent pas le suivi après la mise en production.
Des scores Lighthouse dépendants des conditions de mesure.
Les résultats Lighthouse actuels donnent une indication utile, mais ils ne décrivent pas exactement l'expérience de chaque visiteur. Une connexion lente ou instable peut augmenter le temps nécessaire pour charger les vidéos, les images, les scripts et les polices. La puissance de l'appareil, le cache et la distance avec le serveur modifient également la perception. Je dois donc lire les scores comme un point de comparaison entre versions et les compléter, après le lancement, par des mesures réalisées dans les conditions réelles d'utilisation.
Aucune faiblesse majeure identifiée dans le formulaire, mais un travail de finition.
Je n'identifie pas actuellement de défaut architectural majeur dans le formulaire. Son interface, sa validation et son envoi technique fonctionnent. Les éléments encore ouverts — destinataires définitifs, champs exacts, protection antispam complète et contrôle de production — relèvent de la finalisation avant lancement. Cette distinction reste importante : une base fonctionnelle n'autorise pas à déclarer le parcours terminé tant que le message n'arrive pas de manière fiable à la bonne personne dans l'environnement public.
Des demandes à formuler plus précisément auprès des graphistes.
Ma collaboration avec l'équipe graphique aurait pu être plus efficace si j'avais décrit plus précisément les éléments attendus avant chaque livraison. Un besoin comme « préparer cette section » peut laisser ouvertes la variante mobile, les dimensions des médias, les états interactifs ou les formats de fichiers. En explicitant ces points plus tôt, j'aurais limité les échanges supplémentaires et les interprétations différentes. Cette précision ne doit pas enfermer la créativité des graphistes ; elle doit rendre visibles les contraintes que l'intégration devra obligatoirement résoudre.
Des textes qui auraient dû être demandés plus tôt.
Le contenu est devenu le principal point de dépendance parce que sa production et sa validation n'ont pas été anticipées suffisamment tôt. J'aurais pu créer dès le départ les tickets éditoriaux, nommer leurs responsables et leur associer des dates cohérentes avec l'intégration. Le texte n'est pas une donnée que l'on insère mécaniquement à la fin : sa longueur, sa hiérarchie et son sens influencent directement la mise en page. Le demander en amont aurait permis au marketing de travailler pendant la construction technique et aurait réduit le risque de concentration des retours à l'approche de la Gamescom.
Un travail en autonomie qui n'a pas retardé le projet.
Le fait d'être seul développeur n'a pas constitué un frein dans ce cas. J'étais même en avance sur les contributions dont dépendait la suite du projet. Cette autonomie a accéléré les choix d'architecture et évité des coordinations techniques supplémentaires sur un site dont la complexité restait maîtrisable par une personne. Elle crée néanmoins une responsabilité de documentation et de maintenabilité : l'avance obtenue pendant le développement ne doit pas devenir une dépendance durable à ma seule mémoire.
Aucun compromis actuellement considéré comme insatisfaisant.
Je ne vois pas, à ce stade, de compromis technique ou visuel que je considère comme mauvais au point de devoir le reprendre immédiatement. Les choix effectués restent cohérents avec le niveau d'ambition, les performances observées et les besoins du site. Ce constat est provisoire : le contenu final et les conditions réelles de production peuvent encore modifier l'évaluation. Un regard critique ne consiste pas à inventer artificiellement un échec, mais à identifier les décisions dont la pertinence devra être vérifiée après usage.
Une difficulté technique modérée.
Le site reste techniquement assez classique pour moi et aucun développement isolé ne s'est imposé comme un obstacle majeur. La difficulté vient davantage de l'assemblage cohérent de plusieurs dimensions — design, animations, contenu, responsive, référencement, formulaire et déploiement — que d'un algorithme particulièrement complexe. Cette observation nuance la réalisation : elle démontre surtout ma capacité à prendre en charge un produit Web de bout en bout et à coordonner ses acteurs, pas la résolution d'une recherche technique inédite.
Moins de fonctionnalités et davantage de temps consacré au socle visuel.
Si je recommençais le projet, je limiterais plus tôt le périmètre fonctionnel et consacrerais davantage de temps à la base du design. Je chercherais d'abord à obtenir une page d'accueil représentative, un système visuel validé et les contenus essentiels, avant d'investir dans des fonctions pouvant attendre une V2. Ce choix ne signifie pas abandonner la qualité technique. Il consiste à appliquer l'effort en priorité sur ce qui détermine la valeur de la première version : l'image, la compréhension de l'activité et la prise de contact.
Un niveau que j'évalue actuellement à 7 sur 10.
J'estime ma maîtrise du développement frontend et de la responsabilité technique sur ce projet à 7 sur 10. Je sais construire l'architecture, intégrer une interface responsive, mettre en place des animations, tester les parcours et préparer le déploiement en autonomie. Je ne me donne pas une note plus élevée, car la réussite d'un responsable technique ne se limite pas à produire le code attendu. Elle inclut également l'anticipation des dépendances, la communication avec les autres métiers et la capacité à concentrer l'équipe sur les décisions les plus importantes.
La communication et la priorisation comme axes de progression.
Pour atteindre un niveau supérieur, je dois encore améliorer la précision de mes demandes, anticiper les validations et rendre plus visible l'ordre réel des priorités. Une bonne priorisation distingue ce qui bloque le lancement, ce qui améliore réellement la valeur pour l'utilisateur et ce qui peut attendre sans conséquence. Cette compétence est particulièrement importante lorsque les autres acteurs ne peuvent consacrer qu'une partie de leur temps au projet. Elle permet de transformer une avance technique personnelle en progression collective du produit.
Valider avec les équipes à chaque avancée significative.
Le principal conseil que je retiens pour l'intégration d'un design produit par une autre équipe est de ne pas attendre la fin pour demander une confirmation. À chaque étape suffisamment concrète — structure, première section, comportement mobile ou animation importante — il faut présenter le résultat, reformuler les écarts et obtenir un accord. Ces validations intermédiaires limitent les reprises massives et permettent au développeur de comprendre l'intention qui se trouve derrière la maquette, plutôt que d'en reproduire uniquement les pixels.
Protéger la qualité par la concentration sur l'essentiel.
À l'approche de l'échéance d'août, la bonne réponse n'est pas d'accélérer toutes les fonctionnalités au même niveau. Je dois concentrer le travail sur les pages principales, les contenus validés, la navigation, le responsive, le contact et la fiabilité du déploiement. Une fonction secondaire incomplète sera reportée en V2 plutôt que livrée sans les contrôles nécessaires. Cette réduction volontaire du périmètre protège à la fois la date, la crédibilité du site et la qualité technique de ce qui sera réellement présenté au public.