Aller au contenu
Kalivins
Menu

Toutes les démonstrations

Démonstration2026

Back-office de menuiserie

Publier un chantier depuis un téléphone, sur un chantier, en 4G médiocre : un écran, trois champs, des photos réduites dans le navigateur avant de partir. À côté, un espace client pour corriger, réordonner les photos et changer les textes du site. Deux conteneurs, une commande, aucun abonnement.

Technologies
Next.js · TypeScript · Payload · PostgreSQL · Docker
Démontre
Web sur mesure

Ouvrir la démonstrationLes identifiants sont affichés sur la page de connexion. Vous pouvez tout modifier : les données sont fictives et remises à zéro toutes les heures.

Lire le code source

Capture de Back-office de menuiserie

Pourquoi une menuiserie

J’ai toujours été fasciné par le talent des artisans. Je suis un nerd, je ne suis clairement pas assez habile pour produire quoi que ce soit en menuiserie, ça ne m’empêche pas d’admirer.

Ce que j’ai vu abandonner

Une entreprise qui vend du merch pour le tourisme régional. C’était impossible pour eux de rentrer les t-shirts correctement, à cause des variations qui ne rentraient pas, puis souvent une erreur 500.

Ils m’ont appelé. J’ai réglé le problème en une journée, quand ça devrait être réglé en une demi-journée maximum. J’ai aussi fait un clean directement dans le core WordPress : du code malicieux s’était injecté dedans et déclenchait des popups pour ceux qui n’avaient pas de protection contre.

Le problème

Cette démonstration part de là. Une menuiserie de dix personnes livre quatre ou cinq chantiers par mois. Chacun est photographié, et rien n’en sort : les photos restent sur un téléphone. Le site, refait il y a des années par un prestataire injoignable depuis, affiche encore trois réalisations de l’époque.

Le gérant demanderait un devis pour « ajouter des photos ». Sa vraie demande est ailleurs : pouvoir le faire sans redemander à personne.

Il aurait entendu parler de WordPress par ses compères, qui lui auraient dit qu’avec ça il pourrait éditer ses images lui-même. C’est en lui expliquant que le sur-mesure vaut mieux dans son cas, et lui évite des complications plus tard, qu’il choisirait l’offre avec back-office.

Son ancien site n’est alors pas récupéré. Il est remplacé, et c’est l’offre complète à 5 500 € qui s’applique. Garder l’existant lui coûterait davantage : greffer un back-office sur du code écrit par quelqu’un d’autre demande de recâbler chaque gabarit, et de reprendre la responsabilité d’un ensemble qu’on n’a pas construit. Sur un site de cet âge, le devis de reprise dépasse l’offre complète. Ça se dit au devis, avec les deux calculs côte à côte.

Ce qui change au quotidien

Le chantier est publié depuis le chantier, pendant que l’équipe range le matériel. La photo est en ligne avant que le gérant ait repris la route, à un moment où l’objection la plus fréquente en rendez-vous reste justement l’absence de réalisations récentes.

Publier prend trois champs et un bouton : un titre, une commune, deux lignes. Cinq photos au maximum. Aucun menu à apprendre.

Le reste vit à côté, dans un espace de quatre écrans que le gérant ouvre rarement : corriger un chantier publié, remonter une photo dans l’ordre, changer un numéro de téléphone, retirer un chantier parce qu’un client a demandé à ne pas apparaître.

Deux conteneurs, 553 Mo, une commande. Rien ne sort de la machine : aucune police distante, aucune mesure d’audience, aucun service tiers, et la base ne publie même pas de port.

Comment ça marche

Personne dans l’entreprise ne travaille sur un ordinateur. Les photos partent du téléphone du chef d’atelier, entre deux poses, depuis un chantier où la 4G plafonne à quelques centaines de kilo-octets par seconde.

Or une photo d’appareil récent pèse 4 à 8 Mo. Cinq d’entre elles font 30 Mo, soit une douzaine de minutes d’envoi pendant lesquelles il ne faut ni verrouiller l’écran ni changer d’application. Personne ne fait ça deux fois.

Un back-office ordinaire aurait donc été utilisé une fois puis abandonné, et l’abandon aurait eu cette cause précise, mesurable, sans aucun rapport avec l’ergonomie de ses menus. Trois décisions découlent de ce seul chiffre.

Les photos sont réduites sur le téléphone, avant de partir. Mesuré sur une photo de 4000 × 3000 pixels : 1 Mo réduit à 197 ko. Le chiffre s’affiche sous chaque vignette. Un chiffre visible rassure quelqu’un qui a déjà attendu dix minutes sur un formulaire. Compresser côté serveur n’aurait rien changé : le trajet coûteux est celui du téléphone au serveur.

Chaque photo part dès qu’elle est choisie, avant même le bouton « Publier ». Quand le gérant finit d’écrire ses deux lignes, elles sont déjà en ligne, et publier n’envoie plus qu’un formulaire de trois champs. L’attente a lieu pendant qu’il écrit.

Une par une, jamais en parallèle. Cinq envois simultanés se partagent une bande passante déjà maigre et se bloquent tous au milieu. Chaque vignette porte son état, donc un échec se règle en une touche au lieu d’immobiliser l’ensemble. La saisie est conservée sur le téléphone, appel entrant compris.

Dans l’espace client, un champ de texte vidé reprend le texte écrit à la livraison. C’est une annulation. Une panne de base rend alors un site complet au lieu de pages blanches, et l’écran affiche le texte d’origine sous chaque champ vide, sans quoi personne ne devine la mécanique.

Ses limites, écrites dans le dépôt

Aucun texte alternatif n’est saisi. Il se compose à l’affichage, à partir du titre et de la commune. Réclamer cinq descriptions d’images à quelqu’un qui pose une fenêtre ferait passer le formulaire de trois champs à huit, et c’est la pente par laquelle un outil devient trop long pour qu’on l’ouvre. Un lecteur d’écran apprend donc de quel chantier il s’agit, sans savoir ce que la photo montre.

Aucune file d’attente hors réseau. La perte de connexion est signalée, la saisie conservée, et la reprise reste manuelle, photo par photo.

Le back-office technique reste installé derrière l’espace client, et il n’a pas la même politesse : sa structure est celle d’un outil de données, avec ses collections et ses filtres. Il a été francisé, habillé et pourvu de vignettes, ce qui règle huit défauts sur huit relevés à l’ouverture. Ce qu’un habillage ne corrige pas, c’est le vocabulaire. C’est la raison d’être de l’espace client.

Une photo envoyée puis retirée du formulaire reste sur le disque. Purger coûterait une heure. Ce n’est pas fait.

Les photos du jeu d’exemple viennent de Wikimedia Commons, sous licence libre, créditées une par une dans le dépôt. Recadrées et étalonnées d’une seule main, elles se lisent comme une série, ce qui les sauve sans les rendre bonnes. Sur une vraie livraison, les photographies viennent du client ou d’un photographe. C’est le poste qui décide si un site vend.

Sous le capot

Cette section s’adresse au développeur qui vous accompagne, s’il y en a un. Vous pouvez la sauter.

Next et Payload dans le même processus, PostgreSQL, sharp pour les images, le tout en deux conteneurs derrière Caddy. Trois pages sont régénérées en quelques millisecondes après chaque publication, sans reconstruction ni redémarrage.

Une faille est apparue en écrivant la section sécurité du dépôt, et elle contredisait le guide remis au client. Masquer un chantier n’était écrit que dans la requête des pages publiques : le site obéissait, l’API ne savait rien, et GET /api/chantiers/4 rendait le chantier masqué en entier à un inconnu. Or la raison pour laquelle on masque, c’est justement un client qui a demandé à ne pas apparaître. La règle est passée dans le contrôle d’accès de la collection, où elle vaut pour tout ce qui interrogera la base un jour.

Le reste des corrections est venu du conteneur, jamais de la machine de développement. Payload ne crée pas ses tables en production : son adaptateur PostgreSQL ne les aligne qu’en développement, et l’image démarrait donc sur une base sans aucune table. Quatre pièges de ce genre sont documentés dans le dépôt, avec ce qu’ils ont appris.

Un arbitrage entier a fini par tomber. La première version refusait les polices auto-hébergées et la matière, au nom de la 4G de chantier. Cet argument vaut pour l’écran de publication, manipulé debout dehors. Il ne vaut pas pour le site public, consulté au calme par quelqu’un qui s’apprête à confier plusieurs milliers d’euros à un inconnu, et sur cet écran-là un site quelconque ne coûte pas des millisecondes : il coûte le rendez-vous. La contrainte avait été appliquée au mauvais écran. Les deux racines de mise en page rendent aujourd’hui la séparation littérale, l’écran de publication ne pouvant pas atteindre la feuille de style de l’autre. Coût de l’inversion, mesuré : six mégaoctets d’image.

Une dernière chose, sur ce texte lui-même. Écrit avant le projet, il annonçait « le site se reconstruit tout seul après chaque publication ». Une vraie reconstruction statique prend 30 à 60 secondes et redémarre un conteneur : le temps qu’elle finisse, le gérant a rangé son matériel et repris la route sans rien voir. Ce qui a été livré est meilleur. Ça ne se dit pas avec le même mot.

L’essayer

Ouvrez la démonstration, le compte est écrit en clair sur la page de connexion. Publiez un chantier depuis votre propre téléphone, en choisissant parmi les photos déjà en ligne, et regardez le site changer sur un autre écran.

C’est la question que pose vraiment cette offre : est-ce que je saurai le mettre à jour moi-même.

L’envoi de photos est fermé sur cette démonstration, et la compression décrite plus haut n’y est donc pas observable. Les identifiants sont publics : n’importe qui pourrait déposer une image illégale sur un domaine qui porte mon nom. Le refus vit dans les droits d’écriture de la base et non dans un bouton grisé, ce qui le rend valable aussi contre un appel direct à l’API. Chez un client, l’envoi fonctionne.

Captures

  • Les réalisations, alimentées depuis le back-office
    Les réalisations, alimentées depuis le back-office
  • Le back-office : ce que le client voit pour publier
    Le back-office : ce que le client voit pour publier
  • Publier depuis un téléphone, sur le chantier
    Publier depuis un téléphone, sur le chantier