=========================================================================
LOT DE CONSOLIDATION — 27/08
Base de depart : VOTRE ZIP « ce qui est en ligne actuellement » (69,6 Mo)
=========================================================================

CE QUE J'AI FAIT D'ABORD : COMPARER
------------------------------------
Vous m'aviez envoye ce matin un zip de 293 Mo, puis celui-ci de 69,6 Mo.
Ils ne contiennent pas la meme chose. J'ai donc tout reconstruit sur CELUI-CI,
puisque c'est lui qui reflete le serveur.

Bonne nouvelle : votre site en ligne contenait DEJA presque tout le travail
d'aujourd'hui. Verifie marqueur par marqueur :
   photos MGT + cadres sombres ......... EN LIGNE
   photo du batiment (A propos) ........ EN LIGNE
   video du hero (accueil) ............. EN LIGNE
   croix de fermeture du devis ......... EN LIGNE (105 pages)
   secteurs cote a cote + boutons ...... EN LIGNE
   pages legales reecrites ............. EN LIGNE
   pictogrammes des services ........... MANQUANT  <- le seul lot absent

CE QUE CONTIENT CE ZIP — 108 FICHIERS
--------------------------------------

1. LOT PICTOGRAMMES SERVICES (16 pages) — le lot de ce matin, reapplique
   Photos remplacees par les pictogrammes en grand sur les 7 pages de
   service FR, leurs 7 jumelles EN, et le catalogue services.html / en.

2. LOT MXP DU 25/08 — remis, et il manquait une piece
   Le fichier images/mxp.webp est DEJA sur votre serveur : c'est le patch
   HTML qui n'avait jamais ete depose. mxp.html et en/mxp.html pointaient
   donc encore sur images/mxp-photo.png et images/mxp-2.png, qui n'existent
   pas -> deux images cassees sur chaque page alors que la bonne photo
   dormait a cote. Corrige.
   Corrige aussi : dans en/mxp.html, deux chemins de visionneuse etaient
   ecrits « images/... » au lieu de « ../images/... ». Depuis /en/ ils ne
   pouvaient pas resoudre.

3. REFERENCES D'IMAGES CASSEES (9 pages)
   La campagne de conversion en WebP du 19/08 avait laisse des references
   vers les anciens .png/.jpg. Le fichier .webp existait pourtant deja.
   Redirigees : baie43u.png, baie34u-fmt.png, baie43u-fmt.png, platine.jpg
   et 12 images ts-*.png/jpg.
   Pages concernees : baie, platine, produits, traitement-surface,
   traitement-surface_1 et les 4 jumelles EN.

4. LOT SEO / MISE EN LIGNE DU 25/08 — jamais depose, refait
   - 3 balises noindex de preproduction retirees
   - canonical absolu auto-referent sur les 105 pages
   - hreflang fr / en / x-default en absolu sur les 104 pages appairees
     (ils etaient relatifs, donc ignores par Google)
   - og:url ajoute, og:image et twitter:image passes en absolu (53 balises)
   - JSON-LD : champs url et logo ajoutes a l'Organization (102 pages)
   - sitemap.xml regenere : 104 URL avec declaration des paires FR/EN
   - robots.txt + robots-PREPROD.txt

   DOMAINE UTILISE : https://future.micronics.fr
   C'est celui que j'ai lu dans VOTRE sitemap.xml et VOTRE robots.txt en
   ligne. Si le site doit basculer sur www.micronics.fr, dites-le : c'est
   une seule constante a changer et je regenere tout en une minute.

RESULTAT MESURE
---------------
Cibles introuvables sur le site : 28 avant, 1 apres.
Les 105 pages ont ete ouvertes une par une dans un navigateur :
   1 seul h1 par page, canonical present et absolu partout,
   0 debordement horizontal, 0 erreur JavaScript.

LE POINT QUI RESTE — images/powerrack.jpg
------------------------------------------
Referencee par alimentations.html, powerrack.html et leurs 2 jumelles EN.
Le fichier n'est NI dans le zip en ligne, NI dans celui de 293 Mo de ce
matin, et il n'existe aucun equivalent .webp. Il est perdu.
Envoyez-moi une photo du PowerRack et je la mets en place. En attendant,
ces pages affichent un cadre vide a cet endroit.

CE QUE JE N'AI PAS PU REMETTRE
-------------------------------
Le lot « options / Micronics Touch Control » du 25/08 est partiellement en
ligne : les deux images (option-control-panel.webp, option-ecran-tactile.webp)
sont bien sur le serveur, mais l'harmonisation des libelles n'a pas ete
deposee — options.html contient encore 5 occurrences de « ecran tactile »
a cote de 2 « Micronics Touch Control ». Je ne l'ai pas corrige ici pour ne
pas melanger un travail de nommage avec un lot de consolidation technique.
Dites-moi et je le fais dans un lot dedie.

DEPOT
-----
Ce zip ne contient QUE les fichiers qui changent : 105 .html + sitemap.xml
+ robots.txt + robots-PREPROD.txt. Aucune image, aucune video : tout ce dont
les pages ont besoin est deja sur votre serveur.
Deposer en respectant l'arborescence : les 54 fichiers a la racine, les 51
du dossier en/ dans en/, et les 3 fichiers a la racine.
robots-PREPROD.txt ne se depose QUE sur une preproduction, renomme robots.txt.


=========================================================================
AJOUT — PICTOGRAMMES REDUITS
=========================================================================
Ce zip REMPLACE le precedent : il contient la consolidation decrite
ci-dessus PLUS l'ajustement de taille ci-dessous. Deposez uniquement
celui-ci.

CE QUE LA MESURE A MONTRE
-------------------------
Le pictogramme occupait :
   26 % de la largeur du panneau  sur une page de service en 1440 px
   37 %                            sur la meme page en 390 px (mobile)
   39 %                            dans le catalogue services.html
C'est sur mobile et dans le catalogue qu'il ecrasait le plus la page,
pas sur le grand ecran.

CE QUI A ETE FAIT
-----------------
Une seule taille servait aux deux composants, alors que leurs panneaux
n'ont pas du tout la meme forme : celui des pages de service est large
(632 px), celui du catalogue est etroit et haut (416 px). Ils ont donc
maintenant des tailles distinctes :

   pages de service   164 px -> 118 px   soit 26 % -> 19 % de la largeur
   catalogue          164 px -> 101 px   soit 39 % -> 24 %
   mobile             120 px ->  88 px   soit 37 % -> 27 %

Le dessin a l'interieur passe de 48 % a 50 % de la pastille et son trait
de 1,5 a 1,6 : le pictogramme reste aussi lisible qu'avant malgre la
reduction. L'arrondi passe de 34 a 26 px pour rester proportionne, et les
deux cercles concentriques suivent automatiquement puisqu'ils sont
exprimes en pourcentage.

CONTROLE
--------
14 pages de service x 2 largeurs + les 2 catalogues : pictogramme toujours
centre au pixel et contenu dans son cadre.
Les 105 pages du site reouvertes une par une : 1 h1 par page, canonical
present partout, 0 debordement, 0 erreur JavaScript.

SI C'EST ENCORE TROP GRAND
--------------------------
Il reste une piste que je n'ai pas prise sans votre accord : le PANNEAU
lui-meme. Sur mobile il fait 245 px de haut avant le moindre mot de texte,
et il passe avant le titre. Le ramener au format 16/9 ferait gagner 60 px
de defilement sur chaque page de service. Dites-le moi si vous voulez.


=========================================================================
AJOUT — PANNEAU REDUIT
=========================================================================
Ce zip REMPLACE les deux precedents. Il contient la consolidation, les
pictogrammes reduits, ET la reduction du panneau ci-dessous.

MESURES AVANT / APRES
---------------------
   page de service, 1440 px    632 x 474  ->  632 x 356   (-25 %)
   page de service,  390 px    327 x 245  ->  327 x 184   (-25 %)
   catalogue services, 1440    416 x 546  ->  416 x 260   (-52 %)
   catalogue EN,       1440    416 x 486  ->  416 x 260   (-46 %)

COMMENT
-------
Pages de service : le cadre passe du format 4/3 au format 16/9, et il est
plafonne a 200 px de haut sous 900 px de large.
Catalogue : le panneau s'etirait sur toute la hauteur du texte a cote
(height:100%), d'ou ses 546 px. Il est desormais cale en haut de colonne
avec un format 16/10 plafonne a 300 px. C'est ce qui explique la baisse
plus forte de ce cote.

CE QUE CA CHANGE VRAIMENT
-------------------------
Sur grand ecran la hauteur de page ne bouge pas : le panneau est a cote du
texte, c'est le texte qui commande la hauteur de la ligne. Le gain y est
uniquement visuel — le bloc ne domine plus la colonne de gauche.
Sur mobile en revanche le panneau est EMPILE AU-DESSUS du texte : la page
de service passe de 7152 a 7090 px, soit 62 px de defilement en moins avant
d'arriver au premier paragraphe.

CONTROLE
--------
5 pages x 8 largeurs (1920 / 1440 / 1100 / 980 / 900 / 860 / 600 / 390),
soit 40 configurations : pictogramme toujours contenu dans son cadre,
jamais au-dela de 32 % de la largeur, panneau jamais ecrase sous 140 px,
0 debordement.
Les 105 pages du site reouvertes : 1 h1 chacune, canonical present,
0 debordement, 0 erreur JavaScript.


=========================================================================
AJOUT — SOUS-MENU « A PROPOS » RETABLI
=========================================================================
Ce zip REMPLACE tous les precedents.

LE PROBLEME
-----------
Sur 8 pages, la colonne « A propos » du mega-menu ne proposait plus que
« Evenements ». Les trois entrees Notre Histoire, Nos Valeurs et Nos
Engagements etaient tout simplement ABSENTES DU HTML de ces pages — ce
n'etait donc ni un bug d'affichage, ni un souci de CSS ou de survol.

Les 8 pages touchees sont exactement les pages de la rubrique elle-meme :
   apropos.html, notre-histoire.html, nos-valeurs.html, nos-engagements.html
   en/about-us.html, en/our-story.html, en/our-values.html, en/our-commitments.html
Autrement dit, le visiteur perdait la navigation entre ces pages au moment
precis ou il en avait besoin : une fois entre dans la rubrique, il ne
pouvait plus passer d'une page A propos a une autre par le menu.

LA CORRECTION
-------------
Les trois liens ont ete reinseres a l'identique du bloc de reference
(index.html pour le FR, en/index.html pour l'EN), au bon endroit dans
l'ordre : A propos / Notre Histoire / Nos Valeurs / Nos Engagements /
Evenements.

CONTROLE
--------
Comptage sur les 105 pages du site : la colonne contient desormais 5 liens
partout, sans exception (elle en comptait 5 sur 97 pages et 2 sur 8).
Test de survol reel en 1440 px sur les 8 pages corrigees plus les deux
pages de reference : les 5 liens sont presents ET visibles a l'ecran, et
chacune des 5 destinations repond correctement.
Test mobile en 390 px : menu burger ouvert puis colonne depliee,
5 liens sur 5 visibles.
0 erreur JavaScript.


=========================================================================
AJOUT — LA BARRE DE MENU NE BOUGE PLUS AU CHARGEMENT
=========================================================================
Ce zip REMPLACE tous les precedents.

REPONSE A LA QUESTION : NON, CE N'EST PAS NORMAL. ET C'EST CORRIGE.
--------------------------------------------------------------------

CE QUE J'AI MESURE (releve image par image, avant correction)
   produits.html    le menu glisse de 39,4 px
   services.html    19,7 px
   en/index.html     6,0 px
   apropos.html      0 px
Le glissement se fait en trois paliers etales sur environ 700 ms, ce qui
le rend bien visible a l'oeil.

LA CAUSE EXACTE
---------------
Le coupable est le petit selecteur FR|EN. Sa largeur passe de 49,2 px a
88,6 px pendant le chargement, et le menu s'elargit exactement d'autant.
Pourquoi : TOUTES les regles qui le dimensionnent (.nav-lang et
.nav-lang a : padding, bordure, police, arrondi) sont declarees dans des
blocs <style> situes APRES </head>. Le navigateur peint donc d'abord un
selecteur nu et trop etroit, puis le corrige quand il rencontre ces blocs
plus bas dans la page.
Et comme la regle .nav-links a porte transition:.25s sans preciser de
propriete — donc sur TOUTES les proprietes — cette correction de mise en
page est ANIMEE au lieu d'etre instantanee. D'ou le mouvement.

A SAVOIR : ce probleme avait deja ete diagnostique et corrige le 19/08 en
deplacant les blocs <style> dans le <head>. Ce correctif n'est PAS present
sur le site en ligne : j'y ai compte 447 blocs <style> apres </head> sur
104 pages. Il a donc ete perdu lors d'un depot ulterieur.

LA CORRECTION
-------------
Un bloc <style id="mx-nav-stable-27-08"> ajoute DANS LE <head> des 105
pages. Il fait deux choses :
  1. il donne au selecteur FR|EN sa geometrie definitive des le premier
     rendu (memes valeurs que celles declarees plus bas, simplement
     connues plus tot)
  2. il limite l'animation de .nav-links a et .nav-lang a a la seule
     couleur : une correction de mise en page ne peut plus etre animee

Je n'ai PAS deplace les 447 blocs <style> vers le <head>. C'etait l'autre
solution, mais elle touche a l'ordre de cascade de tout le site pour un
gain identique. La correction ci-dessus traite la cause mesuree en un seul
bloc reversible.

CONTROLE
--------
Releve image par image sur les 105 pages du site : amplitude de deplacement
du menu = 0,0 px partout, en position comme en largeur (elle allait
jusqu'a 39,4 px avant).
Verifie que rien n'a ete casse au passage :
   survol d'un lien de menu   -> la couleur change toujours (gris -> blanc),
                                 la position et la largeur ne bougent pas
   survol du selecteur EN     -> le fond s'eclaircit toujours
   soulignement du lien actif -> toujours present (99,4 px)
   mega-menu au survol        -> s'ouvre toujours
105 pages reouvertes : 1 h1 chacune, canonical present, 0 debordement,
0 erreur JavaScript.


=========================================================================
CORRECTION COMPLETE DU MOUVEMENT DE L'EN-TETE
=========================================================================
Ce zip REMPLACE tous les precedents.

MON PREMIER CORRECTIF NE TRAITAIT QU'UNE PARTIE DU PROBLEME
------------------------------------------------------------
Ma mesure precedente demarrait au DOMContentLoaded, c'est-a-dire APRES que
tout le CSS de la page ait ete lu. Elle ne pouvait donc pas voir ce qui se
passe pendant le tout premier rendu. En reprenant le releve des la premiere
image affichee, deux autres causes sont apparues.

CAUSE 2 — LA LARGEUR DU CONTENEUR (le gros du mouvement)
--------------------------------------------------------
La variable --maxw vaut 1240px dans le <head>, puis elle est redefinie a
1440px dans un bloc <style> du corps de page. Mesure sur produits.html :
   a 191 ms : l'en-tete fait 1240 px, centre  (logo a x=124, menu a x=340)
   a 229 ms : il fait 1425 px, pleine largeur (logo a x=24,  menu a x=425)
Le logo se decalait de 100 px et le menu de 85 px, d'un coup.
CORRECTION : la valeur finale de --maxw est desormais declaree dans le
<head>. Elle est calculee PAGE PAR PAGE a partir de ce que chaque fichier
declare reellement, et non imposee uniformement : 3 pages (devis.html,
index-autonome.html, traitement-surface_1.html) n'avaient pas ce saut et
n'ont pas ete touchees, pour ne pas modifier leur mise en page.

CAUSE 3 — LA BARRE DE DEFILEMENT
---------------------------------
Une fois la cause 2 reglee, il restait exactement 15,0 px de decalage sur
15 pages. C'est la largeur de la barre de defilement : sur les pages dont
le contenu s'allonge apres coup (onglets du catalogue, carrousels), la
barre apparait en cours de chargement et retrecit la zone visible de 15 px,
ce qui deplace tout le contenu centre, en-tete compris.
CORRECTION : sa place est desormais reservee d'emblee, via
scrollbar-gutter:stable, avec repli overflow-y:scroll pour les navigateurs
qui ne connaissent pas cette propriete.

RESULTAT MESURE
---------------
Releve image par image, des le PREMIER rendu, sur les 105 pages :
   deplacement du menu, du logo et du conteneur = 0,0 px partout.
Avant correction, produits.html cumulait 85 px (conteneur) + 39 px
(selecteur FR|EN) + 15 px (barre de defilement).

VERIFICATIONS DE NON-REGRESSION
-------------------------------
   survol d'un lien de menu   -> couleur toujours animee, geometrie stable
   survol du selecteur EN     -> fond toujours anime
   soulignement du lien actif -> present (99,4 px)
   mega-menu                  -> s'ouvre toujours au survol
   6 pages x 6 largeurs (1920 a 390) : aucun debordement horizontal,
   conteneur jamais plus large que la zone visible
   105 pages reouvertes : 1 h1, canonical present, 0 erreur JavaScript


=========================================================================
VERIFICATION DU DECALAGE AU CLIC — MESURE COMPARATIVE
=========================================================================
Ce zip REMPLACE tous les precedents.

J'ai reproduit exactement votre geste : partir de l'accueil, aller sur
« Nos produits », et relever la position de la barre de menu image par
image, sur les DEUX versions en parallele.

   SITE EN LIGNE (votre zip)  la barre part de x=399,6 et finit a x=425,2
                              AMPLITUDE 65 px, largeur 916 -> 976 px
   CE ZIP                     x=425,2 du debut a la fin
                              AMPLITUDE 0,0 px, largeur 976 px constante

Le decalage que vous voyez est donc bien reel, et il est corrige dans ce
zip — mais UNIQUEMENT une fois les fichiers deposes sur le serveur. Tant
que produits.html en ligne reste l'ancien, le probleme persistera a
l'ecran, quels que soient les zips livres.

POUR TESTER RAPIDEMENT SANS TOUT DEPOSER
-----------------------------------------
Le correctif est entierement contenu dans l'en-tete de chaque page. Vous
pouvez donc deposer le SEUL fichier produits.html de ce zip et rafraichir
la page : le decalage doit disparaitre immediatement. Si c'est concluant,
deposez le reste.
Pensez a vider le cache du navigateur (Ctrl+F5) : une ancienne version
gardee en cache donnerait l'impression que rien n'a change.

CONTROLE COMPLEMENTAIRE — COHERENCE ENTRE LES PAGES
---------------------------------------------------
J'ai aussi verifie que la barre ne saute pas d'une page a l'autre : les
51 pages francaises ont TOUTES exactement la meme position de menu
(x=425,2, largeur 975,8) et les 51 pages anglaises aussi (x=570,2,
largeur 830,8 — l'ecart entre les deux langues est normal, les libelles
anglais sont plus courts). Aucune page francaise ne se distingue des
autres.

DETAIL TECHNIQUE CORRIGE AU PASSAGE
------------------------------------
Le commentaire que j'avais ecrit dans le bloc de correction contenait le
texte litteral d'une balise de fin de <head>. Sans effet sur l'affichage,
mais c'est un piege pour tout outil qui chercherait cette balise par
simple recherche de texte — y compris mes propres scripts, qui s'y sont
laisses prendre lors de la verification. Le texte a ete reformule sur les
105 pages. Chaque page contient desormais exactement une balise de fin de
head, et les trois correctifs y sont bien tous les trois.


=========================================================================
AJOUT — ANIMATION 3D DU GLOBE (28/08)
=========================================================================
Ce zip REMPLACE tous les precedents.

OU ELLE EST POSEE
-----------------
index.html et contact.html avaient deja une section « carte du monde »
(id="international") avec une mappemonde SVG plate et des arcs animes.
La video du globe remplace exactement ce SVG. Tout le reste de la section
est conserve : titre, sous-titre, et les 4 chiffres cles (30 pays livres,
5 continents, depuis 1989, 100% Made in France).
Le petit repere « Villette-d'Anthon » qui etait pose sur l'ancienne carte
de contact.html est masque : l'etiquette est deja incrustee dans la video.

POIDS DE LA VIDEO : 11,7 Mo -> 768 Ko
--------------------------------------
Telle quelle, la video aurait ajoute 11,7 Mo au chargement de deux pages
tres visitees. Elle est reencodee en 1440 px de large, CRF 24.
J'ai compare un agrandissement de l'original et des versions compressees :
a CRF 24 le resultat est indiscernable de l'original. Une version plus
legere encore (360 Ko) etait possible, mais le texte incruste commencait
a se degrader.
Un poster est genere depuis une image de la video (28 Ko) : le bon visuel
s'affiche avant meme le demarrage de la lecture, et sert aussi de repli
si la video ne charge pas.

FICHIERS A DEPOSER EN PLUS DES HTML
------------------------------------
   videos/globe-monde.mp4              768 Ko  -> /videos/
   images/globe-monde-poster.webp       28 Ko  -> /images/
Mode BINAIRE dans FileZilla.
Comme pour la video du hero, un second <source> pointe vers la racine du
site : vous pouvez y deposer une copie du .mp4 en filet de securite.

LES PAGES ANGLAISES N'ONT PAS ETE TOUCHEES — VOLONTAIREMENT
------------------------------------------------------------
La video porte deux textes incrustes en FRANCAIS : « Fabricant d'energie
positive » et « NOUS LIVRONS DANS LE MONDE ENTIER ». La poser telle quelle
sur en/index.html et en/contact.html afficherait du francais a un visiteur
anglophone. Ces deux pages conservent donc leur carte SVG actuelle.
Envoyez-moi une version anglaise du fichier (comme vous l'aviez fait pour
baie-avantages-hero-en.mp4) et je la branche en deux minutes.

INCIDENT PENDANT LE TRAVAIL — CE QUI A FAILLI PARTIR
-----------------------------------------------------
Mon premier essai utilisait une expression de recherche pour retirer
l'ancien repere de carte. Elle a trouve une correspondance ailleurs dans
la page et a supprime, sur l'accueil, les 4 chiffres cles ainsi qu'une
balise de fermeture, laissant la page mal formee.
Detecte en comparant le nombre de balises avant et apres. J'ai tout repris
depuis la version saine, en bornant strictement l'operation au seul bloc
de la carte. Les compteurs sont desormais identiques avant/apres sur les
deux pages : KPI 11->11 et 7->7, </button> 16->16 et 15->15,
</div> 170->170 et 76->76, </section> 8->8 et 2->2.

CONTROLE
--------
Accueil et contact, en 1440 px et 390 px : video presente et dimensionnee
(1320x743 sur l'accueil, 1180x665 sur contact, 327x185 sur mobile),
plus aucun SVG de carte, repere bien masque, 4 chiffres cles toujours la,
0 debordement, 0 erreur JavaScript.
Les 105 pages du site reouvertes : aucune anomalie, et l'en-tete ne bouge
toujours pas d'un pixel.
NOTE : le navigateur de test n'embarque pas le decodeur H.264, je n'ai donc
pas pu voir la video tourner ici — comme pour celle du hero. Structure,
chemins et cadrage sont verifies ; un coup d'oeil apres depot reste utile.


=========================================================================
AJOUT — BAIE MODULAIRE : PHOTO A LA PLACE DE LA VIDEO (28/08)
=========================================================================
Ce zip REMPLACE tous les precedents.

CE QUE J'AI TROUVE EN OUVRANT LA PAGE
--------------------------------------
La video n'etait pas un fichier appele par la page : elle etait ENCODEE EN
BASE64 DIRECTEMENT DANS LE HTML. Resultat, baie.html pesait 3,18 Mo, dont
3,05 Mo pour cette seule video, plus une image d'attente egalement en base64.
Meme chose sur en/modular-cabinet.html.
C'est le pire cas de figure pour le chargement : ce poids ne peut etre ni mis
en cache separement, ni charge en differe, ni compresse par le serveur aussi
bien qu'un vrai fichier. Il devait etre retelecharge a chaque visite, avant
meme que le texte de la page s'affiche.

RESULTAT
--------
   baie.html                 3,18 Mo  ->  0,13 Mo   (-96 %)
   en/modular-cabinet.html   3,19 Mo  ->  0,13 Mo   (-96 %)
La photo utilisee est images/hero-scene-baie.webp, deja presente sur votre
serveur : 25 Ko. Aucun fichier image a deposer.

POURQUOI CETTE PHOTO
--------------------
La page contient deja 8 photos de baie (baie-accueil, scenebaie, triplebaie,
baiechatgpt, baielinkedin, et les 3 gabarits 25U/34U/43U). hero-scene-baie
est la seule vue large de la baie en salle technique qui n'y figurait pas
encore : pas de doublon dans la page, et un format 16/9 identique a celui de
la video remplacee.
Si vous preferez une autre photo, dites-le : c'est une ligne a changer.

UN PIEGE RENCONTRE
------------------
Une regle preexistante, .bfeat-photo img{max-height:560px;width:auto},
visait l'ancienne image detouree de ce bloc. Appliquee a la nouvelle
banniere, elle lui imposait 560 px de haut a TOUTES les largeurs : correct
sur grand ecran par hasard, mais deforme sur mobile (327 x 560 au lieu de
327 x 184). Un petit bloc <style id="mx-baie-photo-28-08"> rend au visuel le
comportement exact qu'avait la video.

CONTROLE
--------
1440 px et 390 px, FR et EN : format 16/9 respecte partout (1040x585 et
327x184), photo bien chargee, plus aucune balise <video> ni aucune donnee
base64 dans les deux pages, les 6 cartes d'avantages intactes, 0 erreur JS,
0 debordement.
Les 105 pages du site reouvertes : aucune anomalie, en-tete toujours stable.

A DEPOSER
---------
baie.html et en/modular-cabinet.html (plus les autres fichiers du lot).


=========================================================================
AJOUT — LA VIDEO DES AVANTAGES DESCEND SUR LA PAGE (28/08)
=========================================================================
Ce zip REMPLACE tous les precedents.

CE QUI A CHANGE SUR baie.html ET en/modular-cabinet.html
---------------------------------------------------------
   HAUT DE PAGE  ("La baie en detail")
       garde la photo hero-scene-baie.webp mise en place plus tot,
       suivie des 6 cartes d'avantages : rien ne bouge.

   5e SECTION sur 11  (ancien id="galerie")
       "En images / La baie modulaire en images" -> SUPPRIMEE
       remplacee par la VIDEO DES AVANTAGES, sous le titre
       FR : "En video / Les avantages de la baie en mouvement"
       EN : "In video / The cabinet's advantages in motion"

LA VIDEO N'EST PLUS EN BASE64
------------------------------
Elle pointe maintenant vers videos/baie-avantages.mp4, DEJA PRESENT sur
votre serveur (2,2 Mo). J'ai verifie que c'est bien la meme sequence que
celle qui etait encodee dans le HTML : l'ecart entre sa premiere image et
images/baie-poster.jpg est de 4 %, soit la seule difference de compression.
Consequence : les deux pages restent a 129 Ko au lieu des 3,18 Mo de depart,
et la video est desormais mise en cache par le navigateur, chargee seulement
quand le visiteur descend jusqu'a elle (preload="none").
AUCUN nouveau fichier video ou image a deposer.

CE QUE LA SUPPRESSION DU CARROUSEL A EMPORTE
---------------------------------------------
Le module supprime etait un carrousel de 6 photos (baie-accueil, baie,
baiechatgpt, scenebaie, triplebaie, baielinkedin) avec fleches et pastilles.
Ces 6 fichiers restent sur votre serveur, simplement plus utilises par cette
page. Si vous voulez recuperer la galerie ailleurs, tout est encore la.
Le JavaScript du carrousel commence par "if(!track) return;" : il se
desactive tout seul en l'absence du bloc. Rien a nettoyer, aucune erreur.

UN PIEGE, LE MEME QUE LA VEILLE
--------------------------------
Ma regle de format ne visait que les images (img.bfeat-video). Appliquee a
une balise <video>, elle ne mordait pas : la video s'affichait en 1040 x 1080
au lieu de 1040 x 585, et en 327 x 1080 sur mobile. La regle vise desormais
les deux types de visuels.

CONTROLE
--------
1440 px et 390 px, FR et EN : les deux visuels de la page sont au format
16/9 exact (1040x585 et 327x184), la video est bien en 5e section sur 11,
le carrousel a disparu du DOM, 0 erreur JS, 0 debordement.
videos/baie-avantages.mp4 et images/baie-poster.jpg repondent en HTTP 200.
Les 105 pages du site reouvertes : aucune anomalie, en-tete toujours stable.

NOTE, COMME POUR LES AUTRES VIDEOS
-----------------------------------
Le navigateur de test n'embarque pas le decodeur H.264 : j'ai valide la
structure, les chemins, le cadrage et l'image d'attente, pas la lecture
elle-meme. Un coup d'oeil apres depot reste utile.
Le second <source> pointe vers la racine du site et renvoie donc un 404 dans
mes tests : c'est le filet de securite prevu si le dossier videos/ n'etait
pas monte. Sur un navigateur qui lit le H.264, la premiere source repond et
la seconde n'est jamais demandee.


=========================================================================
AJOUT — PHOTO DU MXP DANS LE CATALOGUE PRODUITS (28/08)
=========================================================================
Ce zip REMPLACE tous les precedents.

CE QUE MONTRAIT LE PANNEAU MXP AVANT
-------------------------------------
Le visuel du panneau MXP de produits.html etait une balise <video> pointant
vers QUATRE fichiers qui n'existent sur votre serveur : videos/mxp.mp4,
video/mxp.mp4, videos/mxp-avantages.mp4, video/mxp-avantages.mp4.
Le mecanisme de repli faisait donc son travail et affichait l'image de
secours... qui etait images/microlab-mx-12v50a.svg, c'est-a-dire un DESSIN
DU MICROLAB. Vos visiteurs voyaient un autre produit sous le titre MXP.

CE QUI A ETE FAIT
-----------------
La <video> est supprimee et l'image de repli pointe desormais sur
images/mxp.webp, la vraie photo du produit (face avant rack, ecran de
pilotage MicrolaX, 1019 x 826), DEJA PRESENTE sur votre serveur.
Aucun fichier a deposer en plus des HTML.
Le texte alternatif decrit le produit au lieu du simple sigle "MXP", et
width/height sont poses sur la balise pour eviter tout saut de mise en page.
Idem sur en/products.html, avec un alt en anglais.

POURQUOI L'IMAGE APPARAIT SANS TOUCHER AU CSS
----------------------------------------------
Le masquage du repli est ecrit .spot-visual.video-on .spot-fallback{display:none}
La classe video-on n'est posee par le JavaScript que lorsqu'une video se
charge reellement. Plus de video, donc plus de classe, donc la photo
s'affiche : aucune regle de style n'a eu besoin d'etre ajoutee.

CONTROLE
--------
1440 px et 390 px, FR et EN : panneau MXP ouvert, plus aucune balise <video>
dedans, la photo est chargee et visible (413x500 sur grand ecran, 273x221 sur
mobile). Elle n'est pas deformee : la regle .spot-visual img porte
object-fit:contain, l'image est donc inscrite dans son cadre en conservant
ses proportions. 0 requete 404, 0 erreur JS, 0 debordement.
Les 105 pages du site reouvertes : aucune anomalie, en-tete toujours stable.

A SAVOIR POUR LA SUITE
-----------------------
Les autres panneaux du catalogue utilisent le meme mecanisme et appellent eux
aussi des videos absentes (microswitch.mp4, baie.mp4, powerswitch.mp4...).
Ils affichent donc leur image de repli. Contrairement au MXP, la plupart ont
un repli correct — mais si vous voulez que je verifie panneau par panneau
qu'aucun autre ne montre le mauvais produit, dites-le moi.


=========================================================================
AJOUT — VIGNETTE MXP DANS LA BARRE DE GAUCHE (28/08)
=========================================================================
Ce zip REMPLACE tous les precedents.

CE QUI CLOCHAIT
---------------
Dans la colonne de gauche de produits.html, 5 produits sur 6 portaient une
VIGNETTE du produit (Microswitch, Powerswitch, Baie modulaire, Microlab,
PowerRack). Le MXP, lui, n'avait qu'un PICTOGRAMME au trait, comme les
entrees de service (Selecteur, Autres, Pieces detachees). Il ne ressemblait
donc pas aux autres produits de la liste.

CE QUI A ETE FAIT
-----------------
La carte MXP passe au meme balisage que les cinq autres :
   avant : <span class="fam-ico"><svg .../></span>
   apres : <span class="fam-ico illu"><img src="images/mxp.webp" ...></span>
C'est exactement la structure de la carte Microlab, reprise telle quelle.
Aucun CSS ajoute : la classe "illu" existait deja et gere le cadre, le fond,
la bordure et le object-fit:contain.
Idem sur en/products.html avec le chemin ../images/.
Aucun fichier a deposer en plus des HTML : mxp.webp est deja sur le serveur.

CONTROLE
--------
1440 px et 390 px, FR et EN : la vignette MXP mesure 56 x 48 px, soit
EXACTEMENT la meme taille que les cinq autres vignettes de la barre (verifie
par comparaison automatique des 6 cadres). Image chargee, 0 requete 404,
0 erreur JS, 0 debordement.
La colonne compte desormais 6 vignettes illustrees sur 9 cartes : les 3
restantes (Selecteur de puissance, Autres, Pieces detachees) gardent leur
pictogramme, ce qui est coherent puisqu'elles ne designent pas un produit.
Les 105 pages du site reouvertes : aucune anomalie, en-tete toujours stable.
