Une application web qui s'installe comme un logiciel classique
Déployer une application Laravel chez un client technique est déjà une affaire de configuration. Mais la livrer à une TPE qui n'a jamais entendu parler de PHP, de Composer ou d'un serveur web ? C'est souvent là que les projets se compliquent, ou que l'on se résigne à des solutions lourdes comme XAMPP.
C'est exactement ce problème qu'a voulu résoudre le développeur derrière WinRavel, un outil open source présenté récemment sur dev.to. Le concept : prendre un projet Laravel, appuyer sur « Build », et obtenir un unique fichier .exe que n'importe quel utilisateur Windows peut lancer en double-cliquant.
Pas d'installation PHP. Pas de configuration Apache. Pas de composer install à expliquer. Juste un exécutable.
Ce qu'il y a sous le capot
L'approche de WinRavel repose sur trois composants assemblés de façon ingénieuse.
FrankenPHP comme serveur embarqué
FrankenPHP est un serveur d'application PHP moderne, basé sur Caddy, qui intègre PHP directement dans son binaire. Il n'a pas besoin d'un serveur web externe et peut servir une application Laravel de manière autonome. C'est lui qui fait tourner l'application une fois l'exécutable lancé.
WinRavel embarque FrankenPHP (avec PHP 8.5) directement dans le stub C# précompilé. Au premier lancement, le .exe s'extrait dans %APPDATA%\<NomApp>, puis FrankenPHP prend le relais pour servir l'application sur 127.0.0.1.
SQLite ou MariaDB selon les besoins
Pour les applications simples, SQLite est la valeur par défaut — pas de processus supplémentaire, tout est dans un fichier. Pour les projets qui requièrent un vrai moteur MySQL (procédures stockées, comportements spécifiques), WinRavel peut embarquer un serveur MariaDB optimisé.
L'astuce technique ici est notable : plutôt que d'embarquer MariaDB dans son intégralité (ce qui représenterait plusieurs centaines de Mo), WinRavel n'inclut que les fichiers strictement nécessaires à l'exécution, en supprimant les outils clients et les composants inutiles en mode embarqué.
Un stub auto-extractible sans recompilation
L'une des décisions d'architecture les plus élégantes : le launcher C# est précompilé une fois pour toutes. Pour packager un nouveau projet Laravel, WinRavel ne recompile rien — il se contente d'accoler au stub existant une archive contenant l'application ([app.zip][config][footer]). Le stub lit lui-même les octets de fin de son propre exécutable au démarrage.
Résultat : les builds sont quasi instantanés, et la machine de build n'a pas besoin du SDK .NET installé.
Un Windows Job Object est également utilisé pour lier les processus PHP (et MariaDB) au launcher parent, évitant ainsi les processus orphelins si la fenêtre est fermée brutalement.
Pourquoi cette approche est pertinente pour les TPE/PME
On pourrait croire que les logiciels desktop ont perdu la bataille face aux SaaS. Dans bien des contextes métier — grandes entreprises connectées, équipes distribuées — c'est vrai. Mais il existe tout un segment d'usages pour lesquels le « tout cloud » reste une contrainte plutôt qu'un avantage :
- Contraintes réseau : ateliers, entrepôts, cabinets sans connexion fiable.
- Données sensibles : certaines PME refusent (à juste titre) d'envoyer leurs données vers des serveurs tiers.
- Coûts d'hébergement : pour un outil interne utilisé par 3 personnes, payer un hébergement mensuel n'a pas toujours de sens.
- Simplicité d'installation : un fichier
.exe que l'on copie sur un poste, c'est un argument opérationnel fort face à un guide de déploiement de 20 étapes.
Dans ces cas, une application Laravel packagée en .exe local n'est pas un bidouillage — c'est une réponse architecturale cohérente.
Limites et points de vigilance
L'outil est prometteur, mais il faut garder en tête quelques réalités avant de l'adopter en production.
Ce n'est pas du natif. L'application tourne dans un serveur web local et s'affiche dans un navigateur. Pour certains utilisateurs, l'expérience est légèrement différente d'un vrai logiciel Windows (pas d'icône dans la barre des tâches, ouverture du navigateur, etc.).
Les mises à jour ne sont pas automatiques. Distribuer un .exe implique de gérer soi-même la mise à jour chez les clients. Ce n'est pas insurmontable, mais c'est un aspect à anticiper dans la conception du projet.
La surface d'attaque change. Un serveur web qui tourne en local sur un poste Windows, ce sont des considérations de sécurité différentes d'un hébergement classique. Les ports exposés, les permissions fichiers et la gestion des mises à jour de FrankenPHP/MariaDB méritent attention.
L'obfuscation du code source est optionnelle mais imparfaite. WinRavel propose une option pour obfusquer le dossier app/, mais l'obfuscation PHP ne garantit pas une protection robuste contre un utilisateur déterminé.
Conclusion : Laravel reprend pied là où on ne l'attendait plus
WinRavel illustre une tendance de fond : les outils du web moderne — frameworks matures, serveurs embarquables, bases de données légères — ont atteint un niveau de robustesse qui leur permet de couvrir des usages autrefois réservés aux applications desktop natives.
FrankenPHP joue ici un rôle clé. Sa capacité à fonctionner comme un binaire autonome le rend particulièrement adapté à ce type de distribution. On peut imaginer des déclinaisons similaires pour d'autres frameworks PHP, voire pour Symfony dans des contextes d'outils internes.
Pour les agences et développeurs qui travaillent avec des TPE/PME, cette approche ouvre une case intéressante dans la palette des solutions : ni SaaS, ni développement natif coûteux, mais une application web packagée, installable, et maîtrisée.
📎 Article source : WinRavel sur dev.to
