23/08/2026

Un site qui entre par un fichier .zip

Entre une maquette finie et un site qu'un client peut administrer, il y a un fossé dont on parle rarement. Le dessin existe. Le CMS existe. Et quelqu'un, au milieu, passe deux jours à recopier l'un dans l'autre.

Ce quelqu'un, c'était nous. Section par section, couleur par couleur, police par police. Avec le taux d'erreur qu'on imagine, et la conviction croissante que ce travail n'aurait jamais dû exister.

Un format, plutôt qu'une conversation

La réponse tient dans une idée simple : cesser de demander « une maquette », et demander un kit structuré. Une archive, avec dedans quatre choses nommées.

  • L'identité, sous forme de jetons : les couleurs, les polices, la taille de base, les rayons. Pas une capture d'écran d'une palette — des valeurs qu'une machine lit.
  • Le socle global : la feuille de style qui vaut pour tout le site.
  • Les sections, numérotées, rangées par page. Une section est une unité qu'on peut déplacer, dupliquer, régler. Une page entière ne l'est pas.
  • Les assets : images, polices libres, tout ce que les pages référencent.

La console reçoit l'archive et fait le reste. On téléverse, on lit le rapport, on choisit ce qu'on garde, on importe.

Le rapport se lit avant, pas après

Le rapport est la partie que nous avons le plus travaillée, et c'est aussi celle qui ressemble le moins à une fonctionnalité.

Il dit ce qui a été trouvé : combien de pages, combien de sections, quelles polices, quels assets. Il dit les écarts de forme — une section qui ne respecte pas la convention de nommage, une image référencée qui n'est pas dans l'archive. Et il dit les avertissements, section par section.

Puis il attend. Rien n'est écrit tant qu'on n'a pas choisi.

Un import est une opération qui écrit beaucoup de choses d'un coup dans un endroit où quelqu'un a peut-être travaillé. Le rendre rapide est facile ; le rendre rassurant demande de le rendre lisible avant d'être exécuté. Un bouton « Importer » qui part immédiatement est un bouton qu'on n'ose plus cliquer au bout de la deuxième mauvaise surprise.

Tout arrive en brouillon. Sans exception.

C'est la règle la plus importante de tout ce chantier, et elle mérite d'être dite seule.

Un kit importé ne publie rien. Les sections deviennent des blocs en brouillon, l'entête et le pied deviennent les brouillons des compositions système, la feuille et le script s'ajoutent aux réglages existants au lieu de prendre leur place. Un chemin de page déjà occupé n'est jamais écrasé.

La raison est arithmétique. Un import réussi fait gagner deux jours. Un import qui écrase une page publiée en fait perdre bien davantage — et la perte n'est pas symétrique, parce qu'un brouillon qu'on jette se rejette d'un clic, quand une page publiée qui disparaît emporte avec elle tout ce que le client avait relu, corrigé et validé.

Quand une opération peut détruire, elle doit demander. Quand elle peut détruire beaucoup, elle doit écrire d'abord ce qu'elle va détruire, et attendre.

L'identité, l'entête et le pied — la moitié qu'on avait oubliée

La première version de l'import posait les pages. Elle ne posait ni l'identité, ni l'entête, ni le pied. Le résultat était troublant : les bonnes sections, aux mauvaises couleurs, sous l'ancien menu.

Trois cases s'y ajoutent. L'identité du kit se fond dans le thème du site — seuls les jetons trouvés bougent, le reste est laissé tel quel. Le texte posé sur la couleur d'accent est calculé pour rester lisible plutôt que choisi à l'œil : c'est une décision que la machine prend mieux que nous, et qui rate silencieusement quand personne ne la prend.

L'entête et le pied du kit deviennent les brouillons des compositions système. Et les polices que le kit chargeait à sa manière remontent en tête de la feuille du site, à l'endroit où un navigateur les attend.

Un détail nous a coûté une mise en ligne : dans une maquette, les liens du menu pointent vers des fichiers — ../../04_Page/tarifs.html. Recopiés tels quels, ils donnent un menu qui affiche des adresses en .html sur un site qui n'en a aucune. Ils sont désormais réécrits vers les vraies pages, y compris les formes relatives à deux niveaux. Personne ne pense à ce genre de chose avant de l'avoir vu en production.

Le gabarit voyage enfin avec la bibliothèque

Dernier maillon, et le plus discret. Nos sites clients dérivent d'un gabarit commun, mis à jour depuis la console par un bouton « Mettre à jour la bibliothèque ». Ce bouton poussait les blocs. Il ne poussait pas le gabarit.

Conséquence : les transitions entre pages, le script global, l'écran de chargement, le widget de relecture — toutes choses livrées, testées, annoncées — restaient lettre morte sur les sites en ligne. Elles fonctionnaient chez nous et nulle part ailleurs.

Les fichiers du gabarit rejoignent la liste, et ils y vont ensemble. Un envoi partiel serait pire que rien : ces fichiers se lisent les uns les autres, et il suffit qu'un seul manque pour que chaque page du site cesse de se rendre.

Ce qu'on en retient

Nous cherchions à gagner deux jours par site. Nous les avons gagnés, mais ce n'est pas ce que le chantier a appris de plus utile.

Il a appris qu'un format vaut mieux qu'une conversation : demander « un kit » plutôt que « une maquette » déplace la discussion une fois pour toutes, et rend la reprise mécanique au lieu d'interprétative. Et il a appris qu'une opération puissante se juge à ce qu'elle refuse de faire toute seule — pas à ce qu'elle sait faire vite.

UN PROJET DE SITE ?

Décrivez votre besoin, nous revenons vers vous avec une proposition claire.

PIKS-L

Chargement en cours