PHP sur le bureau : maîtriser BosonPHP pour des applications natives ultra-performantes

Schéma d

Pendant plus de vingt ans, PHP a régné en maître absolu sur le backend web. Son modèle d’exécution était immuable : une requête HTTP entre, un processus naît, génère une réponse, puis meurt. Mais cette époque est révolue. L’introduction et la maturation de l’extension FFI (Foreign Function Interface) ont ouvert une brèche dans laquelle s’engouffrent de nouvelles architectures.

Aujourd’hui, le projet BosonPHP s’impose comme la nouvelle frontière de l’écosystème. Il ne s’agit pas d’un simple serveur web localisé, mais d’un véritable runtime open-source (sous licence MIT) conçu pour exécuter du code PHP sous forme d’application de bureau native. Fini le poids excessif de Chromium et de Node.js propres à l’écosystème Electron. Place à une exécution directe, ultra-légère et redoutablement rapide.

BosonPHP 0.19.5 : anatomie d’un noyau pour le bureau

Le slogan officiel du projet sur GitHub résume parfaitement sa philosophie : “Because it’s not an Electron!” (Parce que ce n’est pas un Electron !).

L’approche traditionnelle pour créer des applications de bureau avec des technologies web consiste à embarquer un navigateur complet dans chaque application. Le résultat ? Une application basique consomme souvent plus de 200 Mo de RAM au repos et pèse lourd sur le disque dur.

BosonPHP prend le contre-pied total. En sa version actuelle 0.19.5, le système s’appuie sur des liaisons de haut niveau (high-level bindings) vers Saucer v6.0, une bibliothèque C++ ultra-légère dédiée à la création de fenêtres WebView intelligentes. BosonPHP enveloppe votre code dans le moteur WebView natif fourni par le système d’exploitation (Edge WebView2 sur Windows, WebKit sur macOS et Linux). L’application finale compilée ne pèse que quelques dizaines de mégaoctets.

Le choix stratégique de PHP 8.4

Vous vous demandez peut-être si BosonPHP utilise déjà PHP 8.5, dont on commence à entendre parler. La réponse est non. À l’heure actuelle, le cœur du réacteur reste fermement ancré sur PHP 8.4 (comme le confirme le tag technique php84 de leur dépôt officiel).

Pourquoi s’en tenir à la version 8.4 ? Parce que la création d’interfaces natives via FFI requiert une manipulation complexe de pointeurs mémoires en langage C. La version 8.4 de PHP offre une stabilité extrêmement bien documentée concernant le ramasse-miettes (Garbage Collector) asynchrone et les structures typées, des éléments vitaux pour éviter les fuites de mémoire dans un processus de longue durée (long-running process). Le passage à une version mineure supérieure nécessiterait de revalider la fiabilité de tous les ponts mémoires sous-jacents.

L’architecture “Zero HTTP Overhead” et les frameworks Bridges

La véritable révolution de BosonPHP réside dans l’absence de réseau. Dans les anciennes tentatives de portage de PHP sur le bureau, un micro-serveur web était lancé en arrière-plan, et l’interface communiquait avec lui via des requêtes TCP sur localhost.

Avec BosonPHP, l’interface graphique communique directement avec le processus PHP en mémoire. Les événements déclenchent directement des méthodes PHP. Mais alors, comment utiliser nos frameworks favoris si tout le concept de requête HTTP a disparu ?

Le système de Bridges

C’est ici que BosonPHP démontre sa puissance d’ingénierie. L’équipe a développé un écosystème de Bridges (ponts) qui émulent le comportement HTTP directement dans la mémoire RAM, sans jamais ouvrir un port réseau.

Le projet propose des composants officiels pour intégrer vos frameworks sans les modifier :

  • boson-php/laravel-provider et boson-php/laravel-http-bridge
  • boson-php/symfony-bundle et boson-php/symfony-http-bridge
  • boson-php/spiral-bridge
  • boson-php/psr-http-bridge (pour n’importe quel routeur compatible PSR-7)

Lorsque la vue WebView de votre application tente de charger une URL interne ou de soumettre un formulaire, le Bridge Boson intercepte l’appel, construit un objet de requête natif (par exemple une Illuminate\Http\Request pour Laravel) et l’injecte dans le framework en mémoire. La réponse est générée et renvoyée à la WebView instantanément.

Développer avec BosonPHP : cas pratique

La structure logicielle de BosonPHP est fortement modulaire. Pour ajouter des fonctionnalités natives, vous installez des extensions spécifiques via Composer.

Prenons l’exemple d’une application qui surveille l’état du réseau et de la batterie. Nous allons utiliser les composants boson-php/webview-ext-battery et boson-php/app-ext-alert.

<?php

use Boson\App;
use Boson\Window;
use Boson\Extensions\Alert\AlertExtension;
use Boson\Extensions\Battery\BatteryExtension;

class SystemMonitor
{
  private App $app;
  private Window $window;

  public function __construct()
  {
    $this->app = new App();
    
    // We register native extensions into the Kernel
    $this->app->register(new AlertExtension());
    $this->app->register(new BatteryExtension());
  }

  public function boot(): void
  {
    $this->window = new Window(
      title: 'Boson System Monitor',
      width: 800,
      height: 600
    );

    $this->window->on('ready', function (Window $win)
    {
      $this->checkBatteryStatus($win);
    });

    $this->app->run();
  }

  private function checkBatteryStatus(Window $win): void
  {
    // Calling the native Battery API via FFI bindings
    $battery = $win->native->getBatteryInfo();
    
    if ($battery->percent < 20 &amp;&amp; !$battery->isCharging)
    {
      // Calling native OS message box without HTML/JS
      $win->native->alert(
        title: 'Warning',
        message: 'Battery level is critically low.'
      );
    }

    // Pushing data to the WebView DOM
    $win->executeJS('updateBatteryUI(' . $battery->percent . ');');
  }
}

$monitor = new SystemMonitor();
$monitor->boot();

Dans ce code, nous constatons la puissance de l’API. L’extension app-ext-alert ne crée pas une fausse boîte de dialogue en HTML (div en position absolue). Elle appelle la véritable API MessageBox de l’OS sous Windows ou l’API NSAlert sous macOS via les liaisons FFI.

La gestion critique de la mémoire en contexte de bureau

C’est le point de friction majeur pour un développeur backend transitionnant vers BosonPHP. En PHP classique (PHP-FPM), le nettoyage de la mémoire n’est pas votre préoccupation principale, car le processus meurt à la fin de la requête.

Dans BosonPHP, votre application peut rester ouverte en arrière-plan pendant des semaines. Les règles de développement changent :

  1. Bannir l’état global infini : Les tableaux stockés dans $GLOBALS ou les propriétés statiques de classes qui s’accumulent au fil du temps provoqueront une fuite de mémoire fatale.
  2. Maîtriser les Weak References (Références faibles) : Boson fournit le composant boson-php/weak-types pour gérer les données. Une référence faible permet d’associer des métadonnées à un objet sans empêcher le Garbage Collector de le détruire s’il n’est plus utilisé ailleurs.
  3. Forcer le nettoyage cyclique : Dans des applications complexes, il est souvent judicieux de lier la fonction gc_collect_cycles() à un minuteur (timer) interne ou au changement d’état de l’application (comme la réduction de la fenêtre dans la barre des tâches).

Le workflow : de l’écriture à la compilation

Le projet excelle par la fluidité de son processus de déploiement. L’expérience développeur (DX) est conçue pour être aussi simple que possible.

Vous initialisez votre projet avec :

composer create-project boson-php/app my-app

Pendant le développement, vous testez l’application en lançant simplement :

php index.php

Une fois le développement terminé, le composant boson-php/compiler entre en action. Il s’occupe de consolider votre code source, les assets front-end, et le moteur PHP interne au sein d’un exécutable unique et autonome.

php vendor/bin/boson compile

L’exécutable généré contient tout le nécessaire. L’utilisateur final n’a absolument pas besoin d’installer PHP sur sa machine. C’est du plug-and-play total.

Conclusion

BosonPHP n’est plus une simple expérimentation. Avec une architecture stable basée sur PHP 8.4, l’intégration de Saucer v6.0, et le support robuste des frameworks via des ponts asynchrones natifs, la version 0.19.5 offre un outillage industriel de haute volée.

Capitaliser sur BosonPHP, c’est utiliser vos connaissances techniques actuelles pour déployer des logiciels ultra-légers et performants sur n’importe quel système d’exploitation de bureau. Le langage éléphant n’est plus seulement le roi du serveur, il a désormais sa place sur vos bureaux.


Frequently Asked Questions

Peut-on utiliser une base de données locale avec une application BosonPHP ? Oui. La technologie recommandée pour le bureau est SQLite. L'extension PDO_SQLITE native de PHP s'intègre parfaitement car elle ne requiert pas de démon ou de service externe. Les opérations de lecture et d'écriture se font directement sur un fichier local au sein de l'espace de stockage de l'application.
Est-ce que BosonPHP supporte le code asynchrone ou le multithreading ? PHP est fondamentalement mono-threadé. Cependant, l'architecture d'événements de Boson utilise la boucle événementielle interne de l'OS. Pour des tâches asynchrones complexes (comme des appels réseau lourds sans geler l'interface utilisateur), vous pouvez utiliser les Fibers (Fibres) natives de PHP 8.1+ ou recourir à des bibliothèques de traitement en arrière-plan compatibles.
Les applications BosonPHP sont-elles sécurisées contre l'injection de code ? Comme le code PHP est exécuté localement et empaqueté dans un binaire, le risque d'injection serveur (Remote Code Execution) disparaît. En revanche, le risque de failles XSS côté client (WebView) demeure. Il est impératif de nettoyer (sanitize) toutes les données envoyées vers la méthode executeJS() pour éviter qu'un utilisateur n'injecte des scripts malveillants dans l'interface de l'application.
Puis-je manipuler les fichiers du système hôte ? Oui, l'application possède les mêmes droits de lecture et d'écriture que l'utilisateur du système d'exploitation l'ayant lancée. Contrairement au navigateur classique (qui est placé en bac à sable ou "sandbox"), BosonPHP permet de manipuler librement des répertoires entiers avec les fonctions natives comme file_put_contents() ou scandir().
Lionel Péramo
Lionel Péramo
Expert Performance Web & Écoconception

Développeur full stack et créateur du framework OTRA (PHP) et de la librairie EcoComposer. J'écris pour rendre le web plus rapide et inclusif.

En savoir plus →