Estimateur de soumission Laravel
Un outil de tarification en libre-service sur ce site bilingue : sept questions, un prix réel à l'écran, sans appel de vente et sans attendre une soumission.
Un acheteur qui ne décrochera pas le téléphone veut quand même un prix. La réponse habituelle est un formulaire et la promesse de le rappeler, ce qui retient ceux qui magasinaient et perd ceux qui étaient prêts. Ce site se chiffre donc lui-même : sept questions, un vrai montant à l'écran, aucun appel. Le risque qui vient avec est évident. Un outil de prix que personne ne vérifie affichera un mauvais chiffre avec aplomb, et continuera de l'afficher.
L'outil est un questionnaire en sept étapes qui chiffre en direct à mesure des réponses, doublé d'un configurateur pour le sur-mesure, chiffré séparément. Une estimation soumise est conservée avec les réponses qui l'ont produite, de sorte qu'un rappel part des chiffres de l'acheteur et non de rien, et un panneau d'administration authentifié couvre ce qui a été capturé. Tout est bilingue, y compris chaque chiffre engendré. La limitation de débit s'applique par appelant avec un plafond par IP, et le point d'analyse d'URL porte sa propre protection SSRF avec son propre test.
Ce que nous avons mesuré
Ce qui tient l'ensemble honnête, c'est une barrière exécutée avant déploiement. Elle parcourt 19 pages à 6 largeurs d'écran dans les deux langues et vérifie 26 compteurs, en recoupant chaque chiffre entre le calculateur JavaScript, un portage Python du même modèle et les fixtures PHPUnit. Elle sort en erreur si un seul compteur bouge. À côté : 34 tests fonctionnels et 675 assertions. La barrière a déjà attrapé un renommage CSS qui cassait ses propres sélecteurs, soit la bonne sorte d'échec : un vérificateur qui remarque qu'il ne voit plus rien.
À quoi ça tient
Elle a aussi attrapé deux défauts qu'un visiteur aurait rencontrés. L'estimation en direct et l'estimation finale partageaient un même budget de limitation, si bien qu'un usage ordinaire produisait 41 appels et un 429 en 39 secondes, avec 73 pour cent des charges utiles identiques à l'octet. Séparément, le résumé des résultats préférait un cache qui n'expirait jamais, donc l'écran se figeait : le serveur renvoyait 720,50 CAD par mois pendant que la page affichait encore 136,50, en silence, sans erreur nulle part. Les deux sont tombés sur un seul correctif : empreinter les réponses pour qu'un résultat ne s'affiche que s'il a été calculé à partir de ce qui est à l'écran. Après : 11 appels au lieu de 41, aucun 429 sur 25 allers-retours, et le résumé conforme au modèle de prix au cent près.
Le mode de panne d'un outil de prix en libre-service n'est pas le plantage. C'est un mauvais chiffre affiché avec assurance que personne ne signale, parce que le visiteur le prend pour le prix et s'en va.
PORTÉE ET LIMITES
La barrière prouve que les trois implémentations s'accordent entre elles, et qu'aucun chiffre n'a bougé sans que quelqu'un l'ait décidé. Elle ne prouve pas que le modèle de prix est commercialement juste : c'est une question d'affaires, qu'aucun test ne tranche. Les décomptes décrivent la barrière telle qu'elle est aujourd'hui et grandissent avec le site.
TECHNOLOGIES
- Laravel 13 · PHP 8.3+ · Vite · SQLite · PHPUnit · Playwright
- PHP 8.3+
- Vite
- SQLite
- PHPUnit
- Playwright