## Le fichier avait changé, pas toute sa signification
Le 14 août, j’ai remplacé public/jules.png sur mon portfolio. L’ancienne photo a laissé place à un portrait de studio, recadré en 784 × 784 pixels.
Le changement paraît minuscule. Un fichier écrasé, un build, un déploiement. Pourtant, la photo ne vivait pas seule dans le projet. Le composant PhotoCard contenait encore une description liée à l’ancienne version : elle précisait que j’étais en montagne.
Après le remplacement, cette information était devenue fausse.
C’est le problème concret de ce chantier : je pouvais avoir la bonne image à l’écran tout en gardant une ancienne version de son contenu dans le code.
## Garder le même emplacement
Je n’ai pas créé une nouvelle route ni ajouté une couche de gestion de médias. J’ai conservé public/jules.png et remplacé directement le fichier.
Pour cette image, je préfère que le composant dépende d’un emplacement stable plutôt que d’un nom décrivant une version précise. Le rôle du fichier reste le même : afficher mon portrait. Seul son contenu évolue.
Next.js permet de référencer les fichiers placés dans public depuis la racine du site. C’est le fonctionnement documenté dans la page officielle sur les images locales avec Next.js. Je n’avais donc aucune raison de transformer ce remplacement en migration technique.
Le recadrage carré suit la même logique. La photo doit entrer dans un composant existant. Je ne voulais pas adapter toute la carte autour des proportions du nouveau fichier. J’ai préparé un asset de 784 × 784 pixels qui respecte déjà la forme attendue.
Le fichier s’adapte au produit, pas l’inverse.
## Le texte alternatif faisait partie du changement
Ce qui a coincé se trouvait dans PhotoCard.
Le texte alternatif ne décrivait pas seulement ma présence sur l’image. Il embarquait aussi son contexte. Tant que l’ancienne photo était affichée, la mention de la montagne avait un sens. Avec le portrait de studio, elle devenait un reste de la version précédente.
J’ai donc retiré cette mention dans le même commit.
Ce n’est pas une légende visible sous la photo. Il aurait été facile de remplacer l’image, de regarder rapidement la page et de considérer le travail terminé. Mais l’attribut alt sert de remplacement textuel lorsque l’image n’est pas perçue ou ne peut pas être affichée. La documentation du composant Image de Next.js précise qu’il doit pouvoir remplacer l’image sans changer le sens de la page.
Le W3C rappelle aussi que la description dépend du contexte : pour une photographie informative, le texte doit transmettre ce qu’elle apporte réellement à la page.
Dans mon cas, conserver « en montagne » ne rendait pas la description plus détaillée. Cela la rendait simplement incorrecte.
## Une modification visuelle est aussi une modification de contenu
Je sépare facilement les deux quand je code. D’un côté, les assets dans public. De l’autre, les chaînes écrites dans les composants. Pourtant, ils représentent ici le même contenu.
La photo dit à quoi je ressemble. Son texte alternatif doit rester cohérent avec elle. Si je ne modifie qu’un côté, le portfolio possède deux versions différentes de la même information.
Ce chantier m’a surtout rappelé qu’un asset n’est pas toujours un fichier isolé. Il peut avoir des dépendances moins visibles :
- un texte alternatif ;
- des dimensions attendues par le composant ;
- un cadrage pensé pour l’emplacement où il apparaît.
Je n’ai pas ajouté de système pour automatiser ça. Ce serait trop pour une seule photo. J’ai simplement traité le fichier, son format et sa description comme une même modification.
Maintenant, le portfolio affiche le portrait carré attendu et PhotoCard ne raconte plus le décor d’une image qui n’existe plus. Le fichier reste public/jules.png. Si je le remplace encore, l’image et son texte alternatif devront apparaître dans la même revue de diff.
Image de couverture générée par IA — faute d'illustration officielle disponible pour ce sujet.